服務架構就像鐵路的鐵軌一樣，是互通的基礎，隻有解決了服務架構的互通，才有可能完成更高層的業務互通，是以用相同的标準統一，合二為一并共建新一代的服務架構是必然趨勢。
Dubbo3.0 是 Dubbo2.0 與 HSF 融合而來，是阿裡經濟體面向内部業務、商業化、開源的唯一标準服務架構。
阿裡巴巴服務架構的選擇與實踐
Dubbo 和 HSF 在阿裡巴巴的實踐
Dubbo 和 HSF 都是阿裡巴巴目前在使用的微服務 RPC 架構。
Dubbo 則在 2011 年開源後，迅速成為業界廣受歡迎的微服務架構産品，在國内外均有着廣泛應用。Dubbo 項目誕生于 2008 年，起初隻在一個阿裡内部的系統使用；2011 年，阿裡 B2B 決定将整個項目開源，僅用了一年時間就收獲了來自不同行業的大批使用者；2014 年，由于内部團隊調整，Dubbo 暫停更新；2017 年 9 月，Dubbo 3.0 重新開機開源，在 2019 年 5 月由 Apache 孵化畢業，成為第二個由阿裡巴巴捐獻至 Apache 畢業的項目。
HSF 在阿裡巴巴使用更多，承接了内部從單體應用到微服務的架構演進，支撐了阿裡曆年雙十一的平穩運作；自 2008 年 5 月釋出第一個版本 1.1 後，經曆數年疊代，HSF 從一個基礎的 RPC 架構逐漸演變成為日支撐十萬億級别調用的易于擴充的微服務架構。内部場景中，使用者既可以選擇少量配置輕松接入微服務體系，擷取高性能的穩定服務調用。也可以按照自身業務需求，對 HSF 進行擴充，擷取整條鍊路的能力增強。
對于集團内的需求而言，穩定和性能是核心，是以，當時選型了在電商這種高并發場景久經考驗的 HSF 做為新一代服務架構核心。随後，HSF 推出了 2.0 的版本，并針對 HSF 之前版本的主要問題進行重構改造，降低了維護成本，進一步提高了穩定性和性能。HSF2.0 解決了通訊協定支援不透明，序列化協定支援不透明等架構擴充性問題。基于 HSF2.0 的 Java 版本，集團内也演進出了 CPP/NodeJs/PHP 等多語言的用戶端。由于 HSF 還相容了 Dubbo 的協定，原有的 Dubbo 使用者可以平滑地遷移到新版本上，是以 HSF 推出後很快就在集團全面鋪開，部署的 server 數量達到數十萬，基本完成了阿裡巴巴内部微服務架構的統一，并經曆了多年雙十一零點流量洪峰的驗證。
下一代微服務的挑戰和機遇
然而，業務的發展和架構自身的疊代使得兩個架構從協定層的簡單相容已經無法滿足需要。随着雲計算的不斷發展和雲原生理念的廣泛傳播，微服務的發展有着以下趨勢：
- K8s 成為資源排程的事實标準，Service Mesh 從提出到發展至今已經逐漸被越來越多使用者所接受。屏蔽底層基礎設施成為軟體架構的一個核心演進目标，無論是阿裡巴巴還是其他企業使用者，所面臨的問題都已經從是否上雲變為如何平滑穩定地低成本遷移上雲。
- 由于上雲路徑的多樣以及由現有架構遷移至雲原生架構的過渡态存在，部署應用的設施靈活異變，雲上的微服務也呈現出多元化的趨勢。跨語言、跨廠商、跨環境的調用必然會催生基于開放标準的統一協定和架構，以滿足互通需求。
- 端上對背景服務的通路呈爆炸性的趨勢增長，應用的規模和整個微服務體系的規模都随之增長。
這些趨勢也給 HSF 和 Dubbo 帶來了新的挑戰。
HSF 和 Dubbo 面臨的挑戰
微服務架構是基礎元件，大部分公司在早期選型或業務發展到一定規模的時候都需要确定使用某一個架構。而一個穩定高效的自研架構通常需要較長時間的疊代來打磨優化。是以大部分公司初期都會傾向于使用開源元件。對阿裡雲而言，這就帶來了一個問題：内部使用的是 HSF 架構，而雲上的使用者大部分都是使用的開源 Dubbo 架構，兩種架構在協定、内部子產品抽象、程式設計接口和功能支援上都存在差異。
如何能讓使用了 HSF 的阿裡集團内部元件的最優實踐和前沿技術更簡單直接地輸出到雲上，這是每一個做技術商業化的同學都會遇到和必須解決的問題。其實我們也有過一些探索，雲上微服務最早推的是 HSF 架構，閉源元件在雲上輸出的時候，對于許多使用者而言，遇到問題後無從排查，整個服務架構對于他們來說是一個黑盒的元件。我們發現這并不是一個很好的産品化方向，在雲上輸出的時候，我們必須選擇擁抱開源的方式，主推 Dubbo 與 Spring Cloud 架構。
同時在集團内也因為同時存在 HSF 與 Dubbo 架構而導緻的不少問題。原有部門或公司的技術棧如何更快地融入到現有技術體系是一個繞不開的問題。一個典型的例子就是 2019 年加入阿裡巴巴的考拉。考拉之前一直使用 Dubbo 作為微服務架構，基于 Dubbo 建構了大規模的微服務應用，遷移的成本高，風險也大。需要集團和考拉的基礎架構部門耗費較長的時間進行遷移前調研、方案設計，確定基本可行後再開始改動。從分批灰階上線，再到最終全量上線。這種換血式的改動不僅需要耗費大量人力，時間跨度也很長，會影響到業務的發展和穩定性。同時由于曆史原因，集團内部始終存在着一定數量的 Dubbo 使用者。為了更好的服務這部分使用者，HSF 架構對 Dubbo 進行了協定層和 API 層的相容。但這種相容僅限于互通，随着 Dubbo 開源社群的多年發展，這種基礎的相容在容災、性能和可疊代性方面，都有着較大的劣勢，同時很難對齊 Dubbo 的服務治理體系。在穩定性方面也存在風險，更無法享受到集團技術發展和 Dubbo 社群演進的技術紅利。
産生這些問題的根本原因是閉源的 HSF 無法直接用于廣大雲上使用者和外部其他使用者，而開源産品對閉源産品的挑戰會随着開源和雲的不斷發展愈演愈烈。越早解決這個問題，阿裡巴巴和外部企業使用者的雲原生遷移成本越低，産生的價值也就越大。
是以，HSF 和 Dubbo 的融合是大勢所趨。為了能更好的服務内外使用者，也為了兩個架構更好發展，Dubbo3.0 和以 Dubbo3.0 為核心适配集團内基礎架構生态的 HSF3.0 應運而生。
三位一體戰略下服務架構的最終選擇 Dubbo3.0
Dubbo3.0 在原有功能集與 API 完全相容的前提下，同時具備了以下幾大面臨雲原生挑戰下的新特性
- Dubbo 3.0 支援全新的服務發現模型，Dubbo 3.0 嘗試從應用模型入手，優化存儲結構，對齊雲原生主流設計模型，避免在模型上帶來的互通問題。新模型在資料組織上高度壓縮，能有效提高性能和叢集的可伸縮性。
- Dubbo 3.0 提出了下一代 RPC 協定 —— Triple。這是一個基于 HTTP/2 設計的完全相容 gRPC 協定的開放性新協定，由于是基于 HTTP/2 設計的，具有極高的網關友好型和穿透性；完全相容 gRPC 協定是的天然在多語言互通方面上具有優勢。
- Dubbo 3.0 面向雲原生流量治理，提出了一套能夠覆寫傳統 SDK 部署、Service Mesh 化部署、VM 虛拟機部署、Container 容器部署等場景的統一治理規則，支援一份規則治理大部分場景，大大降低流量治理治理成本，使得異構體系下全局流量治理變得可能。
- Dubbo 3.0 将提供接入 Service Mesh 的解決方案，面向 Mesh 場景，Dubbo 3.0 提出了兩種接入方式，一種是 Thin SDK 模式，部署模型和目前 Service Mesh 主流部署場景完全一樣，而 Dubbo 将進行瘦身，屏蔽掉與 Mesh 相同的治理功能，僅保留核心的 RPC 能力；第二種是 Proxyless 模式，Dubbo 将接替 Sidecar 的工作職責，主動與控制面進行通信，基于 Dubbo 3.0 的統一治理規則應用雲原生流量治理功能。
服務架構在阿裡雲商業化方向上的演進思路
對于微服務架構來說，由于關聯到客戶的業務代碼，要做商業化還是有非常大的挑戰的。
首先，遷移成本上來說，希望把降低遷移成本為 0，最開始我們在雲上售賣的是 HSF + EDAS Container 這一套的架構，是以客戶在上雲的時候，不得不對自己的業務代碼進行改造，另外，由于代碼不開源，排查問題也是一個非常頭疼的問題，後來，我們發現客戶大多數的微服務架構都會選擇開源的 Dubbo/Spring Cloud，但是客戶有自建的注冊中心，如果要上雲還需要把自己的注冊中心遷移到 MSE 注冊中心上，這個過程需要使用者對代碼做改造才行，一般來說會采用雙注冊的方案，在雲上我們發現推動客戶做代碼改造，包括 SDK 的更新是一件非常難的事情，很多客戶的 Dubbo 版本還停留在 4-5 年的版本，不僅需要研發、測試、運維都來關注，還需要排期支援，這個動作會耗費大量的人力資源，同時面臨許多穩定性的挑戰。光是這一步就會阻擋住許多的客戶了，為了解決客戶 SDK 更新的問題，我們在想，能不能不要遷移注冊中心呢，最好是代碼一行也不用改，部署到雲上來，但我們又需要提供同等的服務治理能力，是以，我們提出了基于 Java Agent 位元組碼增強的技術，幫助使用者不改一行代碼使用雲産品，對客戶做到了随時可上可下，沒有綁定，讓客戶比較放心的上雲産品，同時我們還提供了能力更強的面運維的托管的注冊中心。
對于商業化中微服務架構的選擇，我們選擇的态度一直是擁抱開源。
我們還需要在開源微服務架構的基礎上提供差異化的服務治理能力，傳統開源微服務架構在 K8s 上的問題在上雲的過程中逐漸暴露出來。通過一系列和客戶的交流，我們總結出了客戶的雲原生下進行微服務治理的幾大痛點，主要包括微服務釋出過程中的無損上下線，标簽路由，服務鑒權，離群執行個體摘除，全鍊路灰階等等，我們通過 Java Agent 技術實作了在使用者不改代碼的情況下，解決了上述問題，通過客戶交流，收集需求，落到産品，給客戶 demo 驗證這個模式跑通了正向的循環，功能不斷豐富中。除了Java Agent，對于多語言的場景我們使用 Service Mesh、WASM 等技術，同樣支援客戶無需修改一行代碼，就具備于 Java 應用一緻的服務治理能力與體驗。
同時在Java Agent 的選擇上我們也有過一些嘗試跟選擇，一開始我們使用閉源開發的 Java Agent，每個雲産品都有一個對應的 Java Agent，這樣會導緻 Java Agent 過多以及Agent沖突等問題，同時由于我們自己維護的 Java Agent 又是閉源的。踩過一些坑後，我們決定使用 Arthas One Agent 重構服務治理體系的 Agent，将治理相關的 Agent 合成一個，同時我們底座的 Java Agent 也使用擁抱開源的政策，我們使用開源的 Arthas One Agent。
Dubbo3.0 順應了這個方向，通過 Dubbo3.0 + Java Agent 将集團技術發展和 Dubbo 社群演進、以及商業化實踐的技術紅利不斷且持續地輸出給雲上的客戶。
服務治理無縫支援 Dubbo3.0
阿裡雲上微服務治理相關的三種解決方案：MSE(微服務引擎，提供微服務治理的能力)、EDAS(全生命周期托管的應用平台)、SAE(具備彈性伸縮能力的Serverless 應用平台)，EDAS 與 SAE 均深度內建了 MSE 服務治理能力；其中 MSE 所有的服務治理能力都是開箱即用，支援近五年來市面上所有開源 Dubbo、Spring Cloud 架構，包括 Dubbo 3.0 您無需修改一行代碼與配置，您隻需将您的 Dubbo 3.0 的應用接入 EDAS/MSE/SAE。包括微服務釋出過程中的無損上下線能力，對齊了微服務與 K8S POD 的生命周期；标簽路由能力弱化了對 IP 的綁定依賴，服務鑒權，離群執行個體摘除，全鍊路灰階，服務 Mock、服務監控、服務契約等等。
如何将一個 HSF 應用無縫更新成 Dubbo 3.0 應用
三位一體是阿裡巴巴“自研”、“開源”、“商業化”采用統一技術體系，在此技術方向下，Dubbo3.0 的設計與落地實作了 HSF/Dubbo 的技術統一，在集團内也正在快速推廣落地中。同時 EDAS Container 4.x版本，正是 Dubbo3.0 的商業化輸出形式之一。
如果您的應用在 EDAS 或者 SAE 上，使用的是 HSF + EDAS Container 這一套的架構，使用者隻需更新容器版本至 4.x 就可以便捷的将 HSF 應用更新為 Dubbo 3.0 應用。更新之後，HSF 應用可沿用原有開發方式，還可以使用 EDAS/SAE 為 Dubbo 應用提供的更加完善的服務治理功能。同時您的HSF應用也将會具備 Dubbo 3.0 的各種新特性、應用級服務發現、Triple 協定等。
Java 微服務 Proxyless Mesh 架構
在異構微服務場景下，随着 ServiceMesh 方案的普及，原先微服務應用如何在 Service Mesh 微服務架構中與其他 Mesh 節點進行互通以及治理能力對齊成了困擾使用者的問題。開源 Spring Cloud / Dubbo 架構在MSE微服務引擎上無需增加 Envoy，同時也無需修改任何一行代碼就可以與 Mesh 架構互通。
Dubbo3.0 的大規模生産實踐案例
Dubbo3.0 在落地的過程中，我們具備許多大規模的實踐，考拉、釘釘等。
下面以釘釘為例介紹
背景
為了擁抱容器化、享受雲上的福利，釘釘文檔在 2020 年啟動了上雲戰役。目前已有 50% 的流量，跑在公有雲叢集。
業務挑戰
文檔的上雲，分成了兩個階段。
第一階段，彈内（即阿裡集團内網絡）和雲上各有一個文檔叢集：彈内叢集承接存量業務；雲上叢集承接增量業務。彈内叢集同時起了代理的功能：對彈内的上遊服務來說，彈内叢集代理了對文檔雲上叢集的調用；對雲上叢集來說，彈内服務代理了集團内下遊的依賴。
第一階段：彈内、雲上各有一個叢集
第二階段，存量資料遷移到了雲上，隻保留雲上叢集。上遊服務、下遊依賴，都是通過 triple 協定直接調用。
第二階段：隻有一個雲上叢集
目前我們處于第一階段。
在第一階段，我們有幾個訴求：
1、希望使用一套代碼，跑在彈内、雲上兩個叢集；
2、希望彈内叢集繼續使用 HSF 協定；
3、希望雲上使用開源的 RPC 協定；
4、希望雲上、彈内叢集，可以互通。
而 Dubbo 3.0，完美的契合我們的需求。
落地方案
1、雙叢集
文檔目前有兩個叢集。彈内叢集暴露了 triple、hsf 雙協定，雲上叢集僅暴露 triple 協定。
彈内的版本号保持 1.0.0 不變，雲上使用 1.0.0.ZJK 的版本号。
對上遊服務來說，隻有彈内一個叢集，所有流量都是打到彈内叢集。這樣上遊業務無需做任何改造。
2、單元化路由
彈内服務，對到來的 HSF 請求進行攔截。如果解析出需要将請求路由到雲上，則對雲上服務發起一次 triple 調用。否則，繼續将請求交給彈内的服務。
3、下遊依賴
文檔有一些對彈内服務的依賴，去除不掉。目前的做法，是文檔自己把下遊服務做一次封裝，暴露出 triple 協定，供雲上調用。
4、服務治理
服務互通完成了之後，就是開始看如何進行服務治理了。包括服務查詢、服務測試、服務壓測、服務限流、服務監控等。
4.1 MSE
服務查詢、服務測試、服務路由等，都是通過接入 MSE 完成的。這裡要特别提一下 MSE 的服務測試。業務同學最開始是在本機 curl hsf 的 http 端口進行測試，非常麻煩，但是在接入 MSE 服務治理之後，就可以直接用 MSE 平台的服務測試功能。服務測試即為使用者提供一個雲上私網 Postman ，讓使用者能夠輕松調用自己的服務。使用者無需感覺雲上複雜的網絡拓撲結構，無需關系服務的協定，無需自建測試工具，隻需要通過控制台即可實作服務調用。支援 Dubbo 3.0 架構，以及 Dubbo 3.0 主流的 Triple 協定。
4.2 其他
由于雲上使用了标準的 Dubbo 協定，Ahas、Arms 等中間件，都可以無縫的接入。
總結
釘釘文檔借助三位一體的紅利實作三個月内快速上雲，通過雲産品方式産品化标準化地解決了上雲過程中遇到的問題，借助 Dubbo3.0 的雲原生特性，以及 MSE 服務治理能力的快速接入與支援，快速完成服務架構從互通到治理的落地。
尾
自研、商用、開源的“三位一體”，使得我們在 雙11 中沉澱的核心技術可以直接給到客戶使用，省略了經過雲上沉澱再輸出的過程，降低了客戶擷取 “雙11 同款技術引擎” 的門檻和成本，可幫助客戶快速邁入數字原生時代。Dubbo3.0 正是在這個戰略下的選擇，Dubbo3.0 和基于 Dubbo3.0 核心的 HSF 正在外部和内部齊頭并進，為阿裡雲上、集團内、以及開源的使用者提供最佳的使用者體驗，一起參與來打造最穩定的服務架構，在雲原生時代下引領微服務的發展。
掃描下方二維碼加群（釘釘搜群号34754806）觀看本次直播回放，或者移步直播間觀看：
https://yqh.aliyun.com/live/detail/26399 阿裡雲 MSE 雲産品已內建Dubbo微服務治了解決方案點選下方連結，即刻上手體驗！
https://mp.weixinbridge.com/mp/wapredirect?url=https%3A%2F%2Fwww.aliyun.com%2Fproduct%2Faliware%2Fmse