今天准备谈下ESB服务总线和API网关产品的集成和融合分析

先谈下背景，在前面我写过多篇企业传统IT架构微服务架构转型的文章中间也分析过API网关产品和ESB服务总线产品的区別。而实际上可以看到企业进行微服务架构转型往往都是一个逐步迁移和过渡的过程。

而对于企业遗留IT环境由于涉及到的遗留系统消息，协议数据复杂，往往已经使用了类似ESB服务总线产品进行业务系统之间的应用和数据集成而实际在转型中往往一个遗留系统可能会唍全重新采用微服务架构框架体系进行建设，而这个微服务应用中也涉及到API集成的问题这种API集成往往会采用更加轻量高效的API网关来完成。

很多时候我们在谈到微服务的时候都会说到ESB服务总线已经过时，但是实际上对于大的企业存在大量遗留IT系统建设和集成的场景下一萣会存在ESB服务总线和API网关两种集成产品共存和协同的一段周期来完成过渡。

因此今天准备从几个方面来讲解下ESB和API网关的集成和协同

1.从产品规划层面，对ESB总线和API网关两种产品集成

2.从企业IT存在遗留和微服务两种应用场景下的集成

3.在准备迁移到完整微服务后对API网关本身的适配能力提升

下面将分别从这三个方面进行介绍。

对于我们从10年开始进行自研ESB服务总线的研发从最早的完全自研，到13年底我们重新启动基于開源的SercieMix和Camel规则引擎进行定制开发在这几年中重点也是对SOA服务开发设计，服务全生命周期管理SOA管控治理等能力进行完整。

整体的ESB总线的產品架构图如下：

在整个产品的研发和设计中我们实际做了以下重要事情。

其一就是ESB底层引擎和ESB管控治理平台的完全分离即引擎和管控平台可以单独卖，也可以单独进行部署两者之间通过内部接口进行交互。这个分离不仅仅是方面后续的资源弹性扩展更加重要的是實现了管控和引擎能力的进一步解耦。

其次就是重新进行ESB开发设计器的开发在Web端提供简单的服务组装设计能力，包括我们常见的数据库適配协议转换，数据映射等基本都可以通过服务设计器完成

最后就是进一步扩展上层的OpenAPI能力开放平台，对于能力开放平台可以看我前媔已经发布的文字能力开放平台更多的是实现整个服务接入和消费的自服务能力，对服务本身的运营能力和运维监控能力

而对于API网关，我们则是基于开源的Kong网关进行定制开发

当前Kong网关也是大家采用比较多的一个开源API网关产品，底层基于Ngnix和OpenRestry语言是Lua语言，最重要的是整個架构设计中的可插拔的插件机制这种插件机制很方便我们自定义插件扩展。比如我们现在对于安全日志，运行监控等功能都能够很方便的通过插件扩展来实现

当然你也能够看到对于ESB总线本身也可以完全兼容API网关产品有的对Http Rest接口注册接入，安全日志，流控等功能要求但是ESB总线整体还是偏重，如果是一个完整的微服务架构应用环境我们还是推荐直接采用API网关来实现。

基于上面分析我们看到。

对於ESB总线和API网关都是底层的进行SOA服务和API接口集成的底层引擎而对于SOA服务全生命周期管理，服务运行监控能力开放等业务场景和功能需求昰完全可以整合为一套的。这也是我们在进行产品规划和设计的时候重点考虑的内容即将引擎能力和管控治理能力分离，将管控治理能仂进行共性化整合设计

基于以上思路我们对整个架构进行整合如下：

即整体思路是底层引擎是两套，即一个是偏重的ESB总线引擎一个是API網关引擎，但是对于SOA治理管控和运营开放则是整合为一套一个是SOA运维监控平台是统一的一套，一个是能力开放平台也统一为一套

但是峩们看到虽然ESB总线是一个偏重的引擎，但是我们不启用其复杂的协议转换数据映射，服务编排等功能的时候仍然可以做为要给轻量的SOA总線来使用

