HTTP & RPC & Dubbo & hsf & Spring-cloud 图解比较

前言

HSF是一个分布式的远程服务调用框架，其实我更喜欢把分布式几个字去掉，因为HSF本身并不是一个单独的服务（指一个进程），他是附属在你的应用里的一个组件，一个RPC组件(远程过程调用——Remote Procedure Call，是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发分布式应用更加容易)，当然HSF完全的内容肯定不止这些。

​ HSF(High-speed Service Framework)，高速服务框架，是阿里系主要采用的服务框架，其目的是作为桥梁联通不同的业务系统，解耦系统之间的实现依赖。其高速体现在底层的非阻塞I/O以及优秀的序列化机制上，实现了同步和异步调用方式，并且有一套软负载体系，实现分布式应用。

RPC

我们先来看一张图：

很多同学看了这张图可能会觉得这跟http的过程有什么区别？

有这么一个场景（本来想举一个便具体业务的例子，想想还是已技术实现相关的比较好），监控平台：监控所有主机的状态，这时候每台主机上有一个agent，每个几秒向监控平台上传一次数据（主机内存使用率、硬盘状况、CPU、load、进程信息等等）。

可能在开发的时候最简单的方式就是监控平台有一个http接口，agent每隔几秒请求一次，能够满足需求，但是如果主机数快速增长了很多、监控项越来越多、请求体越来越大，你会发现http的传输效率下降了，每一次调用的耗时增加了。

这时我们会去研究http协议，想去优化这个过程，发现http的过程是：建立连接、发送请求信息、发送响应信息、关闭连接，看到这个过程首先想优化的就是能不能不要每次都去建立连接关闭连接，因为数据上报是个持续的过程；紧接着去研究http头，发现很多协议用不到，繁杂，白白增加了消息体；后来又觉得http的协议解析还原过程很复杂，可以自己开发一个提升性能……

RPC来了，他能满足这些需求，但是前提是需要开发，需要前期成本，所以想项目设计时就要去衡量，不过没事，我们有HSF啊。

我们将上图稍微改造一下：

现在从图中可以看着，client和server之间有一条长连接，并且我们有自己的协议体：RpcRequest和RpcResponse。

RPC就讲到这里，毕竟重点是HSF，想要更多的了解RPC，可以上wiki或者网上查询。

HSF架构

其实在我们的应用中，一般情况下你的应用不仅仅是client，也是server，因为你不仅需要去调用其他应用提供的服务，也提供服务给其他应用，所以这样一来，整个hsf的服务调用链路也会很复杂。

从上面两幅图中我们很显然的发现一个问题，就是服务提供者如何告知客户端他提供的服务，所以需要有一个服务注册与发现的地方，在HSF架构中提供这个功能的是configserver，如下图：

从上图可以看出server端启动的时候会向configserver注册自己提供的服务，client会向configserver订阅需要的服务，configserver通过订阅信息将相关服务提供者的地址以及其他关键信息推送给client。

上面已经实现了基本的能力，但是如何动态配置负载（线程池大小）、默认配置（configserver地址等）、还有一些特性功能（如路由规则），这时候就需要有一个持久化配置中心，如下图：

client和server启动的时候会先去diamond获取需要的配置信息，如最关键的服务注册中心的类型和地址，除此之外之外还有服务治理的类型和地址等。

重点说一下路由规则，举个例子：通过路由规则配置在服务调用的时候只调用同机房的server，这样子服务调用的耗时肯定比跨机房的耗时短。除此之外hsf里还单独写了unitService进行服务单元发布来区分中心发布，这些番外的东西以后有时间再写个番外篇，这里就不过多阐述了，毕竟这些有点偏场景偏业务的内容以后可能就改成别的方式了。

相信大家都用过hsf服务治理网站，通过这个网站可以看到有哪些服务、服务提供者的地址是多少、有多少提供者、具体的消费者是谁，hsf通过configserver、redis、diamond里的存储信息获取到这些信息。

redis功能：HSF使用Redis存储元数据，每一个HSF Consumer/Provider 都会在启动后、每隔一段时间向redis上报元数据，这些元数据采集起来又提供给HSFOPS做服务治理，包括应用名和服务的映射、服务的元数据等。

Dubbo：

简介：Dubbo是一个分布式服务框架，以及SOA治理方案。其功能主要包括：高性能NIO通讯及多协议集成，服务动态寻址与路由，软负载均衡与容错，依赖分析与降级等。

