为什么企业要自研中间件：基于技术演进、企业规模与组织治理的研究

摘要

中间件是连接分布式系统中应用、组件与数据资源的关键基础设施，其作用已从早期的事务处理与异构互联，演化为支撑事件流、服务治理、配置管理、多租户控制、跨地域复制与平台化交付的核心能力层。本文围绕“企业为什么要自研中间件”这一问题，采用规范性研究与案例归纳相结合的方法，系统分析开源中间件、基于开源的二次开发以及完全自研三种技术路径的适用边界，并进一步讨论中小企业、大型企业与超大型跨国企业在中间件决策上的差异。研究表明：对于绝大多数企业，合理路径应为“开源优先、二开其次、自研兜底”；只有当主流产品的核心假设已无法满足企业在业务语义、可靠性目标、规模边界、合规治理与全球部署方面的关键要求时，自研中间件才具有充分正当性。同时，基础架构部门的价值不在于垄断技术决策，而在于通过平台工程将共性复杂度产品化，并借助 Inverse Conway Maneuver、Golden Path 与 Policy as Code 等方法，避免组织边界固化为软件架构边界。(IBM)

关键词

中间件；自研中间件；二次开发；开源选型；平台工程；Conway’s Law；基础架构

引言

IBM 将中间件界定为一种使分布式网络中的应用或组件之间实现通信或连接的软件，本质上是将原本未被设计为直接互联的系统以“software glue”的方式绑定起来。这一定义说明，中间件并非单一产品，而是一类承担连接、抽象、治理与集成职责的软件基础设施。随着企业系统从单体应用向分布式、微服务、云原生和全球化部署演进，中间件已从“连接层工具”上升为决定系统规模上限、治理复杂度和研发效率的重要基础平台。(IBM)

今天关于中间件的争论，已经不再是“需不需要用消息队列、注册中心、配置中心”这种初级问题，而是“企业在什么条件下应采用成熟开源中间件、在什么条件下应围绕其进行二次开发、又在什么条件下必须完全自研”。这个问题之所以重要，是因为中间件一旦决策失误，后果往往不是一次性成本超支，而是数年的版本升级困难、兼容性债务、稳定性负担和组织摩擦。Kafka 官方强调其已被数千家公司采用，且超过 80% 的 Fortune 100 企业在使用；RabbitMQ 强调其是可靠且成熟的消息与流代理；Pulsar 强调多租户与跨地域复制；NATS 强调轻量与高性能。这意味着对大量企业而言，市场上已经存在相当成熟的公共供给，自研从来不是默认正确答案。(Kafka)

因此，本文的核心目标不是为“自研中间件”做情绪化辩护，而是建立一个更严格的判断框架：

厘清中间件的发展历程及其与企业能力建设之间的关系；
界定开源、二开、自研三种路径的适用边界；
从企业规模与组织治理角度，解释基础架构部门为何存在，以及怎样避免“组织架构决定软件架构”的失真。(IBM)

研究问题与研究方法

本文试图回答四个研究问题：

中间件为何在企业技术体系中逐步上升为基础性能力；
企业在开源、二开、自研三种路径之间应如何判断边界；
不同规模企业为何会得出不同的中间件决策；
基础架构部门应如何通过平台化而非组织权力来塑造合理的软件架构。(IBM)

在方法上，本文采用规范性研究与案例归纳结合的方式：

以 IBM、OMG、Eclipse、ASF、CNCF、AWS、Google Cloud 及相关项目官方文档为主要材料，对中间件定义、技术演进、项目成熟度与组织治理理论进行归纳；
以 Kafka、RabbitMQ、NATS、Pulsar、RocketMQ、Dubbo、Nacos、Sentinel 为代表性样本，比较不同产品在定位、扩展性、多租户、复制、高可用与治理上的差异；
以企业规模和组织复杂度为横轴，构建一个“问题属性—能力成熟度—治理需求—自研必要性”的分析框架。

该方法的优点是来源权威、逻辑清晰，缺点是偏规范分析而非实证统计。(Kafka)

中间件的发展历程与问题提出

从历史上看，中间件最初并不服务于今天熟悉的“微服务治理”，而是服务于事务处理。IBM 官方资料显示，CICS 在 1968 年推出，最初承担的是高价值在线事务处理环境的支撑角色。这一时期的核心问题不是“服务发现”或“事件流”，而是如何在有限资源、严格事务要求和复杂业务流程中保证执行的可靠性与连续性。(IBM)

