来源：阿里云中间件开源往事

分布式架构和云原生重塑了中间件的游戏规则，这给国内开发者提供了重新定义中间件的历史机遇。

在分布式架构流行前，国外 IT 厂商引领着中间件市场的发展，且以闭源、重商业的服务形式为主；随着云计算和互联网的普及，阿里将 RPC 框架、消息队列、服务发现、配置中心、分布式事务、限流降级等核心应用中间件技术对外开源，加速了分布式架构在国内的落地，也使得开发者在 Spring 技术栈以外多了一种选择。而云原生则实现了中间件以 BaaS 或 SaaS 的形态出现，解决了分布式应用架构落地后，中间件在容量管理、交付、运维、容灾上的难题，使用者通过标准化的 API 就可以完成对中间件的调用，从而提升企业整体的开发和运维效率。

• Apache Dubbo：同步架构通信，从 RPC 框架到全面拥抱云原生基础设施
• Apache RocketMQ ：异步架构通信，从 Messaging 到 Streaming 和 Eventing
• Nacos：从架构下沉到关键组件，持续突破性能瓶颈，市场占有率已经超过50%
• Sentinel：首次涉及服务治理领域，但不止于限流降级，即将发布里程碑版本2.0
• Spring Cloud Alibaba：对国内开发者、阿里云、Spring 三方来说，都是一个好消息
• Arthas：一款工具型开源项目，Stat 即将突破 3w
• ChaosBlade：业务稳定，不仅需要事中限流降级，更需要事前故障演练
• Seata：让分布式事务的使用像本地事务的使用一样，简单和高效
• AppActive：Sentinel、ChaosBlade、AppActive，高可用三家马车成功集结
• OpenSergo：解决日益增长的微服务框架混用企业的服务治理难

Apache Dubbo（以下简称 Dubbo）是阿里巴巴于 2012 年开源的分布式服务治理框架，是国内影响力最大、使用最广泛的开源 RPC 框架之一，2017 年捐献给 Apache 基金会，2019 年正式毕业。

“从孵化器毕业是一种荣誉，但这并不是结束，而是另一种开始。这有点像求学，毕业并不意味着学习上的中断，而是发挥更大社会价值的开始。毕业也更像是一个成人礼，意味着 Dubbo 团队已经符合 Apache 对一个成熟开源项目的要求，并开始具备独立发展的能力。”阿里云高级技术专家北纬当时在接受媒体采访时回答道。

从 Apache 孵化器毕业，并不是结束。服务框架就像铁路的铁轨一样，是互通的基础，只有解决了服务框架的互通，才有可能完成更高层的业务互通，所以采用相同的标准是新一代服务框架发展的必然趋势。2021 年，Dubbo 正式发布 3.0 版本，Dubbo3.0 是 Dubbo2.0 与 HSF 融合而来，是阿里巴巴面向内部业务、商业化、开源的唯一标准服务框架。

Dubbo3.0 的发布，也源自全面拥抱云原生基础设施的核心演进方向

随着 K8s 成为资源调度的事实标准，Service Mesh 从提出到发展至今已经逐渐被越来越多用户所接受。Dubbo 这类 Java 微服务治理体系面临了许多新的需求，包括期望应用可以更快的启动、应用通信的协议穿透性可以更高、能够对多语言的支持更加友好等。因此，Dubbo3.0 首次提出了全新的服务发现模型、下一代 RPC 协议和适配云原生基础设施等新能力。

• Dubbo 3.0 支持应用级服务发现：Dubbo 原本采用接口级别的注册方式，存储在注册中心中的数据会在很大程度上存在重复的内容，随着服务规模的增长，注册中心的数据量就会爆发式地增长，支持应用级服务发现后，不仅大大减少注册中心的内存压力，以获得更强的性能，更重要的是，打通了与其他微服务体系之间在地址发现层面的鸿沟，这是在适配 Kubernetes 等基础设施上，走出的重要一步。
• Dubbo 3.0 提出了下一代 RPC 协议 —— Triple：这是一个基于 HTTP/2 设计的完全兼容 gRPC 协议的开放性新协议，具有极高的网关友好型和穿透性，完全兼容 gRPC 协议是的天然在多语言互通方面上具有优势。这也解决了上一代协议中生态不互通、协议头无法再承载更多元数据信息的问题。

