分散式架構和雲原生重塑了中介軟體的遊戲規則，這給國內開發者提供了重新定義中介軟體的歷史機遇。

在分散式架構流行前，國外 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 達幾千萬，也創造了當時世界上最大的訊息流轉記錄。

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 規定了控制面和資料面的通訊約定，確保使用者使用一種 Spec 即可描述不同框架、不同協議、不同語言的微服務架構，讓開發者不再需要關注底層差異。

在此基礎之上，再逐步將全鏈路灰度、無損上下線、流量打標等能力融合進來，提供一套完整的服務治理規範和實現的方案。

至此，10 個開源專案，覆蓋架構到治理，將阿里雲在應用中介軟體領域沉澱的技術傾囊而出。始於架構，精於治理。他們既是獨立執行的開源專案，開發者可以搭配其他開源元件形成一套自己的開源技術棧，也是一套完整的分散式應用的開源解決方案，同時使用多個開源專案實現應用的快速交付。

開源的故事並沒有就此結束，雲原生對中介軟體遊戲規則的重塑仍在持續。應用中介軟體的開源範疇已隨容器和 Serverless 技術的普及升級到了應用雲原生，他們和 Koordinator、KubeVela、OpenYurt、sealer、OpenKurise、Serverless Devs 等共同構成了阿里雲在應用雲原生領域的開源全景圖。

原文連結：http://click.aliyun.com/m/1000349413/

本文為阿里雲原創內容，未經允許不得轉載。