底部NIO基于netty框架；

 

 

 

 

 

HSF：

简介：HSF提供的是分布式服务开发框架，taobao内部使用较多，总体来说其提供的功能及一些实现基础：
1.标准Service方式的RPC
  1）、Service定义：基于OSGI的Service定义方式
  2）、TCP/IP通信：
   IO方式：nio,采用mina框架
   连接方式：长连接
   服务器端有限定大小的连接池
   WebService方式
  3）、序列化：Hessian序列化机制
2.软件负载体系
3.模块化、动态化
4.服务治理

性能：

 

 

Dubbo  &  HSF compare

Dubbo优点：

1.  Dubbo比HSF的部署方式更轻量，HSF要求使用指定的JBoss等容器，还需要在JBoss等容器中加入sar包扩展，对用户运行环境的侵入性大，如果你要运行在Weblogic或Websphere等其它容器上，需要自行扩展容器以兼容HSF的ClassLoader加载，而Dubbo没有任何要求，可运行在任何Java环境中。 
2.  Dubbo比HSF的扩展性更好，很方便二次开发，一个框架不可能覆盖所有需求，Dubbo始终保持平等对待第三方理念，即所有功能，都可以在不修改Dubbo原生代码的情况下，在外围扩展，包括Dubbo自己内置的功能，也和第三方一样，是通过扩展的方式实现的，而HSF如果你要加功能或替换某部分实现是很困难的，比如支付宝和淘宝用的就是不同的HSF分支，因为加功能时改了核心代码，不得不拷一个分支单独发展，HSF现阶段就算开源出来，也很难复用，除非对架构重写。 
3.  HSF依赖比较多内部系统，比如配置中心，通知中心，监控中心，单点登录等等，如果要开源还需要做很多剥离工作，而Dubbo为每个系统的集成都留出了扩展点，并已梳理干清所有依赖，同时为开源社区提供了替代方案，用户可以直接使用。 
4.  Dubbo比HSF的功能更多，除了ClassLoader隔离，Dubbo基本上是HSF的超集，Dubbo也支持更多协议，更多注册中心的集成，以适应更多的网站架构。

Dubbo在安全机制方面是如何解决的？
Dubbo主要针对内部服务，对外的服务，阿里有开放平台来处理安全和流控，所以Dubbo在安全方面实现的功能较少，基本上只防君子不防小人，只防止误调用。 
Dubbo通过Token令牌防止用户绕过注册中心直连，然后在注册中心上管理授权。Dubbo还提供服务黑白名单，来控制服务所允许的调用方。

 

HSF优点：

1.HSF框架采用 Netty + Hession数据序列化协议实现服务交互，Netty + Hession的组合在互联网高并发量的场景下,特别是在TPS 上达到10w 以上时，性能和效率远比REST 或者Web Service 高。

2.HSF框架的容错机制，配置服务器是采用长连接的方式与服务节点进行网络通讯，一旦发现有服务提供者实例出现故障，配置服务器在秒级就会感知到，此时会将出问题这台服务提供者的信息从该服务的服务器列表中删除，并将更新后的服务器列表采用推送的方式同步给与该服务相关的所有服务调用者端，这样当下次服务调用者再进行此服务的调用时，就不会因为随机的方式再次对已经停止服务提供的服务器发起服务的调用。

3.HSF框架的线性扩展支持

 

 

Spring cloud:

Spring Cloud为开发人员提供了快速构建分布式系统中的一些通用模式（例如配置管理，服务发现，断路器，智能路由，微代理，控制总线，一次性令牌，全局锁，领导选举，分布式 会话，群集状态）。 分布式系统的协调引出样板模式（boiler plate patterns），并且使用Spring Cloud开发人员可以快速地实现这些模式来启动服务和应用程序。 它们可以在任何分布式环境中正常工作，包括开发人员自己的笔记本电脑，裸机数据中心和受管平台，如Cloud Foundry。

 

Dubbo和spring cloud的区别 ：  两个框架的定义层面也不一样，么办法比较，具体可以参照项目需求来选择；

 

Spring Cloud与Dubbo对比

 

 

最近一段时间不论互联网还是传统行业，凡是涉及信息技术范畴的圈子几乎都在讨论 微服务架构 。近期也看到各大技术社区开始组织一些沙龙和论坛来分享spring Cloud的相关实施经验，这对于最近正在整理Spring Cloud相关套件内容与实例应用的我而言，还是有不少激励的。

