寫在 Dubbo go 的第五年

時間 2021-02-18

標籤 git 程序員 github apache api 緩存安全網絡架構併發欄目 Dubbo 简体版

原文原文鏈接

做者 | 於雨git

阿里巴巴雲原生公衆號後臺回覆「915」便可查看 dubbogo v1.5.1 項目管理圖清晰大圖！程序員

引語

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

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

立項

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

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 之間的戾氣。