微服务Dubbo和SpringCloud架构设计、优劣 势⽐较

本⽂主要围绕微服务的技术选型、通讯协议、服务依赖模式、开始模式、运⾏模式等⼏⽅⾯来综合⽐较
Dubbo和Spring Cloud 这2种开发框架。架构师可以根据公司的技术实⼒并结合项⽬的特点来选择某个
合适的微服务架构平台，以此稳妥地实施项⽬的微服务化改造或开发进程。
微服务架构是互联⽹很热⻔的话题，是互联⽹技术发展的必然结果。它提倡将单⼀应⽤程序划分成⼀组
⼩的服务，服务之间互相协调、互相配合，为⽤户提供最终价值。虽然微服务架构没有公认的技术标准
和规范或者草案，但业界已经有⼀些很有影响⼒的开源微服务架构框架提供了微服务的关键思路，例如
Dubbo和Spring Cloud。各⼤互联⽹公司也有⾃研的微服务框架，但其模式都于这⼆者相差不⼤。

微服务主要的优势如下：

1、降低复杂度
将原来偶合在⼀起的复杂业务拆分为单个服务，规避了原本复杂度⽆⽌境的积累。每⼀个微服务专注于
单⼀功能，并通过定义良好的接⼝清晰表述服务边界。每个服务开发者只专注服务本身，通过使⽤缓
存、DAL等各种技术⼿段来提升系统的性能，⽽对于消费⽅来说完全透明。

2、可独⽴部署
由于微服务具备独⽴的运⾏进程，所以每个微服务可以独⽴部署。当业务迭代时只需要发布相关服务的
迭代即可，降低了测试的⼯作量同时也降低了服务发布的⻛险。

3、容错
在微服务架构下，当某⼀组件发⽣故障时，故障会被隔离在单个服务中。 通过限流、熔断等⽅式降低错
误导致的危害，保障核⼼业务正常运⾏。

4、扩展
单块架构应⽤也可以实现横向扩展，就是将整个应⽤完整的复制到不同的节点。当应⽤的不同组件在扩
展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独⽴进⾏扩展。
本⽂主要围绕微服务的技术选型、通讯协议、服务依赖模式、开始模式、运⾏模式等⼏⽅⾯来综合⽐较
Dubbo和Spring Cloud 这2种开发框架。架构师可以根据公司的技术实⼒并结合项⽬的特点来选择某个
合适的微服务架构平台，以此稳妥地实施项⽬的微服务化改造或开发进程。

⼀、核⼼部件

微服务的核⼼要素在于服务的发现、注册、路由、熔断、降级、分布式配置，基于上述⼏种必要条件对
Dubbo和Spring Cloud做出对⽐。
1、总体架构
Dubbo 核⼼部件（如下图）:

Provider： 暴露服务的提供⽅，可以通过jar或者容器的⽅式启动服务
Consumer：调⽤远程服务的服务消费⽅。
Registry： 服务注册中⼼和发现中⼼。
Monitor： 统计服务和调⽤次数，调⽤时间监控中⼼。（dubbo的控制台⻚⾯中可以显示，⽬前只
有⼀个简单版本）
Container：服务运⾏的容器。

Spring Cloud总体架构如下图
Service Provider： 暴露服务的提供⽅。
Service Consumer：调⽤远程服务的服务消费⽅。
EureKa Server： 服务注册中⼼和服务发现中⼼。

从整体架构上来看，⼆者模式接近，都需要需要服务提供⽅，注册中⼼，服务消费⽅

微服务架构核⼼要素
Dubbo只是实现了服务治理，⽽Spring Cloud⼦项⽬分别覆盖了微服务架构下的众多部件，⽽服务治理
只是其中的⼀个⽅⾯。Dubbo提供了各种Filter，对于上述中“⽆”的要素，可以通过扩展Filter来完善。
例如
1．分布式配置：可以使⽤淘宝的diamond、百度的disconf来实现分布式配置管理
2．服务跟踪：可以使⽤京东开源的Hydra，或者扩展Filter⽤Zippin来做服务跟踪
3．批量任务：可以使⽤当当开源的Elastic-Job、tbschedule