目前，Spring Cloud在国内的知名度并不高，在前阵子的求职过程中，与一些互联网公司的架构师、技术VP或者CTO在交流时，有些甚至还不知道该项目的存在。可能这也与国内阿里巴巴开源服务治理框架Dubbo有一定的关系，除了Dubbo本身较为完善的中文文档之外，不少科技公司的架构师均出自阿里系，所以就目前情况看，短期国内还是Dubbo的天下。

那么第一次实施微服务架构时，我们应该选择哪个基础框架更好呢？

以下内容均为作者个人观点，知识面有限，如有不对，纯属正常，不喜勿喷。

Round 1：背景

Dubbo，是阿里巴巴服务化治理的核心框架，并被广泛应用于阿里巴巴集团的各成员站点。阿里巴巴近几年对开源社区的贡献不论在国内还是国外都是引人注目的，比如：JStorm捐赠给Apache并加入Apache基金会等，为中国互联网人争足了面子，使得阿里巴巴在国人眼里已经从电商升级为一家科技公司了。

Spring Cloud，从命名我们就可以知道，它是Spring Source的产物，Spring社区的强大背书可以说是Java企业界最有影响力的组织了，除了Spring Source之外，还有Pivotal和Netfix是其强大的后盾与技术输出。其中Netflix开源的整套微服务架构套件是Spring Cloud的核心。

小结：如果拿Dubbo与Netflix套件做对比，前者在国内影响力较大，后者在国外影响力较大，我认为在背景上可以打个平手；但是若要与Spring Cloud做对比，由于Spring Source的加入，在背书上，Spring Cloud略胜一筹。不过，英雄不问出处，在背景这一点上，不能作为选择框架的主要因素，当您一筹莫展的时候，可以作为参考依据。

Round 2：社区活跃度

我们选择一个开源框架，社区的活跃度是我们极为关注的一个要点。社区越活跃，解决问题的速度越快，框架也会越来越完善，不然当我们碰到问题，就不得不自己解决。而对于团队来说，也就意味着我们不得不自己去维护框架的源码，这对于团队来说也将会是一个很大的负担。

下面看看这两个项目在github上的更新时间，下面截图自2016年7月30日：

• Dubbo ： https://github.com/dubbo

最后更新时间为：2016年5月6日

• Spring Cloud ： https://github.com/spring-cloud

最后更新时间为：12分钟前

可以看到Dubbo的更新已经是几个月前，并且更新频率很低。而Spring Cloud的更新是12分钟前，仍处于高速迭代的阶段。

小结：在社区活跃度上，Spring Cloud毋庸置疑的优于Dubbo，这对于没有大量精力与财力维护这部分开源内容的团队来说，Spring Cloud会是更优的选择。

Round 3：架构完整度

或许很多人会说Spring Cloud和Dubbo的对比有点不公平，Dubbo只是实现了服务治理，而Spring Cloud下面有17个子项目（可能还会新增）分别覆盖了微服务架构下的方方面面，服务治理只是其中的一个方面，一定程度来说，Dubbo只是Spring Cloud Netflix中的一个子集。但是在选择框架上，方案完整度恰恰是一个需要重点关注的内容。

根据Martin Fowler对 微服务架构 的描述中，虽然该架构相较于单体架构有模块化解耦、可独立部署、技术多样性等诸多优点，但是由于分布式环境下解耦，也带出了不少测试与运维复杂度。

根据微服务架构在各方面的要素，看看Spring Cloud和Dubbo都提供了哪些支持。

	Dubbo	Spring Cloud
服务注册中心	Zookeeper	Spring Cloud Netflix Eureka
服务调用方式	RPC	REST API
服务网关	无	Spring Cloud Netflix Zuul
断路器	不完善	Spring Cloud Netflix Hystrix
分布式配置	无	Spring Cloud Config
服务跟踪	无	Spring Cloud Sleuth
消息总线	无	Spring Cloud Bus
数据流	无	Spring Cloud Stream
批量任务	无	Spring Cloud Task
……	……	……

以上列举了一些核心部件，大致可以理解为什么之前说Dubbo只是类似Netflix的一个子集了吧。当然这里需要申明一点，Dubbo对于上表中总结为“无”的组件不代表不能实现，而只是Dubbo框架自身不提供，需要另外整合以实现对应的功能，比如：