随着异构系统增多，中间件逐步进入分布式互操作阶段。OMG 对 CORBA 的说明表明，这一代中间件所解决的核心问题，是让不同语言、平台和网络中的应用能够通过统一机制协同工作。也就是说，中间件从事务处理器逐步变成异构系统之间的“翻译层”和“协议层”。(omg.org)

再往后，企业级平台标准化成为主流。Jakarta EE 的历史回顾显示，企业 Java 从 1999 年开始形成更完整的平台标准，将事务、消息、容器、连接器和 Web 能力逐步纳入统一体系。这一阶段说明，中间件开始不只是“连接应用”，而是直接承担企业级开发范式和基础能力供给。(newsroom.eclipse.org)

进入云原生与事件驱动时代后，中间件再次发生质变。Kafka 官方将自身定义为分布式事件流平台；RabbitMQ 将自己定义为可靠且成熟的消息与流代理；Pulsar 将多租户与 Geo-Replication 作为核心能力；NATS 强调单二进制、轻量和高性能。这一阶段中间件已不再是辅助层，而是直接决定数据流组织方式、系统解耦能力、租户隔离方式与全球容灾策略的底座。也正因为如此，“企业是否应自研中间件”成为一个必须严肃回答的问题。(Kafka)

开源、二开与自研的三路径分析

什么情况下应该用开源中间件

当企业面临的是行业共性问题，而不是企业独有的核心差异化问题时，开源中间件应当是默认选项。消息传递、事件流、服务发现、配置管理、流控熔断、多租户管理，这些都早已不是未经验证的新问题。Kafka、RabbitMQ、Pulsar、NATS、Dubbo、Nacos、Sentinel 已分别在各自方向形成清晰定位。尤其 Kafka 官方直接给出了其被数千家公司使用、覆盖超过 80% Fortune 100 企业的事实，这已经足以说明：在大量通用问题上，市场供给是成熟的。(Kafka)

此外，开源更适合那些需要明确生命周期与支持路径的企业场景。RabbitMQ 官方维护发布与支持时间线；PostgreSQL 官方明确 major version 大约每年一版，且每个 major version 支持 5 年；ASF 和 CNCF 的治理资料则说明，成熟项目并非“代码仓库”而已，而是带有长期治理与生产成熟度背书的公共基础设施。这种情况下，企业最理性的做法不是追求“自己掌控一切”，而是优先利用已经存在的高质量社会化供给。(RabbitMQ)

更关键的是，很多企业其实根本没有持续维护中间件内核的能力。会搭建、会调优、会接入，和能承担多年协议演进、兼容升级、漏洞修复、生态支持、值班治理，是完全不同的能力层级。没有内核维护团队、没有长期 SRE 体系、没有可靠灰度升级能力的企业，盲目谈自研，通常不是技术自信，而是技术判断失真。(PostgreSQL)

什么情况下应该基于中间件进行二次开发

二次开发最合理的前提是：底层开源产品已经覆盖了大部分核心能力，但企业仍需要补齐安全、租户、审计、控制台、自助交付、统一 SDK、权限模型和治理策略等“管理平面能力”。此时，正确做法是围绕扩展点、插件机制与外围控制平面做增强，而不是动不动重写数据平面内核。Dubbo 官方明确提出其采用 Microkernel + Plugin 设计，功能通过扩展点实现，用户可以用自定义扩展替换既有实现；Dubbo 的 SPI、协议、注册中心、负载均衡等都可以替换。这类架构天生就鼓励企业“二开而不是重写”。(Apache Dubbo)

Nacos 官方文档更直接。其认证文档明确提醒：Nacos 是内部微服务组件，应运行在可信内网，其认证实现是弱认证，不是防恶意攻击的强认证；如果运行在不可信环境或有更强认证诉求，需要基于官方简单实现做增强。这类官方表述实际上已经把“二开适用场景”说透了：很多企业所谓的“自研诉求”，本质上并不是注册中心或配置中心内核不行，而是它们缺少企业级安全与治理能力。面对这种问题，正确答案是插件化增强、网关前置、审计补强、租户隔离和平台封装，而不是再写一个新的 Nacos。(Nacos 官网)

因此，只要问题主要集中在接入一致性、合规审计、组织治理、自助化交付和开发体验上，企业就应优先选择二开路线。因为这类问题的本质是平台工程问题，而不是复制协议、消息存储或一致性内核问题。(Google Cloud)

什么情况下应该完全自研中间件

