Dubbo-go 发布 1.5 版，朝云原生迈出关键一步
作者 | 于雨、何鑫銘 等
引語
計算機技術(shù)浪潮每 10 年都有一次技術(shù)顛覆，相關(guān)知識體系最遲每 5 年都會革新一次，大概每兩年貶值一半，在應(yīng)用服務(wù)通信框架領(lǐng)域亦然。凡是有長期生命的通信框架，大概有 5 年的成長期和 5 年的穩(wěn)定成熟期。每個時代都有其匹配的應(yīng)用通信框架，在 20 年前的 2G 時代，強跨語言跨平臺而弱性能的 gRPC 是不會被采用的。
每個通信框架，不同的人從不同角度看出不同的結(jié)論：初學(xué)者看重易用易學(xué)，性能測評者注重性能，應(yīng)用架構(gòu)師考慮其維護(hù)成本，老板則考慮則綜合成本。一個應(yīng)用通信框架的性能固然重要，其穩(wěn)定性和進(jìn)化能力更重要，得到有效維護(hù)的框架可在長時間單位內(nèi)降低其綜合成本：學(xué)習(xí)成本、維護(hù)成本、升級成本和更換成本。
**什么是 Dubbo-go？**第一，它是 Dubbo 的 Go 語言版本，全面兼容 Dubbo 是其第一要義；第二，它是一個 Go 語言應(yīng)用通信框架，會充分利用作為云原生時代第一語言—Go 語言的優(yōu)勢，擴(kuò)展 dubbo 的能力。
2008 年誕生的 Dubbo 已有十多年歷史，依靠阿里和其社區(qū)，歷久彌新。2016 年發(fā)布的 Dubbo-go 也已進(jìn)入第五個年頭，如今全面兼容 Dubbo v2.7.x 的 Dubbo-go v1.5 終于發(fā)布了。
回首過往，Dubbo-go 已經(jīng)具備如下能力：
- 互聯(lián)互通：打通了 gRPC 和 Spring Cloud 生態(tài)；
- 可觀測性：基于 OpenTracing ?和 Prometheus，使得其在 Logging、Tracing 和 Metrics 方面有了長足進(jìn)步；
- 云原生：Dubbo-go 實現(xiàn)了基于 Kubernetes API Server 為注冊中心的通信能力，做到了升級成本最低。
毋庸諱言，相較于現(xiàn)有成績，發(fā)展階段的 Dubbo-go 對未來有更多的期待之處：
-
易用性：Dubbo-go 的入門成本并不低，把很多感興趣者擋在了門外，但好消息是，隨著 Dubbo-go 在阿里內(nèi)部的逐步推開，阿里中間件團(tuán)隊對其進(jìn)行了進(jìn)一步的封裝，經(jīng)生產(chǎn)環(huán)境檢驗后會開放給社區(qū)使用；
-
云原生：目前的 Dubbo-go 的基于 kubernetes 的方案，從技術(shù)分層角度來看， Kubernetes API Server 終究是系統(tǒng)的運維態(tài)組件，不應(yīng)該暴露給應(yīng)用層，否則會造成 APIServer 自身通信壓力過大，且系統(tǒng)整體風(fēng)險很高：應(yīng)用層使用不當(dāng)，或者框架自身的流量方面的 bug，可能會把 APiServer 打垮，后果就是造成整體后端服務(wù)能力的癱瘓！所以應(yīng)用層需要感知的是 Kubernetes 提供給應(yīng)用層的 Operator，不斷進(jìn)化的 Dubbo-go 計劃在 v1.6 版本中發(fā)布 Dubbo-go Operator。
雄關(guān)漫道真如鐵，而今邁步從頭越。Dubbo-go 社區(qū)**【釘釘群 23331795】**與 Dubbo-go 同在。
應(yīng)用維度注冊模型
經(jīng)過一段時間的努力之后，我們終于完成了應(yīng)用維度的服務(wù)注冊與發(fā)現(xiàn)。和原本已有的接口維度的注冊模型比起來，新的注冊模型有兩個突出特點：
- 和主流的注冊模型保持一致。目前的主流做法都是按照應(yīng)用為基本單位來進(jìn)行注冊的，如 Spring Cloud。在支持應(yīng)用維度注冊之后，對于接下來的云原生支持，奠定了基礎(chǔ)；
- 大幅度減輕對注冊中心的壓力。在該模型之下，從注冊中心的視角看過去，集群規(guī)模只和實例數(shù)量成正比，而不是現(xiàn)有的和服務(wù)數(shù)量成正比；
當(dāng)然，我們在設(shè)計的時候就考慮到了用戶的遷移成本。要遷移到新的注冊模型，只需要將現(xiàn)有使用的注冊中心換成新的 ServiceDiscoveryRegistry 就可以。
ServiceDiscoveryRegistry 是支持多種實現(xiàn)的。目前來說，我們支持：
- nacos
- etcd
- zookeeper
我們提倡新上線的業(yè)務(wù)盡量使用 nacos 和 etcd 這種更可靠穩(wěn)定的注冊中心。
Metadata Report 元數(shù)據(jù)中心
v1.5 版本在支持應(yīng)用維度注冊模型時，有很重要的一個問題需要解決，即接口維度的元數(shù)據(jù)存儲。服務(wù)維度的注冊模型和應(yīng)用維度的注冊模型，本質(zhì)的區(qū)別是往注冊中心注冊的數(shù)據(jù)維度的不一致。雖然我們在應(yīng)用維度注冊模型中，將接口維度的數(shù)據(jù)從注冊中心中剔除了，但是在 rpc 的框架中，一個 consumer 要想真正找到想要調(diào)用的服務(wù)地址，就必須得到 provider 端開放的服務(wù)信息。這部分?jǐn)?shù)據(jù)，在 v1.5 版本中，我們將它們存儲到了元數(shù)據(jù)中心中。
元數(shù)據(jù)中心，是一個接口定義。泛指一塊存儲區(qū)域，可以對接口級別的元數(shù)據(jù)進(jìn)行存儲、讀取，provider 端調(diào)用存儲，consumer 端調(diào)用讀取。元數(shù)據(jù)中心中的數(shù)據(jù)需要保持準(zhǔn)確性、實時性。
目前元數(shù)據(jù)中心，有兩個父類（Go 中沒有繼承，此處說的父子類，單純指子類對父類的組合關(guān)系）實現(xiàn)，一個是 local 實現(xiàn)，一個是 remote 實現(xiàn)。local 實現(xiàn)是將 provider 的內(nèi)存作為虛擬元數(shù)據(jù)中心，remote 實現(xiàn)是指依賴 ZooKeeper、etcd、nacos 等注冊中心作為元數(shù)據(jù)中心。目前 remote 有 zookeeper、nacos、etcd 和 consul 的子類實現(xiàn)。即用戶可以將元數(shù)據(jù)信息，通過以上的第三方注冊中心進(jìn)行數(shù)據(jù)存儲和分發(fā)。
Invocation 接口支持 attribute 屬性
invocation 結(jié)構(gòu)中新增 attribute 屬性支持，用于流程內(nèi)部的屬性存儲。和 attachment 不同點在于，attachment會從 consumer 傳遞到 provider，但 attribute 屬性不會。
K8s 注冊中心
在 v1.5 版本之前，K8s 注冊中心的實現(xiàn)是通過直接使用 K8s client 中 Pod 對象的 List&&Watch 接口。在本次迭代中引入了 K8s informer。這樣做的原因在于兩點，首先一定的程度上來講 dubbo-go 的 K8s 注冊中心也是一個 K8s controller，使用 informer 的模式更加 K8s native。更重要的是社區(qū)計劃后續(xù)向 CRD+Operator 的模式演進(jìn)，informer 模式是對后續(xù)的演進(jìn)的探索。除了這個鋪墊之外，本次迭代還對跨 namespace 的服務(wù)發(fā)現(xiàn)做了支持。再有就是為了減少對 kube-apiserver List&&Watch 的壓力，對 provider 和 consumer 的行為進(jìn)行了區(qū)分，provider 不再進(jìn)行 Watch 而僅對 kube-apiserver 進(jìn)行寫操作。
優(yōu)化路由模型
在 1.5 版本之前，Router 模型中屬性是包含：優(yōu)先級與路由屬性，Router Chain 只包含路由屬性。從中能識別出其實 Router Chain 也是一種特殊 Router。1.5 版本之后，使 Router 更抽象，分離出其優(yōu)先級屬性，新增 Priority Router、Chain 繼承 Router 使其變?yōu)樘厥獾?Router，使關(guān)系上看起來更加清晰。如下圖：
回顧與展望
Dubbo-go 處于一個比較穩(wěn)定成熟的狀態(tài)。目前新版本正處于往云原生方向的嘗試，應(yīng)用服務(wù)維度注冊是首先推出的功能，這是一個和之前模型完全不一樣的新注冊模型。該版本是我們朝云原生邁進(jìn)新一步的關(guān)鍵版本。除此之外，包含在該版本也有一些之前提到的優(yōu)化。
下一個版本 v1.5.1，雖然仍是以兼容 Dubbo 2.7.x 為主要任務(wù)，但在分布式能力的增強上，也是我們關(guān)注的重點。
在分布式事務(wù)方面，有一個重要的基于 Seata 擴(kuò)展實現(xiàn)。通過增加過濾器，在服務(wù)端接收 xid 并結(jié)合 seata-golang 達(dá)到支持分布式事務(wù)的目的。?從而使 Dubbo-go 在分布式場景下，讓用戶有更多的選擇，能適應(yīng)更多的個性化場景。
與此同時，在傳輸鏈路安全性上，TLS 安全傳輸鏈路是該版本重要功能之一。通過提供統(tǒng)一入口，未來能引入更多的與傳輸鏈路安全性相關(guān)的功能，適應(yīng)用戶不一樣的使用場景。
注冊中心模型上，支持多注冊中心集群負(fù)載均衡。業(yè)務(wù)部署假設(shè)是雙注冊中心（圖 1 ），從原來雙注冊中心中所有 Provider 一起選址。優(yōu)化成選址時的多了一層注冊中心集群間的負(fù)載均衡（圖 2 ）。
（圖 1 ）
（圖 2 ）
以前的 dubbo-go RPC 層直接復(fù)用了 getty 框架 的 RPC，未能實現(xiàn)協(xié)議和應(yīng)用通信地址的隔離。阿里中間件展圖同學(xué)重構(gòu)了 dubbo-go ?RPC 層，實現(xiàn)了連接復(fù)用：可以實現(xiàn) consumer 與 provider 端的同一個 TCP 連接上進(jìn)行多協(xié)議通信。相關(guān) PR 業(yè)已合并，會在 dubbo-go v1.5.1 中發(fā)布。
目前下一個版本正在緊鑼密鼓的開發(fā)中，具體規(guī)劃及任務(wù)清單?，都已經(jīng)在 Github 上體現(xiàn)。
“阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢、云原生大規(guī)模的落地實踐，做最懂云原生開發(fā)者的公眾號。”
總結(jié)
以上是生活随笔為你收集整理的Dubbo-go 发布 1.5 版，朝云原生迈出关键一步的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 阿里产品专家：高情商的技术人，如何做沟通
- 下一篇： Arthas 征文活动火热进行中，che