寫在 Dubbo go 的第五年 引語 立項 團隊 管理 展望

引語

dubbogo 項目已進入第五個年頭。

項目發展的前兩年，我們把 hessian2 協議庫、網絡庫和整體基礎框架搭建一番。從 2018 年項目被 Dubbo 官方接納開始，依託阿里平臺，社區開始形成並快速發展。與社區同學們齊心合力之下，如今全面兼容 Dubbo v2.7.x 的 Dubbo-go v1.5.1 已經發布。

立項

一個項目整體必須提煉出核心目標，指明其存在的意義和價值。有了初心，項目發展過程中產生困惑時，才能明確答覆 “我是誰？從哪裏來？到哪裏去”。

1. dubbogo

dubbogo 項目有其自身的 milestone 要求，大致規劃了每個階段的關鍵里程碑，在項目發展初期僅僅是實現 Dubbo 的某個功能，但在發展過程中會不斷結合當下的技術發展潮流，不斷修正其未來發展方向。

其發版計劃是通過“開發當前版本、規劃新版本、根據反饋修正新版本”的模式定義當前版本的開發內容和下一個版本的發展方向。每次發版後會根據社區使用反饋對下一代的發展目標進行修正。

站在喫瓜人的角度，或許可以說出 “dubbogo 不就是 dubbo 的 Go 語言版本嘛，照着抄就是了” 之類的論調。而參與過 dubbogo 項目跟着社區一路走來的人，就知道 dubbogo 並不簡單定位於 Dubbo 項目的 Go 語言版本。

dubbogo 初心不變，不同時間對自身定位均有升級。我認爲當前 dubbogo 的定位是：

• 全面兼容 Dubbo；
• 一個 Go 語言應用通信框架，充分利用作爲雲原生時代第一語言---Go 語言的優勢，擴展 dubbo 的能力。

2. dubbo-go-proxy

dubbogo 項目初期目的是依靠 Dubbo 實現 "bridge the gap between Java and Go" ，目前 dubbogo 正與 Dubbo 齊頭並進，已經達到項目立項的目標。有長期生命的通信框架，大概有 5 年的成長期和 5 年的穩定成熟期。目前的 dubbogo 處在成長期和穩定成熟期的過渡期，這意味着社區如果想保持發展態勢，就必須開始走多元化道路，發展自己的生態了。

眼下 dubbogo 社區正在集中精力孵化一個新的項目---實現一個基於 dubbogo 的 HTTP 網關，項目的意義是：dubbogo 自身是一個流量控制中間件，在其上擴展項目，其方向很自然就是做一個 proxy/sidecar or gateway，且社區一直有網關這方面的需求。

項目目的如下：

• 做一個具有生產使用意義的網關；
• dubbo-go-proxy 驗證 dubbogo 的能力，對 dubbogo 未來的進化指出新方向，共同進化；
• 優化 dubbogo 的穩定性和性能。

團隊

項目立項完畢後，就進入招兵買馬階段了。

1. 來源

dubbogo 社區發展初期，其關鍵成員都是通過提交 issue 或者 pr 的同學撩來的。通過這種方式撩來的同學因爲志同道合，有極高的概率同社區一起走下來。dubbogo 社區的 core member 就是這樣來的。

其次是與其他公司的合作。dubbogo 本身是一個有着極高生產環境需求的項目，在發展過程中依次與攜程、塗鴉、鬥魚、虎牙、螞蟻金服和阿里集團有過極深的合作，其間與攜程的合作對 dubbogo 成型而言極爲關鍵。

另一個途徑是與其他社區合作。dubbogo 項目發展過程中，與以下社區合作過：

• 與 MOSN 社區合作實現 Dubbo Mesh；
• 與 sentinel 社區合作，在 Dubbo/Dubbo-go 完整接入 sentinel 的降級和限流方案；
• 與 Apollo 社區合作，在 Dubbo-go 中實現遠程配置下發；
• 與 Nacos 社區合作，實現基於 Nacos 的服務發現。

與其他社區合作的好處是使得雙方的項目都受益：擴展雙方的能力和使用場景，其次是社區間人員的流動。在合作過程中，dubbogo 自身受益極大，目前有 4 個社區 committer 來自於其它社區。合作完成後並不意味着結束，而是一個新的雙贏的開始：社區項目也是發展的，當一個項目有新特性時可以同時快速被另一個項目採用驗證，對擴展開發者們的技術能力和人脈也是極爲有利的，dubbogo 社區目前的好幾個同學同時活躍在多個社區。

