阿里云中间件开源往事

在分布式架构流行前，国外 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：解决日益增长的微服务框架混用企业的服务治理难

从 RPC 框架到全面拥抱云原生基础设施

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

Dubbo 和社区开发者们

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

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

来自 Dubbo 官网首页

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

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

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

从 Messaging 到 Streaming 和 Eventing

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

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

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

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