如果把 RPC 作为同步通信的实现机制，那么消息队列可以看作是异步通信的实现机制。除了用于异步通信外，消息队列还能用于解耦、削峰填谷、分布式事务等场景，这对消息队列在性能、稳定性上提出了更高的要求。

2011 年，当时的双 11 经常会出现消息延迟半天甚至一天以上，导致商家看不到买家已经购买了的商品的问题。而解决这个问题的本质是如何实现高速读写，但基于之前的架构，无法彻底地解决问题。那么，就需要设计一个全新的存储架构。负责全新产品设计的任务，刚好落到了 RocketMQ 创始人&作者王小瑞身上。

但当时总共就两个人，一个人负责 Notify，王小瑞则负责全新产品的设计。但开源，可以汇聚数百人、数千人、数万人一起来开发，也能吸收所有公司、行业、业务场景的需求，汇聚最大的生产力。因此，从第一天开始的时候，RocketMQ 就是托管在 GitHub 上，也就是说它的第一行代码就是对所有开发者和用户开放的，整个开发过程也是对用户开放的，这也吸引了特别多的开发者，大家帮助 Review 代码、测试 Bug，RocketMQ 在众多开发者的参与下进展迅速。

2016 年的那届双 11，RocketMQ 团队首次将低延迟存储解决方案应用于双 11 的支撑，经受住了流量的大考，整个大促期间，99.996% 的延迟落在了 10ms 以内，完成了保障交易稳定的既定目标，对于读写比例几乎均衡的分布式消息引擎来说，这一技术上的突破，即便是放在全球范围内，也绝对是值得称赞的。同时，“双 11”当天达到万亿级消息量，峰值 TPS 达几千万，也创造了当时世界上最大的消息流转记录。

2016 年，在历时 3 个月的开源重塑后，RocketMQ 团队启动了向 Apache 软件基金会的捐赠之路，经过近一年的努力，在 2017 年 9 月 25 日，Apache 软件基金会官方宣布，阿里巴巴捐赠给 Apache 社区的开源项目 RocketMQ 从 Apache社区正式毕业，成为 Apache 顶级项目（TLP），这是国内首个非 Hadoop 生态体系的 Apache 社区顶级项目。

值得一提的是，根据项目毕业前的统计，RocketMQ 有百分八十的新特性与生态集成来自于社区的贡献。

2021 年，在经历社区众多开发者的不断努力，RocketMQ 5.0 正式发布，新版本核心包括两大新亮点：

• 首先，消息核心场景全面扩展，RocketMQ 5.0 不再局限于消息解耦场景，将消息的应用场景从 Messaging 拓展到了 Streaming 和 Eventing 领域；
• 其次，技术架构不断演进，逐渐形成一站式融合处理的技术架构和趋势。

2022 年，批量消息索引、逻辑队列发布 RocketMQ-MQTT、RocketMQ-Connect、RocketMQ-Streams，完成了从业务消息平台向『消息、事件、流』一体化融合处理平台的升级。开发者可以实现一份消息存储，支持流式计算、异步投递、集成驱动等多个场景。实现技术问题一站式解决，大大降低技术复杂度和运维成本，简化企业应用架构。

分布式应用的落地，仅仅是一个 RPC 框架和一套异步消息系统是不够的，还需要一系列围绕分布式应用架构的组件。

2018 年夏天，国内应用中间件开源领域，迎来了两位新成员。

作为微服务生态下的两款重要开源组件，Nacos 主打动态服务发现、配置和服务管理，Sentinel 则是聚焦在限流和降级两个方面。

