很多開發者一直以來好奇：阿里自己有沒有在用Dubbo，會不會用Dubbo？在剛剛結束的雙11，我們了解到阿里雲今年提出了“三位一體”的理念，即將“自研技術”、“開源項目”、“商業產品”形成統一的技術體系，最大化技術的價值。終於，在2020的雙11，阿里巴巴經濟體也用上了Dubbo！本文是阿里雙十一在考拉大規模落地 Dubbo3.0 的技術分享，系統介紹了 Dubbo3.0 在性能、穩定性上對考拉業務的支撐。
覃柳傑（花名：未宇）Github ID: qinliujie，Apache Dubbo PMC；阿里巴巴微服務框架 HSF 負責人，負責 HSF 研發及 Dubbo 在阿里的落地。
HSF 是阿里內部的分布式的服務框架，作為集團中間件最重要的中間件之一，歷經十多屆雙十一大促，接受萬億級別流量的錘煉，十分的穩定與高效。另外一方面，Dubbo 是由阿里中間件開源出來的另一個服務框架，並且在 2019 年 5 月以頂級項目身份從 Apache 畢業，坐穩國內第一開源服務框架寶座，擁有非常廣泛的用戶群體。
在集團業務整體上雲的大背景下，首要挑戰是完成 HSF 與 Dubbo 的融合，以統一的服務框架支持雲上業務，同時在此基礎上衍生出適應用下一代雲原生的服務框架 Dubbo 3.0,最終實現自研、開源、商業三位一體的目標。今年作為 HSF&Dubbo 融合之后的 Dubbo 3.0 在集團雙十一落地的第一年，在兼容性、性能、穩定性上面都面臨着不少的挑戰。可喜的是，在今年雙十一在考拉上面大規模使用，表現穩定，為今后在集團大規模上線提供了支撐。
Dubbo 3.0 總體方案
在上面的方案中，可以看出來我們是以 Dubbo 為核心，HSF 作為功能擴展點嵌入到其中，同時保留 HSF 原有的編程 API，以保證兼容性。為什么我們選址以 Dubbo 為核心基礎進行融合，主要這兩點的考量：
1.Dubbo 在外部擁有非常廣泛的群眾基礎，以 Dubbo 為核心，符合開源、商業化的目標；
2.HSF 也經歷過核心升級的情況，我們擁有比較豐富的處理經驗，對於 Dubbo 3.0 新核心內部落地也是處於可控的范圍之內。
選定這個方案之后，我們開始朝着這個方向努力，由於 Dubbo 開源已久，不像 HSF 這樣經歷過超大規模集群的考驗驗證，那么我們是如何去保證它的穩定性呢？
穩定性
為了保證新核心的穩定，我們從各個方面進行鞏固，保證萬無一失
1.功能測試
HSF3 共有集成用例數百個， 100% 覆蓋到了 HSF 的核心功能；HSF3 的單測共有上千個，行覆蓋率達到了 51.26%
2.混沌測試
為了面對突發的異常情況，我們也做了相應的演練測試，例如 CS 注冊中心地址停推空保護測試、異常注入、斷網等情況，以此驗證我們的健壯性；例如，我們通過對部份機器進行斷網，結果我們發現有比較多的異常拋多。
原因是 Dubbo 對異常服務端剔除不夠及時，導致還會調用到異常服務器，出現大量報錯。
同時，我們也構建了突發高並發情況下的場景，發現了一些瓶頸，例如：
瞬間大並發消耗掉絕大部分 CPU 。
3.性能優化
Dubbo 核心之前未經歷過超大規模集團的考驗，性能上面必將面臨着巨大的挑戰；對於 Dubbo 來說，優化主要從地址推送鏈路和調用服務鏈路兩個鏈路來進行。對於地址推送鏈路，主要是減少內存的分配，優化數據結構，減少靜態時地址占用內存對應用的影響，從而減少 ygc/fgc 造成的抖動問題。我們利用測試同學提供的風暴程序，模擬了反復推送海量地址的場景，通過優化，120萬個 Dubbo 服務地址常態內存占用從 8.5G 下降到 1.5G，有效降低 GC 頻率
另外一方面，在調用鏈路上，我們主要對選址過程、LoadBalacer、Filter 等進行優化，總體 CPU 下降達到 20%，RT 也有一個比較明顯的下降。
成果
在雙十一考拉零點高峰，某個 Dubbo 接口，總的流量達到了數百萬次/每分鍾 ,全程穩定順滑，達到了預定的目標，Dubbo 3.0 是至重啟開源以來，首次在這么大規模的場景進行驗證，充分證明了 Dubbo 3.0 的穩定性。
結語
在本次雙11考拉落地 Dubbo 3.0 只是在阿里內部全面落地 Dubbo3.0 的第一步，現在 Dubbo 3.0 雲原生的新特性也如火如荼的進行開發與驗證，如應用級服務發現、新一代雲原生通信協議 Triple 等已經開始在集團電商應用開始進行 Beta 試點。
阿里微服務體系完成了通過開源構建生態和標准，通過雲產品 MSE、EDAS 等完成產品化和能力輸出，通過阿里內部場景鍛煉高性能和高可用的核心競爭力。從而完成了三位一體的正向循環，通過標准持續輸出阿里巴巴的核心競爭力，讓外部企業快速享有阿里微服務能力，加速企業數字化轉型！
原文鏈接
本文為阿里雲原創內容，未經允許不得轉載。