中间件行业25年演进：从国外垄断到云原生与国产化

1. 中间件行业演进的底层逻辑

1.1 中间件到底是什么：夹层里的大角色

做开发十多年，跟中间件打了无数次交道，但每次给刚入行的同事解释“中间件”，都会发现对方一脸茫然。其实一句话可以讲明白：中间件是跑在操作系统之上、应用软件之下的那一层基础软件，专门处理分布式系统里“多个程序怎么互相通信、怎么协调事务、怎么交换数据”这些脏活累活。你平时用的消息队列、缓存、API网关、注册中心、配置中心，本质上都是中间件的子类。

我习惯拿“同声传译”打比方。两个讲不同语言的人开会，中间必须有个翻译才能顺畅对话；放到系统里，两个服务调用彼此，中间必须有层软件帮忙翻译协议、转换数据格式、搞定网络延迟和容错，这个做翻译的层就是中间件。再换一个类比，它也更像机场塔台——飞机（请求）要起飞降落（访问不同服务），塔台负责调度航道、处理排队、应对突发天气（服务雪崩、网络抖动），保证整个机场（整个系统）不乱。

中间件这个角色之所以重要，在于它决定了一个系统的上限。业务代码写得再漂亮，给到一组不稳定的消息队列或者一个扛不住高并发的交易中间件，整套系统照样会在流量高峰时垮掉。2000年左右国内刚开始企业信息化的那批系统，很多业务逻辑本身并不复杂，复杂度全部集中在“怎么保证跨系统调用的数据一致、不丢消息”上，那正是中间件发挥核心价值的场景。

1.2 25年演进的三条主线：形态、技术、市场

把2000年到2025年这25年整体铺开看，我个人倾向于用三条主线去梳理中间件行业的变化，它们纠缠在一起，互相驱动，缺一条都讲不清完整图景。

第一条线是形态之变。中间件最开始是一个个安装包，重、需要专门服务器部署，跑起来像一台耐用但笨重的老式机床。后来逐步演进成可集群部署的软件套件，再到现在变成云上按需开通的托管服务，你甚至不需要关心它装在哪台机器上，点一点按钮就创建完成。中间件的“存在感”越来越低，但价值反而更高了。

第二条线是技术之变。技术选型的演进脉络非常清晰：早期是CORBA、EJB这种偏重量级的分布式对象模型，后来SOA火了，企业服务总线ESB成为主流，再后来微服务架构兴起，大单体被拆成一堆小服务，中间件的角色被进一步打散、下沉，注册中心、API网关、消息队列、分布式事务框架各自承担原有一体化中间件的部分职责。最近几年又冒出服务网格、云原生中间件这些新名词，核心思路是把中间件能力进一步抽象到基础设施层去。

第三条线是市场之变。这条线最直观。2000年出头，国内关键行业的核心系统几乎被国外中间件产品包揽，那时候做项目，中间件采购成本经常比服务器硬件还高。到2010年以后，国产产品逐步在中小系统里打开局面。近几年，在国产化和行业数字化双重因素下，国内中间件厂商终于有机会进入银行、证券、能源这些过去门槛很高的关键行业，整个市场格局被彻底重写。

三条线交织的结果是：今天的中间件行业早已不是“买一款软件装上”这么简单，而是一套融合了开源生态、云服务能力和国产替代逻辑的复合体系。理解这套演进逻辑，比单纯知道某个产品名有用得多。

2. 2000-2010：国外产品主导与国产种子萌发

2.1 国外产品统治的年代：贵但让人放心

2000年初，我做系统集成项目时，最头疼的事情就是客户预算清单里的中间件采购项。那个年代，银行、电信这类高端行业用的基本都是国外老牌厂商的交易中间件和应用服务器产品。交易中间件解决的是分布式事务问题，尤其适合银行核心账务系统这种“绝对不允许账目平不了”的场景；应用服务器则是Java企业应用的标准运行容器，企业业务系统、Web应用大多都部署在它上面。

那批国外产品有几个鲜明特点。

稳定性确实强。经过二十年打磨，核心事务处理能力非常成熟，不少银行核心系统在超大并发下跑几十年不出大问题。我在2004年配合某项目上线，赶上跨行交易高峰，那套商业中间件扛住了每秒大几千笔的并发，放到当年这是很夸张的数字。