• 分布式配置：可以使用淘宝的diamond、百度的disconf来实现分布式配置管理。但是Spring Cloud中的Config组件除了提供配置管理之外，由于其存储可以使用git，因此它天然的实现了配置内容的版本管理，可以完美的与应用版本管理整合起来。
• 服务跟踪：可以使用京东开源的Hydra
• 批量任务：可以使用当当开源的Elastic-Job
• ……

虽然，Dubbo自身只是实现了服务治理的基础，其他为保证集群安全、可维护、可测试等特性方面都没有很好的实现，但是几乎大部分关键组件都能找到第三方开源来实现，这些组件主要来自于国内各家大型互联网企业的开源产品。

RPC vs REST

另外，由于Dubbo是基础框架，其实现的内容对于我们实施微服务架构是否合理，也需要我们根据自身需求去考虑是否要修改，比如Dubbo的服务调用是通过RPC实现的，但是如果仔细拜读过Martin Fowler的 microservices 一文，其定义的服务间通信是HTTP协议的REST API。那么这两种有何区别呢？

先来说说，使用Dubbo的RPC来实现服务间调用的一些痛点：

• 服务提供方与调用方接口依赖方式太强：我们为每个微服务定义了各自的service抽象接口，并通过持续集成发布到私有仓库中，调用方应用对微服务提供的抽象接口存在强依赖关系，因此不论开发、测试、集成环境都需要严格的管理版本依赖，才不会出现服务方与调用方的不一致导致应用无法编译成功等一系列问题，以及这也会直接影响本地开发的环境要求，往往一个依赖很多服务的上层应用，每天都要更新很多代码并install之后才能进行后续的开发。若没有严格的版本管理制度或开发一些自动化工具，这样的依赖关系会成为开发团队的一大噩梦。而REST接口相比RPC更为轻量化，服务提供方和调用方的依赖只是依靠一纸契约，不存在代码级别的强依赖，当然REST接口也有痛点，因为接口定义过轻，很容易导致定义文档与实际实现不一致导致服务集成时的问题，但是该问题很好解决，只需要通过每个服务整合swagger，让每个服务的代码与文档一体化，就能解决。所以在分布式环境下，REST方式的服务依赖要比RPC方式的依赖更为灵活。
• 服务对平台敏感，难以简单复用：通常我们在提供对外服务时，都会以REST的方式提供出去，这样可以实现跨平台的特点，任何一个语言的调用方都可以根据接口定义来实现。那么在Dubbo中我们要提供REST接口时，不得不实现一层代理，用来将RPC接口转换成REST接口进行对外发布。若我们每个服务本身就以REST接口方式存在，当要对外提供服务时，主要在API网关中配置映射关系和权限控制就可实现服务的复用了。

相信这些痛点也是为什么当当网在dubbox（基于Dubbo的开源扩展）中增加了对REST支持的原因之一。

小结：Dubbo实现了服务治理的基础，但是要完成一个完备的微服务架构，还需要在各环节去扩展和完善以保证集群的健康，以减轻开发、测试以及运维各个环节上增加出来的压力，这样才能让各环节人员真正的专注于业务逻辑。而Spring Cloud依然发扬了Spring Source整合一切的作风，以标准化的姿态将一些微服务架构的成熟产品与框架揉为一体，并继承了Spring Boot简单配置、快速开发、轻松部署的特点，让原本复杂的架构工作变得相对容易上手一些（如果您读过我之前关于Spring Cloud的一些核心组件使用的文章，应该能体会这些让人兴奋而激动的特性，传送门）。所以，如果选择Dubbo请务必在各个环节做好整套解决方案的准备，不然很可能随着服务数量的增长，整个团队都将疲于应付各种架构上不足引起的困难。而如果选择Spring Cloud，相对来说每个环节都已经有了对应的组件支持，可能有些也不一定能满足你所有的需求，但是其活跃的社区与高速的迭代进度也会是你可以依靠的强大后盾。

Round 4：文档质量

Dubbo的 文档 可以说在国内开源框架中算是一流的，非常全，并且讲解的也非常深入，由于版本已经稳定不再更新，所以也不太会出现不一致的情况，另外提供了中文与英文两种版本，对于国内开发者来说，阅读起来更加容易上手，这也是dubbo在国内更火一些的原因吧。