dubbogo 項目已經過了草莽階段，形成了一個的 800 多人的社區羣，所以 dubbogo-proxy 項目立項後，很快就在社區羣內找到很多項目愛好者。

2. 成員的 qualification

項目發展初期有很多同學會 Java 不懂 Dubbo 不會 Go，最後都通過參與項目提升了自我的能力。當然有些人會擔心項目代碼的質量，但只要秉持 "Community Over Code" 這個 "Apache Way"，在發展過程中這些問題都不大。

2019 年時，參與 dubbogo 項目的成員中一部分同學平時的工作是進行業務開發，秉承着對中間件通信技術 “我是誰？我從哪裏來？要到那裏去” 的初心參與 dubbogo 的開發，無論是對 dubbogo 抑或是對其自身技術水平提升都產生了積極的影響。

dubbogo 社區對 dubbogo 發版時間有一定期限要求，所以對參與人員的時間投入也有一定的要求。每個版本的核心功能的 owner，需要保證在 deadline 期限內完成開發任務。

dubbogo 每個版本都有一個發版人，負責相應版本的任務拆分、發展跟蹤、代碼 Review 和最後的測試驗收，這就要求發版人自身的技術水平和時間投入極高。目前 dubbogo 每個大版本的發版人都不是同一個人，每次 dubbogo 發版，都意味着每個發版人的體力和精力的極大付出。於某在此致敬歷屆發版人！

管理

項目立項後，就需要明確發展大方向、發展 milestone、版本規劃、以及一段時間內的具體的開發規劃。項目發展初期，Roadmap 可以不清晰，先摸着石頭過河，在發展過程中逐步明確其內容。

1. 需求收集

dubbogo 項目發展初期，其目標僅僅是實現 dubbo 某個版本的功能， 所以其需求收集並不用花費很久時間。隨着 2019 年 8 月份發佈 v1.0 後，dubbogo 越來越多地被多家生產廠商投入生產使用環境中，目前其需求方來源如下：

• 實現 dubbo 某個版本的功能；
• 實際使用方的生產需求；
• 爲緊跟當下最近技術發展方向而進行的技術預演。

dubbogo 當前的 K8s 註冊中心技術方案就是緊跟最新技術發展方向而進行預演的極好例證，其發展時間線如下：

• 2019 年 7 月，隨着阿里集團和螞蟻金服在雲原生方向的推波助瀾，阿里 dubbo 開發團隊並未給出可靠的技術方向，dubbogo 社區 core members 也都沒有云原生方向的技術積累和相應人才，決定先開發一個基於 kube-apiserver 的註冊中心，以進行技術儲備；
• 2019 年 8 月， 調研 dubbo 的 K8s 註冊中心方案後，dubbogo 社區決定拋開它獨立實現一個，爭取以最低代價把 dubbo 應用遷移到 K8s 環境中運行起來，同時決定未來的發展方向是 dubbogo operator；
• 2019 年 11 月，社區的王翔同學給出了初步實現，在 2020 年 1 月隨 dubbogo v1.2 版本發佈；
• 2020 年 4 月，有用戶要求在 K8s 環境中 consumer 可跨 namespace 訪問 provider，相應實現在 2020 年 7 月隨着 dubbogo v1.5 版本發佈；
• 2020 年 5 月，dubbogo 社區和 mosn 社區合作實現了 dubbo mesh；
• 2020 年 6 月，社區意識到 kube-apiserver 是系統的運維態 IaaS 層的核心組件，不應該跨過 PaaS 層直接暴露給應用層，否則應用層使用不當或者框架自身的流量方面的 bug 把 kube-apiserver 打垮後將造成整個系統的 P0 級故障，dubbogo v1.6 應當給出 dubbogo operator 的具體實現；
• 2020 年 7 月，dubbogo v1.5 發佈後，社區已經知道完全可以把目前的 kube-apiserver 註冊中心的實現獨立成爲一個 dubbogo operator，未來的方向是結合 Istio 拓展其灰度發佈、限流、故障注入和配置動態下發能力。

