【拥有新时代的通信协议，引领云原生迈向更高的舞台】解密 Dubbo3 从微服务升华到云原生 | 社区征文

感谢宣言

首先要感谢【2020 云原生微服务大会】给我们带来了 RPC 的云原生希望：Dubbo3，一个可以融合 Kubernetes 的云原生 RPC 服务框架，从此它不再只是属于微服务领域咯！

Dubbo3 拥抱云原生升级总体路线

我们会侧重于下面红色填充的部分，针对于 Dubbo3 云原生技术的领域的探索和研究：

看 Dubbo3 带来了什么？

要是说到 Dubbo 想必大家应该知道，它是一个 Java 技术领域的 RPC 框架，但是为什么今天要把它和云原生挂钩了呢？因为迎接着云原生的不断更新和升级，Dubbo 没有停滞不前，创造了 Dubbo3，它摒弃了之前的缺点，从而创造了更多更多的奇迹，特别是兼容了云原生技术。

“鼠”年给云原生建立好的开端

摘自官网资料中的 Dubbo3 的虎年的发展计划：

“牛”年完美收官和中肯评价

Dubbo3 是 Apache 顶级项目 Dubbo 的一个非常具有里程碑性质的版本，它是让 Dubbo 服务体系全面拥抱云原生的一个重要节点。

去年的 11 月会官方又发布了 Dubbo3.1 版本，同时社区也组织了相关的 Dubbo 在 Mesh 场景下部署的实现与实践的案例分享沙龙

“虎”年 Dubbo3 虎虎生威！

官方计划在今年 3 月会发布 Dubbo3.2 版本：这个版本中将带来全新的大规模应用部署下智能流量调度机制，提高系统稳定性与资源利用率。

Dubbo3 目前已经和阿里巴巴集团内部的 RPC 框架实现了融合，期望用它来解决内部落地问题，做到技术栈统一。（官方介绍）

直奔主题，迈向云原生时代

如果你看到了这里，那么接下来你将会认识 Dubbo3 的诞生将如何引领微服务领域更进一步，从而迈入云原生的领域，这当然不仅仅是 Dubbo3，之前也介绍了 Java 生态另外一个云原生领域的技术 Quarkus 等技术，而本文内容侧重点去介绍 Dubbo3 迈向云原生的技术分析和探索，如果有不正确的地方，还需要大家多多指正。

如何转型微服务到云原生？

如今已经全面得到全面发展的云原生技术时代，Dubbo3 全面拥抱云原生，将 Dubbo 原本的架构进行了升级，形成 【全新的服务发现模型】、 【下一代云原生服务通信协议】 和 【完美支持云原生基础设施】 的方案。

• （取其精华） Dubbo3 依然会保留之前已有的开箱即用和落地实践的优点。

• （去其糟粕） Dubbo3 将会剔除不符合云原生架构理念，将会更好的复用底层云原生基础设施并且将会更加支持云原生的微服务架构。

去其糟粕，重新整顿治理模型

云原生走出的重要一步

了解 Dubbo 的开发者都知道，Dubbo 之前的服务治理都是接口层级的。同一个应用发布的多个服务会在注册中心注册多份数据，注册服务的元数据相互独立。但是存储在注册中心中的数据会在很大程度上存在重复的内容，其实浪费了一部分的存储。

对超大规模的影响

当整个集群的规模足够大的时候，由于服务注册发现是服务维度的，注册中心的数据量就会爆发式地增长。

在 2020 年云原生微服务大会上，Dubbo 已经出现了服务治理层面的改造升级的雏形，它将原本的接口层级的服务治理模型改造成为了应用层级，同时也引入了其他的核心组件，完美的解决了接口以及应用指令层面的都兼容的场景！下图就是两种不同方式的服务治理机制：

左边图是 Dubbo 早起版本的架构模型，右边图是 Dubbo3 的服务治理架构图。

主要总体和新的服务治理机制划分了两个状态：

• 部署态：接口应用的映射，主要通过了上面的元数据中心，可进行管理接口到应用的映射以及应用级的元数据。Dubbo 框架会自动上报这个关系到元数据中心。

• 运行态：会将 Dubbo 侧的配置以及运行用户侧的配置和服务治理则通过这份映射关系重新将应用粒度映射到接口粒度，此部分同时也会上报的元数据中心

• 会将作为应用服务实例和应用绑定关系进行上报，应用级选址和接口级选址同时存在，方便进行服务治理。

存储的模型结构案例

{    "name": "provider-service",    "id": "192.168.1.1:20880",    "address": "192.168.0.102",    "port": 20880,    "sslPort": null,    "payload": {        "id": null,        "name": "provider-service",        "metadata": {        "metadataService": "{\"dubbo\":{\"version\":\"1.0.0\",\"dubbo\":\"2.0.2\",\"release\":\"2.7.5\",\"port\":\"20881\"}}",            "endpoints": "[{\"port\":20880,\"protocol\":\"dubbo\"}]",            "storage-type": "local",            "revision": "6785535733750099598",        }    },    "registrationTimeUTC": 1583461240877,    "serviceType": "DYNAMIC",    "uriSpec": null}