文档和服务也规范。厂商提供的技术文档、售后支持体系、故障响应流程都是标准化的，出了问题一个工单上来，处理链路很清晰。这一点对当年IT人员捉襟见肘的金融机构来说，是极大的心理安全感。

但缺点同样突出。首先是贵，授权费用按CPU颗数算，两路、四路服务器的授权费用一交就是几十万甚至上百万起步，后续每年的维护升级费又是一笔不小支出。其次是黑盒，闭源代码让你没法深入定制，碰到特殊业务场景只能顺着厂商的设计方案走，想绕都绕不过去。再就是重，部署要求高、学习曲线陡，一个小功能往往牵扯一堆配置文件。

那时候国内不是没有做中间件的团队，但处境普遍艰难。一方面，产品成熟度跟国外产品差距明显，性能测试跑不过人家；另一方面，市场信任度低，你跟银行信息中心的人说“我们也有中间件”，对方会礼貌地点头，但到了采购环节最终还是选了老牌产品。这个阶段国产中间件的生存逻辑主要是“跟随着做”，在低端市场找空间，在边缘系统中反复打磨稳定性。

2.2 国产中间件的第一粒种子：模仿中积累

国产中间件的起步路线，基本就是照着国外产品做。2000年前后，国内几家软件公司陆续推出基于Java EE规范的应用服务器产品，核心卖点是“兼容某国外主流规范”、“支持企业级Java应用”。你可以理解成，国外出了个标准，国内厂商照着标准实现一套，先保证业务应用能跑起来。

那个阶段的国产产品，说好听是“初步可用”，说直白一点就是“能跑但不敢推上核心系统”。我在2006年给某社保系统做过一次方案，客户当时为了控制预算，选了某国产应用服务器部署一套非核心查询系统。实际效果是基本功能没问题，但只要并发上来，性能瓶颈就会出现，需要反复调优JVM参数和数据库连接池配置。反观同机房另一套跑在国外产品上的系统，几乎不用怎么操心。

但这种“照着做”的过程并非没有价值。开发国产中间件的人在这个过程中真正搞懂了分布式事务怎么实现两阶段提交、集群间怎么同步会话、消息队列怎么保证可靠投递。这些底层经验，是后面国产中间件能力突破的关键积累。

国产中间件当年还有一个天然优势是本地化服务。某个系统出了问题，国内厂商的工程师可以当天到场排查，而国外产品往往需要飞越时差在一两天后才能响应。对很多预算有限、重视响应速度的企事业单位来说，这个卖点其实挺打动人的。量大了以后，口碑慢慢建立，国产产品开始在教育、社保、交通等信息技术集成项目里小范围渗透。

回头看2000-2010这十年，我的总体评价是：国外产品定义了中间件的技术标准和商业玩法，国内产品则在模仿和学习中磨出了第一代技术骨干。没有这十年的积累，后面国产中间件就算碰上风口，也接不住。

3. 2010-2018：云计算与开源浪潮重塑中间件版图

3.1 云计算的冲击：从“买软件”到“开服务”

2010年前后，国内外云计算开始真正走向落地。云平台带来的第一个改变是：你不需要再自己买服务器、装操作系统、部署中间件了，而是直接在网页上开通一个数据库实例、一个缓存实例、一个消息队列服务。中间件这种原本需要单独购买授权的软件，突然被“服务化”了。

这个转变对行业的冲击是结构性的。

对用户来说，中间件的获取成本断崖式下降。以前用商业中间件，动辄几十万授权费；云上用开源中间件封装的服务，按量付费，一个月几百、几千块钱就能用上，而且不用管底层运维。我2013年帮某创业公司做技术方案，他们预算有限，我直接选了云上的消息队列和缓存服务，整个中间件成本比传统方案低了至少八成，上线速度也从“采购审批三个月”变成“开通即用”。这种体验一旦培养起来，再想让企业回到自建机房买商业授权，就没那么容易了。

对传统商业中间件厂商来说，这无疑是巨大的商业挑战。云服务商以极低的价格提供“看起来差不多”的能力，还包运维，传统中间件“稳定安全”的卖点被弱化。大量原来的商业中间件客户，尤其在中小型企业市场，开始逐步流失。那时候业内经常讨论一个问题：商业中间件到底是卖软件授权，还是卖服务？结论很快就清楚了，服务才是未来。

3.2 开源中间件的黄金年代：Kafka与Redis们改变了什么