Nacos 和 Sentinel 均是在阿里 10 多年的核心业务场景下沉淀所产生的，他们的开源是对国内应用中间件领域开源技术方案的有效补充，同时也非常强调融入开源生态，除了兼容 Dubbo，也支持 Spring Cloud 和 Kubenetes 等生态，以增强自身的生命力。

“Nacos 起源于阿里巴巴内部，历经十多年双 11 洪峰考验的三款产品 - VIPServer/Configserver/Diamond ，沉淀了简单易用、稳定可靠、性能卓越的核心竞争力，并吸引了 200 多位优秀贡献者，共迭代 44 个版本，服务虎牙、好未来、小米等多家企业，在 2.0 的里程碑版本上，全面升级了通信协议、服务一致性模型、支持服务网格生态和多语言生态。”彦林在 Nacos star 突破 2w 后分享道。

Nacos 2.0 的发布，是 Nacos star 突破 2w 的又一个里程碑事件。随着 Nacos 用户规模的增长，和用户业务日益复杂，Nacos 2.0 的发布是一个必然。Nacos 1.x 时代：

• 服务发现性能不够强：在 10W、5W 级客户端下，服务端完全处于 Full GC 状态，推送完全失败，集群不可用；在 2W 客户端规模下，虽然服务端运行状态正常，但由于心跳处理不及时，大量服务在摘除和注册阶段反复进行，因此达不到稳定状态，CPU 一直很高；1.2W 客户端规模下，可以稳定运行，但稳态时 CPU 消耗是更大规模下 2.0 的 3 倍以上。

• 配置管理性能不够强：连接客户端数量达到 6000 时，稳定状态的 CPU 一直很高，且 GC 频繁；当客户端规模达到 1.2w 时，已经无法达到稳态，所以无法支撑这个量级的客户端数。推送规模达到 3000TPS 时，占了 80%的 CPU 资源；一旦达到 6000TPS 时，CPU 资源上升到了 90%。

Nacos2.0 作为一个跨代版本，对架构做了全面升级，彻底解决了 Nacos1.X 的性能问题，针对服务发现的场景，Nacos2.0 能够在 10w 级规模下，稳定运行，相比 Nacos1.X 版本的 1.2w 规模，提升约 10 倍；针对配置管理的场景，Nacos2.0 单机最高能够支撑 4.2W 个客户端连接，相比 Nacos1.X，提升了 7 倍，且推送时的性能明显好于 1.X。

一边是 Nacos 宣布开源，逐步迭代到 2.0 版本，提供企业版 MSE，另一边是 Spring Cloud 生态下的服务注册和发现组件宣布停止开源投入，勇敢者的游戏充满了变数，但在 Nacos 团队看来，这场游戏自己可以走到最后：在 2021 年某第三方媒体对注册中心开源方案采用的调研中，Nacos 的市场占有率已经超过 50%。

Nacos 只是阿里云众多中间件开源项目中的一员，随后还有更多的开源项目反哺给社区，形成生态，例如轻量级限流降级组件 Sentinel。

影响生产环境的稳定性因素，从来源上看，我们通常可以归纳位两类，一类是版本发布过程中，引入的代码变更带来的风险，一类是外部不规则流量带来的风险。而 Sentinel 作为一款高可用范畴的开源项目，他要解决的就是外部流量导致的稳定性风险。

2018 年 7 月，中间件开发者 Meetup 深圳站现场，只能容纳 400 人的场地，来了近 700 位开发者。Sentinel 创始人子矜在现场宣布了轻量级限流降级组件 Sentinel 的开源。“Sentinel 经历了 10 多年双 11 的考验，覆盖了阿里的所有核心场景，也因此积累了大量的流量归整场景以及生产实践。Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。”

• 流量控制：某个服务的上限是 1 秒处理 3000 个 QPS，但如果实际情况遇到高于3000的 QPS 该如何解决呢？Sentinel 通过流量统计的方式，当流量超过阈值，会帮助服务通过直接拒绝、冷启动、匀速器三种方式来应对，从而起流量控制的作用。