异构化体系或者语言通信

Dubbo 与其他服务生态的通信

目前 Spring cloud 和 K8s 都是基于实例，也就是应用级别进行的注册发现，Dubbo 要成为连接异构系统最好用的 RPC 框架就需要支持实例粒度；

应用级别治理机制，打通了与其他微服务体系之间在地址发现层面的鸿沟，也成为适配 Kubernetes Native Service 等基础设施的技术理论基础。

去其糟粕，开创跨生态协议

如果想要完成对云原生的转化出了上述解决了的问题之外，仍然还要有两个需要攻克的难题：

协议不够标准和通用化，导致语言生态无法互通

Dubbo 原有的协议提供了 RPC 技术体系的核心骨架组成。其中，协议头、标志位、请求 ID 以及请求/响应数据，如下图所示。

Dubbo 协议基于二进制流定制了与 RPC 强绑定的核心语义：上图所示就是之前 Dubbo 版本的协议组成部分，其结构分布会让用户很难直接理解，基本上都属于 Dubbo 自定义以及非标准的格式组成部分。细节不多说，大家可以看到有 16 位的高魔术头和低魔术头组成、数据包协议类型，事件类型、序列化方式等。而对于越来越多的云原生治理设施，比如 Kubernete Service。

协议头包含的原始数据信息过多，对云原生的介入造成阻碍

Dubbo 协议的协议头已无法再承载更多的元数据信息。Service Mesh 组件，需要对数据进行治理那么需要对更加完整的数据包进行解析才能获取到必要的元数据信息（如 RPC 上下文），从性能到易用性方面都会面临挑战。

协议层面需要做的改进和升级要点

1. 需要一个统一格式和标准的跨语言

2. 采用 Grpc 和 Http2 的协议格式，作为统一的标准化格式协议基础，并且支持原生的 grpc 协议模式

3. 此外还可以支持平滑的支持迁移到 protobuf 协议机制

4. 需要较为完整的服务治理的功能机制

5. 采用了较为符合云原生服务架构机制，应用层级的服务治理体系。

6. 协议应该提供更完善的请求模型，除了 Request/Response 模型，还应该支持 Streaming 和 Bidirectional；

下一代云原生协议——Triple 协议机制

Triple 协议是 Dubbo3 新时代产物协议，它可以兼容 gRPC 和 HTTP/2，并在协议层面扩展了负载均衡和流量控制相关机制，以及可以在原有的基础上进行对 protobuf 协议的平滑迁移处理。

• （与 GRPC 的互通性）Dubbo3 新协议是基于 GRPC 扩展的协议，这也保证了在生态系统上新协议和 GRPC 是能够互通和共享的；

• （与 Protobuf 迁移性）在序列化方面，新协议会在序列化方面给予足够的支持，平滑的适配现有序列化，方便迁移到 Protobuf；

更多内容可以参考文章：https://dubbo.apache.org/zh/docs/v3.0/references/tri/

兼容 Kubernetes 基础设施组件

针对于 Kubernetes 的基础设施的兼容和介入，主要包含两个部分：Kubernetes 生命周期对齐探针和 Mesh 的支持。

对齐 Kubernetes 的生命周期

能够让 Dubbo 服务原生的在 K8s 体系内注册和发现，这都要归功于自身所带的探针技术。K8s 的 Pod 的生命周期与服务调度息息相关，通过对 Kubernetes 官方探针的实现，能够使 Dubbo 乃至整个应用的生命周期与 Pod 的生命周期对齐。

通过 Dubbo 的 SPI 机制，在内部实现多种“探针”，基于 Dubbo QOS 运维模块的 HTTP 服务，使容器探针能够获取到应用内对应探针的状态。另外，SPI 的实现机制也利于用户自行拓展内部“探针”，使整个应用的生命周期更有效的进行管控。

• Startup 启动探针：建立启动服务的探针监听组件，与 pod 的声明起始点相同

• Liveness 存活探针：活跃状态的 pod 状态，就如同，Health Endpoint 相同，预示着，pod 或者容器处于活跃状态。

• Readiness 就绪探针：当完全处于成功运行状态下，例如：pod 或者容器的状态进行监控和 hook 回调机制。

Triple 协议通过使用 HTTP2 进行 header/payload 分离解决了网关需要解析完整协议的问题。

Mesh 的 xDS 的机制体系

服务注册发现和治理，注册发现需要 Dubbo 能够在 Mesh 的 xDS 体系内作为数据面打通。

治理则需要将原有的规则逐步迁移至基于 YAML 的剔除 IP 依赖的规则。最终的形态将是原生的 Dubbo 服务能够和基于 thin SDK 的 Dubbo + Mesh 完美互通和进行服务治理。

