写在 Dubbo go 的第五年

做者 | 于雨

阿里巴巴云原生公众号后台回复“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 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，作最懂云原生开发者的公众号。”