Go 版本入 Dubbo 生態一週年：已和 Spring Cloud、gRPC 互通

joke59發表於2020-05-28

去年 5 月，阿里開源的高效能 RPC 框架 Dubbo 從 ASF 畢業並晉升頂級專案，同時，還宣佈 Go 語言版本的 Dubbo-go (https://github.com/apache/dubbo-go) 正式加入 Dubbo 官方生態。

經過一年的發展， Dubbo-go 在技術和社群運營方面都已經有了不錯的成績。Dubbo-go 是 Dubbo 的完整 Go 語言實現，在功能實現和技術路徑上與 Dubbo 有不同程度的對標，專案團隊預計很快便可以追平 Java 版的功能。當然，也是因為基於 Go 語言開發，Dubbo-go 更易上手，未來或將反哺 Dubbo 的雲原生化。

Dubbo-go 近期還實現了 REST 協議以及 gRPC 的支援，打通了 Spring Cloud 和 gRPC 生態，再加上與 Java Dubbo 的互通，應用場景廣泛。因此，它被其開發者叫做 “all-in-one” 的 RPC 框架。

目前 Dubbo 官方已經投入人力參與 Dubbo-go 的開發，阿里集團今年完成 HSF 和 Dubbo 的融合後，會在集團內逐步推廣使用 Dubbo-go。

開源中國採訪了當前正在開發中的 v1.5 版本的主要推進者鄧明，回顧 Dubbo-go 的過往，尤其是最近一年的發展情況，並展望專案未來的發展。

Dubbo-go 過去發展回顧

OSCHINA：作為專案主要推動者之一，可以簡單回顧下 Dubbo-go 的發展歷程嗎？

Dubbo-go 鄧明：

首先，個人代表社群，藉助貴方平臺，感謝 Dubbo-go 的使用者、曾經合作過的各個媒體平臺以及 Dubbo 官方過去一年來對我們專案的關注，Dubbo-go 目前的發展離不開各方力量的幫助。

實際上，在 Dubbo-go 加入 Dubbo 官方生態之前，已經發展了兩年。它最早由其創始人於雨在 2016 年 5 月構建，同年 9 月釋出並開源的。如下時間軸圖清晰記錄了 Dubbo-go 的前世今生。

OSCHINA：在去年專案剛加入 Dubbo 官方生態的時候，有開發團隊成員說，Dubbo-go 當時還沒能發揮出 Go 語言的優勢，功能完整性還要完善。作為一個為解決 Go 專案與 Java & Dubbo 專案互通的專案，經過一年的發展，專案現在能發揮出 Go 語言的優勢了嗎，為什麼？

Dubbo-go 鄧明：

和去年比起來，在發揮 Go 語言自身優勢上，有了很大的提高。

Go 語言協程的個數上限比 Java 執行緒數目多。Go 語言的協程只執行在使用者態，初始堆疊小且可伸縮，而 Java 執行緒啟動因使用者態系統態之間切換帶來的額外成本被執行緒池抹平，所以只有在較大併發需求的場景下（核數限制的情況下，Java 執行緒池中最大執行緒數被限制），才會發揮優勢。Dubbo 中類似的場景：非同步處理網路和協議化的處理。我們在網路庫 Getty 中加入了協程池，實現了網路收發和邏輯處理的解耦。

另外，Go 語言上手速度確實比 Java 快好幾個數量級，只要搭好具有良好擴充套件性的架子，社群 contributor 培養的成本比 Java 低很多。得益於此，Dubbo-go 的功能和效能將很快追平 Java。

OSCHINA：關於 Dubbo-go 在 Java 和 Go 執行時的相容互通和功能一致目標，目前進展如何？

Dubbo-go 鄧明：

目前，Dubbo-go 已經完全對齊 Dubbo v2.6.x，正在全力開發 v1.5.0 版本可以全面對齊 v2.7.x。

Dubbo v2.7.5 之後開始支援應用維度的服務註冊，這也是 v1.5.0 計劃支援的核心特性。

可以劇透一下，目前 v1.5.0 版本的 Dubbo-go 開發工作已經進入了尾聲，正處於測試階段。等 v1.5.0 釋出之後，我們會陸續釋出幾個小版本，用於對齊 Dubbo v2.7.5 之後的版本。可以說，v1.5.x 主要是為了配合 dubbo 的雲原生化。

OSCHINA：Dubbo-go 近期實現了 REST 協議支援，可以和 Spring Cloud 生態互聯；年初實現了和 gRPC 的互聯，這對 Dubbo-go 有什麼意義？

Dubbo-go 鄧明：

Dubbo-go 在支援了 REST 協議之後，已經可以做到跟絕大部分基於 HTTP 協議的微服務框架進行通訊。

【REST 總體設計】

另外一個突出優點是，支援了 gRPC 和 REST 之後，Dubbo-go 就可以考慮和一些公司內部自研的框架進行通訊了。通常一些比較大的公司會自研框架，或者深度定製某些開源框架。而只要它們支援 gRPC 或者 HTTP 協議，Dubbo-go 就可以保證與這些框架的無縫銜接。

還有一個優勢，REST 協議對前端更友好，可以直接把 Dubbo-go 開發的服務給前端用，而不用加一層協議轉換，也避免了前端直接發起 RPC 請求。因此，Dubbo-go 也就可以成為它們在 Go 微服務框架的一個比較優秀的選擇。

OSCHINA：1.4 版本中，Dubbo-go 在可觀測性方面採用了 tracing 和 metric，metric 的實現參考了 Dubbo 的做法，也做了一些調整，具體是怎麼樣？

Dubbo-go 鄧明：

可觀測性是衡量一個微服務框架的重要方面。一般可觀測性分成 tracing、metric 和 log 三個部分。

在 v1.4 Dubbo-go 之前，tracing 和 metric 是 Dubbo-go 的薄弱環節。為了支援這兩個，我們考察了比較多的開源框架的做法。我們發現，因為要考慮對接非常多諸如 zipkin/cat 等監控框架，所以它們往往會設計一整套監控和度量的 API。

Dubbo 也是如此。Dubbo 的 metric 比較依賴阿里內部一個開源的 metric 的專案。這個專案也不是隻能給 Dubbo 應用，而是 Java 專案都可以考慮。本質上來說，它定義了一套 API，而後提供了對不同開源框架的適配實現。把握住這一核心之後，我們就要考慮一個問題：要不要自己設計一套 API？我們的答案是 NO，並且選擇了 opentracing API 作為我們監控使用的 API。

首先，我們回顧那些自己設計了 API 的開源專案，它們的 API 和 opentracing API 還比較相像。我覺得我設計不出來一個明顯比 opentracing API 更加優雅的 API 了。

另外從實現效率上來說，如果我們使用 opentracing API 作為 Dubbo-go 接入 metric 和 tracing 的 API，那麼，任何支援 opentracing API 的框架，都可以做到開箱即用。

目前我們正在向社群使用者徵集監控意見，看社群希望我們在框架內什麼地方進一步埋點。我們也得到了很多反饋，下一步就要考慮進一步優化採集的資料。

OSCHINA：Dubbo-go 的開發團隊之前介紹，Dubbo-go 首要目的就是解決 Go 專案與 Java & Dubbo 專案的互通問題，同時也為 Go 專案提供了一種 RPC 與微服務開發框架的選擇。但從之前的使用者使用列表來看，直接把它作為 Go 的一個 RPC 框架來使用的好像並不是特別多，現在情況是這樣嗎？

Dubbo-go 鄧明：

這個情況已經有了很大的改善了。最開始的時候，我們的使用者大部分都是 Java Dubbo 那裡過來的。但是到今年，據我們瞭解，已經有一些使用者已經是直接把 Dubbo-go 作為 RPC 框架。在經過一年的發展以後，即便不考慮和 Dubbo 保持相容這一特點，Dubbo-go 也可以說一個比較優秀的 Go 語言 RPC 框架。

尤其是在異構系統通訊和服務治理方面，我們提供了非常多樣化的支援。這是很多別的 RPC 框架所不具備，或者不如我們的。

OSCHINA：總結一下這一年裡，Dubbo-go 技術方面值得了解的進展吧？

Dubbo-go 鄧明：

Dubbo-go 這一年的進步很大，實現了非常多非常重要的特性。

首先要提及的就是支援了很多協議，比如說基於 protobuf 的 gRPC 和 REST。這些協議保證了我們能夠與市面上大多數的 RPC 框架進行通訊，而且我們在 1.5.0 裡面，還擴充套件支援支援基於 Json 的 gPRC 和基於 protobuf 的 TCP 通訊。

第二則是支援了配置中心。這個功能可以提供給使用者極大的配置上的靈活性。

第三則是可觀測性上改進，也就是前面提到的 metric 和 tracing。

第四則是現在正在進行的應用註冊模型，它能讓我們更好地擁抱 k8s 和 servise mesh。為了支援應用註冊模型，我們還實現了一個後設資料中心，這個後設資料中心非常有利於做閘道器。此外還實現了很多功能，如新的限流演算法，負載均衡演算法和路由策略等。具體內容，歡迎大家去看我們的 release log。

【Dubbo-go 總體架構圖】

Dubbo-go 生態建設

OSCHINA：上個月，Go 官方公佈的最新調查報告顯示，Go 語言的主要用途包括編寫 RPC 服務，其次庫和框架方面增量巨大。“競爭對手” 變多會影響到 Dubbo-go 原本的計劃實施嗎，Dubbo-go 和其他同類專案比有什麼不同？

Dubbo-go 鄧明：

我們對 Go 社群的進步感同身受。實際上，Dubbo-go 這一年很多功能的實現，都離不開合作社群的支援。比如說我們提供的基於 Nacos 的配置中心支援，以及現在正在測試基於 Nacos 的應用維度服務註冊與發現，都十分依賴 Nacos 的 Go 語言 SDK 支援。

而且我們也注意到，別的 Go 語言的微服務框架在這一年也取得了不錯的進步，這是一種很好的鞭策。在 RPC 框架上，一直都是百家齊放百花爭鳴局面，迫使我們朝著 “人無我有，人有我精” 的方向前進。到目前來說，我們感覺我們的競爭優勢還是比較明顯的：

第一點就是保持了和 Dubbo 的相容，那麼原本的 Dubbo 使用者在考慮 Go 語言框架的時候，我們就會是首選；

第二個競爭優勢則是 支援多協議。這幾年一個很明顯的趨勢就是，一個公司的技術棧難以保持單一，因為不同框架、不同語言會有不同優點。所以 Dubbo-go 也會是那些考慮連線異構系統使用者的首選；

第三則是軟實力，也就是我們社群自身的優點。我們 社群非常有活力，使用者有什麼問題都能夠得到很快的響應；而我們的迭代速度，一直比較快。如果使用者覺得自己能夠很快獲得幫助，那麼他們也會傾向選擇我們。

OSCHINA：我們瞭解到，Dubbo-go/getty 是 Dubbo-go 中比較能體現 Go 語言優勢的部分，目前已經被解耦出來，可以直接用。Dubbo-go 的其他組成部分會考慮同樣解耦嗎？

Dubbo-go 鄧明：

這可以說是一個非常長遠和理想化的計劃了。我們現在正在做的一件事，是把專案裡面用的公共方法、和框架無關的程式碼抽取出來，做成一個工具類庫，也就是 dubbogo-gost 這個專案。

我們注意到，不管是在 Dubbo-go，還是別的框架，這些程式碼都很類似，比如說對不同型別的資料排序。之前我們找過開源的 lib，但是都不盡如人意，所以我們打算把自己的拿出來，做成類似瑞士軍刀一樣小巧高效的工具。

另外還要提到 dubbo-go-hessian2 開源倉庫。我們可以自豪地說，這個庫是 Go 裡面對 hessian v2 協議支援最好的開源庫。不僅僅是我們在用，阿里和螞蟻金服也在用。我們也希望吸引更加多使用者來使用，幫我們改進。

OSCHINA：Dubbo-go 今年 3 月 25 日的新版本 1.4.0 中 “拿出了使用 k8s 作為註冊中心的解決方案”，選擇性放棄 Service 功能，將後設資料直接寫入到 Pod 物件的 Annotations 中。為什麼做出這個決策，後續有什麼落地計劃？

Dubbo-go 鄧明：

在使用 k8s 作為註冊中心這個點上，討論就花了很長的時間。

其實最初考慮的是直接使用 k8s 服務發現模型，後來發現 k8s service 和 Dubbo-go Interface 之間存在一些難以調和的矛盾。比如說 Kubernetes 已經為其承載的服務提供了⼀套服務發現，服務註冊，以及服務叢集管理機制。⽽ Dubbo-go 也擁有⾃成體系的服務叢集管理。

這兩個功能點形成了衝突，在無法調和兩者的情況下，我們放棄了這個計劃，並且提出了現在這個隨 1.4.0 版本釋出使用的模型。

【k8s registry 設計方案】

後續，我們將主要考慮 k8s 本身提供的 CRD + Operator 的方案，畢竟越來越多的 k8s 周邊的專案都在以 Operator 作為切入點。Dubbo-go 社群後續的方案將會以 CRD 的形式在 k8s 內註冊和發現服務。這樣做的原因有很多，首先是為了減少 Dubbo-go 對 kube-apiserver 的直接依賴。其次是為了標準化註冊模型，當服務模型以 CRD 的形式存在在 k8s 叢集中之後，其他圍繞 k8s 的專案可以直接使用這些資源二次開發和擴充。而這種方式更加 CloudNative。

OSCHINA：Dubbo-go 現在在雲原生應用上的佈局是怎樣的？

Dubbo-go 鄧明：

社群的主要人力正與螞蟻金服的 mosn 社群展開合作。目前有 5 個人力與 mosn 社群一起在 mosn 中實現 Dubbo 的服務發現、服務註冊和基本的 RPC 通訊等資料平面的能力，在 istio 層面支援通過 XDS 實現配置下發，以實現 mosn + Dubbo-go 【嵌入 mosn】 + istio 這種 sidecar 形式的雲原生方案。已完成的工作已經在多點科技展開測試，近期 mosn 社群同學會在 A2M 大會上公佈具體進展。

除了 sidecar 這種 proxy 形式的雲原生方案，社群還計劃實現 Dubbo-go【應用 sdk】 + istio 這種 proxyless 方式的雲原生方案。Java 應用或者 Go 應用通過 istio 的 xDS 協議完成服務註冊和發現以及路由分發。或者說，我們力求微服務和雲原生共存，可以稱之為 “雙模微服務”。這種 “雙模微服務” 允許標準的 Dubbo-go + sidecar 和 Dubbo-go【應用 sdk】 + istio 兩種模式部署的應用共存。這將是 Dubbo-go v1.6 的核心工作。

OSCHINA：Dubbo-go 幾乎是剛一誕生就轉移到 Apache，並且很快釋出了 Apache Dubbo Go v1.1.0，這對社群運營的幫助是什麼，可以分享下 Dubbo-go 的運營情況和經驗嗎？

Dubbo-go 鄧明：

可以說，Apache 基金會對我們的幫助是很大的。

一方面，Apache 自身的光環十分有助於吸引開發關注和參與；另外一方面，Apache 的一些要求，也讓社群運營更加規範。

社群運營需要進一步規範化，透明化，以吸引更加多的人蔘與。我注意到很多優秀的社群運營做得很好，他們對 issue 的管理很細緻，打上了各種標籤，做到了對 issue 的輕重緩急的管理。這種標籤能夠很容易吸引一些打算嘗試開源的新人，給社群帶來新的血液。

我們嘗試使用 milestone 的方式來管理 Dubbo-go 的整體進度。現在也在嘗試定期召開社群會議，討論社群發展方向，重大特性的設計，以及解決爭端會議會面向整個社群，想參與的人都可以參與。

【4.26 社群會議開了攝像頭的幾位成員】

Dubbo-go 應用及規劃

OSCHINA：Dubbo-go 適合什麼樣的企業和場景？

Dubbo-go 鄧明：

我們認為，如果使用者需要一款 Go 語言方面 gRPC 框架，可以考慮 Dubbo-go；如果公司有和異構系統通訊的需求，Dubbo-go 也是一個比較好的選擇。特別是，公司內部還有 Java Dubbo 或者 Spring Clound 之類的應用，那麼 Dubbo-go 優勢就更加大了。

Dubbo-go 可以說是 " all-in-one " 性質的 RPC 框架，自身包含服務治理等功能，非常省時省力，而且能夠降低使用微服務的門檻。

OSCHINA：GitHub 的使用者列表中已經有來自 14 家企業的使用記錄，Dubbo-go 一般會提供哪些後續支援？

Dubbo-go 鄧明：

我們一直都快速響應使用者的問題，而且積極鼓勵使用者參與到 Dubbo-go 的開發中來。目前塗鴉智慧、攜程等幾家使用者已經成為了社群貢獻的主要力量。

有時候使用者來做調研，進來社群諮詢問題的時候，我們都會笑稱他 “如果選擇了 Dubbo-go，就選擇了一個強大的售後團隊”。

社群一位很活躍的 Contributor 潘總【github id: pantianying】對我們的熱情服務應該深有體會。比如他會提 issue，然後我們也會很快解決像 router、優雅退出功能就是在潘總提出之後，我們很快實現的，還有早期一次重構之後，也是潘總嚐鮮試用。嚐鮮版通常有很多 BUG，所以我們都是上班打工，下班給潘總修 BUG，也算是服務周到熱情用心了。

額外說下，目前 Dubbo 官方也已經投入人力參與 Dubbo-go 的開發，阿里集團今年完成 HSF 和 Dubbo 的融合後，會在集團內逐步推廣使用 Dubbo-go。

【潘總在分享 Dubbo-go 的實踐】

OSCHINA：Dubbo-go 下一版本預計什麼時候釋出，有沒有一些長遠的發展計劃？

Dubbo-go 鄧明：

當前正在測試的是 v1.5 版本，希望六月份能發出來。v1.6 版本正在設計和規劃中，v1.6 是和 Dubbo 3 對齊的，所以也會是一個比較大的版本。

今年我們社群主要集中在兩件事上。第一件是雲和雲原生的支援，現在進行中的 v1.5 和 v1.6 都是圍繞這一點的。今年幾乎所有大的 feature 都是這方面的。

第二件事，則是進一步提高 Dubbo-go 的文件、註釋和程式碼質量。坦白來說，Dubbo-go 的文件並不是特別好，尤其是使用者文件。我們也收到了很多使用者的批評正在加強 CI 和自動化測試這塊。總而言之，文件與質量這件事是今年的頭等大事。

OSCHINA：最後，請介紹一下自己吧。

Dubbo-go 鄧明：

說起來挺有意思的，就是我本身是業務開發，並不是傳統意義上的中介軟體開發或者基礎架構開發。我目前在 eBay 做支付業務的開發。eBay 是一個 WLB 的公司，也就是在 eBay 我才有了足夠的業餘時間，開始投入到了開源社群中。

【鄧明在 Dubbo 社群開發者日做分享】

Dubbo-go 是我第一個深入參與的開源專案，也是我第一次嘗試將個人對分散式系統和微服務治理的理解付諸實踐的專案。它是我的第一個 “孩子”。

因為工作的關係，我算是 Dubbo-go 社群投入時間最多的人之一，為 Dubbo-go 開發了一些很有意思的特性，也因此成了 Apache committer。另外我還扮演了編輯的角色，幫社群小夥伴寫的部落格文章把把關，潤潤色。我也算是 Dubbo-go 的主要管理人員了，比如說 v1.5 這個版本就是主要由我推進的——這大概還是因為我時間比較多。