网站类网站开发教程,微信小程序表单制作,企业管理培训课程安排,wordpress默认字体改黑色分布式架构和云原生重塑了中间件的游戏规则#xff0c;这给国内开发者提供了重新定义中间件的历史机遇。
在分布式架构流行前#xff0c;国外 IT 厂商引领着中间件市场的发展#xff0c;且以闭源、重商业的服务形式为主#xff1b;随着云计算和互联网的普及#xff0c;阿…分布式架构和云原生重塑了中间件的游戏规则这给国内开发者提供了重新定义中间件的历史机遇。
在分布式架构流行前国外 IT 厂商引领着中间件市场的发展且以闭源、重商业的服务形式为主随着云计算和互联网的普及阿里将 RPC 框架、消息队列、服务发现、配置中心、分布式事务、限流降级等核心应用中间件技术对外开源加速了分布式架构在国内的落地也使得开发者在 Spring 技术栈以外多了一种选择。而云原生则实现了中间件以 BaaS 或 SaaS 的形态出现解决了分布式应用架构落地后中间件在容量管理、交付、运维、容灾上的难题使用者通过标准化的 API 就可以完成对中间件的调用从而提升企业整体的开发和运维效率。
本文讲述了阿里云在应用中间件领域核心开源项目的过去、现在和未来篇幅较长故事线罗列如下
Apache Dubbo同步架构通信从 RPC 框架到全面拥抱云原生基础设施Apache RocketMQ 异步架构通信从 Messaging 到 Streaming 和 EventingNacos从架构下沉到关键组件持续突破性能瓶颈市场占有率已经超过50%Sentinel首次涉及服务治理领域但不止于限流降级即将发布里程碑版本2.0Spring Cloud Alibaba对国内开发者、阿里云、Spring 三方来说都是一个好消息Arthas一款工具型开源项目Stat 即将突破 3wChaosBlade业务稳定不仅需要事中限流降级更需要事前故障演练Seata让分布式事务的使用像本地事务的使用一样简单和高效AppActiveSentinel、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 代码、测试 BugRocketMQ 在众多开发者的参与下进展迅速。
2016 年的那届双 11RocketMQ 团队首次将低延迟存储解决方案应用于双 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 框架和一套异步消息系统是不够的还需要一系列围绕分布式应用架构的组件。
技术人的仲夏之夜
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 三方来说都是一个好消息。
夏天过后开源的热度仍在延续
效率的好处在于我们可以把自己的注意力和时间聚焦在更需要创造力的事情上做更有成就感的事情。对于工作在工程领域的开发者们而言他们的效率意识更强。
2018 年 9 月阿里将内部广泛使用的 Java 线上诊断工具进行开源取名 Arthas (阿尔萨斯)。也许是击中了开发者线上排查问题的痛点Arthas 在距离开源后的第一个 Release 版发布仅 147 天就获得了超过 1w 的 star 数并有 40 多位 Contributors 参与开源贡献。 Arthas Contributors
从中我们不仅看到 Arthas 这类工具型开源项目在开发者群体中的受欢迎程度也发现越来越多的国内开发者开始参与开源贡献并视为一种社区荣誉。技术领域一切里程碑的达成都源于一份技术情怀。截止目前Arthas 已有接近 3w star 和 146 位 Contributors这对一款线上诊断工具而言是一份不错的答卷。
时间来到 2019 年。
如果把生产阶段比作高考那么 Sentinel 解决的是事中的稳定性问题一旦出现流量徒增可以通过限流和降级来应对而 2019 年开源的 Chaosblade 则是更多从事前的方式来提高架构的高可用性通过建立故障演练机制把各类可以预见的故障提前演练出来例如随机杀节点、延时响应甚至中断机房。
Chaosblade 和 Sentinel 师出同门源自阿里在全链路压测、线上流量管控、故障演练上沉淀的这一套高可用核心技术。阿里云资深技术专家中亭说道“阿里因其多元化的业务场景和日益复杂的技术架构会遇到各式各样的故障故障治理的难度增量了几个台阶。Chaosblade 从 2011 年开始经历了强弱依赖的治理和建设、同城容灾演练、在交易和中间件链路尝试演练三个阶段经过 6 年多的打磨最终将最佳实践和工具框架形成统一的标准对外进行开源帮助 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 没多久双十一的规模较上年进一步飞增。阿里的工程师正面临以下两大难题一方面是机房资源非常紧张容量不足另一方面是杭州出现罕见的高温天气机房面临断电的风险异地多活架构就是在这个背景下孵化出来的。后来随着淘宝的业务规模演进异地多活也从近距离同城双机房到远距离异地双活再到三地四单元、多地多活沉淀了丰富的机房级应用多活经验。
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 SpecSpec 规定了控制面和数据面的通信约定确保用户使用一种 Spec 即可描述不同框架、不同协议、不同语言的微服务架构让开发者不再需要关注底层差异。在此基础之上再逐步将全链路灰度、无损上下线、流量打标等能力融合进来提供一套完整的服务治理规范和实现的方案。 至此10 个开源项目覆盖架构到治理将阿里云在应用中间件领域沉淀的技术倾囊而出。始于架构精于治理。他们既是独立运行的开源项目开发者可以搭配其他开源组件形成一套自己的开源技术栈也是一套完整的分布式应用的开源解决方案同时使用多个开源项目实现应用的快速交付。
开源的故事并没有就此结束云原生对中间件游戏规则的重塑仍在持续。应用中间件的开源范畴已随容器和 Serverless 技术的普及升级到了应用云原生他们和 Koordinator、KubeVela、OpenYurt、sealer、OpenKurise、Serverless Devs 等共同构成了阿里云在应用云原生领域的开源全景图。
原文链接
本文为阿里云原创内容未经允许不得转载。