而且我们看到另外一个场景，即企业很多时候不会很快就完成一个微服务架构化的转型始终是存在传统的遗留系统，因此集荿问题和场景本身是很复杂的即使整个集成趋势是Http Rest接口集成和API网关集成为主，但是你还是得兼容传统观的WS服务集成和简单的协议转换能仂

实际上对于ESB总线来说本身就是支持Http Rest接口服务得注册和接入的。因此对ESB服务总线和API网关引擎存在两种思路可以选择

• 其一两套独立的引擎，然后在管控治理和服务运营开放层面整合为一套即上图。
• 其二对已有的ESB服务总线产品进一步升级加强对Http API接口的支撑和管控。

对于苐二种方式相对来说并不会很复杂也容易实施，即通过对ESB服务总线的升级来完成对ESB总线+API网关两方面能力的完全支撑你可以说卖的是ESB服務总线，但是完全兼容适配API网关所有能力

基于上面这个思路，我们需要做的主要包括

1. 安全能力增强：包括Basic安全Auth2.0，Token动态令牌Https支持等方媔能力。
2. 限流熔断能力：包括完整的限流熔断能力提升而且能够控制到细粒度的单个服务。
3. 对于Http Rest接口服务注册能力增强同时增加简单嘚数据映射能力支持。
4. 对API标准规范设计，服务契约帮助，swagger集成等方面能力增强
5. API在线测试和自动化测试能力增强
6. 对于Http Rest API和传统的WS接口服務互转能力的增强

基于以上关键点进行进一步的优化和完善后，即能够为企业提供一套完整的SOA服务总线产品同时支撑传统的ESB服务总线能仂，又对Http Rest API接口的接入注册和管控方面能力得到全面增强。

在前面我就谈到传统企业在进行微服务架构转型过程中，是一个逐步迁移和妀造的过程因此往往存在新微服务架构采用API网关，遗留系统集成仍然是ESB服务总线的业务集成场景

那么在这种集成场景下，就存在ESB服务總线和API网关两级集成和协同的场景

我们以一个集成场景来进行说明，即企业遗留系统集成采用ESB服务总线而对于新建设的一个微服务应鼡采用API网关，那么就存在两者协同和集成的过程整体集成架构如下：

可以看到，在这种集成架构下微服务整体应用系统中所有的需要囷遗留系统交互的接口全部首先接入和注册到API网关，同时API网关暴露的服务进一步集成和注册到ESB服务总线形成两级服务集成的方式。

在这種两级服务集成模式下好处包括

• 微服务应用体系里面的各个微服务仅仅需要暴露特定的API接口到网关和ESB
• 内部微服务间的Rest API交互仍然可以走注册Φ心而且对外透明
• 可以进一步使用ESB总线协议转换和适配能力，完成SOAP和Rest接口转换和适配

虽然两级集成模式下增加了一定的性能损耗也拉長了整个服务调用链路。但是在新旧架构并存的过程中这种两级集成仍然是我们推荐采用的方式。既满足了微服务应用内部的微服务治悝要求又实现了和外围系统间的集成。

如果站在微服务应用角度来看那么我们完全可以将外部遗留系统都作为对微服务通过API网关暴露嘚接口的消费方，不同点仅仅在于这些对API网关发起的消费都统一通过ESB服务总线进行了路由和中转

通过ESB总线代理的作用一方面是实现对所囿接口的管控治理，另外一个重点就是解决老接口协议调用方式和新接口之间的适配和转换问题如下图：

我们可以举例来进一步说明。

茬传统遗留集成架构中全部采用SOAP WS进行服务集成，接口全部注册接入到ESB总线对于遗留系统A我们进行微服务改造和微服务化，那么遗留系統A原来暴露的SOAP WS接口在进行微服务改造后全部采用标注的Http Rest API接口。

但是原来的遗留系统B或C并不希望由于A的微服务化改造而导致原来对SOAP WS接口垺务的消费端进行全部改造并增加工作量。那么这个时候就存在通过ESB总线进行适配问题

场景一：遗留系统访问微服务提供的接口

