Dubbo3.0的发布，也源自全面拥抱云原生基础设施的核心演化方向
随着K8s成为资源调度的事实标准，ServiceMesh从提出到发展至今已然渐渐被越来越多用户所接受。Dubbo这类Java微服务整治体系面临了许多新的需求，包括期望应用可以更快的启动、应用通讯的合同穿透性可以更高、能够对多语言的支持愈发友好等。为此，Dubbo3.0首次提出了全新的服务发觉模型、下一代RPC合同和适配云原生基础设施等新能力。
从Messaging到Streaming和Eventing
假如把RPC作为同步通讯的实现机制，这么消息队列可以看作是异步通讯的实现机制。不仅用于异步通讯外，消息队列能够用于前馈、削峰填谷、分布式事务等场景，这对消息队列在性能、稳定性上提出了更高的要求。
2011年，当时的双11常常会出现消息延后半天甚至三天以上，造成店家看不到卖家早已订购了的商品的问题。而解决这个问题的本质是怎样实现高速读写，但基于之前的构架，未能彻底地解决问题。这么，就须要设计一个全新的储存构架。负责全新产品设计的任务，正好落到了RocketMQ创始人&作者王小瑞头上。
但当时总共就两个人，一个人负责Notify，王小瑞则负责全新产品的设计。但开源，可以凝聚数千人、数百人、数千人一上去开发，也能吸收所有公司、行业、业务场景的需求，凝聚最大的生产力。因而，从第三天开始的时侯，RocketMQ就是托管在GitHub上，也就是说它的第一行代码就是对所有开发者和用户开放的，整个开发过程也是对用户开放的，这也吸引了非常多的开发者，你们帮助Review代码、测试Bug，RocketMQ在诸多开发者的参与下进展迅速。
2016年的那届双11，RocketMQ团队首次将低延后储存解决方案应用于双11的支撑，经受住了流量的大考，整个大促期间，99.996%的延后落在了10ms以内，完成了保障交易稳定的既定目标，对于读写比列几乎均衡的分布式消息引擎来说，这一技术上的突破，虽然是置于全球范围内，也绝对是值得赞扬的。同时，“双11”当天达到万亿级消息量，峰值TPS达几千万，也创造了当时世界上最大的消息流转记录。
RocketMQ和社区开发者们
2016年，在长达3个月的开源重构后linux命令详解词典，RocketMQ团队启动了向Apache软件基金会的捐款之路，经过近一年的努力，在2017年9月25日，Apache软件基金会官方宣布，阿里巴巴捐献给Apache社区的开源项目RocketMQ从Apache社区即将结业，成为Apache顶尖项目（TLP），这是国外首个非Hadoop生态体系的Apache社区顶尖项目。
值得一提的是，按照项目结业前的统计，RocketMQ有百分八十的新特点与生态集成来自于社区的贡献。
2021年，在经历社区诸多开发者的不断努力，RocketMQ5.0即将发布，新版本核心包括两大新亮点：
2022年，批量消息索引、逻辑队列发布RocketMQ-MQTT、RocketMQ-Connect、RocketMQ-Streams，完成了从业务消息平台向『消息、事件、流』一体化融合处理平台的升级。开发者可以实现一份消息储存，支持流式估算、异步投递、集成驱动等多个场景。实现技术问题一站式解决，大大减少技术复杂度和运维成本，简化企业应用构架。
分布式应用的落地，仅仅是一个RPC框架和一套异步消息系统是不够的，还须要一系列围绕分布式应用构架的组件。
技术人的仲夏之夜
2018年夏季，国外应用中间件开源领域，迎来了两位新成员。
作为微服务生态下的两款重要开源组件，Nacos主俘获态服务发觉、配置和服务管理，Sentinel则是聚焦在限流和降级两个方面。
Nacos和Sentinel均是在阿里10多年的核心业务场景下沉淀所形成的，她们的开源是对国外应用中间件领域开源技术方案的有效补充，同时也十分指出融入开源生态，不仅兼容Dubbo，也支持SpringCloud和Kubenetes等生态，以提高自身的生命力。
“Nacos起源于阿里巴巴内部，历经十多年双11洪峰考验的三款产品-VIPServer/Configserver/Diamond，沉淀了简单易用、稳定可靠、性能卓越的核心竞争力，并吸引了200多位优秀贡献者，共迭代44个版本，服务虎牙、好未来、小米等多家企业，在2.0的里程碑版本上，全面升级了通讯合同、服务一致性模型、支持服务网格生态和多语言生态。”彦林在Nacosstar突破2w后分享道。
Nacos2.0的发布，是Nacosstar突破2w的又一个里程碑风波。随着Nacos用户规模的下降，和用户业务日渐复杂，Nacos2.0的发布是一个必然。Nacos1.x时代：
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开源调查问卷系统，另一边是SpringCloud生态下的服务注册和发觉组件宣布停止开源投入，勇敢者的游戏饱含了变数，但在Nacos团队看来，这场游戏自己可以走到最后：在2021年某第三方媒体对注册中心开源方案采用的督查中开源调查问卷系统，Nacos的市场占有率早已超过50%。
Nacos只是阿里云诸多中间件开源项目中的一员，此后还有更多的开源项目反哺给社区，产生生态，比如轻量级限流降级组件Sentinel。
影响生产环境的稳定性诱因，从来源上看，我们一般可以归纳位两类，一类是版本发布过程中，引入的代码变更带来的风险，一类是外部不规则流量带来的风险。而Sentinel作为一款高可用范畴的开源项目，他要解决的就是外部流量造成的稳定性风险。
中间件开发者Meetup广州站
2018年7月，中间件开发者Meetup北京站现场，只能容纳400人的场地，来了近700位开发者。Sentinel创始人子矜在现场宣布了轻量级限流降级组件Sentinel的开源。“Sentinel经历了10多年双11的考验，覆盖了阿里的所有核心场景，也因而积累了大量的流量归整场景以及生产实践。Sentinel以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。”
2019年，Sentinel贡献的spring-cloud-circuitbreaker-sentinel模块即将被社区合并至SpringCloudCircuitBreaker，由此，Sentinel也加入了SpringCloudCircuitBreaker俱乐部，成为SpringCloud官方的主流推荐选择之一。开源项目须要不断延伸他的能力范畴能够保持持续的生命力，Sentinel不止于限流降级，他是否也可以帮助开发者解决新版本发布过程中的众多稳定性风险，这是即即将发布的Sentinel2.0要回答的问题。
SpringCloud官方推荐的微服务方案不止Sentinel一个，还有SpringCloudAlibaba.
2018年，中国的Java圈发生了一件大事。SpringCloud联合创始人SpencerGibb在Spring官网的博客页面宣布：阿里巴巴开源SpringCloudAlibaba，并发布了首个预览版本。随即，SpringCloud官方Twitter也发布了此消息。
来自SpringCloud官方Twitter
SpringCloudAlibaba项目由两部份组成：阿里巴巴开源组件和阿里云产品组件，借以为Java开发人员在使用阿里云产品的同时，通过借助Spring框架的设计模式和具象能力，注入SpringBoot和SpringCloud的优势。
SpringCloud本身是一套微服务规范，并不是一个用来即可用的框架，而SpringCloudAlibaba的开源为开发者们提供了这套规范的实现方法，而这些实现方法对调用阿里云的资源和云产品能力非常友好，这对国外开发者、阿里云、Spring三方来说，都是一个好消息。
夏季之后，开源的热度仍在延续
效率的用处在于，我们可以把自己的注意力和时间聚焦在更须要创造力的事情上，做更有成就感的事情。对于工作在工程领域的开发者们而言，她们的效率意识更强。
2018年9月，阿里将内部广泛使用的Java线上确诊工具进行开源，起名Arthas(阿尔萨斯)。其实是击中了开发者线上排查问题的痛点，Arthas在距离开源后的第一个Release版发布仅147天，就获得了超过1w的star数，并有40多位Contributors参与开源贡献。
ArthasContributors
从中，我们除了见到Arthas这类工具型开源项目在开发者群体中的受欢迎程度，也发觉越来越多的国外开发者开始参与开源贡献，并视为一种社区荣誉。技术领域，一切里程碑的达成，都缘于一份技术情结。截至目前，Arthas已有接近3wstar和146位Contributors，这对一款线上确诊工具而言，是一份不错的答卷。
时间来到2019年。
假如把生产阶段称作中考，这么Sentinel解决的是事中的稳定性问题，一旦出现流量徒增，可以通过限流和降级来应对，而2019年开源的Chaosblade则是更多从事前的方法来提升构架的高可用性，通过构建故障演习机制，把各种可以预见的故障提早演习下来，比如随机杀节点、延时响应，甚至中断机房。
Chaosblade和Sentinel师出同门，源自阿里在全链路压测、线上流量管控、故障演习上沉淀的这一套高可用核心技术。阿里云资深技术专家中亭说道：“阿里因其多样化的业务场景和日渐复杂的技术构架，会碰到各色各样的故障，故障整治的难度增量了几个台阶。Chaosblade从2011年开始，经历了强弱依赖的整治和建设、同城容灾演习、在交易和中间件链路尝试演习三个阶段，经过6年多的打磨，最终将最佳实践和工具框架产生统一的标准，对外进行开源红旗linux5.0，帮助DevOps人员减短建立混沌工程的路径。”
在微服务构架普遍落地的明天，分布式事务带来的数据一致性问题、性能问题越来越绕不开。分布式事务理解上去有点门槛，但却无处不在，他是相对本地事务而言的，服务和服务之间不须要跨网路才能完成的，称之为本地事务，须要跨网路能够完成的，称之为分布式事务，比如金融行业建行之间的汇款业务须要跨网路就能完成，电商行业交易下单调用外部库存系统、物流系统须要跨网路能够完成等。
尽管业内有一些分布式事务开源的解决方案，但要么是性能差、要么是数据一致性不够、要么是侵入性高，不容易落地。反正，是有点“不爽”。
宣布Seata开源的Meetup现场
而这些“不爽”集中反映在了分布式事务开源中间件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没多久，双11的规模较上年进一步飞增。阿里的工程师正面临以下两大困局，一方面是机房资源十分紧张，容量不足，另一方面是广州出现罕见的低温天气，机房面临断电的风险，异地多活构架就是在这个背景下孵化下来的。后来，随着网店的业务规模变迁，异地多活也从近距离同城双机房到远距离异地双活，再到三地四单元、多地多活，沉淀了丰富的机房级应用多活经验。
AppActive的开源，一是希望给多活提供一个统一的规范和定义，在这个基础上，你们能够共享成熟的实践经验，以防止因认知误差带来的企业在基础设施成本、应用改建成本、运维成本等成本面的投入，因而让“多活”成为一项事实意义的普惠技术；二是基于标准，提供各个层次多活能力的实现。
在应用多活的规范中，定义了LRA（同城多活）、UDA（异地多活）、HCA（混和云多活）和BFA（业务流量多活）4层能力。在AppActive发布的第一个版本里，提供了BFA和UDA的基础能力，BFA和UDA的强化能力、LRA和HCA的能力将成为后续的演化方向。
利用以上能力，企业可以实现：
分布式应用整治领域的开源，除了是能力的开源，更重要的是规范和定义的统一，AppActive这般，OpenSergo亦是。
在阿里云首届中间件开发者会议的会前问卷中，采用多种微服务框架或RPC框架混用的开发者比列达24%。“语言和服务框架的异构会促使服务整治的成本呈现指数级的降低，一是由于每位开源框架和合同针对微服务整治的定义概念和能力都不一致，二是你们的整治模型和整治规则也是不同的，三是阵雨趋势下，不同云厂商提供的服务整治相关的PaaS服务（比如阿里云的Serverless应用引擎SAE）也不同，这都会促使开发者无论是在认知还是技术迭代上就会存在特别大的限制。”OpenSergo创始人望陶在接受InfoQ的访谈时谈到。
2022年4月，OpenSergo对外开源，该项目由阿里云、bilibili、字节，以及SpringCloudAlibaba、Nacos、ApacheDubbo、Sentinel、Sofa社区共同维护，致力打造一个和语言无关、和技术形态无关，但紧贴业务的统一服务整治规范和实现。他的定位和能力犹如项目的命名一样，Open是开放的意思，Sergo则是取了服务整治两个英语词组ServiceGovernance的前部份字母Ser和Go，合上去即是一个开放的服务整治项目。
OpenSergo包含了以下三部份内容：
在此基础之上，再逐渐将全链路灰度、无损上下线、流量打标等能力融合进来，提供一套完整的服务整治规范和实现的方案。
至此，10个开源项目，覆盖构架到整治，将阿里云在应用中间件领域沉淀的技术倾囊而出。源于构架，精于整治。她们既是独立运行的开源项目，开发者可以搭配其他开源组件产生一套自己的开源技术栈，也是一套完整的分布式应用的开源解决方案，同时使用多个开源项目实现应用的快速交付。
开源的故事并没有就此结束，云原生对中间件游戏规则的塑造仍在持续。应用中间件的开源范畴已随容器和Serverless技术的普及升级到了应用云原生，她们和Koordinator、KubeVela、OpenYurt、sealer、OpenKurise、ServerlessDevs等共同构成了阿里云在应用云原生领域的开源全景图。
原文链接：
