去年5月，阿里開源的高性能 RPC 框架 Dubbo 從 ASF 畢業並晉升頂級項目，同時，還宣佈 Go 語言版本的 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三個部分。
[http://peter.bourgon.org/img/instrumentation/01.png]
在 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 這個版本就是主要由我推進的——這大概還是因爲我時間比較多。
【2019.04 社區成員會師阿里討論發展方案，相談甚歡】
【2019.12上海 gopher 方銀城在分享 Dubbo-go】
【2019.06上海 meetup】
【2019.12.28 Dubbo 社區開發者日】
本文轉載自公衆號開源中國（ID：oschina2013）。
原文鏈接：