今年5月，穆萨开放源码的高效能 RPC 架构 Dubbo 从 ASF 大学毕业并晋升为世界顶级工程项目，同时，还正式宣布宣布 Go 词汇版的 Dubbo-go 正式宣布重新加入 Dubbo 非官方自然生态。
历经一年的产业发展， Dubbo-go 在控制技术和街道社区营运方面都早已有了极好的战绩。Dubbo-go 是 Dubbo 的完备 Go 词汇同时实现，在机能同时实现和控制技术方向上与 Dubbo 有不同某种程度的Kanniyakumari，工程项目项目组预计今年迅速便能追平 Java 版的机能。总之，也原因在于如前所述 Go 词汇合作开发，Dubbo-go 较易入门，今后或将赋能 Dubbo 的云原分子生物。
Dubbo-go 上周还同时实现了 REST 协定以及 gRPC 的全力支持，贯通了 Spring Cloud 和 gRPC 自然生态，再加之与 Java Dubbo 的互联互通，应用领域情景广为。因此，它被其合作开发人员叫作“all-in-one”的 RPC 架构。
目前 Dubbo 非官方早已资金投入物力参予 Dubbo-go 的合作开发，穆萨集团公司今年顺利完成 HSF 和 Dubbo 的结合后，会在集团公司内全面推广使用 Dubbo-go。
开放源码中国专访了现阶段正在合作开发中的 v1.5 版的主要就Rupununi白培生，简述 Dubbo-go 的甚或，特别是前段时间一年的产业发展情况，并展望未来工程项目今后的产业发展。
Dubbo-go 往后产业发展简述
OSCHINA：作为工程项目主要就实践者之一，能单纯简述下 Dubbo-go 的产业发展心路历程吗？
Dubbo-go白培生：
具体来说
事实上，在 Dubbo-go 重新加入 Dubbo 非官方自然生态以后，早已产业发展了一年。它最先由其创办人于雨在2016年5月构筑，翌年9月正式发布并开放源码的。如下表所示本篇图明晰历史记录了 Dubbo-go 的今生今生。
OSCHINA：在今年工程项目刚重新加入 Dubbo 非官方自然生态的时候，有合作开发项目组核心成员说，Dubbo-go 彼时还未能充分发挥出 Go 词汇的优势，机能完备性还要完善。作为一个为解决 Go 工程项目与 Java & Dubbo 工程项目互通的工程项目，历经一年的产业发展，工程项目现在能充分发挥出 Go 词汇的优势了吗，为什么？
Dubbo-go 白培生：
和今年比起来，在充分发挥 Go 词汇自身优势上，有了很大的提高。
Go 词汇协程的个数上限比 Java 线程数目多。Go 词汇的协程只运行在用户态，初始堆栈小且可伸缩，而 Java 线程启动因用户态系统态之间切换带来的额外成本被线程池抹平，所以只有在较大并发需求的情景下（核数限制的情况下，Java线程池中最大线程数被限制），才会充分发挥优势。Dubbo 中类似的情景：异步处理网络和协定化的处理。我们在网络库 Getty 中重新加入了协程池，同时实现了网络收发和逻辑处理的解耦。
另外，Go 词汇入门速度确实比 Java 快好几个数量级，只要搭好具有良好扩展性的架子，街道社区 contributor 培养的成本比 Java 低很多。得益于此，Dubbo-go 的机能和性能将迅速追平 Java。
OSCHINA：关于 Dubbo-go 在 Java 和 Go 运行时的兼容互联互通和机能一致目标，目前进展如何？
Dubbo-go 白培生：
目前，Dubbo-go 早已完全对齐 Dubbo v2.6.x，正在全力合作开发 v1.5.0 版本能全面对齐 v2.7.x。
Dubbo v2.7.5 之后开始全力支持应用领域维度的服务注册，这也是 v1.5.0计划全力支持的核心特性。
能剧透一下，目前 v1.5.0 版的 Dubbo-go 合作开发工作早已进入了尾声，正处于测试阶段。等 v1.5.0 正式发布之后，我们会陆续正式发布几个小版，用于对齐 Dubbo v2.7.5 之后的版。能说，v1.5.x 主要就是为了配合dubbo的云原分子生物。
OSCHINA：Dubbo-go 上周同时实现了 REST 协定全力支持，能和 Spring Cloud 自然生态互联；年初同时实现了和 gRPC 的互联，这对 Dubbo-go有什么意义？
Dubbo-go 白培生：
Dubbo-go 在全力支持了 REST 协定之后，早已能做到跟绝大部分如前所述 HTTP 协定的微服务架构进行通信。
【REST 总体设计】
另外一个突出优点是，全力支持了 gRPC 和 REST之后，Dubbo-go 就可以考虑和一些公司内部自研的架构进行通信了。通常一些比较大的公司会自研架构，或者深度定制某些开放源码架构。而只要它们全力支持 gRPC 或者 HTTP 协定，Dubbo-go 就能保证与这些架构的无缝衔接。
还有一个优势，REST 协定对前端更友好，能直接把Dubbo-go合作开发的服务给前端用，而不用加一层协定转换，也避免了前端直接发起 RPC 请求。因此，Dubbo-go 也就能成为它们在 Go 微服务架构的一个比较优秀的选择。
OSCHINA：1.4版中，Dubbo-go 在可观测性方面采用了 tracing 和 metric，metric 的同时实现参考了 Dubbo 的做法，也做了一些调整，具体是怎么样？
Dubbo-go 白培生：
可观测性是衡量一个微服务架构的重要方面。一般可观测性分成 tracing、metric 和 log三个部分。
[http://peter.bourgon.org/img/instrumentation/01.png]
在 v1.4 Dubbo-go 以后，tracing 和 metric 是 Dubbo-go 的薄弱环节。为了全力支持这两个，我们考察了比较多的开放源码架构的做法。我们发现，因为要考虑对接非常多诸如 zipkin/cat 等监控架构，所以它们往往会设计一整套监控和度量的 API。
Dubbo 也是如此。Dubbo 的 metric 比较依赖穆萨内部一个开放源码的 metric 的工程项目。这个工程项目也不是只能给 Dubbo 应用领域，而是 Java 工程项目都能考虑。本质上来说，它定义了一套 API，而后提供了对不同开放源码架构的适配同时实现。把握住这一核心之后，我们就要考虑一个问题：要不要自己设计一套 API？我们的答案是 NO，并且选择了 opentracing API 作为我们监控使用的 API。
具体来说，我们简述那些自己设计了 API 的开放源码工程项目，它们的 API 和 opentracing API还比较相像。我觉得我设计不出来一个明显比 opentracing API 更加优雅的 API 了。
另外从同时实现效率上来说，如果我们使用 opentracing API 作为 Dubbo-go 接入 metric 和 tracing 的 API，那么，任何全力支持 opentracing API 的架构，都能做到开箱即用。
目前我们正在向街道社区用户征集监控意见，看街道社区希望我们在架构内什么地方进一步埋点。我们也得到了很多反馈，下一步就要考虑进一步优化采集的数据。
OSCHINA：Dubbo-go 的合作开发项目组以后介绍，Dubbo-go 首要目的就是解决 Go 工程项目与 Java & Dubbo 工程项目的互联互通问题，同时也为 Go 工程项目提供了一种 RPC 与微服务合作开发架构的选择。但从以后的用户使用列表来看，直接把它作为 Go 的一个 RPC 架构来使用的好像并不是特别多，现在情况是这样吗？
Dubbo-go 白培生：
这个情况早已有了很大的改善了。最开始的时候，我们的用户大部分都是 Java Dubbo 那里过来的。但是到今年，据我们了解，早已有一些用户早已是直接把 Dubbo-go 作为 RPC 架构。在历经一年的产业发展以后，即便不考虑和 Dubbo 保持兼容这一特点，Dubbo-go 也能说一个比较优秀的 Go 词汇 RPC 架构。
特别是在异构系统通信和服务治理方面，我们提供了非常多样化的全力支持。这是很多别的 RPC 架构所不具备，或者不如我们的。
OSCHINA：总结一下这一年里，Dubbo-go 控制技术方面值得了解的进展吧？
Dubbo-go 白培生：
Dubbo-go 这一年的进步很大，同时实现了非常多非常重要的特性。
具体来说要提及的就是全力支持了很多协定，比如说如前所述 protobuf 的 gRPC 和 REST。这些协定保证了我们能够与市面上大多数的 RPC 架构进行通信，而且我们在1.5.0里面，还扩展全力支持全力支持如前所述 Json 的 gPRC 和 如前所述 protobuf 的 TCP 通信。
第二则是全力支持了配置中心。这个机能能提供给用户极大的配置上的灵活性。
第三则是可观测性上改进，也就是前面提到的 metric 和 tracing。
第四则是现在正在进行的应用领域注册模型，它能让我们更好地拥抱 k8s 和 servise mesh。为了全力支持应用领域注册模型，我们还同时实现了一个元数据中心，这个元数据中心非常有利于做网关。此外还同时实现了很多机能，如新的限流算法，负载均衡算法和路由策略等。具体内容，欢迎大家去看我们的 release log。
【Dubbo-go 总体架构图】
Dubbo-go 自然生态建设
OSCHINA：上个月，Go 非官方公布的最新调查报告显示，Go 词汇的主要就用途包括编写 RPC 服务，其次库和架构方面增量巨大。“竞争对手”变多会影响到 Dubbo-go 原本的计划实施吗，Dubbo-go 和其他同类工程项目比有什么不同？
Dubbo-go 白培生：
我们对 Go 街道社区的进步感同身受。事实上，Dubbo-go 这一年很多机能的同时实现，都离不开合作街道社区的全力支持。比如说我们提供的如前所述 Nacos 的配置中心全力支持，以及现在正在测试如前所述 Nacos 的应用领域维度服务注册与发现，都十分依赖 Nacos 的 Go 词汇 SDK 全力支持。
而且我们也注意到，别的 Go 词汇的微服务架构在这一年也取得了极好的进步，这是一种很好的鞭策。在 RPC 架构上，一直都是百家齐放百花争鸣局面，迫使我们朝着“人无我有，人有我精”的方向前进。到目前来说，我们感觉我们的竞争优势还是比较明显的：
第一点就是保持了和 Dubbo 的兼容，那么原本的 Dubbo 用户在考虑 Go 词汇架构的时候，我们就会是首选；
第二个竞争优势则是全力支持多协定。这几年一个很明显的趋势就是，一个公司的控制技术栈难以保持单一，因为不同架构、不同词汇会有不同优点。所以 Dubbo-go 也会是那些考虑连接异构系统用户的首选；
第三则是软实力，也就是我们街道社区自身的优点。我们街道社区非常有活力，用户有什么问题都能够得到迅速的响应；而我们的迭代速度，一直比较快。如果用户觉得自己能够迅速获得帮助，那么他们也会倾向选择我们。
OSCHINA：我们了解到，Dubbo-go/getty 是 Dubbo-go 中比较能体现 Go 词汇优势的部分，目前早已被解耦出来，能直接用。Dubbo-go 的其他组成部分会考虑同样解耦吗？
Dubbo-go 白培生：
这能说是一个非常长远和理想化的计划了。我们现在正在做的一件事，是把工程项目里面用的公共方法、和架构无关的代码抽取出来，做成一个工具类库，也就是 dubbogo-gost 这个工程项目。
我们注意到，不管是在 Dubbo-go，还是别的架构，这些代码都很类似，比如说对不同类型的数据排序。以后我们找过开放源码的 lib，但是都不尽如人意，所以我们打算把自己的拿出来，做成类似瑞士军刀一样小巧高效的工具。
另外还要提到 dubbo-go-hessian2 开放源码仓库。我们能自豪地说，这个库是 Go 里面对 hessian v2 协定全力支持最好的开放源码库。不仅仅是我们在用，穆萨和蚂蚁金服也在用。我们也希望吸引更加多用户来使用，帮我们改进。
OSCHINA：Dubbo-go今年3月25日的新版1.4.0中“拿出了使用 k8s 作为注册中心的解决方案”，选择性放弃 Service 机能，将元数据直接写入到 Pod 对象的 Annotations 中。为什么做出这个决策，后续有什么落地计划？
Dubbo-go 白培生：
在使用 k8s 作为注册中心这个点上，讨论就花了很长的时间。
其实最初考虑的是直接使用 k8s 服务发现模型，后来发现 k8s service 和 Dubbo-go Interface 之间存在一些难以调和的矛盾。比如说 Kubernetes 早已为其承载的服务提供了套服务发现，服务注册，以及服务集群管理机制。 Dubbo-go 也拥有成体系的服务集群管理。
这两个机能点形成了冲突，在无法调和两者的情况下，我们放弃了这个计划，并且提出了现在这个随1.4.0版正式发布使用的模型。
【k8s registry 设计方案】
后续，我们将主要就考虑 k8s 本身提供的 CRD + Operator 的方案，毕竟越来越多的 k8s 周边的工程项目都在以 Operator 作为切入点。Dubbo-go 街道社区后续的方案将会以 CRD 的形式在 k8s 内注册和发现服务。这样做的原因有很多，具体来说是为了减少 Dubbo-go 对 kube-apiserver 的直接依赖。其次是为了标准化注册模型，当服务模型以 CRD 的形式存在在 k8s 集群中之后，其他围绕 k8s 的工程项目能直接使用这些资源二次合作开发和拓展。而这种方式更加 CloudNative。
OSCHINA：Dubbo-go 现在在云原生应用领域上的布局是怎样的？
Dubbo-go 白培生：
街道社区的主要就物力正与蚂蚁金服的 mosn 街道社区展开合作。目前有 5 个物力与 mosn 街道社区一起在 mosn 中同时实现 Dubbo 的服务发现、服务注册和基本的 RPC 通信等数据平面的能力，在 istio 层面全力支持通过 XDS 同时实现配置下发，以同时实现 mosn + Dubbo-go 【嵌入 mosn】 + istio 这种 sidecar 形式的云原生方案。已顺利完成的工作早已在多点科技展开测试，上周 mosn 街道社区同学会在 A2M 大会上公布具体进展。
除了 sidecar 这种 proxy 形式的云原生方案，街道社区还计划同时实现 Dubbo-go【应用领域 sdk】 + istio 这种 proxyless 方式的云原生方案。Java 应用领域或者 Go 应用领域通过 istio 的 xDS 协定顺利完成服务注册和发现以及路由分发。或者说，我们力求微服务和云原生共存，能称之为“双模微服务”。这种“双模微服务”允许标准的 Dubbo-go + sidecar 和 Dubbo-go【应用领域 sdk】 + istio 两种模式部署的应用领域共存。这将是 Dubbo-go v1.6 的核心工作。
OSCHINA：Dubbo-go 几乎是刚一诞生就转移到 Apache，并且迅速正式发布了 Apache Dubbo Go v1.1.0，这对街道社区营运的帮助是什么，能分享下 Dubbo-go 的营运情况和经验吗？
Dubbo-go 白培生：
能说，Apache 基金会对我们的帮助是很大的。
一方面，Apache 自身的光环十分有助于吸引合作开发关注和参予；另外一方面，Apache 的一些要求，也让街道社区营运更加规范。
街道社区营运需要进一步规范化，透明化，以吸引更加多的人参予。我注意到很多优秀的街道社区营运做得很好，他们对 issue 的管理很细致，打上了各种标签，做到了对 issue 的轻重缓急的管理。这种标签能够很容易吸引一些打算尝试开放源码的新人，给街道社区带来新的血液。
我们尝试使用 milestone 的方式来管理 Dubbo-go 的整体进度。现在也在尝试定期召开街道社区会议，讨论街道社区产业发展方向，重大特性的设计，以及解决争端会议会面向整个街道社区，想参予的人都能参予。
【4.26街道社区会议开了摄像头的几位核心成员】
Dubbo-go应用领域及规划
OSCHINA：Dubbo-go 适合什么样的企业和情景？
Dubbo-go 白培生：
我们认为，如果用户需要一款 Go 词汇方面 gRPC 架构，能考虑 Dubbo-go；如果公司有和异构系统通信的需求，Dubbo-go 也是一个比较好的选择。特别是，公司内部还有 Java Dubbo 或者 Spring Clound 之类的应用领域，那么 Dubbo-go 优势就更加大了。
Dubbo-go 能说是 ” all-in-one ” 性质的 RPC 架构，自身包含服务治理等机能，非常省时省力，而且能够降低使用微服务的门槛。
OSCHINA：GitHub 的用户列表中早已有来自14家企业的使用历史记录，Dubbo-go 一般会提供哪些后续全力支持？
Dubbo-go 白培生：
我们一直都快速响应用领域户的问题，而且积极鼓励用户参予到 Dubbo-go 的合作开发中来。目前涂鸦智能、携程等几家用户早已成为了街道社区贡献的主要就力量。
有时候用户来做调研，进来街道社区咨询问题的时候，我们都会笑称他“如果选择了 Dubbo-go，就选择了一个强大的售后项目组”。
街道社区一位很活跃的 Contributor 潘总【github id: pantianying】对我们的热情服务应该深有体会。比如他会提 issue，然后我们也会迅速解决像 router、优雅退出机能就是在潘总提出之后，我们迅速同时实现的， 还有早期一次重构之后，也是潘总尝鲜试用。尝鲜版通常有很多 BUG，所以我们都是上班打工，下班给潘总修 BUG，也算是服务周到热情用心了。
额外说下，目前 Dubbo 非官方也早已资金投入物力参予 Dubbo-go 的合作开发，穆萨集团公司今年顺利完成 HSF 和 Dubbo的结合后，会在集团公司内全面推广使用 Dubbo-go。
【潘总在分享Dubbo-go的实践】
OSCHINA：Dubbo-go 下一版预计今年什么时候正式发布，有没有一些长远的产业发展计划？
Dubbo-go 白培生：
现阶段正在测试的是 v1.5 版，希望六月份能发出来。v1.6 版正在设计和规划中，v1.6是和 Dubbo 3 对齐的，所以也会是一个比较大的版。
今年我们街道社区主要就集中在两件事上。第一件是云和云原生的全力支持，现在进行中的 v1.5 和 v1.6 都是围绕这一点的。今年几乎所有大的 feature 都是这方面的。
第二件事，则是进一步提高 Dubbo-go 的文档、注释和代码质量。坦白来说，Dubbo-go 的文档并不是特别好，特别是用户文档。我们也收到了很多用户的批评正在加强CI和自动化测试这块。总而言之，文档与质量这件事是今年的头等大事。
OSCHINA：最后，请介绍一下自己吧。
Dubbo-go 白培生：
说起来挺有意思的，就是我本身是业务合作开发，并不是传统意义上的中间件合作开发或者基础架构合作开发。我目前在 eBay 做支付业务的合作开发。eBay 是一个 WLB 的公司，也就是在 eBay 我才有了足够的业余时间，开始资金投入到了开放源码街道社区中。
【白培生在 Dubbo 街道社区合作开发人员日做分享】
Dubbo-go 是我第一个深入参予的开放源码工程项目，也是我第一次尝试将个人对分布式系统和微服务治理的理解付诸实践的工程项目。它是我的第一个“孩子”。
因为工作的关系，我算是 Dubbo-go 街道社区资金投入时间最多的人之一，为 Dubbo-go 合作开发了一些很有意思的特性，也因此成了 Apache committer。另外我还扮演了编辑的角色，帮社区小伙伴写的博客文章把把关，润润色。我也算是 Dubbo-go 的主要就管理人员了，比如说 v1.5 这个版就是主要就由我推进的——这大概还原因在于我时间比较多。
【2019.04 街道社区核心成员会师穆萨讨论产业发展方案，相谈甚欢】