• 熔断降级：服务之间会有相互依赖关系，例如服务 A 1 秒可以处理上万个 QPS，但服务 B 不具备这么高的处理能力，那么如何保证服务 A 在高频调用服务B时，服务 B 仍能正常工作呢？Sentinel 通过对并发线程数进行限制和响应时间上对资源进行降级，这两种手段来实现熔断或降级，从而保证服务 B 可以正常工作。

2019 年，Sentinel 贡献的 spring-cloud-circuitbreaker-sentinel 模块正式被社区合并至 Spring Cloud Circuit Breaker，由此，Sentinel 也加入了 Spring Cloud Circuit Breaker 俱乐部，成为 Spring Cloud 官方的主流推荐选择之一。开源项目需要不断延展他的能力范畴才能保持持续的生命力，Sentinel 不止于限流降级，他是否也可以帮助开发者解决新版本发布过程中的诸多稳定性风险，这是即将要发布的 Sentinel2.0 要回答的问题。

Spring Cloud 官方推荐的微服务方案不止 Sentinel 一个，还有 Spring Cloud Alibaba.

2018 年，中国的 Java 圈发生了一件大事。Spring Cloud 联合创始人 Spencer Gibb 在 Spring 官网的博客页面宣布：阿里巴巴开源 Spring Cloud Alibaba，并发布了首个预览版本。随后，Spring Cloud 官方 Twitter 也发布了此消息。

Spring Cloud Alibaba 项目由两部分组成：阿里巴巴开源组件和阿里云产品组件，旨在为 Java 开发人员在使用阿里云产品的同时，通过利用 Spring 框架的设计模式和抽象能力，注入 Spring Boot 和 Spring Cloud 的优势。

Spring Cloud 本身是一套微服务规范，并不是一个拿来即可用的框架，而 Spring Cloud Alibaba 的开源为开发者们提供了这套规范的实现方式，而这种实现方式对调用阿里云的资源和云产品能力十分友好，这对国内开发者、阿里云、Spring 三方来说，都是一个好消息。

效率的好处在于，我们可以把自己的注意力和时间聚焦在更需要创造力的事情上，做更有成就感的事情。对于工作在工程领域的开发者们而言，他们的效率意识更强。

2018 年 9 月，阿里将内部广泛使用的 Java 线上诊断工具进行开源，取名 Arthas (阿尔萨斯)。也许是击中了开发者线上排查问题的痛点，Arthas 在距离开源后的第一个 Release 版发布仅 147 天，就获得了超过 1w 的 star 数，并有 40 多位 Contributors 参与开源贡献。

从中，我们不仅看到 Arthas 这类工具型开源项目在开发者群体中的受欢迎程度，也发现越来越多的国内开发者开始参与开源贡献，并视为一种社区荣誉。技术领域，一切里程碑的达成，都源于一份技术情怀。截止目前，Arthas 已有接近 3w star 和 146 位 Contributors，这对一款线上诊断工具而言，是一份不错的答卷。

时间来到 2019 年。

如果把生产阶段比作高考，那么 Sentinel 解决的是事中的稳定性问题，一旦出现流量徒增，可以通过限流和降级来应对，而 2019 年开源的 Chaosblade 则是更多从事前的方式来提高架构的高可用性，通过建立故障演练机制，把各类可以预见的故障提前演练出来，例如随机杀节点、延时响应，甚至中断机房。

Chaosblade 和 Sentinel 师出同门，源自阿里在全链路压测、线上流量管控、故障演练上沉淀的这一套高可用核心技术。阿里云资深技术专家中亭说道：“阿里因其多元化的业务场景和日益复杂的技术架构，会遇到各式各样的故障，故障治理的难度增量了几个台阶。Chaosblade 从 2011 年开始，经历了强弱依赖的治理和建设、同城容灾演练、在交易和中间件链路尝试演练三个阶段，经过 6 年多的打磨，最终将最佳实践和工具框架形成统一的标准，对外进行开源，帮助 DevOps 人员缩短构建混沌工程的路径。”

