Spring Cloud与Dubbo共存方案总结

1、背景

假设有一个遗留的Dubbo系统，如今想改用Spring Cloud。

因为遗留Dubbo系统比较庞大，短时间以内没法完成技术栈的迁移。所以须要“分步走”，即：初期实现二者共存，后期逐步绞杀Dubbo应用，最终实现技术栈的统一。

p.s. 这里并无贬低Dubbo的意思，仅是按照该场景讨论。

2、头脑风暴

架构迁移、技术栈更换、项目重构时的第一步每每不是“改造”，而是“中止修改”。基于这个原则，我的不太倾向于去当即大幅重构Dubbo应用原先的代码。缘由有二：首先是原则问题，更重要的是时间成本、技术风险很可贵到控制。

而，假如新编写的Spring Cloud应用去进行迁就，例如：

彻底不动Dubbo遗留系统，使用RestTemplate或Feign编写Dubbo（DubboX）的RESTful API客户端代理 —> 有必定的实现复杂度、Dubbo接口改形成RESTful API后，消费方都须要再次修改（开始是代理，后来不用代理，所以有二次修改的问题）。

索性将Spring Cloud应用也整合Dubbo—>存在改造不完整、技术栈不统1、没法约束开发人员用哪一种方式API、额外的复杂度的问题（越多的组件、越多的环节意味着越多的坑）。

考虑到通常来说，遗留系统的改造过程当中通常都是新系统调用老系统，不多出现老系统大规模调用新系统的场景（至少我这边目前是这样^_^）。所以，笔者列出几种仅需少许的代码编写成本便可实现Spring Cloud与Dubbo短时间/长期共存，而且侵入性较小，同时还容许咱们改造遗留Dubbo系统的几种方案，算是抛砖引玉。期待朋友们提出更优雅、成本更小的方案。

3、亮代码

Sample1：借助Ribbon调用Dubbo应用。

优势：

架构不依赖Eureka或其余服务注册组件，借助Ribbon去调用Dubbo微服务暴露的RESTful API；

缺点：

若是Dubbo微服务较多时，均需手动配置，不适合新式的部署环境（例如Docker，由于每次部署IP/端口可能都不一样）

Sample2：借助Sidecar

使用Sidecar，Dubbo微服务必须实现健康检查（对于Spring Boot程序即：添加spring-boot-starter-actuator依赖）。

优势：

这种方式下，Dubbo应用也可经过Sidecar调用Spring Cloud微服务的接口，Sidecar是链接Spring Cloud应用于Dubbo应用的桥梁。

能够经过Sidecar传播Dubbo微服务的健康状态到Eureka Server。

缺点：

在于每一个Dubbo微服务节点必须额外部署一个Sidecar应用。

在Dubbo微服务调用Spring Cloud微服务时，增长了调用链的长度。（需使用Sidecar转发）

Sample3：借助Eureka实现整合

将Dubbo应用也注册到Eureka上。

优势：

没有多余的组件（除了Dubbo的注册中心ZK）

没有什么局限

缺点：

对于非Spring Boot的应用，改造有必定的成本。

GOING FAR

本项目中几个Demo中，都是手动编码为Dubbo应用开放RESTful API的，实际迁移过程能够借助cglib或者lombok之类的工具，实现从Dubbo接口道RESTful API的转换。本仓库主要仍是为你们提供思路，不作具体讨论。

代码下载地址

https://github.com/itmuch/spring-cloud-dubbo-together