阿里云中间件开源往事
技术琐话 2022-08-22 08:33 发表于北京
分布式架构和云原生重塑了中间件的游戏规则，这给国内开发者提供了重新定义中间件的历史机遇。
在分布式架构流行前，国外 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：解决日益增长的微服务框架混用企业的服务治理难
01
从 RPC 框架到全面拥抱云原生基础设施
Aliware
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 协议是的天然在多语言互通方面上具有优势。这也解决了上一代协议中生态不互通、协议头无法再承载更多元数据信息的问题。
02
从 Messaging 到 Streaming 和 Eventing
Aliware
如果把 RPC 作为同步通信的实现机制，那么消息队列可以看作是异步通信的实现机制。除了用于异步通信外，消息队列还能用于解耦、削峰填谷、分布式事务等场景，这对消息队列在性能、稳定性上提出了更高的要求。
2011 年，当时的双 11 经常会出现消息延迟半天甚至一天以上，导致商家看不到买家已经购买了的商品的问题。而解决这个问题的本质是如何实现高速读写，但基于之前的架构，无法彻底地解决问题。那么，就需要设计一个全新的存储架构。负责全新产品设计的任务，刚好落到了 RocketMQ 创始人&作者王小瑞身上。
但当时总共就两个人，一个人负责 Notify，王小瑞则负责全新产品的设计。但开源，可以汇聚数百人、数千人、数万人一起来开发，也能吸收所有公司、行业、业务场景的需求，汇聚最大的生产力。因此，从第一天开始的时候，RocketMQ 就是托管在 GitHub 上，也就是说它的第一行代码就是对所有开发者和用户开放的，整个开发过程也是对用户开放的，这也吸引了特别多的开发者，大家帮助 Review 代码、测试 Bug，RocketMQ 在众多开发者的参与下进展迅速。
2016 年的那届双 11，RocketMQ 团队首次将低延迟存储解决方案应用于双 11 的支撑，经受住了流量的大考，整个大促期间，99.996% 的延迟落在了 10ms 以内，完成了保障交易稳定的既定目标，对于读写比例几乎均衡的分布式消息引擎来说，这一技术上的突破，即便是放在全球范围内，也绝对是值得称赞的。同时，“双 11”当天达到万亿级消息量，峰值 TPS 达几千万，也创造了当时世界上最大的消息流转记录。
RocketMQ 和社区开发者们
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 框架和一套异步消息系统是不够的，还需要一系列围绕分布式应用架构的组件。
03
技术人的仲夏之夜
Aliware
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%。
Nacos 和社区开发者们
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 作为一款高可用范畴的开源项目，他要解决的就是外部流量导致的稳定性风险。
中间件开发者 Meetup 深圳站
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 官方 Twitter
Spring Cloud Alibaba 项目由两部分组成：阿里巴巴开源组件和阿里云产品组件，旨在为 Java 开发人员在使用阿里云产品的同时，通过利用 Spring 框架的设计模式和抽象能力，注入 Spring Boot 和 Spring Cloud 的优势。
Spring Cloud 本身是一套微服务规范，并不是一个拿来即可用的框架，而 Spring Cloud Alibaba 的开源为开发者们提供了这套规范的实现方式，而这种实现方式对调用阿里云的资源和云产品能力十分友好，这对国内开发者、阿里云、Spring 三方来说，都是一个好消息。