在微服务架构普遍落地的今天，分布式事务带来的数据一致性问题、性能问题越来越绕不开。分布式事务理解起来有点门槛，但却无处不在，他是相对本地事务而言的，服务和服务之间不需要跨网络就能完成的，称之为本地事务，需要跨网络才能完成的，称之为分布式事务，例如金融行业银行之间的转账业务需要跨网络才能完成，电商行业交易下单调用外部库存系统、物流系统需要跨网络才能完成等。

虽然业内有一些分布式事务开源的解决方案，但要么是性能差、要么是数据一致性不够、要么是侵入性高，不容易落地。总之，是有点“不爽”。

而这种“不爽”集中反映在了分布式事务开源中间件 Seata 上，清铭在 2019 年 1 月中间件开发者 Meetup 上宣布分布式事务中间件 Seata 正式开源后的一周内，Seata 便收获了 3000+ star，社区讨论的 issue 达 58 个。

阿里巴巴是国内最早一批进行应用分布式（微服务化）改造的企业，所以很早就遇到微服务架构下的分布式事务问题。2014 年发布 TXC，开始为集团内应用提供分布式事务服务。2016 年，TXC 经过产品化改造，以 GTS 的身份上线阿里云，成为当时业界唯一一款云上提供分布式事务的商业化产品。2019 年，基于 TXC 和 GTS 的技术积累，开源了 Seata，和社区一起共建分布式事务解决方案。2022 年，经过多年的打磨，Seata 发布了 1.5.0 里程碑版本，该版本共有 61 名 contributor 贡献了近 7w+代码，同时也推出 Seata 企业版，并在微服务引擎 MSE 上提供商业化服务。企业版相比开源版内核 RT 降低 20% 以上，TPS 性能提升 30%，并且解决了高并发场景下的事务处理“毛刺”问题。

TXC/GTS/Seata/MSE 一脉相承，其愿景是让分布式事务的使用像本地事务的使用一样，简单和高效。

治理不仅是架构的延续，更是下一代应用中间件技术的演进方向。

分布式应用架构的需求包括 RPC 框架、消息队列、服务发现、配置中心、网关、分布式事务等，解决的是分布式应用落地的问题，但随着服务数量的增加、服务之间的依赖更加复杂，分布式应用治理成为更加迫切的需求，包括流量治理、开发测试治理、数据库治理、混沌工程、多活，解决的是用好、管好分布式应用的问题。

但显然，仅仅是 Sentinel、Chaoblade 还无法满足开发者对于用好、管好分布式应用的开源诉求，于是阿里云再一次开源了两款面向分布式应用治理领域的项目，Appactive 和 OpenSergo。

在 2022 年 1 月的云原生实战峰会上，云原生应用平台负责人叔同宣布应用多活 Appactive 正式开源。由此，Sentinel、Chaosblade 和 AppActive 形成了高可用的三架马车，帮助企业构建稳定可靠的企业级生产系统，提高企业面对容灾、容错、容量管控等的稳态系统建设能力。

2013 年，当时淘宝完成去 O 没多久，双十一的规模较上年进一步飞增。阿里的工程师正面临以下两大难题，一方面是机房资源非常紧张，容量不足，另一方面是杭州出现罕见的高温天气，机房面临断电的风险，异地多活架构就是在这个背景下孵化出来的。后来，随着淘宝的业务规模演进，异地多活也从近距离同城双机房到远距离异地双活，再到三地四单元、多地多活，沉淀了丰富的机房级应用多活经验。

AppActive 的开源，一是希望给多活提供一个统一的规范和定义，在这个基础上，大家才能共享成熟的实践经验，以避免因认知偏差带来的企业在基础设施成本、应用改造成本、运维成本等成本面的投入，从而让“多活”成为一项事实意义的普惠技术；二是基于标准，提供各个层次多活能力的实现。

