感谢宣言
首先要感谢【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 上下文），从性能到易用性方面都会面临挑战。
协议层面需要做的改进和升级要点
- 需要一个统一格式和标准的跨语言
- 采用Grpc和Http2的协议格式，作为统一的标准化格式协议基础，并且支持原生的grpc协议模式
- 此外还可以支持平滑的支持迁移到protobuf协议机制
- 需要较为完整的服务治理的功能机制
- 采用了较为符合云原生服务架构机制，应用层级的服务治理体系。
- 协议应该提供更完善的请求模型，除了 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: 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，虎年蒸蒸日上，光彩夺目，为云原生时代，提供更多的力量和能源，下图就是整体对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模块的负载策略形成了冲突，会出现紊乱的。
总结分析
-
Dubbo3相比于之前的版本中的基于
接口粒度的服务发现机制，3.x引入了全新的基于应用粒度的服务发现机制，新模型带来两方面的巨大优势： -
Dubbo3定义了全新的RPC通信协议——Triple，它是基于 HTTP/2上构建的RPC协议，完全兼容gRPC，并在此基础上扩展出了更丰富的语义。
-
Dubbo3构建的业务应用可直接部署在VM、Container、Kubernetes等平台，Dubbo3很好的解决了Dubbo服务与调度平台之间的生命周期对齐，Dubbo服务发现地址 与容器平台绑定的问题
-
Dubbo3打通与其他异构微服务体系的地址互发现障碍。新模型使得Dubbo3能实现与异构微服务体系如Spring Cloud、Kubernetes Service、gRPC等
-
Dubbo3性能的提升，在官方的介绍中：
- Dubbo3在大规模集群实践中的性能与稳定性。新模型可大幅提高系统资源利用率，降低Dubbo地址的单机内存消耗（50%），降低注册中心集群的存储与推送压力（90%），Dubbo可支持集群规模步入百万实例层次。