只有当主流产品的核心假设与企业关键诉求发生系统性冲突时，自研才具有真正的工程正当性。RocketMQ 官方“Why choose RocketMQ”就是标准案例：ActiveMQ 在队列和 virtual topic 增长后出现 IO 瓶颈，而 Kafka 在当时又不能满足低延迟与高可靠业务消息要求，因此才决定开发新的消息引擎。这个案例的关键不在于“做了一个自己的 MQ”，而在于“已有产品方向本身不满足目标问题”。(RocketMQ)

同样，超大型企业在全球多区域部署、强合规、强租户隔离、跨云治理和业务语义极其特殊的场景中，可能确实会碰到开源产品虽强但“方向略偏”的问题。Pulsar 将多租户与 Geo-Replication 作为核心特性，Kafka 也提供多租户与跨集群数据镜像，RabbitMQ 则提供基于 Raft 的 quorum queues 和 federation；这说明成熟开源已经覆盖了大量复杂诉求。也正因如此，如果企业在这些能力之上仍然无法满足自身要求，自研才可能成立。否则，大多数所谓自研，实际上只是重复造轮子。(pulsar.apache.org)

我的判断非常明确：**“不舒服”不是自研理由，“现有产品的核心设计无法支撑关键业务目标”才是。**前者适合二开，后者才轮到自研。很多企业把这两者混为一谈，最后不是做出一个落后于开源社区数年的内核，就是背上一套维护不动的技术债。

中间件选型的分析框架

真正成熟的中间件选型，不应该从产品名开始，而应该从问题类型开始。Kafka 是事件流平台，RabbitMQ 是消息与流代理，Pulsar 强调多租户与跨地域，NATS 是轻量高性能消息系统，Dubbo 是服务通信与治理框架，Nacos 是配置与服务发现，Sentinel 是流量防护与熔断体系。把这些性质不同的技术放进一个“谁更好”的横向比较，本身就是错题。(Kafka)

因此，本文提出一个四层决策模型：

问题属性：到底是消息、事件流、服务治理、配置管理还是流量保护。
非功能约束：吞吐、延迟、顺序性、持久化、重放、隔离、跨地域、恢复时间目标。
组织能力：是否具备平台化运维、版本升级、故障治理和长期维护能力。
研发路径选择：能否直接使用开源，是否需要二开，是否必须自研。(Kafka)

基于此，可以形成如下判断逻辑：如果问题是通用问题、非功能约束可由成熟产品满足、组织具备运营而不具备内核研发能力，则选择开源；如果问题的核心差距在安全、租户、控制台、自助化和审计，则选择二开；如果现有产品的复制协议、事务语义、存储模型或全球治理方式均无法满足要求，且企业具备长期内核维护能力，才进入自研。这个模型的价值，在于它能把“技术冲动”压回到“边界判断”。(RocketMQ)

不同规模企业的中间件决策差异

对于中小企业而言，自研中间件通常不是一个理性选项。它们的核心约束往往不是技术极限，而是人力、现金流、上线速度与运维承载能力。既然 Kafka、RabbitMQ、NATS、Pulsar 等已经成熟，且很多项目具备清晰支持路径，那么中小企业更应把资源投入业务创新，而不是试图在底座层做行业重复建设。(Kafka)

大型企业的情况不同。它们通常不是“没得用”，而是“用了很多但不统一”，于是租户模型、权限模型、审计能力、规范落地、自助式交付和跨团队治理成为主要矛盾。这类企业最优路径通常是“开源内核 + 平台化封装 + 有边界的二开”。说得更直接一点，大型企业真正该自研的往往不是 broker 本身，而是围绕 broker 构建的统一接入层、治理层和运营层。(Apache Dubbo)

超大型跨国企业则可能进入局部自研阶段。因为这类企业面对的不只是高并发，而是多区域监管、数据主权、全球容灾、超大规模租户隔离、多云控制与复杂组织边界等问题。Pulsar、Kafka、RabbitMQ 已提供不少全球化能力，但某些企业仍可能需要在全球控制平面、策略平面和租户治理上做深度定制。即便如此，我仍不赞成“全栈自研”。真正理性的做法是：能借用成熟数据平面的尽量借用，把自研集中到企业特有的控制与治理层。(Kafka)

基础架构部门的意义与组织—架构关系

