What’s New in Dubbo-go v1.5

引语

计算机技术浪潮每 10 年都有一次技术颠覆，相干常识体系最迟每 5 年都会变革一次，大略每两年升值一半，在应用服务通信框架畛域亦然。但凡有长期生命的通信框架，大略有 5 年的成长期和 5 年的稳固成熟期。每个时代都有其匹配的利用通信框架，在 20 年前的 2G 时代，强跨语言跨平台而弱性能的 gRPC 是不会被采纳的。

每个通信框架，不同的人从不同角度看出不同的论断：初学者看重易用易学，性能测评者重视性能，利用架构师思考其保护老本，老板则思考则综合老本。一个利用通信框架的性能诚然重要，其稳定性和进化能力更重要，失去无效保护的框架可在长时间单位内升高其综合老本：学习老本、保护老本、降级老本和更换老本。

什么是 Dubbo-go？第一，它是 Dubbo 的 Go 语言版本，全面兼容 Dubbo 是其第一要义。第二，它是一个 Go 语言利用通信框架，会充分利用作为云原生时代第一语言 —Go 语言的劣势，扩大 dubbo 的能力。

2008 年诞生的 Dubbo 已有十多年历史，依附阿里和其社区，历久弥新。2016 年公布的 Dubbo-go 也已进入第五个年头，现在全面兼容 Dubbo v2.7.x 的 Dubbo-go v1.5 终于公布了。

回首过往，Dubbo-go 曾经具备如下能力：

• 互联互通：买通了 gRPC 和 Spring Cloud 生态；
• 可观测性：基于 OpenTracing  和 Prometheus，使得其在 Logging、Tracing 和 Metrics 方面有了长足进步；
• 云原生：Dubbo-go 实现了基于 Kubernetes API Server 为注册核心的通信能力，做到了降级老本最低。

毋庸讳言，相较于现有问题，倒退阶段的 Dubbo-go 对将来有更多的期待之处：

• 易用性：Dubbo-go 的入门老本并不低，把很多感兴趣者挡在了门外。但好消息是，随着 Dubbo-go 在阿里外部的逐渐推开，阿里中间件团队对其进行了进一步的封装，经生产环境测验后会凋谢给社区应用。

• 云原生：目前的 Dubbo-go 的基于 kubernetes 的计划，从技术分层角度来看，Kubernetes API Server 究竟是零碎的运维态组件，不应该裸露给应用层，否则会造成 APIServer 本身通信压力过大，且零碎整体危险很高：应用层使用不当，或者框架本身的流量方面的 bug，可能会把 APiServer 打垮，结果就是造成整体后端服务能力的瘫痪！所以应用层须要感知的是 kubernetes 提供给应用层的 Operator，一直进化的 Dubbo-go 打算在 v1.6 版本中公布 Dubbo-go Operator。

雄关漫道真如铁，而今迈步从头越。Dubbo-go 社区【钉钉群 23331795】与 Dubbo-go 同在。

利用维度注册模型

通过一段时间的致力之后，咱们终于实现了利用维度的服务注册与发现。和本来已有的接口维度的注册模型比起来，新的注册模型有两个突出特点：

1. 和支流的注册模型保持一致。目前的支流做法都是依照利用为根本单位来进行注册的，如 Spring Cloud。在反对利用维度注册之后，对于接下来的云原生反对，奠定了根底；
2. 大幅度加重对注册核心的压力。在该模型之下，从注册核心的视角看过来，集群规模只和实例数量成正比，而不是现有的和服务数量成正比；

当然，咱们在设计的时候就思考到了用户的迁徙老本。要迁徙到新的注册模型，只须要将现有应用的注册核心换成新的 ServiceDiscoveryRegistry 就能够。

ServiceDiscoveryRegistry 是反对多种实现的。目前来说，咱们反对：

1. nacos;
2. etcd;
3. zookeeper;

咱们提倡新上线的业务尽量应用 nacos 和 etcd 这种更牢靠稳固的注册核心。

Metadata Report 元数据中心