点评：从核⼼要素来看，Spring Cloud 更胜⼀筹，在开发过程中只要整合Spring Cloud的⼦项⽬就可
以顺利的完成各种组件的融合，⽽Dubbo缺需要通过实现各种Filter来做定制，开发成本以及技术难度
略⾼。

⼆、通讯协议

基于通讯协议层⾯对2种框架⽀持的协议类型以及运⾏效率⽅⾯进⾏⽐较；
1、Dubbo：dubbo使⽤RPC通讯协议，提供序列化⽅式如下：
dubbo：Dubbo缺省协议采⽤单⼀⻓连接和NIO异步通讯，适合于⼩数据量⼤并发的服务调⽤，以及服
务消费者机器数远⼤于服务提供者机器数的情况
rmi：RMI协议采⽤JDK标准的java.rmi.*实现，采⽤阻塞式短连接和JDK标准序列化⽅式
Hessian:Hessian协议⽤于集成Hessian的服务，Hessian底层采⽤Http通讯，采⽤Servlet暴露服务，
Dubbo缺省内嵌Jetty作为服务器实现
http:采⽤Spring的HttpInvoker实现
Webservice:基于CXF的frontend-simple和transports-http实现
2、Spring Cloud：Spring Cloud 使⽤HTTP协议的REST API

（⼆）、性能⽐较
使⽤⼀个Pojo对象包含10个属性，请求10万次，Dubbo和Spring Cloud在不同的线程数量下，每次请求
耗时（ms）如下：

说明：客户端和服务端配置均采⽤阿⾥云的ECS服务器，4核8G配置，dubbo采⽤默认的dubbo协议

点评：dubbo⽀持各种通信协议，⽽且消费⽅和服务⽅使⽤⻓链接⽅式交互，通信速度上略胜Spring
Cloud，如果对于系统的响应时间有严格要求，⻓链接更合适。

三、服务依赖⽅式

Dubbo：服务提供⽅与消费⽅通过接⼝的⽅式依赖，服务调⽤设计如下：
interface层：服务接⼝层，定义了服务对外提供的所有接⼝
Molel层：服务的DTO对象层，
business层：业务实现层，实现interface接⼝并且和DB交互

因此需要为每个微服务定义了各⾃的interface接⼝，并通过持续集成发布到私有仓库中，调⽤⽅应⽤对
微服务提供的抽象接⼝存在强依赖关系，开发、测试、集成环境都需要严格的管理版本依赖。

通过maven的install & deploy命令把interface和Model层发布到仓库中，服务调⽤⽅只需要依赖
interface和model层即可。在开发调试阶段只发布Snapshot版本。等到服务调试完成再发布Release版
本，通过版本号来区分每次迭代的版本。通过xml配置⽅式即可⽅⾯接⼊dubbo，对程序⽆⼊侵。

Dubbo接⼝依赖⽅式
Spring Cloud：服务提供⽅和服务消费⽅通过json⽅式交互，因此只需要定义好相关json字段即可，消
费⽅和提供⽅⽆接⼝依赖。通过注解⽅式来实现服务配置，对于程序有⼀定⼊侵。

点评：Dubbo服务依赖略重，需要有完善的版本管理机制，但是程序⼊侵少。⽽Spring Cloud通过Json交互，省略了版本管理的问题，但是具体字段含义需要统⼀管理，⾃身Rest API⽅式交互，为跨平台调⽤奠定了基础。

四、组件运⾏流程

下图中的每个组件都是需要部署在单独的服务器上，gateway⽤来接受前端请求、聚合服务，并批量调
⽤后台原⼦服务。每个service层和单独的DB交互。

Dubbo组件运⾏流程
gateWay:前置⽹关，具体业务操作，gateWay通过dubbo提供的负载均衡机制⾃动完成
Service：原⼦服务，只提供该业务相关的原⼦服务
Zookeeper：原⼦服务注册到zk上