至於 dubbo-go-proxy ，dubbogo 社區並不打算借鑑其他項目，完全依靠社區同學貢獻各自想法後，進行項目需求收集。目前 dubbogo 社區已經收集完畢 dubbo-go-proxy 的項目需求方的意見，社區已有 5 位同學參與項目一期開發，預計 10 月份發佈初版。

2. 項目管理

需求收集完畢，定義近期一段時間內的開發目標後，就進入了項目任務拆解和項目開發管理階段。像 dubbogo 和 dubbo-go-proxy 這種後來者項目，處於追趕階段，個人理解它們並沒有所謂的後發優勢，更沒有特定的技術優勢，能夠做的就是快速迭代，縮短與競品的差距。

dubbogo 要求接受開發任務的各個 feature owner 必須在某個 deadline 前完成相應的開發任務。當然，feature 的等級不同，非核心 feature 【如技術預演性的 feature】允許 delay，順延發布也無不可。

我們在項目每個版本的需求收集階段，會把愛好者統一拉入一個小羣進行溝通交流。進入開發階段時，由於項目時間 deadline 限定以及技術匹配度兩項要求，每個版本就很自然能選出能夠留下來參與項目開發的人。最終參與每個版本開發的人儘量不要超過 7 個人，否則溝通成本就會劇增。

下圖是 dubbogo v1.5.1 的項目管理圖：

其有任務分解、技術風險以及風險預案。

工具是生產力，目前以 dubbogo 項目開發進度跟蹤工具使用 Github Projects。如上圖，每個子任務進度，這個工具都會及時顯示，相應的任務 owner 可以及時根據任務進度和 deadline ，調整開發計劃。更進一步的好處是，沒有人會對工具產生意見，擺脫“交通基本靠走，通訊基本靠吼”的溝通模式，減少版本發版人和 feature owner 之間的戾氣。

3. 代碼質量

開源項目的開發任務不僅僅是開發代碼，也不意味着因爲各個 owner 僅僅是業餘時間參與開源項目就可以降低對代碼質量要求。

工具就是生產力，合適的工具能夠減少人工工作量和提升代碼質量。dubbogo 在項目開發過程中的各個階段都用到了如下工具：

• auto-comment：contributor 提出 issue 或者 pr 後，可很方便地發出預先定製的評語；
• hound：一個 Go 語言項目靜態代碼檢測工具，自動 Review 代碼；
• travis：一個 Github 項目自動化測試工具，可自動執行代碼單測和用戶自定義的集成測試，併發出釘釘通知；
• 人工 Review：dubbogo 社區要求每個 pr 至少有三個 committer 級別的人 Review 通過；
• goreportcard：一個很好的 Github 項目靜態代碼檢測工具；
• gitee：作爲國內一個比較強大的代碼託管網站，免費爲項目提供了一些代碼安全和靜態代碼質量檢測工具，dubbogo 也經常使用，受益良多；
• 代碼規範，社區內部有一份簡單的代碼規範，並隨着項目發展不斷完善。

展望

dubbogo 項目每次發完版本，發版人都會首先發出一份 "What's New"，除了總結最新版本的特性外，還會總結其近期進展並對未來發展進行規劃，以幫助項目愛好者和使用者瞭解其實現思路和使用方法。

dubbogo 自身還有很多缺點，如：

• 網站建設和文檔質量都有待改進；
• API 用戶友好度不夠；
• 配置文件過多且沒有合理的文檔說明導致入門門檻高；
• 整體性能改進，很多地方可添加調用鏈的緩存以減小鎖競爭；
• 添加 prometheus 指標，繼續提高 可觀測性；
• 在協議層面支持其他微服務框架，實現原生通信，以繼續提升其互聯互通性；
• dubbo-samples 用例不夠豐富，繼續添加測試用例，以減小入門門檻；

作者簡介

於雨，一個有十多年服務端基礎架構研發一線工作經驗的程序員，目前在螞蟻金服可信原生部從事容器編排和 service mesh 工作。熱愛開源，從 2015 年給 Redis 貢獻代碼開始，陸續改進過 Muduo/Pika/Dubbo/Dubbo-go 等知名項目。

原文鏈接
本文爲阿里雲原創內容，未經允許不得轉載。