作者 | 於雨、何鑫銘 等

引語

計算機技術浪潮每 10 年都有一次技術顛覆，相關知識體系最遲每 5 年都會革新一次，大概每兩年貶值一半，在應用服務通訊框架領域亦然。凡是有長期生命的通訊框架，大概有 5 年的成長期和 5 年的穩定成熟期。每個時代都有其匹配的應用通訊框架，在 20 年前的 2G 時代，強跨語言跨平臺而弱效能的 gRPC 是不會被採用的。

每個通訊框架，不同的人從不同角度看出不同的結論：初學者看重易用易學，效能測評者注重效能，應用架構師考慮其維護成本，老闆則考慮則綜合成本。一個應用通訊框架的效能固然重要，其穩定性和進化能力更重要，得到有效維護的框架可在長時間單位內降低其綜合成本：學習成本、維護成本、升級成本和更換成本。

什麼是 Dubbo-go？第一，它是 Dubbo 的 Go 語言版本，全面相容 Dubbo 是其第一要義；第二，它是一個 Go 語言應用通訊框架，會充分利用作為雲原生時代第一語言—-Go 語言的優勢，擴充套件 dubbo 的能力。

2008 年誕生的 Dubbo 已有十多年曆史，依靠阿里和其社群，歷久彌新。2016 年釋出的 Dubbo-go 也已進入第五個年頭，如今全面相容 Dubbo v2.7.x 的 Dubbo-go v1.5 終於釋出了。

回首過往，Dubbo-go 已經具備如下能力：

• 互聯互通：打通了 gRPC 和 Spring Cloud 生態；
• 可觀測性：基於 OpenTracing 和 Prometheus，使得其在 Logging、Tracing 和 Metrics 方面有了長足進步；
• 雲原生：Dubbo-go 實現了基於 Kubernetes API Server 為註冊中心的通訊能力，做到了升級成本最低。

毋庸諱言，相較於現有成績，發展階段的 Dubbo-go 對未來有更多的期待之處：

• 易用性：Dubbo-go 的入門成本並不低，把很多感興趣者擋在了門外，但好訊息是，隨著 Dubbo-go 在阿里內部的逐步推開，阿里中介軟體團隊對其進行了進一步的封裝，經生產環境檢驗後會開放給社群使用；

• 雲原生：目前的 Dubbo-go 的基於 kubernetes 的方案，從技術分層角度來看， Kubernetes API Server 終究是系統的運維態元件，不應該暴露給應用層，否則會造成 APIServer 自身通訊壓力過大，且系統整體風險很高：應用層使用不當，或者框架自身的流量方面的 bug，可能會把 APiServer 打垮，後果就是造成整體後端服務能力的癱瘓！所以應用層需要感知的是 Kubernetes 提供給應用層的 Operator，不斷進化的 Dubbo-go 計劃在 v1.6 版本中釋出 Dubbo-go Operator。

雄關漫道真如鐵，而今邁步從頭越。Dubbo-go 社群 【釘釘群 23331795】與 Dubbo-go 同在。

應用維度註冊模型

經過一段時間的努力之後，我們終於完成了應用維度的服務註冊與發現。和原本已有的介面維度的註冊模型比起來，新的註冊模型有兩個突出特點：

• 和主流的註冊模型保持一致。目前的主流做法都是按照應用為基本單位來進行註冊的，如 Spring Cloud。在支援應用維度註冊之後，對於接下來的雲原生支援，奠定了基礎；
• 大幅度減輕對註冊中心的壓力。在該模型之下，從註冊中心的視角看過去，叢集規模只和例項數量成正比，而不是現有的和服務數量成正比；

當然，我們在設計的時候就考慮到了使用者的遷移成本。要遷移到新的註冊模型，只需要將現有使用的註冊中心換成新的 ServiceDiscoveryRegistry 就可以。

ServiceDiscoveryRegistry 是支援多種實現的。目前來說，我們支援：

• nacos
• etcd
• zookeeper

我們提倡新上線的業務儘量使用 nacos 和 etcd 這種更可靠穩定的註冊中心。

Metadata Report 後設資料中心

v1.5 版本在支援應用維度註冊模型時，有很重要的一個問題需要解決，即介面維度的後設資料儲存。服務維度的註冊模型和應用維度的註冊模型，本質的區別是往註冊中心註冊的資料維度的不一致。雖然我們在應用維度註冊模型中，將介面維度的資料從註冊中心中剔除了，但是在 rpc 的框架中，一個 consumer 要想真正找到想要呼叫的服務地址，就必須得到 provider 端開放的服務資訊。這部分資料，在 v1.5 版本中，我們將它們儲存到了後設資料中心中。

