作者 | 於雨

阿里巴巴雲原生公眾號後臺回覆“915”即可檢視 dubbogo v1.5.1 專案管理圖清晰大圖！

引語

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 的專案管理圖 （阿里巴巴雲原生公眾號後臺回覆“915”即可檢視清晰大圖）：

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

工具是生產力，目前以 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 用例不夠豐富，繼續新增測試用例，以減小入門門檻；

希望藉助社群之力，在 dubbogo 發展過程中消化並解決掉這些問題，dubbogo 社群【釘釘群號 23331795】與 dubbogo 同在。

作者簡介

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

“ 阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”