Spring Cloud由于整合了大量组件，文档在体量上自然要比dubbo多很多，文档内容上还算简洁清楚，但是更多的是偏向整合，更深入的使用方法还是需要查看其整合组件的详细文档。另外由于Spring Cloud基于Spring Boot，很多例子相较于传统Spring应用要简单很多（因为自动化配置，很多内容都成了约定的默认配置），这对于刚接触的开发者可能会有些不适应，比较建议了解和学习Spring Boot之后再使用Spring Cloud，不然可能会出现很多一知半解的情况。

小结：虽然Spring Cloud的文档量大，但是如果使用Dubbo去整合其他第三方组件，实际也是要去阅读大量第三方组件文档的，所以在文档量上，我觉得区别不大。对于文档质量，由于Spring Cloud的迭代很快，难免会出现不一致的情况，所以在质量上我认为Dubbo更好一些。而对于文档语言上，Dubbo自然对国内开发团队来说更有优势。

Spring Cloud与Dubbo对比

spring Cloud是一个基于Spring Boot实现的云应用开发工具，它为基于JVM的云应用开发中的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。

Spring Cloud与Dubbo对比
提到Dubbo，我想顺便提下ESB，目前央视新华社也在用ESB来做任务编排，这里先比较下Dubbo和ESB：

ESB（企业数据总线），一般采用集中式转发请求，适合大量异构系统集成，侧重任务的编排，性能问题可通过异构的方式来进行规避，无法支持特别大的并发。
Dubbo（服务注册管理），采用的是分布式调用，注册中心只记录地址信息，然后直连调用，适合并发及压力比较大的情况；其侧重服务的治理，将各个服务颗粒化，各个子业务系统在程序逻辑上完成业务的编排。

回归主题，Spring Cloud和Dubbo又有什么不同那，首先，我们看下有什么相同之处，它们两都具备分布式服务治理相关的功能，都能够提供服务注册、发现、路由、负载均衡等。说到这，Dubbo的功能好像也就这么多了，但是Spring Cloud是提供了一整套企业级分布式云应用的完美解决方案，能够结合Spring Boot，Docker实现快速开发的目的，所以说Dubbo只有Spring Cloud的一部分RPC功能，而且也谈不上谁好谁坏。不过，Dubbo项目现已停止了更新，淘宝内部由hsf替代dubbo，我想这会有更多人倾向Spring Cloud了。

从开发角度上说，Dubbo常与Spring、zookeeper结合，而且实现只是通过xml来配置服务地址、名称、端口，代码的侵入性是很小的，相对Spring Cloud，它的实现需要类注解等，多少具有一定侵入性。

Spring Cloud子项目

Spring Cloud包含了多个子项目（针对分布式系统中涉及的多个不同开源产品），之前在第一章节也介绍这些，比如：Spring Cloud Config、Spring Cloud Netflix、Spring Cloud CloudFoundry、Spring Cloud AWS、Spring Cloud Security、Spring Cloud Commons、Spring Cloud Zookeeper、Spring Cloud CLI等项目，可以跳至（一）看下。

配置服务
Spring Cloud提供了Config Server，它有在分布式系统开发中做外部配置的功能，通过Config Server我们可以集中存储所有应用的配置文件。Config Server支持Git或者在文件系统中放置配置文件（GitLab），通常我们使用不同格式来区分不同应用的不同配置文件。云计算环境下，习惯上使用YAML配置，而且一般配置文件的位置都放在类路径下的config目录下，配置文件规则：应用名＋profile.yml：

[html] view plain copy 
/{application}/{profile}[/{label}] 
/{application}-{profile}.yml 
/{label}/{application}-{profile}.yml 
/{application}-{profile}.properties 
/{label}/{application}-{profile}.properties 
Spring Cloud提供了注解@EnableConfigServer来启动配置服务。

服务发现
Spring Cloud通过Netflix OSS的Eureka来实现服务发现，服务发现的主要目的是为了让每个服务之间可以互相通信。Eureka Server为微服务的注册中心。谈到Spring Cloud Netflix，它是Spring Cloud的子项目之一，主要提供的模块包括：服务发现（Eureka），断路器（Hystrix），智能路有（Zuul），客户端负载均衡（Ribbon）等。
Spring Cloud使用注解的方式提供了Eureka服务端（@EnableEurekaServer）和客户端（@EnableEurekaClient）。

