はじめに：分散アーキテクチャとクラウドネイティブは、ミドルウェアのゲームルールを再構築しました。これにより、国内の開発者はミドルウェアを再定義する歴史的な機会を得ることができます。この記事では、アプリケーションミドルウェアの分野におけるAlibaba Cloudのコアオープンソースプロジェクトの過去、現在、未来について説明します。
分散アーキテクチャとクラウドネイティブは、ミドルウェアゲームのルールを再構築しました。これにより、国内の開発者はミドルウェアを再定義する歴史的な機会を得ることができます。
分散アーキテクチャが普及する前は、外国のITベンダーがミドルウェア市場の開発を主導し、主にクローズドソースおよびビジネスヘビーサービスの形で、クラウドコンピューティングとインターネットの普及に伴い、Ali統合RPCフレームワーク、メッセージキューを使用していました。 、サービスディスカバリ、構成センター、分散トランザクション、現在の制限とダウングレード、およびその他のコアアプリケーションミドルウェアテクノロジーは、外部にオープンソース化されているため、中国での分散アーキテクチャの実装が加速され、開発者は外部で追加の選択肢を得ることができます。春のテクノロジースタック。クラウドネイティブは、ミドルウェアをBaaSまたはSaaSの形式で表示できるようにし、分散アプリケーションアーキテクチャの実装後の容量管理、配信、運用と保守、およびディザスタリカバリにおけるミドルウェアの問題を解決します。ユーザーは標準化されたAPIを使用してミドルウェアを呼び出すことで、企業の全体的な開発と運用および保守の効率を向上させます。
この記事では、アプリケーションミドルウェアの分野におけるAlibaba Cloudのコアオープンソースプロジェクトの過去、現在、未来について説明します。長く、ストーリーラインは次のとおりです。
- Apache Dubbo：RPCフレームワークからクラウドネイティブインフラストラクチャの完全な包含までの同期アーキテクチャ通信
- Apache RocketMQ：メッセージングからストリーミングおよびイベントまでの非同期アーキテクチャ通信
- Nacos：アーキテクチャの沈下から主要コンポーネントまで、パフォーマンスのボトルネックを突破し続けており、市場シェアは50％を超えています。
- Sentinel：初めて、サービスガバナンスの分野が含まれますが、現在の制限とダウングレードに限定されません。マイルストーンバージョン2.0はまもなくリリースされます。
- Spring Cloud Alibaba：国内の開発者、Alibaba Cloud、Springに朗報
- Arthas：ツールベースのオープンソースプロジェクトであるStatは、3wを突破しようとしています
- ChaosBlade：安定したビジネスには、イベント中の現在の制限とダウングレードだけでなく、障害前のドリルも必要です
- Seata：ローカルトランザクションを使用するのと同じくらい簡単かつ効率的に分散トランザクションを使用する
- AppActive：Sentinel、ChaosBlade、AppActive、3台の高可用性キャリッジが正常に組み立てられました
- OpenSergo：成長するマイクロサービスフレームワーク混合企業のサービスガバナンスの難しさを解決する
RPCフレームワークから、クラウドネイティブインフラストラクチャを完全に採用するまで
Apache Dubbo（以下、Dubboと呼びます）は、2012年にAlibabaによってオープンソース化された分散サービスガバナンスフレームワークです。これは、中国で最も影響力があり、広く使用されているオープンソースRPCフレームワークの1つです。2017年にApache Foundationに寄贈され、正式に提供されました。 2019年に卒業しました。
ダボとコミュニティ開発者
「インキュベーターからの卒業は名誉ですが、それは終わりではなく、別の始まりです。学校に行くようなものです。卒業は学習の中断を意味するのではなく、より大きな社会的価値の始まりを意味します。卒業はより多くのことですこれは、卒業式のようなものです。つまり、Dubboチームは、成熟したオープンソースプロジェクトに対するApacheの要件を満たし、独自に開発できるようになりました。」AlibabaCloudの上級技術専門家であるBeiweiは次のように回答しました。当時のメディアへのインタビュー。
ApacheIncubatorを卒業するのは終わりではありません。鉄道の線路と同様に、サービスフレームワークは相互運用性の基盤であり、サービスフレームワークの相互運用性を解決することによってのみ、より高いレベルのビジネス相互運用性を実現できます。したがって、同じ標準の採用は、新世代のサービスフレームワーク。2021年に、Dubboはバージョン3.0を正式にリリースします。Dubbo3.0はDubbo2.0とHSFの融合であり、Alibabaの社内ビジネス、商業化、およびオープンソース向けの唯一の標準サービスフレームワークです。
ダボ公式サイトホームページより
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 达几千万，也创造了当时世界上最大的消息流转记录。
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 Spec：Specは、コントロールプレーンとデータプレーン間の通信規則を指定します。これにより、ユーザーは1つのSpecを使用して、さまざまなフレームワーク、さまざまなプロトコル、さまざまな言語のマイクロサービスアーキテクチャを記述できるため、開発者は注意を払う必要がなくなります。根本的な違い。
これに基づいて、フルリンクグレースケール、ロスレスオンラインおよびオフライン、トラフィックマーキングなどの機能が徐々に統合され、サービスガバナンス仕様と実装ソリューションの完全なセットが提供されます。
これまでに、アーキテクチャからガバナンスまでをカバーする10のオープンソースプロジェクトが、AlibabaCloudがアプリケーションミドルウェアの分野で蓄積したテクノロジーを注ぎ出しました。アーキテクチャから始めて、ガバナンスに長けてください。これらは独立したオープンソースプロジェクトであるだけでなく、開発者は他のオープンソースコンポーネントと独自のオープンソーステクノロジースタックを形成できるだけでなく、分散アプリケーション用のオープンソースソリューションの完全なセットを形成し、複数のオープンソースプロジェクトを使用して迅速なアプリケーション配信を実現できます。
オープンソースの話はそれだけではなく、ミドルウェアゲームルールのクラウドネイティブな再構築が続いています。アプリケーションミドルウェアのオープンソースカテゴリは、コンテナおよびサーバーレステクノロジーの普及により、アプリケーションクラウドネイティブにアップグレードされました。Koordinator、KubeVela、OpenYurt、シーラー、OpenKurise、Serverless Devsとともに、アプリケーションクラウドの分野におけるAlibabaCloudのオープンソースパノラマネイティブが形成されます。
最初のAlibabaCloudミドルウェア開発者会議がまもなく開催されます。会議に登録するには、ここをクリックして、中国でのミドルウェアのオープンソース採用の現状についての説明を受けてください。
元のリンク：click.aliyun.com/m/100034941…
この記事はAlibabaCloudのオリジナルコンテンツであり、許可なく複製することはできません。