v1.5 版本在反对利用维度注册模型时，有很重要的一个问题须要解决，即接口维度的元数据存储。服务维度的注册模型和利用维度的注册模型，实质的区别是往注册核心注册的数据维度的不统一。尽管咱们在利用维度注册模型中，将接口维度的数据从注册核心中剔除了，然而在 rpc 的框架中，一个 consumer 要想真正找到想要调用的服务地址，就必须失去 provider 端凋谢的服务信息。这部分数据，在 v1.5 版本中，咱们将它们存储到了元数据中心中。元数据中心，是一个接口定义。泛指一块存储区域，能够对接口级别的元数据进行存储、读取，provider 端调用存储，consumer 端调用读取。元数据中心中的数据须要放弃准确性、实时性。目前元数据中心，有两个父类（Go 中没有继承，此处说的父子类，单纯指子类对父类的组合关系）实现，一个是 local 实现，一个是 remote 实现。local 实现是将 provider 的内存作为虚构元数据中心，remote 实现是指依赖 ZooKeeper、etcd、nacos 等注册核心作为元数据中心。目前 remote 有 zookeeper、nacos、etcd 和 consul 的子类实现。即用户能够将元数据信息，通过以上的第三方注册核心进行数据存储和散发。

Invocation 接口反对 attribute 属性

invocation 构造中新增 attribute 属性反对，用于流程外部的属性存储。和 attachment 不同点在于，attachment 会从 consumer 传递到 provider，但 attribute 属性不会。

k8s 注册核心

  在 v1.5 版本之前，k8s 注册核心的实现是通过间接应用 [k8s client](https://github.com/kubernetes/client-go) 中 Pod 对象的 List&&Watch 接口。在本次迭代中引入了 k8s informer。这样做的起因在于两点，首先肯定的水平上来讲 dubbo-go 的 k8s 注册核心也是一个 k8s controller，应用 informer 的模式更加 k8s native。更重要的是社区打算后续向 CRD+Operator 的模式演进，informer 模式是对后续的演进的摸索。除了这个铺垫之外，本次迭代还对跨 namespace 的服务发现做了反对。再有就是为了缩小对 kube-apiserver List&&Watch 的压力，对 provider 和 consumer 的行为进行了辨别，provider 不再进行 Watch 而仅对 kube-apiserver 进行写操作。

优化路由模型

在 1.5 版本之前，Router 模型中属性是蕴含：优先级与路由属性，Router Chain 只蕴含路由属性。从中能辨认出其实 Router Chain 也是一种非凡 Router。1.5 版本之后，使 Router 更形象，拆散出其优先级属性，新增 Priority Router、Chain 继承 Router 使其变为非凡的 Router，使关系上看起来更加清晰。如下图：

回顾与瞻望

Dubbo-go 处于一个比较稳定成熟的状态。目前新版本正处于往云原生方向的尝试，应用服务维度注册是首先推出的性能，这是一个和之前模型齐全不一样的新注册模型。该版本是咱们朝云原生迈进新一步的要害版本。除此之外，蕴含在该版本也有一些之前提到的优化。

下一个版本 v1.5.1，尽管仍是以兼容 Dubbo 2.7.x 为次要工作，但在分布式能力的加强上，也是咱们关注的重点。

在 分布式事务 方面，有一个重要的基于 Seata 扩大实现。通过减少过滤器，在服务端接管 xid 并联合 seata-golang[2] 达到反对分布式事务的目标。从而使 Dubbo-go 在分布式场景下，让用户有更多的抉择，能适应更多的个性化场景。

与此同时，在 传输链路安全性 上，TLS 平安传输链路是该版本重要性能之一。通过提供对立入口，将来能引入更多的与传输链路安全性相干的性能，适应用户不一样的应用场景。

注册核心模型 上，反对多注册核心集群负载平衡。业务部署假如是双注册核心（图 1），从原来双注册核心中所有 Provider 一起选址。优化成选址时的多了一层注册核心集群间的负载平衡（图 2）。

（图 1）

（图 2）

以前的 dubbo-go RPC 层间接复用了 getty 框架 的 RPC[3]，未能实现协定和利用通信地址的隔离。阿里中间件展图同学重构了 dubbo-go RPC 层，实现了连贯复用：能够实现 consumer 与 provider 端的同一个 TCP 连贯上进行多协定通信。相干 PR 业已合并，会在 dubbo-go v1.5.1 中公布。

目前下一个版本正在紧锣密鼓的开发中，具体布局及工作清单[1]，都曾经在 Github 上体现。

[1] : https://github.com/apache/dubbo-go/projects/8

[2] : https://github.com/seata-golang/seata-golang

[3] : https://github.com/AlexStocks/getty/tree/master/rpc