简介： dubbogo 我的项目已进入第五个年头。与社区同学们齐心合力之下，现在全面兼容 Dubbo v2.7.x 的 Dubbo-go v1.5.1 曾经公布。

作者 | 于雨

阿里巴巴云原生公众号后盾回复“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 的能力。

1. 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 我的项目立项后，很快就在社区群内找到很多我的项目爱好者。

1. 成员的 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 月份公布初版。

1. 项目管理

需要收集结束，定义近期一段时间内的开发指标后，就进入了我的项目工作拆解和我的项目开发治理阶段。像 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 之间的戾气。

1. 代码品质

开源我的项目的开发工作不仅仅是开发代码，也不意味着因为各个 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 等出名我的项目。