在应用多活的规范中，定义了 LRA（同城多活）、UDA（异地多活）、HCA（混合云多活）和 BFA（业务流量多活）4 层能力。在 AppActive 发布的第一个版本里，提供了 BFA 和 UDA 的基础能力，BFA 和 UDA 的加强能力、LRA 和 HCA 的能力将成为后续的演进方向。

借助以上能力，企业可以实现：

• 分钟级 RTO：恢复时间快，阿里内部生产级别恢复时间平均在 30s 以内，外部客户生产系统恢复时间平均在 1 分钟。
• 资源充分利用：资源不存在闲置的问题，多机房多资源充分利用，避免资源浪费。
• 切换成功率高：依托于成熟的多活技术架构和可视化运维平台，相较于现有容灾架构，切换成功率高，阿里内部年切流数千次的成功率高达 99.9% 以上。
• 流量精准控制：应用多活支持流量自顶到底封闭，依托精准引流能力将特定业务流量打入对应机房，企业可基于此优势能力孵化全域灰度、重点流量保障等特性。

分布式应用治理领域的开源，不仅是能力的开源，更重要的是规范和定义的统一，AppActive 如此，OpenSergo 亦是。

在阿里云首届中间件开发者大会的会前问卷中，采用多种微服务框架或 RPC 框架混用的开发者比例达 24%。“语言和服务框架的异构会使得服务治理的成本呈现指数级的增加，一是因为每个开源框架和协议针对微服务治理的定义概念和能力都不一致，二是大家的治理模型和治理规则也是不同的，三是多云趋势下，不同云厂商提供的服务治理相关的 PaaS 服务（例如阿里云的 Serverless 应用引擎 SAE）也不同，这就会使得开发者无论是在认知还是技术迭代上都会存在非常大的限制。”OpenSergo 创始人望陶在接受 InfoQ 的采访时提到。

2022 年 4 月，OpenSergo 对外开源，该项目由阿里云、bilibili、字节，以及 Spring Cloud Alibaba、Nacos、Apache Dubbo、Sentinel、Sofa 社区共同维护，旨在构建一个和语言无关、和技术形态无关，但贴近业务的统一服务治理规范和实现。他的定位和能力就像项目的命名一样，Open 是开放的意思，Sergo 则是取了服务治理两个英文单词 Service Governance 的前部分字母 Ser 和 Go，合起来即是一个开放的服务治理项目。

OpenSergo 包含了以下三部分内容：

• 控制面：开发者可以通过 CRD 或者 Dashboard 的方式查看、修改服务治理配置，并将这些管控信息下发到数据面，从而 统一了服务治理的规则，开发者不必再绑定到某个开源方案、某个云厂商提供的服务上。
• 数据面：JavaAgent、Servcie Mesh、各个接入 OpenSergo 的微服务框架都能够接收到服务治理配置，并应用到当前的业务流量中。各个数据面都能够认可 OpenSergo 规定的服务治理配置、流量标签等信息，确保降低开发者理解成本。
• OpenSergo Spec：Spec 规定了控制面和数据面的通信约定，确保用户使用一种 Spec 即可描述不同框架、不同协议、不同语言的微服务架构，让开发者不再需要关注底层差异。

在此基础之上，再逐步将全链路灰度、无损上下线、流量打标等能力融合进来，提供一套完整的服务治理规范和实现的方案。

至此，10 个开源项目，覆盖架构到治理，将阿里云在应用中间件领域沉淀的技术倾囊而出。始于架构，精于治理。他们既是独立运行的开源项目，开发者可以搭配其他开源组件形成一套自己的开源技术栈，也是一套完整的分布式应用的开源解决方案，同时使用多个开源项目实现应用的快速交付。

开源的故事并没有就此结束，云原生对中间件游戏规则的重塑仍在持续。应用中间件的开源范畴已随容器和 Serverless 技术的普及升级到了应用云原生，他们和 Koordinator、KubeVela、OpenYurt、sealer、OpenKurise、Serverless Devs 等共同构成了阿里云在应用云原生领域的开源全景图。