Photo @ Ilya Orehov
从编程开发的角度来说，Apache Dubbo （以下简称 Dubbo）首先是一款 RPC 服务框架，它最大的优势在于提供了面向接口代理的服务编程模型，对开发者屏蔽了底层的远程通信细节。同时 Dubbo 也是一款服务治理框架，它为分布式部署的微服务提供了服务发现、流量调度等服务治理解决方案。
面向接口代理的透明服务开发框架
public interface GreetingsService {String sayHi(String name);}
// 和调用本地服务一样，完全透明。private GreetingService greetingService;public void doSayHello(String name) {greetingService.sayHi("Hello world!");}
同构/异构微服务体系面临的问题
-
我们可能要在不同的服务之间采用不同的通信协议，因为不同的服务面临不同的业务场景，而这也进一步导致了数据传输特点的不同，我们需要分别采用更适合各类业务特点的协议。比如典型的场景：我们可能对于普通的业务服务采用 Dubbo 协议，对于和 FrontEnd 交互的服务需要 HTTP 协议，而对于需要流式数据传输的业务则采用 gRPC 协议等等。
-
Dubbo 体系内部另一个常出现的问题是，在大规模分布式部署的场景下，微服务系统会做跨区域、跨注册中心的部署，这个时候就会出现多集群间地址同步和流量调度的问题。
Dubbo 体系内的多协议、多注册中心机制
我们将通过两个场景示例，来分别具体的讲一下 Dubbo 的多协议、多注册中心机制的使用方式和工作原理。
多协议
-
DemoService1 DemoService2 通过 dubbo 协议发布
-
DemoService3 DemoService4 通过 gRPC 协议发布
-
DemoService0 通过 dubbo 、gRPC 双协议发布
<dubbo:service interface="org.apache.dubbo.samples.basic.api.DemoService1" protocol="dubbo"/><dubbo:service interface="org.apache.dubbo.samples.basic.api.DemoService2" protocol="dubbo"/><dubbo:service interface="org.apache.dubbo.samples.basic.api.DemoService3" protocol="grpc"/><dubbo:service interface="org.apache.dubbo.samples.basic.api.DemoService4" protocol="grpc"/><dubbo:service interface="org.apache.dubbo.samples.basic.api.DemoService0" protocol="dubbo, grpc"/>
<dubbo:reference protocol="dubbo" interface="org.apache.dubbo.samples.basic.api.DemoService1"/><dubbo:reference protocol="dubbo" interface="org.apache.dubbo.samples.basic.api.DemoService2"/><dubbo:reference protocol="grpc" interface="org.apache.dubbo.samples.basic.api.DemoService0"/>
<dubbo:reference protocol="grpc" interface="org.apache.dubbo.samples.basic.api.DemoService3"/> <dubbo:reference protocol="grpc" interface="org.apache.dubbo.samples.basic.api.DemoService4"/><dubbo:reference protocol="dubbo" interface="org.apache.dubbo.samples.basic.api.DemoService0"/>
Dubbo 多协议支持现状
Dubbo 目前所支持的协议包括 Dubbo、REST、Thrift、gRPC、JsonRPC、Hessian 等，基本涵盖了业界大多数主流的 RPC 通信协议。需要注意的是，这些协议的支持都是以直接集成官方 Release 实现的形式来做的，我认为这是一个很好的选择，既保证了协议解析自身的稳定性，又能使 Dubbo 社区更专注的将更多的精力放在 Dubbo 外围服务治理能力的改善上。试想如果 Dubbo 社区自己为每个协议提供实现，那是要花费多少精力和时间才能使每种协议达到稳定的生产可用。
多协议能解决的问题
-
将 RPC 框架无缝地接入 Dubbo 的服务治理体系。 通过协议扩展将 RPC 协议纳入 Dubbo 服务开发体系，从而复用 Dubbo 的编程模型和服务发现、流量管控等能力。比如 gRPC，其服务治理体系相对比较弱、编程 API 不够友好，很难直接用于微服务开发。 -
满足不同场景的调用需求。
各个服务可能是为了满足不同业务需求而开发，同时外围消费端应用的技术栈也可能多种多样，通过启用不同的通信协议，可以最优化不同场景的通信需求。 -
实现协议间的迁移。
通过支持多种协议，借助注册中心的协调，可以快速满足公司内协议迁移的需求。如从自有协议升级到 Dubbo 协议，Dubbo 协议自身升级，从 Dubbo 协议迁移到 gRPC，从 REST 迁移到 Dubbo 协议等。
多注册中心
<dubbo:registry id="beijingRegistry" address="zookeeper://${zookeeper.address1}" default="false"/> <dubbo:registry id="shanghaiRegistry" address="zookeeper://${zookeeper.address2}" /><dubbo:service interface="org.apache.dubbo.samples.multi.registry.api.HelloService" ref="helloService" registry="shanghaiRegistry,beijingRegistry"/><dubbo:service interface="org.apache.dubbo.samples.multi.registry.api.DemoService" ref="demoService" registry="shanghaiRegistry,beijingRegistry"/>
<dubbo:registry id="beijingRegistry" address="zookeeper://${zookeeper.address1}" default="false" preferred="true" weight="100"/> <dubbo:registry id="shanghaiRegistry" address="zookeeper://${zookeeper.address2}" default="true" weight="20"/><dubbo:reference interface="org.apache.dubbo.samples.multi.registry.api.DemoService"/><dubbo:reference interface="org.apache.dubbo.samples.multi.registry.api.DemoService" registry="beijingRegistry, shanghaiRegistry"/><dubbo:reference interface="org.apache.dubbo.samples.multi.registry.api.HelloService" registry="beijingRegistry"/><dubbo:reference interface="org.apache.dubbo.samples.multi.registry.api.HelloService" registry="shanghaiRegistry,shanghaiRegistry"/>
Dubbo 对异构注册中心集群的支持
虽然我们会做多注册中心集群部署，但通常情况下，我们部署的都是相同的注册中心产品，如都是 Zookeeper、Nacos；而对于注册中心迁移的场景，则要求 Dubbo 能提供对更多的注册中心产品的支持，或者最重要的是要有很好的扩展能力。Dubbo 官方目前支持的注册中心实现有：
多订阅带来的流量调度问题
<!-- 来自 preferred=“true” 注册中心的地址将被优先选择，只有该中心无可用地址时才 Fallback 到其他注册中心 --><dubbo:registry address="zookeeper://${zookeeper.address1}" preferred="true" />
<!-- 选址时会和流量中的 zone key 做匹配，流量会优先派发到相同 zone 的地址 --><dubbo:registry address="zookeeper://${zookeeper.address1}" zone="beijing" />
<!-- 来自北京和上海集群的地址，将以 10:1 的比例来分配流量 --><dubbo:registry id="beijing" address="zookeeper://${zookeeper.address1}" weight=”100“ /><dubbo:registry id="shanghai" address="zookeeper://${zookeeper.address2}" weight=”10“ />
多注册中心适用的场景
-
同区域流量优先调度
出于容灾或者服务伸缩性需求，服务/应用往往需要部署在多个独立的机房/区域，在每个区域有独立注册中心集群的场景下，实现同区域的流量优先调度就能很好的解决延迟和可用性问题。
-
注册中心迁移
公司的服务一直以来可能是存储在某一个注册中心，如 Zookeeper，但到了某个时间节点，因为各种各样的原因，当我们要迁移到另外的注册中心时，多注册中心模型能够保证平滑的迁移。
-
异构系统互通
不同微服务体系开发的服务，都封闭在各自的服务发现体系中，而通过统一的多注册中心模型，可以实现不同体系的服务互相发现。
借助 Dubbo 联通异构的微服务体系
如上图所示，我们有部分微服务可以是基于 SpringCloud、gRPC、K8S 或者是自建体系构建的，他们各自之间默认是相互隔离无法联通的。当我们再构建一套基于 Dubbo 的微服务体系时，则利用 Dubbo 的多协议、多服务发现模型，我们就可以做到和各个微服务体系间的两两之间的互联互通。进一步的，如图中橙色箭头所示，依赖 Dubbo 体系作为桥接层，我们还可以实现两个异构微服务体系间的打通。
Dubbo 体系内的协议迁移（共存）
当前在云原生、Mesh 的大背景下， HTTP1/2、gRPC 协议开始受到越来越多的关注，一方面原因自然是因为它们在标准化方面做的更好，得到的更多的网络设备和基础设施的支持，具备更好的通用性和穿透性。对于很多有云原生迁移意愿的企业来说，往此类协议迁移无疑将对之后的架构升级有更多的帮助。
-
最左边的代表尚未迁移的老应用，这类应用在迁移过程中仍然要消费和提供 Dubbo 协议的服务。
-
中间的代表处于迁移中的应用，他们中间可能有些是服务提供者，既要为左边的老系统提供提供 Dubbo 协议服务；又要为右边的新系统提供 gRPC 服务；因此他们都是双协议暴露服务。
-
最右边则代表是新开发的或者已经迁移完成的应用，这个体系内已能完全用 gRPC 协议通信。
-
最终度过中间态后，我们期望所有的应用都达到最左边应用的状态，实现完全的 gRPC 协议通信。
Spring Cloud 体系迁移到 Dubbo 体系（共存）
Dubbo 体系内的部分应用作为透明的联通两个体系的关键节点，部分服务提供者应用要双协议发布、部分消费者应用要做到选定协议消费。由于老的 Spring Cloud 体系不允许做任何改动，因此联通两套体系的关键是 REST 协议，对 Dubbo 侧的应用来说：
-
部分应用可能要以 REST 协议消费 SpringCloud 的服务；
-
部分应用可能要暴露 REST 协议共 SpringCloud 消费；
-
Dubbo 自有体系内则通过自己选定的协议通信，这里就比较灵活了，可以是 Dubbo、REST、gRPC 等其中的任一种。而如果选定 REST 协议则对于与 SpringCloud 体系的联通就变得更加自然了，因为两端的协议都是统一的。
<dubbo:reference interface ="xxx.SpringService" protocol="rest"/><dubbo:service interface="xxx.NewService" protocol="rest,dubbo"/>作为 Dubbo 的维护者，虽然我们这里有明显的偏向性，讲的是从如何从 SpringCloud 体系迁移到 Dubbo 体系。但是反过来考虑，如果你已经或者即将选型 Dubbo 来开发微服务，则未来从 Dubbo 迁移到 SpringCloud 也是同样的思路，Dubbo 的多协议、多注册模型为双向迁移都提供了同样的灵活性。
自建体系迁移到 Dubbo 体系（共存）
http://dubbo.apache.org/zh-cn/docs/dev/impls/protocol.html
总结与展望
作者信息：
刘军，GitHub账号Chickenlj，Apache Dubbo PMC，项目核心维护者，见证了Dubbo从重启开源到Apache毕业的整个流程。现任职阿里云云原生应用平台团队，参与服务框架、微服务相关工作，目前主要在推动Dubbo开源的云原生化。
注意：本文归作者所有，未经作者允许，不得转载