後設資料中心，是一個介面定義。泛指一塊儲存區域，可以對介面級別的後設資料進行儲存、讀取，provider 端呼叫儲存，consumer 端呼叫讀取。後設資料中心中的資料需要保持準確性、實時性。

目前後設資料中心，有兩個父類（Go 中沒有繼承，此處說的父子類，單純指子類對父類的組合關係）實現，一個是 local 實現，一個是 remote 實現。local 實現是將 provider 的記憶體作為虛擬後設資料中心，remote 實現是指依賴 ZooKeeper、etcd、nacos 等註冊中心作為後設資料中心。目前 remote 有 zookeeper、nacos、etcd 和 consul 的子類實現。即使用者可以將後設資料資訊，通過以上的第三方註冊中心進行資料儲存和分發。

Invocation 介面支援 attribute 屬性

invocation 結構中新增 attribute 屬性支援，用於流程內部的屬性儲存。和 attachment 不同點在於，attachment會從 consumer 傳遞到 provider，但 attribute 屬性不會。

K8s 註冊中心

在 v1.5 版本之前，K8s 註冊中心的實現是通過直接使用 K8s client 中 Pod 物件的 List&&Watch 介面。在本次迭代中引入了 K8s informer。這樣做的原因在於兩點，首先一定的程度上來講 dubbo-go 的 K8s 註冊中心也是一個 K8s controller，使用 informer 的模式更加 K8s native。更重要的是社群計劃後續向 CRD+Operator 的模式演進，informer 模式是對後續的演進的探索。除了這個鋪墊之外，本次迭代還對跨 namespace 的服務發現做了支援。再有就是為了減少對 kube-apiserver List&&Watch 的壓力，對 provider 和 consumer 的行為進行了區分，provider 不再進行 Watch 而僅對 kube-apiserver 進行寫操作。

優化路由模型

在 1.5 版本之前，Router 模型中屬性是包含：優先順序與路由屬性，Router Chain 只包含路由屬性。從中能識別出其實 Router Chain 也是一種特殊 Router。1.5 版本之後，使 Router 更抽象，分離出其優先順序屬性，新增 Priority Router、Chain 繼承 Router 使其變為特殊的 Router，使關係上看起來更加清晰。如下圖：

回顧與展望

Dubbo-go 處於一個比較穩定成熟的狀態。目前新版本正處於往雲原生方向的嘗試，應用服務維度註冊是首先推出的功能，這是一個和之前模型完全不一樣的新註冊模型。該版本是我們朝雲原生邁進新一步的關鍵版本。除此之外，包含在該版本也有一些之前提到的優化。

下一個版本 v1.5.1，雖然仍是以相容 Dubbo 2.7.x 為主要任務，但在分散式能力的增強上，也是我們關注的重點。

在 分散式事務方面，有一個重要的基於 Seata 擴充套件實現。通過增加過濾器，在服務端接收 xid 並結合 seata-golang 達到支援分散式事務的目的。 從而使 Dubbo-go 在分散式場景下，讓使用者有更多的選擇，能適應更多的個性化場景。

與此同時，在 傳輸鏈路安全性上，TLS 安全傳輸鏈路是該版本重要功能之一。通過提供統一入口，未來能引入更多的與傳輸鏈路安全性相關的功能，適應使用者不一樣的使用場景。

註冊中心模型上，支援多註冊中心叢集負載均衡。業務部署假設是雙註冊中心（圖 1 ），從原來雙註冊中心中所有 Provider 一起選址。優化成選址時的多了一層註冊中心叢集間的負載均衡（圖 2 ）。

（圖 1 ）

（圖 2 ）

以前的 dubbo-go RPC 層直接複用了 getty 框架 的 RPC，未能實現協議和應用通訊地址的隔離。阿里中介軟體展圖同學重構了 dubbo-go RPC 層，實現了連線複用：可以實現 consumer 與 provider 端的同一個 TCP 連線上進行多協議通訊。相關 PR 業已合併，會在 dubbo-go v1.5.1 中釋出。

目前下一個版本正在緊鑼密鼓的開發中， 具體規劃及任務清單 ，都已經在 Github 上體現。

“ 阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”