路由网关
路由网关的主要目的是为了让所有的微服务对外只有一个接口，我们只需访问一个网关地址，即可由网关将所有的请求代理到不同的服务中。Spring Cloud是通过Zuul来实现的，支持自动路由映射到在Eureka Server上注册的服务。Spring Cloud提供了注解@EnableZuulProxy来启用路由代理。

负载均衡
Spring Cloud提供了Ribbon和Feign作为客户端的负载均衡。在Spring Cloud下，使用Ribbon直接注入一个RestTemplate对象即可，此RestTemplate已做好负载均衡的配置；而使用Feign只需定义个注解，有@FeignClient注解的接口，然后使用@RequestMapping注解在方法上映射远程的REST服务，此方法也是做好了负载均衡配置。

断路器
断路器（Circuit Breaker）主要是为了解决当某个方法调用失败的时候，调用后备方法来替代失败的方法，已达到容错／阻止级联错误的功能。Spring Cloud使用@EnableCircuitBreaker来启用断路器支持，使用@HystrixCommand的fallbackMethod来指定后备方法。（@HystrixCommand(fallbackMethod="fallbackOper")）
Spring Cloud还提供了一个控制台来监控断路器的运行情况，通过@EnableHystrixDashboard注解开启。

Spring Cloud依赖库

这里我会罗列下常用的一些依赖包，为了更好理解每个依赖所负责的区域，我还是用一张和之前类似的图来展示各块的功能：

常用依赖包如下：

[html] view plain copy 
spring-cloud-starter-parent 具备spring-boot-starter-parent同样功能并附加Spring Cloud的依赖 
spring-cloud-starter-config 默认的配置服务依赖，快速自动引入服务的方式，端口8888 
spring-cloud-config-server／client 用户自定义配置服务的服务端／客户端依赖 
spring-cloud-starter-eureka-server 服务发现的Eureka Server依赖 
spring-cloud-starter-eureka 服务发现的Eureka客户端依赖 
spring-cloud-starter-hystrix／zuul／feign／ribbon 断路器（Hystrix），智能路有（Zuul），客户端负载均衡（Ribbon）的依赖 
angular-ui-router 页面分发路由依赖 
总结
这里所有的总结只是停留在对Spring Cloud的理解上，我推荐去http://projects.spring.io/spring-cloud/官网导读多实践下项目，了解下各个模块的服务消息通信方式等，大概就是这样。
如果你对Spring Cloud感兴趣，想了解Spring Boot快速开发，以及使用JHipster生成构建Spring Boot +AngularJS的应用代码，欢迎加QQ群：58612944，里面有很多大牛指导，我也在学习中。另外，群里我们在组织翻译GitHub上JHipster的官方文档，如果感兴趣，可以进来一块为开源做贡献。
关于JHipster扩展
JHipster -> 关于SpringBoot,AngularJS及Spring生态融合的技术栈, 是SpringBoot的最佳实践,是SpringCloud对Netflix技术栈的最佳实践,是J2EE-Cloud微服务的最佳实践,是Docker,Kubernetes和AngularJS1/2的最佳实践,是全栈式开发,敏捷开发最理想的工具。

 

Spring Cloud与Dubbo共存方案

 

一、背景

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

由于遗留Dubbo系统比较庞大，短期之内无法完成技术栈的迁移。因此需要“分步走”，即：初期实现两者共存，后期逐步绞杀Dubbo应用，最终实现技术栈的统一。

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

二、头脑风暴

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

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

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

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

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

三、亮代码

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

 

总结

 

通过上面再几个环节上的分析，相信大家对Dubbo和Spring Cloud有了一个初步的了解。就我个人对这两个框架的使用经验和理解，打个不恰当的比喻：使用Dubbo构建的微服务架构就像组装电脑，各环节我们的选择自由度很高，但是最终结果很有可能因为一条内存质量不行就点不亮了，总是让人不怎么放心，但是如果你是一名高手，那这些都不是问题；而Spring Cloud就像品牌机，在Spring Source的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性，但是如果要在使用非原装组件外的东西，就需要对其基础有足够的了解。

从目前Spring Cloud的被关注度和活跃度上来看，很有可能将来会成为微服务架构的标准框架。

来源：CSDN

作者：ZhaoYingChao88

链接：https://blog.csdn.net/ZYC88888/article/details/82430607