Service Name - > Dubbo RPC Service，Kubernetes 要维护调度的服务与应用内建 RPC 服务绑定，维护的服务数量变多，而对于 Kubernetes Service 作为一个抽象概念，Service Name - > Application Name，Dubbo 应用和 Kubernetes 服务一一对应，对于微服务运维和建设环节透明，与开发阶段解耦，例如 service 配置一样。

Dubbo 3 提出了两种部署模式，一种是配合 Sidecar 部署的 Thin SDK 模式、另一种是直接接入控制面的 Proxyless Mesh 模式。

apiVersion: v1kind: Servicemetadata:  name: rpc-service-1spec:  selector:    app: provider-app-name  ports: ##
---
apiVersion: v1kind: Servicemetadata:  name: rpc-service-2spec:  selector:    app: provider-app-name  ports: ##
---
apiVersion: v1kind: Servicemetadata:  name: rpc-service-Nspec:  selector:    app: provider-app-name  ports: ##...

Dubbo3 的架构分布

摘自官网的 Dubbo3 的架构分布，细思极恐，多么完整和庞大的生态，祝愿 Dubbo3，虎年蒸蒸日上，光彩夺目，为云原生时代，提供更多的力量和能源，下图就是整体对 Dubbo3 的技术架构拓展图。

技术疑问点

有的小伙伴们会说，为什么 Dubbo3 无法直接使用 Kubernetes 服务发现模型（注册中⼼），而是采用 ZK 或者 Nacos 注册中心？我们会针对于 K8s 和 Dubbo3 在服务发现机制进行深入分析原因?

Kubernetes

Kubernetes 的容器集群化管理⽅案管理资源的维度可分为服务进程管理和服务接⼊管理。

• 服务实例管理：主要⽅式为 Pod 模式加 Controller 模式，controller 会将特定 Label 的 Pod 保持在恒定的数量。

• 服务管理：主要为 Service ，Service 默认为具有特定标签 Label 的 Pod 统⼀提供⼀个 VIP(Kubernetes-ClusterIP)，需要请求该组 Pod 的请求都默认会按照 round-robin 的负载策略转发到真正提供服务的 Pod 。并且 CoreDNS 为该 Kubernetes-Service 提供集群内唯⼀的域名。

kube-ApIServer 提供的 API(HTTPS)服务为例。K8s 集群为该服务分配了一个集群内有效的 ClusterIP，并通过 CoreDNS 为其分配了唯一的域名 kubernetes。如果集群内的 Pod 需要访问该服务时直接通过 https://kubernetes:443 即可完成。

原因 1：Dubbo 的元数据模型要多于 K8s 的数据模型

• dubbo 的服务注册是基于每个进程的，每个 dubbo 进程均需进⾏独⽴的注册，dubbo 目前的服务发现模型是针对 Endpoint 级别的（虽然目前已拆分为元数据中心和注册中心），但是其真正意义注册的信息不只 IP 和端⼝包括其他的⼀些元数据。

• 而 Kubernetes-Service：标准的资源对象具有的微服务中并未提供，dubbo 进程元数据字段因此，⽆法直接使⽤Kubernetes-Service 进⾏服务注册与发现。

原因 2：Dubbo 的负载均衡技术与 K8s 集群机制出现冲突

Kubernetes-Service：默认为服务创建 VIP，提供 round-robin 的负载策略也与 dubbo⾃有的 Cluster 模块的负载策略形成了冲突，会出现紊乱的。

总结分析

1. Dubbo3 相比于之前的版本中的基于接口粒度的服务发现机制，3.x 引入了全新的基于应用粒度的服务发现机制，新模型带来两方面的巨大优势：

2. Dubbo3 定义了全新的 RPC 通信协议——Triple，它是基于 HTTP/2 上构建的 RPC 协议，完全兼容 gRPC，并在此基础上扩展出了更丰富的语义。

3. Dubbo3 构建的业务应用可直接部署在 VM、Container、Kubernetes 等平台，Dubbo3 很好的解决了 Dubbo 服务与调度平台之间的生命周期对齐，Dubbo 服务发现地址 与容器平台绑定的问题

4. Dubbo3 打通与其他异构微服务体系的地址互发现障碍。新模型使得 Dubbo3 能实现与异构微服务体系如 Spring Cloud、Kubernetes Service、gRPC 等

5. Dubbo3 性能的提升，在官方的介绍中：

6. Dubbo3 在大规模集群实践中的性能与稳定性。新模型可大幅提高系统资源利用率，降低 Dubbo 地址的单机内存消耗（50%），降低注册中心集群的存储与推送压力（90%），Dubbo 可支持集群规模步入百万实例层次。

文章来源

https://xie.infoq.cn/article/11130401db152c59dfaf822ca