基础架构部门存在的真正意义，不是替企业“统一技术思想”，更不是通过审批权强行规定所有团队必须怎么做，而是把共性复杂度抽象成平台产品，降低业务研发的认知负担。Google Cloud 将平台工程定义为设计和维护内部开发者平台，用 Golden Paths 装备工程团队；CNCF 平台白皮书则强调平台应服务企业价值流而非自我存在；AWS 也把内部开发者平台视为帮助开发者自助管理环境、部署、资源和配置的内部产品。把这三者放在一起看，结论非常清楚：基础架构团队首先应该是产品团队，其次才是技术团队。(Google Cloud)

之所以很多企业的基础架构团队最终沦为“阻塞器”，根源在于 Conway’s Law。Mel Conway 的经典表述指出，设计系统的组织，会产出反映其沟通结构的系统设计。AWS Well-Architected 进一步明确提出，组织可以通过 Inverse Conway Maneuver，根据期望的软件架构和业务域目标来反向设计团队结构。如果企业先把组织永久切成“MQ 组、注册中心组、网关组、配置中心组”，再让业务系统围绕这些边界适配，那么架构最终就会变成组织分工的镜像。(melconway.com)

避免这一问题的关键，不是再开几轮架构评审会，而是改变交付方式：

应让平台团队提供 Golden Paths，而不是提供审批口径；
应把治理规则沉淀为 Policy as Code，而不是靠人工口头约束；
应让平台采用率、交付效率和开发者体验成为平台团队的核心指标，而不是“是否把大家管住”。

只有当基础架构从“统治者”变为“能力供给者”，它的存在才真正有价值。(Google Cloud)

讨论：一个更可执行的企业决策原则

基于前文分析，本文给出一个强判断：绝大多数企业不该把自研中间件当作战略目标，而应按照如下阶段推进能力建设：

把“高质量使用开源中间件”当作第一阶段能力；
把“围绕开源做平台化治理”当作第二阶段能力；
只有在第三阶段才谈得上“为特殊边界自研”。

这是因为中间件的核心价值不在于拥有代码，而在于拥有长期可持续的能力体系。(apache.org)

进一步说，企业如果连开源中间件的生命周期都管理不好，连升级节奏、灰度治理、观测体系和支持策略都做不到，就不应该高谈阔论“掌握核心中间件技术”。这种组织如果自研，通常只会把社区已经解决过十年的问题，再用更少的人、更差的生态和更高的风险重演一遍。这个判断听起来不客气，但它更接近工程现实。(RabbitMQ)

研究局限性

本文主要基于官方文档、项目资料与组织治理材料进行规范性分析，因此优点是来源权威、论证边界清晰，但局限在于缺少面向具体企业的一手访谈数据与量化统计结果。此外，不同企业所处行业、监管强度、技术债状况、全球化程度差异很大，文中的决策模型更适合作为分析框架，而非机械套用的结论模板。后续如果进一步结合企业案例访谈、成本模型与失败案例对照，研究说服力会更强。(tag-app-delivery.cncf.io)

结论

本文的核心结论可以概括为三点：

中间件的发展本质上是企业系统复杂度和组织复杂度不断上升后的必然产物，它从事务处理、异构互操作一路演进到今天的云原生事件流与平台化治理层。
企业在中间件决策上应遵循“开源优先、二开其次、自研兜底”的次序：通用问题用开源，治理问题做二开，只有在核心设计假设失配时才自研。
基础架构部门真正的价值不是决定所有团队必须用什么，而是通过平台工程、Golden Path、Policy as Code 和 Inverse Conway Maneuver，把共性复杂度产品化，并让组织设计服务于目标软件架构，而不是反过来。(IBM)

归根到底，自研中间件不是荣誉勋章，而是最后手段。企业真正该追求的，不是“我们有没有自己的 MQ/注册中心/配置中心”，而是“我们是否能以最低的长期总成本，获得足够稳定、足够可治理、足够可演进的基础能力”。在这个问题上，理性比情怀重要得多。(Kafka)

参考文献（按 GB/T 7714 体例整理）

1 IBM. What Is Middleware?[EB/OL]. IBM Think, 2026-04-23. (IBM)

2 IBM. History of CICS Transaction Server[EB/OL]. IBM Support, 2026-04-23. (IBM)

3 Object Management Group. Common Object Request Broker Architecture (CORBA)[EB/OL]. OMG, 2026-04-23. (omg.org)

4 Eclipse Foundation. A Developer’s Guide to Jakarta EE 11[EB/OL]. Eclipse Newsletter, 2026-04-23. (newsroom.eclipse.org)

5 Apache Kafka. Apache Kafka[EB/OL]. Apache Software Foundation, 2026-04-23. (Kafka)