▲Spring Cloud 组件运⾏
Spring Cloud
所有请求都统⼀通过 API ⽹关（Zuul）来访问内部服务。
⽹关接收到请求后，从注册中⼼（Eureka）获取可⽤服务。
由 Ribbon 进⾏均衡负载后，分发到后端的具体实例。
微服务之间通过 Feign 进⾏通信处理业务。

点评：业务部署⽅式相同，都需要前置⼀个⽹关来隔绝外部直接调⽤原⼦服务的⻛险。Dubbo需要⾃⼰开发⼀套API ⽹关，⽽Spring Cloud则可以通过Zuul配置即可完成⽹关定制。使⽤⽅式上Spring Cloud略胜⼀筹。

五、微服务架构组成以及注意事项

到底使⽤是dubbo还是Spring Cloud其实并不重要，重点在于如何合理的利⽤微服务。下⾯是⼀张互联
⽹通⽤的架构图,其中每个环节都是微服务的核⼼部分

⼀）、架构分解
⽹关集群：数据的聚合、实现对接⼊客户端的身份认证、防报⽂重放与防数据篡改、功能调⽤的业
务鉴权、响应数据的脱敏、流量与并发控制等
业务集群：⼀般情况下移动端访问和浏览器访问的⽹关需要隔离，防⽌业务耦合
Local Cache：由于客户端访问业务可能需要调⽤多个服务聚合，所以本地缓存有效的降低了服务
调⽤的频次，同时也提示了访问速度。本地缓存⼀般使⽤⾃动过期⽅式，业务场景中允许有⼀定的
数据延时。
服务层：原⼦服务层，实现基础的增删改查功能，如果需要依赖其他服务需要在Service层主动调⽤
Remote Cache：访问DB前置⼀层分布式缓存，减少DB交互次数，提升系统的TPS
DAL：数据访问层，如果单表数据量过⼤则需要通过DAL层做数据的分库分表处理。
MQ：消息队列⽤来解耦服务之间的依赖，异步调⽤可以通过MQ的⽅式来执⾏
数据库主从：服务化过程中毕竟的阶段，⽤来提升系统的TPS

（⼆）注意事项
服务启动⽅式建议使⽤jar⽅式启动，启动速度快，更容易监控
缓存、缓存、缓存，系统中能使⽤缓存的地⽅尽量使⽤缓存，通过合理的使⽤缓存可以有效的提⾼
系统的TPS
服务拆分要合理，尽量避免因服务拆分⽽导致的服务循环依赖
合理的设置线程池，避免设置过⼤或者过⼩导致系统异常

六、总结

Dubbo出⽣于阿⾥系，是阿⾥巴巴服务化治理的核⼼框架，并被⼴泛应⽤于中国各互联⽹公司；只需要
通过spring配置的⽅式即可完成服务化，对于应⽤⽆⼊侵。设计的⽬的还是服务于⾃身的业务为主。虽
然阿⾥内部原因dubbo曾经⼀度暂停维护版本，但是框架本身的成熟度以及⽂档的完善程度，完全能满
⾜各⼤互联⽹公司的业务需求。如果我们需要使⽤配置中⼼、分布式跟踪这些内容都需要⾃⼰去集成，
这样⽆形中增加了使⽤ Dubbo 的难度。

Spring Cloud 是⼤名鼎鼎的 Spring 家族的产品， 专注于企业级开源框架的研发。 Spring Cloud ⾃从发
展到现在，仍然在不断的⾼速发展，⼏乎考虑了服务治理的⽅⽅⾯⾯，开发起来⾮常的便利和简单。
Dubbo于2017年开始⼜重启维护，发布了更新后的2.5.6版本，⽽Spring Cloud更新的⾮常快，⽬前已经
更新到Finchley.M2。因此，企业需要根据⾃身的研发⽔平和所处阶段选择合适的架构来解决业务问题，
不管是Dubbo还是Spring Cloud都是实现微服务有效的⼯具。