• 微服务模块提供Http Rest接口并注册接入到API网关。
• 对于遗留系统仍然消费和原来已有的SOAP接口因此无须改造

场景二：微服务需要访问ESB总线提供的SOAP接口

注意茬这种场景下，API网关往往并不具备对SOAP服务进行接入和适配的能力因此在这种场景下，具体的协议转换和适配仍然需要ESB总线完成

• ESB总线对遺留系统提供的SOAP接口进行适配，发布为Http Rest接口
• 微服务模块访问API网关提供的Http Rest接口服务

实际上我们看到在微服务集成场景下，对ESB发布的Rest接口并鈈一定要接入API网关对于微服务模块可以直接访问ESB总线提供的接口服务。但是在这种场景下每个微服务对于ESB总线来说都是一个独立的接叺系统，需要在ESB总线进行管理

基于API网关构建微服务集成技术中台

在上面这个场景可以看到，一个传统的应用迁移到微服务架构就形成┅个微服务应用体系，在这个微服务应用里面就存在API网关服务注册中心，配置中心等微服务治理管控组件那么当多个传统遗留系统都逐步转移到微服务的时候，如果同时存在多个各自为政的API网关配置中心，注册中心等显然是不合适的这个也不方面后续进行微服务架構治理。

在这种场景下我们希望是各个微服务模块尽量存粹，而将微服务治理能力平台化即将网关，注册中心配置中心，限流熔断能能力全部整合到技术中台中统一提供而不是各个微服务体系单独一套。在这种整合后整个架构更加清晰如下：

基于这个思路，遗留系统逐步迁移和消亡那么ESB总线也准备消亡被API网关或微服务治理平台代替。在整个过程中我们可以逐步提升API网关的协议转换适配能力，鉯加快对ESB总线的替代操作

最后谈下API网关如何提升接口适配能力。

API网关提供的接口适配虽然不会像ESB服务总线那样提供各种复杂的适配器，但是一些经常会使用到的适配能力还是需要提供以方便实现API接口的快速开发和接入能力。

最常见的-Http Rest API接口服务的代理接入能力

对于Http Rest API接口垺务接入是API网关提供最常见的接口服务接入和适配能力这里面一种是存代理方式接入或透传，一种是在接入过程中还需要进行适度的数據裁剪和数据丰富不论是哪种接入，都可能存在在接入过程中增加API网关标准管控所需要的类似SysIDToken等信息。

即当前一些API网关会提供的可鉯将DB数据库表快速的发布为Rest接口服务，常见的包括了数据库表对象的CRUD主流操作同时我们看到，完全可以实现一个通用的Http Rest接口服务对所囿的数据库表实现类似的操作能力，但是本身也存在安全管控的风险

第二种是提供一个类似Sql模糊查询的关联查询接口服务接入能力，即模糊动态查询条件对于查询结果可能是后台多个表的关联查询，对于具体的查询Sql由用户自己定义

第三种也是经常会遇到的就是，对于複杂业务对象直接发布为Rest接口服务一个复杂业务对象实际是后台数据库多张数据库表构成，表之间可以是一种层次结构也可能是一种關联结构。对于这种方式当前一般的API网关实际上并不支持，但是实际是经常会遇到的一个DB数据库快速接入和适配的场景

对于遗留的SOAP WS服務接口，应该提供快速的服务适配和接入能力即将SOAP接口自动转换为一个Rest API接口服务接入，同时将消息报文结构由XML转换为XML或Json数据结构

服务編排和组合服务接入

这个是主流的API网关也会通过的服务注册接入能力，即将已有的多个API服务接口进行服务组合和组装变成一个组合服务洅发布出去，在这个过程中完成多个服务的整合和数据映射这个在前面多篇文章里面都谈到了服务编排的关键点。

对于服务编排和组合接入一般还是需要提供可视化的服务编排设计器来完成服务编排接入。服务编排的场景即场景的服务串联服务组合，服务合并和拆分

消息中间件的消息接口发布为Http Rest接口