6 Apache Kafka. Powered By Apache Kafka[EB/OL]. Apache Software Foundation, 2026-04-23. (Kafka)

7 RabbitMQ Team. RabbitMQ: One Broker to Queue Them All[EB/OL]. RabbitMQ, 2026-04-23. (RabbitMQ)

8 RabbitMQ Team. Release Information[EB/OL]. RabbitMQ, 2026-04-23. (RabbitMQ)

9 RabbitMQ Team. Quorum Queues[EB/OL]. RabbitMQ, 2026-04-23. (RabbitMQ)

10 RabbitMQ Team. Federation Plugin[EB/OL]. RabbitMQ, 2026-04-23. (RabbitMQ)

11 Synadia. What is NATS[EB/OL]. NATS Docs, 2026-04-23. (pulsar.apache.org)

12 Apache Pulsar. Features[EB/OL]. Apache Software Foundation, 2026-04-23. (pulsar.apache.org)

13 Apache Pulsar. Pulsar Overview[EB/OL]. Apache Software Foundation, 2026-04-23. (pulsar.apache.org)

14 Apache Pulsar. Geo Replication[EB/OL]. Apache Software Foundation, 2026-04-23. (pulsar.apache.org)

15 Apache Pulsar. Multi Tenancy[EB/OL]. Apache Software Foundation, 2026-04-23. (pulsar.apache.org)

16 Apache RocketMQ. Why Choose RocketMQ[EB/OL]. Apache Software Foundation, 2026-04-23. (RocketMQ)

17 Apache Dubbo. Framework Design[EB/OL]. Apache Software Foundation, 2026-04-23. (Apache Dubbo)

18 Apache Dubbo. Compatibility Test[EB/OL]. Apache Software Foundation, 2026-04-23. (Apache Dubbo)

19 Nacos Group. Authentication[EB/OL]. Nacos, 2026-04-23. (Nacos 官网)

20 Alibaba Sentinel. Introduction[EB/OL]. Sentinel, 2026-04-23. (sentinelguard.io)

21 Apache Software Foundation. How the ASF Works[EB/OL]. Apache Software Foundation, 2026-04-23. (apache.org)

22 Apache Software Foundation. A Primer on ASF Governance[EB/OL]. Apache Software Foundation, 2026-04-23. (apache.org)

23 Cloud Native Computing Foundation. Graduated and Incubating Projects[EB/OL]. CNCF, 2026-04-23. (CNCF)

24 Cloud Native Computing Foundation. Project Lifecycle and Process[EB/OL]. CNCF Contributors, 2026-04-23. (CNCF Contributors)

25 PostgreSQL Global Development Group. Versioning Policy[EB/OL]. PostgreSQL, 2026-04-23. (PostgreSQL)

26 Conway M E. Conway’s Law[EB/OL]. Mel Conway’s Home Page, 2026-04-23. (melconway.com)

27 AWS. Structure Teams Around Desired Business Outcomes[EB/OL]. AWS Well-Architected DevOps Guidance, 2026-04-23. (AWS 文档)

28 AWS. Adapting to Change[EB/OL]. AWS Prescriptive Guidance, 2026-04-23. (AWS 文档)

29 Google Cloud. What is Platform Engineering?[EB/OL]. Google Cloud, 2026-04-23. (Google Cloud)

30 Google Cloud. Golden Paths for Engineering Execution Consistency[EB/OL]. Google Cloud Blog, 2026-04-23. (Google Cloud)

31 Cloud Native Computing Foundation TAG App Delivery. CNCF Platforms White Paper[EB/OL]. CNCF, 2026-04-23. (tag-app-delivery.cncf.io)

32 Cloud Native Computing Foundation. Policy as Code (PaC)[EB/OL]. Cloud Native Glossary, 2026-04-23. (Cloud Native Glossary)

为什么企业要自研中间件：基于技术演进、企业规模与组织治理的研究 ​

摘要 ​

关键词 ​

引言 ​

相关研究 ​

研究问题与研究方法 ​

中间件的发展历程与问题提出 ​

开源、二开与自研的三路径分析 ​

什么情况下应该用开源中间件 ​

什么情况下应该基于中间件进行二次开发 ​

什么情况下应该完全自研中间件 ​

中间件选型的分析框架 ​

不同规模企业的中间件决策差异 ​

基础架构部门的意义与组织—架构关系 ​

讨论：一个更可执行的企业决策原则 ​

研究局限性 ​

结论 ​

参考文献（按 GB/T 7714 体例整理） ​