与云计算同步崛起的是开源中间件运动。2010年前后，一批开源项目密集诞生并快速成熟，其中最典型的要数分布式消息系统和缓存系统。

以分布式消息系统为例，它最初贡献于大数据日志收集场景，核心设计是用分区和顺序写盘的方式来支撑超高吞吐，一台普通服务器就能扛住每秒几十万条消息的写入。这让它很快成了大数据管线的事实标准，几乎所有大数据的日志收集、数据同步管道都跑在它上面。我在2015年给某电商平台搭用户行为分析管道，每天几亿条埋点日志，用的就是这套方案，单机吞吐量跑到每秒二十万条以上，几乎没有掉过链子。

另一类是缓存系统，这个更不用多说，现在随便一个后端项目里都有它的身影。它把热数据放在内存里，读性能达到亚毫秒级，彻底改变了“查询数据库”的单一路径。配合哨兵集群、分片集群部署，能扛住大规模并发读。2016年一次双十一大促压测，我记得最清楚的是缓存集群撑住了每秒百万级的读取压力，而数据库层的读压力几乎被削平了。

开源中间件的大规模流行，叠加云厂商把它们转成托管服务，让整个行业的游戏规则彻底变了：核心中间件能力从“少数商业产品掌握”变成“人人可用”。这个变化冲击最大的就是传统商业中间件厂商，也让国产中间件厂商面临一个选择：继续做传统的应用服务器、交易中间件，还是开源化、云化？回头看，那些行动快的厂商后来活得都不错，行动慢的大概率一路承压。

这个阶段还出现了一个重要趋势：微服务架构开始在业界传播。2014年前后，一批互联网公司已经先用微服务架构替代了传统SOA架构，服务拆细了，服务数量激增，服务之间的通信、发现、容错就变成一个新问题。这直接催生了对注册中心、API网关、分布式调用链追踪等新一代中间件的强烈需求。传统ESB服务的定位开始尴尬，因为它更适合粗粒度的模块间集成，不太适合微服务场景下几千个节点之间的灵活通信。

4. 2018-2025：云原生与国产化的双重变奏

4.1 云原生到底改变了中间件什么：能力下沉与配置化

2018年之后，“云原生”这个概念从热词变成了技术现实。对我这种做架构的人来说，云原生最核心的影响是：中间件的存在方式又变了一层。

以前用消息队列，你得关心集群有几个节点、磁盘多大、要不要做多副本；用缓存，你得关心内存够不够、主从同步正不正常。云原生时代，这些底层的容量管理和故障转移被平台层接管了大半，你更多地通过配置和声明式API去描述自己的需求：给我建一个三副本、高可用的消息队列实例，存储容量按需扩展，自动进行滚动升级。中间件从“需要运维照顾的软件”彻底变成“随取随用的平台能力”。

这背后是一整套技术栈的升级。容器编排系统把应用和依赖打包成标准单元，快速部署到成千上万台机器上；微服务框架统一解决服务发现、负载均衡、熔断降级；API网关集中处理鉴权、限流、灰度发布；服务网格把通信治理能力进一步从业务代码里抽出来，放进网络代理层。这每一项技术单独看都是中间件的一个门类，合在一起，就构成了一张完整的云原生中间件能力网。

我在某省政务云平台项目里深有体会。项目里有几十个子系统，几百个微服务，如果按传统方式为每个系统分别规划中间件，资源消耗和运维复杂度都不可接受。后来统一用云原生中间件平台，所有业务系统共享一套消息、缓存、注册中心能力，通过命名空间和配额隔离实现资源隔离。这一套设计跑下来，中间件资源整体利用率提升了至少一倍。中间件从原来的“一个系统配一套”，变成了“一套平台服务一堆系统”。

4.2 国产中间件进入关键行业的黄金期

也是从2018年前后开始，国产中间件遇到了真正的行业机遇。这个机遇的底层逻辑很简单：关键行业需要自主可控的基础软件，而中间件作为应用和操作系统之间的承重墙，自然被放到替代清单的高优先级位置。

与2000年那种被动追随不同，这一轮国产中间件厂商手里已经有了不少底牌。经过近二十年积累，国内厂商在交易中间件、消息中间件、应用服务器等核心品类上都推出了对标产品。我2019年参与过某金融机构中间件选型测试，拿某国产消息中间件去跟国外主流产品做了对比：基础消息推拉能力、持久化性能、集群高可用、跨机房容灾，几轮压测下来差距已经很小，部分指标甚至略优。当时我的感受是，国产中间件从“能用”到“好用”的拐点，真的到来了。