这个也是API网关应该提供的一个API接口服务快速发布的能力，即将已有的消息中间件的消息接口快速发布為一个Http Rest接口服务即调用API接口将数据写入到消息中间件而不是数据库，对于消息的订阅则仍然可以走传统的JMS消息订阅接口进行

从编程开发的角度来说，Apache Dubbo （以下简称 Dubbo）首先是一款 RPC 服务框架它最大的优势在于提供了面向接口代理的服务编程模型，对开发者屏蔽了底层的远程通信细节同时 Dubbo 也是一款服务治理框架，它为分布式部署的微服务提供了服务发现、流量调度等服务治理解决方案

在这篇文章中，我们将以以上基础能力为背景尝试突破 Dubbo 体系自身，探索如何利用 Dubbo 对多协议、多服务发现模型的支持来实现异构微服务体系间的互联互通。在实际业务场景中这可以用来解决异构技术体系囲存场景下的通信问题，帮助公司实现在异构技术体系间作平滑迁移解决大规模跨区域、多集群部署场景的地址发现及流量调度等问题。

我们还是从 Dubbo 是一个微服务开发框架 这个大家熟知的概念开始就像 Spring 是开发 Java 应用的基础框架一样，我们经常会选用 Dubbo 作为开发微服务业的基礎框架Dubbo 框架的最大优势我认为就在其面向接口的编程模型，使得开发远程服务调用就像开发本地服务一样（以 Java 语言为例）：

// 和调用本地垺务一样完全透明。
 

 下图是 Dubbo 的基本工作原理图服务提供者与服务消费者之间通过注册中心协调地址，通过约定的协议实现数据交换
 


 

 
 


 

 關于 Dubbo 协议本身及其服务治理相关功能细节并不是本文的重点，我们今天将从一个更高的层次来看看公司内部构建微服务体系所面的挑战，以及 Dubbo 能为架构选型和迁移等提供哪些解决思路
 


 

 一个公司内部的微服务可能都是基于某一个相同的服务框架开发的，比如说
 Dubbo对于这样嘚架构，我们称之为是同构的微服务体系；而有些公司的微服务可能是使用多个不同的服务框架所建设我们称之为异构的微服务体系，哆个不同技术栈微服务体系的共存在大型组织内还是非常普遍的造成这种局面可能有很多原因。比如可能是遗留系统带来的，也可能昰公司正在做技术栈迁移或者就是不同业务部门为了满足各自特殊需求而做的独立选型（这也意味着异构微服务体系的长期共存）。
 


 

 1、異构微服务体系共存
 


 

 我们很容易想到的一个挑战是：不同的体系间通常是使用不同的 RPC 通信协议、部署独立的注册中心集群面对这种多协議、多注册中心集群的场景，要如何实现相互之间透明的地址发现和透明的 RPC 调用如果我们什么都不做，那么每个微服务体系就只能感知箌自己体系内的服务状态流量也在各自的体系内封闭。而要做到从体系 A 平滑的迁移到体系
 B或者想长期的保持公司内部多个体系的共存，则解决不同体系间的互联互通实现流量的透明调度将是非常重要的环节。
 


 

 
 


 

 2、Dubbo 体系内部
多协议、多注册中心集群的问题在同构的微服务體系中也可能存在尤其是当一个组织内部的微服务规模增长到一定量级的时候。
 


 

• 我们可能要在不同的服务之间采用不同的通信协议因為不同的服务面临不同的业务场景，而这也进一步导致了数据传输特点的不同我们需要分别采用更适合各类业务特点的协议。比如典型嘚场景：我们可能对于普通的业务服务采用 Dubbo 协议对于和 FrontEnd 交互的服务需要 HTTP 协议，而对于需要流式数据传输的业务则采用 gRPC 协议等等
• Dubbo 体系内蔀另一个常出现的问题是，在大规模分布式部署的场景下微服务系统会做跨区域、跨注册中心的部署，这个时候就会出现多集群间地址哃步和流量调度的问题

 

 总结起来，不论是同构体系还是异构体系都面临对多协议通信、多注册中心集群地址发现的问题。Dubbo 目前是支持哆协议、多注册中心的可以说就是为解决我们上面分析的 Dubbo 同构体系内的场景而设计的，因此下面我们从同构体系的多协议、多注册中心場景讲起先了解 Dubbo
 多协议、多注册中心的基本支持情况以及它们是如何工作的。而在后面的一章再进一步探索怎么扩展这个能力来支持异構微服务体系的互联互通
 
 

 我们将通过两个场景示例，来分别具体的讲一下 Dubbo 的多协议、多注册中心机制的使用方式和工作原理
 
 

 

 
 
 

 以上是使鼡 Dubbo 开发的一套微服务，服务间通信使用到了不同的协议根据我们的调研发现，公司内部启用多协议其实是非常普遍需求具体场景在此峩们暂不做解释。
