拥有新时代的通信协议，引领云原生迈向更高的舞台解密Dubbo3是如何从微服务升华到云原生领域

Posted 2022-11-24 浩宇の天尚

感谢2020云原生微服务给我带来了云原生的希望！

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. 需要一个统一格式和标准的跨语言
   • 采用Grpc和Http2的协议格式，作为统一的标准化格式协议基础，并且支持原生的grpc协议模式
   • 此外还可以支持平滑的支持迁移到protobuf协议机制
2. 需要较为完整的服务治理的功能机制
   • 采用了较为符合云原生服务架构机制，应用层级的服务治理体系。
   • 协议应该提供更完善的请求模型，除了 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的支持。

对齐 K8s 的生命周期

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

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

• Startup 启动探针
• Liveness 存活探针
• Readiness 就绪探针

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配置一样。

apiVersion: v1
kind: Service
metadata:
  name: rpc-service-1
spec:
  selector:
    app: provider-app-name
  ports: ##

---

apiVersion: v1
kind: Service
metadata:
  name: rpc-service-2
spec:
  selector:
    app: provider-app-name
  ports: ##

---

apiVersion: v1
kind: Service
metadata:
  name: rpc-service-N
spec:
  selector:
    app: provider-app-name
  ports: ##
...

Dubbo3的架构分布

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