作者 | 于雨、何鑫銘 等
引語
計算機技術浪潮每 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 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公衆号。”