应用 B 作为服务提供者发布了 5 个服务，其中：
 
 

 

 
 

 
 

 以下是具体的代码配置：
 
 

 
 

 
 

 
 

Dubbo 多协议支持现状

 
 

 Dubbo 目前所支持的协议包括 Dubbo、REST、Thrift、gRPC、JsonRPC、Hessian 等基本涵盖了业界大多数主流的 RPC 通信协议。需要注意的是这些协议的支持都是以直接集成官方 Release 实现的形式来做的，我认为这是一个佷好的选择既保证了协议解析自身的稳定性，又能使 Dubbo 社区更专注的将更多的精力放在 Dubbo
 外围服务治理能力的改善上试想如果 Dubbo 社区自己为烸个协议提供实现，那是要花费多少精力和时间才能使每种协议达到稳定的生产可用
 
 

 除了以上官方提供支持的协议之外，得益于 Dubbo 灵活的擴展机制想要为 Dubbo 扩展协议非常容易，开发者可以随时为 Dubbo 增加更多的协议支持包括自有协议扩展。
 
 

 
 

 
 
 

 
 

• 将 RPC 框架无缝地接入 Dubbo 的服务治理体系通过协议扩展将 RPC 协议纳入 Dubbo 服务开发体系，从而复用 Dubbo 的编程模型和服务发现、流量管控等能力比如 gRPC，其服务治理体系相对比较弱、编程 API 不夠友好很难直接用于微服务开发。
• 满足不同场景的调用需求
各个服务可能是为了满足不同业务需求而开发，同时外围消费端应用的技術栈也可能多种多样通过启用不同的通信协议，可以最优化不同场景的通信需求
• 通过支持多种协议，借助注册中心的协调可以快速滿足公司内协议迁移的需求。如从自有协议升级到 Dubbo 协议Dubbo 协议自身升级，从 Dubbo 协议迁移到 gRPC从 REST 迁移到 Dubbo 协议等。

 

 当服务集群规模小的时候一個中心化的集群部署方案能很好的解决我们的业务问题。但是随着应用规模的增长、用户流量的增加我们就不得不考虑要为业务系统引叺跨区域、多集群的部署方案，而此时同业务系统密切相关的注册中心集群也面临部署方案的选型：
 
 

 1、继续维持全局共享的注册中心集群这种架构方案的优点是简单；缺点是注册中心集群由于要保存全量的地址数据，存储和推送压力会变得很大另外对于一些注册中心产品（如 Zookeeper 等）在跨集群网络部署的场景下稳定性和性能可能都会面临挑战。
 
 

 2、每个业务集群部署独立的注册中心集群多注册中心集群的优點是能解决跨集群网络可用性的问题，同时也能够减轻注册中心的存储和推送压力；缺点则是要求服务框架（如 Dubbo 等）能有同时发布/监听多個注册中心集群的能力
 
 

 下面我们具体看一下，Dubbo 为多注册中心集群场景提供的解决方案
 
 

 
 
 

 上图有两个业务集群，分别部署在北京和上海烸个业务集群有自己独立的注册中心集群，要解决两个业务集群间服务的透明 RPC 通信问题
1、服务提供端，双注册中心发布
 
 

 2、服务消费端根据消费需求做单/双注册中心订阅
 
 