这个阶段国产中间件覆盖面也明显扩展。我跟同行交流时总结过，现在国产中间件几乎覆盖了所有主流品类：应用服务器、交易中间件、消息中间件、缓存中间件、API网关、分布式事务框架、服务网格。不少厂商还推出了统一的中间件管理平台，把多种中间件统一纳管，提供了类似于PaaS的使用体验。这种“全家桶”策略在关键行业里很讨巧，因为客户希望尽量减少供应商数量，降低集成复杂度。

不过也要泼一盆冷水。国产中间件在常规场景已经足够可靠，但在最极端、最苛刻的场景下，比如大型国有银行核心账务系统每秒数万笔的强一致交易，国产产品能够提供的生产级案例仍然不多。稳定性是需要时间喂出来的，而时间恰恰是最难压缩的。好在越来越多的行业客户愿意给国产产品提供核心系统验证机会，这个“最后一公里”的问题正被一点点克服。

4.3 可观测性中间件：一个全新的爆发品类

2020年以后，还有一个之前容易被忽略的品类开始爆发：可观测性中间件。传统的监控工具主要看“某个节点挂了没有”，而现代大型分布式系统更进一步，要求能追踪一个请求从入口到所有内部调用的完整链路，同时汇聚指标、日志、链路追踪三类数据，统一分析定位问题。

我2021年排查一个线上问题印象很深。当时外围服务间歇性超时，数据库、网络指标都正常，传统监控完全抓不到异常。后来通过全链路追踪中间件把请求路径全部拉出来，才发现是某个底层服务框架在特定场景下发生线程阻塞，导致请求悄悄排长队。这个定位过程，用老一代监控工具可能得折腾几天，用链路追踪工具一小时就破了案。

可观测性相关的开源生态也很热闹，像一些开源指标系统、日志系统、调用链系统成了标准组合。云厂商和国产中间件厂商也纷纷跟进，把这套能力做成一体化可观测平台。以我看到的趋势，这个品类还会继续往智能化方向走，比如跟踪数据自动进行根因定位、异常检测，帮助运维人员在海量数据里快速找到元凶。

5. 中间件选型的现实策略：不同阶段怎么选

5.1 三种典型场景的选型对照

25年演进分析到最后，总要落到“我手头的项目该怎么选中间件”这个现实问题上。我根据自己的实践经验，把常见的选型场景归纳成三类，不敢说覆盖所有情况，但大概率能对上一大半。

第一类是传统单体架构且核心交易型系统。典型代表是银行传统核心、企业ERP这类对数据一致性要求极高的系统。这类场景的关键词是“稳”，选型上优先考虑成熟度高、事务能力强、支持强一致性的商业中间件。如果所在行业对国产化有要求，就选国产头部的交易中间件产品，同时确认它是否支持两阶段提交、是否经过同等规模场景的验证。

第二类是互联网/云原生应用。典型代表是电商平台、SaaS服务这类高并发快迭代的业务。这类场景的关键词是“快”，选型上优先考虑云厂商提供的托管中间件或者开源产品，比如分布式消息系统、缓存系统、注册中心、配置中心等。这里最重要的是避免重复造轮子，能用托管服务就让平台去扛底层那些滚动升级、容量伸缩的琐事。

第三类是传统政企信息化项目。典型代表是政务系统、大型企业内部管理系统。这类场景的关键词是“合规”，选型上既要考虑国产化要求，又要兼顾生态兼容性。我建议优先考虑国产厂商的统一中间件平台，一个平台管理多种中间件组件，既满足合规诉求，又降低运维复杂度。

为了更直观，我列个对照表：

5.2 从架构视角看：中间件不是越多越好

很多团队有个惯性：项目一启动就先把各种中间件塞进来，消息队列、缓存、注册中心、配置中心、链路追踪一个不落。最后系统复杂度膨胀，很多中间件只承担了一小撮流量，却贡献了大量运维成本。我的建议是先做减法，再谈选型。

一个业务刚起步时，单体架构加一个数据库完全够用，这时候硬上微服务和一堆中间件，反而拖慢开发速度。等业务量真的上来了，拆分的必要性出现了，再按需引入：出现了服务发现的需求再上注册中心，出现了异步处理的场景再上消息队列，出现了读热点再上缓存。每引入一个中间件，都得想清楚它解决了哪个具体问题，如果说不清楚，就先不要上。

