闲话 dubbogo 社区
阿
于雨约 10 分钟
于雨约 10 分钟于雨 2016 年 3 月在位于上海张江的 张衡路与华佗路 交叉口的 盛大研发中心 工作时，公司大部分项目使用了 Java 技术栈，其中相当数量的服务使用了已经无人维护的 Dubbo v2.5.4-snapshot。公司老板陈大年【内部称呼 年总】觉得云原生时代来了，让大家用 Go 语言改造公司的 Java 项目。于是公司新项目纷纷使用 Go 进行构建，但面临一个很重要的问题：Go 语言服务与 Java 服务之间如何进行通信？
子曰，没有什么服务解耦是一层代理解不了的，如果一层不够，再来一层。如上图，刚开始大家给出的解决方案就是：
- 有旧的 Java 服务，如 Service0，则先再构建一个 Service0 的代理 S0-Porxy，实现公司内部通信协议与 Dubbo 服务通信协议的转换；
- 网关 Gateway 层如果检测到服务是 Go 语言构建的服务，则把请求转到 Go 网关 GoGateway Proxy；
- Go 网关 GoGateway Proxy 如果要调用旧的 Java 服务，如 Service0，则先把请求转到 S0-Porxy 代理。
这套系统运转了一个月后，相关开发和运维同学怨声载道：
- 需要给每个 Service 都实现一套 service-proxy，开发同学的代码 搬砖工作繁重；
- 整体服务链路增加了两个节点，导致 RT 上升；
- 运维同学对这套系统意见尤其大，运维成本翻倍，系统 SLO 下降；
于是有同学提出了更高明的建议：在 GoGateway Proxy 中实现 Dubbo 的泛化调用。这个技术方案的好处是可以节省掉 service-proxy 的开发维护工作，但还是会导致 RT 上升与 SLO 下降。最终大老板拍板定案：实现一个 Go 语言版本的 Dubbo，跨过 Proxy，以零通信成本方式实现 Go 与 Java 之间的互联互通。
2016 年 4 月，于雨所在的基础架构接过任务是，团队中无人懂 Go 语言，而恰好于雨此前接触过 Go 语言，陆陆续续也用 Go 做过一些小项目，自然而然地就被委以重任，开始着手构建 Dubbo 的 Go 语言版本。于雨把这个项目命名为 dubbogo，发音类似于 double-gou，恰好于某微信头像是 两只小狗，内部便把这个项目戏称为 “两条狗”。
开发第一个版本历时 3 个多月，于雨当时的加班量是同事的三倍。于某当时怀孕的媳妇只身在北京，无人照看，于某经常周末还是待在上海加班扑在这个项目上。同事们当时就说，于雨这是把 dubbogo 当做自己的孩子了。
不少人“以为” 甚至 “羡慕” dubbogo 社区的 阿里背景，有 dubbo 可以自带流量支持，甚至可以沾染 apache 的光环。但于某 2016 年开始构建 dubbogo 时，dubbo 处于无人维护的停滞状态，当时这些所谓的光环和背景，自然无从谈起。
2018 年 5 月，于某在北京见到了 dubbo 二代目北纬，开启了 dubbogo 和 dubbo 社区的合作。北纬把项目名称改为 dubbo-go，当作 dubbo 多语言生态中的一员。当时 dubbo 多语言生态有 Javascript、Php、Python，甚至有 Erlang。其中 Python 版本的 dubbo 竟然有两个不同的实现！dubbo-go 当时可能是最不起眼的存在。经过四年到现在【2022 年】，也就剩下了 dubbo-go 和 dubbo-js。现在，一般地，于某称呼社区为 “dubbogo社区”，dubbogo 社区的顶级项目有 apache/dubbo-go 和 apache/dubbo-go-pixiu。
2019 年起，阿里开源办公室如 Amber 和 Dubbo 二代目 北纬 给予了 dubbogo 社区大力支持，社区自己当然也很努力。
毋庸讳言，dubbogo 被不少公司采用，相当一部分原因是他们原来采用了 dubbo 系统，在转向云原生方向升级系统时，自然就采用了 dubbo-go。但也有不少公司原来压根就没用 dubbo，在进行系统升级改造时采用了 dubbo-go。
dubbogo 项目和社区能够发展起来，与我们社区对用户 主动跟进使用进度、第一时间解决问题 的作风不无关系，我们在支持用户的过程中可谓认真负责。下面列举于雨和 dubbogo 社区对一些客户的响应过程，以记述一些往事。
得物后台使用的是 dubbo-go 1.5 版本。dubbo-go 底层通信框架支持 TCP + Hessian2、HTTP + JsonRPC V2、gRPC + Protubuf，得物采用的技术方案是 gRPC + Protubuf。dubbo-go 的 gRPC 通信，最早是 2019 年由字节跳动的 徐建海 同学在 dubbo-go 1.2 版本中开发的。但，也仅仅是开发完成并给出了代码 samples 而已。实话说，dubbo-go 在 gRPC 这块 bug 不少，毕竟尚未经历一家公司的生产环境把它打磨一番。
得物当时跟于雨对接的是年轻有为的柯瞻同学，大家都称他 小柯。2020 年底小柯开始与于某对接时，其熟悉的开发语言是 Java，刚开始学习 Go 语言，处于入门状态。“得物 + dubbo-go” 的合作就酱紫开始了。 跟得物合作的那三个月，于雨夜里凌晨在线，陪着小柯同学上线他们基于 dubbo-go 改造的业务系统。上线过程当然并不顺利，中间坎坷自不待言，但小柯同学精力和技术热情过人，遇到的大部分问题，总能自己第一时间解决。
dubbo-go 部分的问题，小柯同学给于雨反馈后，于雨经常晚上十点下班后，拉着 dubbo 社区负责人 北纬 以及两个社区的核心开发者们一起拉起钉钉会议，一行一行代码在线会诊，直至问题得到解决。更多次，小柯同学周末会把线上运行情况与 dubbogo 社区进行对齐，追查其中网络流量抖动的原因。
新系统开发完成后，从稳定性出发在生产环境进行灰度发布，逐步将流量接入 Dubbo-go。
基于 Nacos 配置中心，将原 gRPC 客户端和 dubbo-go 的客户端封装成一个统一入口（简称 ClinetDubbo），它根据 Nacos 配置判断具体通信链路。
在切换过程中，通过 Nacos 的配置逐步灰度调整线上流量，做到出问题时可实时回滚。
得物与 dubbogo 社区的合作直至小柯确认其 平台运行平稳度 超过直接使用 gRPC 为止，此时 小柯 已经熟练掌握 Go 语言和 gRPC 与 dubbo-go。小柯后来曾说，估计很少有其他开源社区及其负责人能这样投入如此大精力在一个算是白嫖的用户身上。
2019 年 6 月中旬于某在杭州出差，其间的一个周六，于某约了 dubbogo 社区一些朋友组织了一次线下 meetup，地点是蚂蚁 Z 空间的一个会议室，阿里开源办公室的白科同学带了六七套 dubbo tshirt 算作赞助，远在成都后来入职腾讯的王翔同学线上接入。参加这次会议的有涂鸦智能的潘天颖同学，自称英文名字是 panty，绰号八戒。会后，panty 告知其打算基于 dubbo-go 构建起涂鸦的网关服务。
2019 年 12 月份，阿里在杭州召开最后一次 dubbo 专场 meetup，于某任出品人，阿里开源办公室的的 顾烜丰 同学协助，于雨同团队的 岳亮 同学一起来捧场。期间有有赞的胡子杰【后来入职蚂蚁中间件 花名 致节】、dubbo-js 作者胡锋、斗鱼的孔令圳、dubbogo社区的邓明 和 涂鸦智能的 panty，panty 专场讲了他们基于 dubbo-go 构建的 gateway。会后，北纬对这个 gateway 很感兴趣， 因为当时 dubbo 生态缺少一个 gateway，而且 dubbo 多语言生态很多项目陷入停滞 。于某拉上 panty 勾兑一番后，panty 答应构建一个初版。最终的目的是： 通过 HTTP、gRPC 接口的形式给 dubbo 用户一个多语言解决方案。
是不是感觉很眼熟？兜兜转转，又回到了第一章节中提到的基于泛化调用的代理方案。所以没有方案是完美的，只有适合场景需要的可以不断迭代计划的架构。
2020 年 2 月份 panty 提交了一个初版 demo 项目 github.com/dubbogo/dubbo-go-proxy。此后 panty 忙于跳槽找工作，把公司内部的工作交给了王文学【后入职蚂蚁中间件 花名 文徐】，这个开源项目便陷入了无人打理的状态。
2020 年 6 月份，于某觉得这个项目确实意义重大，在 dubbogo社区 钉钉群开始找人组建团队专职维护这个项目。2020 年 8 月份于某在杭州，铁城 带上 徐杨清 同学在杭州谋划了一番后便重启了项目，计划是先做 gateway，然后做 sidecar。
2021 年 3 月，dubbo-go-proxy 已经被建设的初具规模，于某计划把它迁入 apache，此时于某决定把项目改为 github.com/apache/dubbo-go-pixiu，因为貔貅是中国神兽，以对标同类的西方 Java 神兽 zuul。
2021 年一整年，于某拜托 Jimmy Song 等一众好友到处帮忙给 pixiu 找用户。此时 pixiu 的 gateway 功能已告成熟，可以接收 HTTP、DUBBO、gRPC 请求，调用后端的 HTTP、DUBBO、gRPC、SpringCloud 服务。其 sidecar 形态也完成了初步工作。
2022 年 7 月，dubbo 团队打算重新构建 dubbo 的控制面，看上了 pixiu。pixiu 团队便把 isito 1.14.3 的代码合入 pixiu，开始重新构建 dubbo service mesh 的控制面。
前面啰嗦半天，交代了 pixiu 这个产品的来历。下面重点讲述一次 pixiu 团队对客户的支持过程。
2022 年 10 月，蚂蚁内部某团队打算基于 dubbo-go 和 dubbo-go-pixiu 的 gateway 构建其一个服务平台，pixiu 基本上能够满足其需求。业界都知道蚂蚁这边 Java 技术平台是 sofa 体系，所以这次同得物一样，并不是 dubbo 流量转化来的用户。
本周三（2022年11月26日），同事告知其还有两个坎很难迈过：
1. HTTP 的 header 无法通过 pixiu 传到 代理的后端 triple 服务
- pixiu 收到客户端发来的 HTTP 请求时，HTTP header 无法以 metadata 的形式传到后端使用了 triple 通信协议的服务平台
-
issue： https://github.com/apache/dubbo-go-pixiu/issues/523
2. triple 协议泛化调用失败
- pixiu 的 triple 协议使用了 protobuf v3，但是 pixiu 调用后端的 triple 服务时，报了通信协议报错；
-
issue： https://github.com/apache/dubbo-go-pixiu/issues/523
当天晚上下班后，于某十点钉钉拉会专场支持，pixiu 团队的梦超、虓雄等筒子和蚂蚁的同学对接到凌晨两点半，总算解决其中一个问题。第二天中午吃饭时间，pixiu 团队的同学又用了 3 个小时总算把第二个问题解决。大致说下其中相关问题：
1. 第一个问题，原因是 pixiu 使用的第三方库有一个 bug，该库已经两年多不维护；
最终解决问题后，蚂蚁同事跟于某说道，pixiu 基本上满足了他们的需求，唯一不足是文档欠缺，一线开发同学在开发过程中不得不花费大量时间阅读 pixiu 的代码，好处是同事们已经把 pixiu 代码通读一遍摸透了细节。
文档建设，确实是 dubbogo 发展过程中的一个不足。但社区以另一个形式正在解决这方面的问题：
1. 2021年在北纬的带领下，构建对应 apache/dubbo-samples 的 apache/dubbo-go-samples 以及 apache/dubbo-go-pixiu-samples；
- apache/dubbo-go-samples master 分支构建 dubbogo 3.0 的示例；
- apache/dubbo-go-samples 1.5 分支构建 dubbogo 1.5 的示例；
2. 每个 dubbo-go-samples 示例都必须给出 中英双文版本 的 readme，说出其中的重要技术点以及操作步骤和使用方法；
- 3 构建 各种 tools 提升 dubbogo 的易用性，以方便用户使用 dubbo-go；
-
项目详见 https://github.com/dubbogo/tools
dubbogo 社区的新愿景是 "Bridging the gap between Dubbo and X" 。2022 年，dubbogo 社区是 边前行、边和生产用户一起打磨产品、边补文档的功课。
dubbogo 社区一直与阿里的 dubbo、nacos、sentinel、seata、rocketmq 各开源社区保持密切合作。目前 dubbogo 社区也在与腾讯 Polaris 社区的进行紧密合作，把 Polaris Mesh 强大的注册、配置以及路由能力引入 dubbogo 中，相关合作成果将在 apache/dubbo-go v3.1.0 中发布。正在计划中的与阿里云 MSE 的合作，将实现跨云的统一微服务能力，避免厂商锁定。
dubbogo 社区 【钉钉群号 23331795】 还很年轻，我们无畏风雨，不骄不躁，将秉承长期主义，在开源征途中继续长征。