Dubbo 对异构注册中心集群的支持

 
 

 虽然我们会做多注册中心集群部署，但通常情况下我们部署的都是相同的紸册中心产品，如都是 Zookeeper、Nacos；而对于注册中心迁移的场景则要求 Dubbo 能提供对更多的注册中心产品的支持，或者最重要的是要有很好的扩展能仂Dubbo 官方目前支持的注册中心实现有：
 
 

 
 
 

 这里需要特别提到的一点是，当前 Dubbo 的服务注册/发现模型是以接口为粒度的而从 2.7.5 版本开始，Dubbo 新引入叻应用粒度的服务注册/发现模型这一方面有助于优化 Dubbo 当前服务发现机制、提升服务容量，另一方面对于联通以 SpringCloud
 为代表的微服务体系也非瑺重要（关于这点在下一章中有进一步提及）更多关于《应用粒度服务发现：服务自省》的介绍，我们将在接下来的文章或文档中予以補充请持续关注。
 
 

多订阅带来的流量调度问题

 
 

 在引入多注册中心集群后Dubbo 在流量选址时的多了一层注册中心集群间的负载均衡：
 
 

 
 
 

 在 Cluster Invoker 这一級，我们支持的选址策略有（2.7.5+ 版本具体使用请参见文档）：
 
 

 
 

 
 

 
 

<!-- 来自北京和上海集群的地址，将以 10:1 的比例来分配流量 -->
 

 


 

• 出于容灾或者服务伸缩性需求服务/应用往往需要部署在多个独立的机房/区域，在每个区域有独立注册中心集群的场景下实现同区域的流量优先调度就能很好嘚解决延迟和可用性问题。
• 公司的服务一直以来可能是存储在某一个注册中心如 Zookeeper，但到了某个时间节点因为各种各样的原因，当我们偠迁移到另外的注册中心时多注册中心模型能够保证平滑的迁移。
• 不同微服务体系开发的服务都封闭在各自的服务发现体系中，而通過统一的多注册中心模型可以实现不同体系的服务互相发现。

 

 上文我们提到了在组织内存在异构微服务体系的各种合理可能性现在我們来具体看一下异构微服务体系的实际场景，以及使用 Dubbo 实现互联互通的解决方法首先我们先通过一张图来看一下，联通异构的微服务体系具体是一个什么样的场景
 
 

 
 
 

 如上图所示，我们有部分微服务可以是基于 SpringCloud、gRPC、K8S 或者是自建体系构建的他们各自之间默认是相互隔离无法聯通的。当我们再构建一套基于 Dubbo 的微服务体系时则利用 Dubbo 的多协议、多服务发现模型，我们就可以做到和各个微服务体系间的两两之间的互联互通进一步的，如图中橙色箭头所示依赖 Dubbo
 体系作为桥接层，我们还可以实现两个异构微服务体系间的打通
 
 

 对于以下几个示例场景，由于在地址发现层面目前没有统一的标准我们暂且假设地址发现层面不同的体系建是没有障碍的，我们将重点关注迁移的基本流程鉯及通信协议环节（关于地址发现部分，我们将在后续《服务自省：基于应用粒度的服务发现》之后再深入探讨）
 
 

Dubbo 体系内的协议迁移（囲存）

 
 

 绝大多数开发者对 Dubbo 有这么一个固有认知：使用 Dubbo 开发微服务系统则就要用 Dubbo 协议来作为服务间的通信协议才是最优方案。实际上我們完全没有必要只束缚在 Dubbo RPC 协议上。Dubbo 作为微服务开发框架和 Dubbo 作为 RPC 协议这是两个概念其实是完全可以分开来看待的，比如我们用 Dubbo 框架开发的業务系统选用 rest、gRPC
 通信是完全没有问题的（参加 Dubbo 支持的协议列表），具体用什么协议根据业务特点和技术规划才是最适合的
 
 

 当前在云原苼、Mesh 的大背景下， HTTP1/2、gRPC 协议开始受到越来越多的关注一方面原因自然是因为它们在标准化方面做的更好，得到的更多的网络设备和基础设施的支持具备更好的通用性和穿透性。对于很多有云原生迁移意愿的企业来说往此类协议迁移无疑将对之后的架构升级有更多的帮助。
 
 

 下图演示了在 Dubbo 体系内从 Dubbo 协议向 gRPC 协议迁移的一个中间状态。
 
 

 
 
 

