作者 | 于雨
阿裡巴巴雲原生公衆号背景回複“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 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公衆号。”