另外要特别注意中间件的一致性。我见过不少团队，消息队列用一套，注册中心用另一套，API网关又用另一套，组合起来兼容性问题不断。同类型中间件尽量选择同一生态、同一厂商，减少集成层的不确定性。这点在传统企业里尤为重要，因为他们的中间件运维人力往往有限，没有精力同时维护多套技术栈。

6. 实战中的常见误区与避坑经验

6.1 三个常见的认知误区：没踩过的人是幸运的

第一，“开源一定比商业便宜”。这个说法小规模看在账面上成立，但一旦把人力成本算进去，结论就不一定了。开源中间件的软件授权费用确实为零，但你需要自己搭集群、做监控、处理升级、应对底层Bug。一个消息队列集群出了问题，排查和修复的成本可能远超当年省下的一点点授权费用。商业中间件或托管服务本质上是“花钱买省心和兜底”，这钱到底值不值，取决于团队的技术实力。

第二，“高性能中间件是万能的”。很多人看到指标测试里每秒几十万的消息吞吐量，就觉得系统加个高性能中间件就能解决所有性能问题。实际上，中间件只是管道，管道再粗，如果业务代码慢、数据库慢、网络抖动，整体性能照样上不去。我多次在性能调优时发现，真正的瓶颈不在中间件，而在业务逻辑里某个串行的外部调用。中间件的性能指标，只有在系统其他环节都健康的情况下才有意义。

第三，“数据一致性靠中间件就完事了”。分布式事务是中间件最难啃的骨头，没有哪种方案能做到高性能和强一致兼得，全链路事务基本都是取舍的结果。有人以为用了分布式事务框架就能高枕无忧，忽略了它也会引入额外的复杂度和性能损耗。我倾向于在架构设计早期就尽量避免分布式事务，比如通过数据最终一致、事件驱动的方式绕开强一致场景，这比事后靠中间件补救要好得多。

6.2 操作层面最值得记住的三条经验

第一条：上线前一定做故障演练，别只测性能。 中间件的高可用能力，平时看不出来，只有在节点宕机、网络分区、消息积压的时候才见真章。我做过一次教训深刻的演练：模拟消息集群的一个节点宕机，结果发现客户端的重连逻辑有Bug，整整两分钟消息断了没人知道。这个问题如果压测不触发，等到生产环境真宕机才发现，后果不堪设想。

第二条：中间件版本升级要当成小项目来管理。 开源中间件社区发版很快，但大版本升级往往伴随着协议变化或配置项调整。最稳妥的办法是先搭一个完全独立的测试环境，模拟生产流量压一遍，确认兼容性和性能都达标后再灰度切换。千万不能图省事，在生产环境直接原地升级。我见过升级后连接全部断掉的事故，原因就是新旧版本的默认行为不一致。

第三条：中间件的监控和告警要前置配置。 不要等出了问题再去看监控面板，要把告警规则提前设好。我经手的系统，至少会配置消息积压量、消费延迟、缓存命中率、服务健康检查这几类基础告警。遇到深夜被电话叫醒的情况，十次有八次都是监控告警先发现问题的。没有监控兜底的中间件，等于在上线时就把火把交给了运气。

7. 后记：一个老开发者的中间件事

写完这25年的演进分析，我最大的感慨是：中间件行业的变化，本质上映射了整个中国软件产业的成长曲线。从最初只能买别人家的产品，到中间自己试着做，再到今天国产产品走进关键行业的核心系统，这条路走得很不容易，但每一步都实实在在踩在基础设施建设的土壤上。

现在我做架构评审，第一件事就是问团队一句话：“你们的中间件是当黑盒用，还是当基础设施来运维？”说得直白一点，前者意味着你完全依赖供应商或平台兜底，后者意味着你的团队有能力理解它、掌控它、在极端情况下修复它。这两种态度，决定了你在中间件暴雷的时候是手足无措还是从容应对。

最后再分享一个我自己琢磨出来的习惯：每隔半年，把当前使用的中间件列表拿出来，逐一问三个问题——它还在解决当初那个问题吗？有没有更简单的方式替代它？团队里还有没有人真正懂它？如果某个中间件的答案变成“不太确定”或者“没人管了”，那就该着手整改了。中间件选型、落地、治理是一辈子的事，别让它成为你系统里最隐蔽也最致命的定时炸弹。