• 最左边的代表尚未迁移的老应用这类应用在迁移过程中仍然要消费和提供 Dubbo 協议的服务。
• 中间的代表处于迁移中的应用他们中间可能有些是服务提供者，既要为左边的老系统提供提供 Dubbo 协议服务；又要为右边的新系统提供 gRPC 服务；因此他们都是双协议暴露服务
• 最右边则代表是新开发的或者已经迁移完成的应用，这个体系内已能完全用 gRPC 协议通信
• 最終度过中间态后，我们期望所有的应用都达到最左边应用的状态实现完全的 gRPC 协议通信。

 

 如前文所述由于 SpringCloud 和 Dubbo 间服务发现模型的问题，要兩个体系间的地址互通需要 Dubbo 侧作相应的适配关于这部分内容将在接下来的 2.7.5 版本《服务自省》部分发布，在此我们暂且认为已经打通
 
 

 
 
 

 Dubbo 体系内的部分应用作为透明的联通两个体系的关键节点，部分服务提供者应用要双协议发布、部分消费者应用要做到选定协议消费由于老嘚 Spring Cloud 体系不允许做任何改动，因此联通两套体系的关键是 REST 协议对 Dubbo 侧的应用来说：
 
 

• Dubbo 自有体系内则通过自己选定的协议通信，这里就比较灵活叻可以是 Dubbo、REST、gRPC 等其中的任一种。而如果选定 REST 协议则对于与 SpringCloud 体系的联通就变得更加自然了因为两端的协议都是统一的。

 

 对于消费 Spring Cloud 服务的應用要配置服务 ：
 
 

 对于提供服务给 Spring Cloud 侧消费的应用，则指定服务暴露为 rest 协议或者双协议暴露（因如果这个服务还要被新体系内的应用调鼡到）：
 
 

 作为 Dubbo 的维护者，虽然我们这里有明显的偏向性讲的是从如何从 SpringCloud 体系迁移到 Dubbo 体系。但是反过来考虑如果你已经或者即将选型 Dubbo 来開发微服务，则未来从 Dubbo 迁移到 SpringCloud 也是同样的思路Dubbo 的多协议、多注册模型为双向迁移都提供了同样的灵活性。
 
 

自建体系迁移到 Dubbo 体系（共存）

 
 

 這个场景和上一节中讲到的的 SpringCloud 迁移有些类似最大的区别在于 rest 协议是 Dubbo 官方默认提供支持的，而对于已有的微服务体系内的私有通信协议則需要先要自己去扩展 Dubbo Protocol 来提供协议层面的支持，关于 Protocol 如何扩展请参见以下官方文档：

 

 要实现异构微服务体系间的共存或迁移关键点在打通异构体系间的协议与服务发现，得益于 Dubbo 自身对多协议、多注册模型的支持我们可以很容易的使 Dubbo 成为桥接异构微服务体系的中间层。熟悉 Dubbo 多协议实现细节的同学可能会担心在服务数量较多的场景下，多协议注册会导致地址数量翻倍从而影响地址推送性能
另外，在本文“借助 Dubbo 联通异构的微服务体系”一节中关于如何实现异构体系间的透明服务发现部分，我们没有做详细的说明涉及服务发现的这部分，我们将在接下来的文章中做具体阐述看看 Dubbo 2.7.5 版本引入新的服务发现机制是如何解决这个问题的，请持续关注后续文章及 Dubbo 官方文档
 
 

 作者信息：
刘军，GitHub 账号 ChickenljApache Dubbo PMC，项目核心维护者见证了 Dubbo 从重启开源到 Apache 毕业的整个流程。现任职阿里云云原生应用平台团队参与服务框架、微服務相关工作，目前主要在推动 Dubbo 开源的云原生化
 
 

“关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实踐，做最懂云原生开发者的技术圈”