【微服务】Dubbo 和 Spring Cloud 比较

【本文是为了梳理知识的总结性文章，总结了一些自认为相关的重要知识点，只为巩固记忆以及技术交流，忘批评指正。其中参考了很多前辈的文章，包括图片也是引用，如有冒犯，侵删。】
当前开源上可选用的微服务框架主要有Dubbo、Spring Cloud等，下面对这两个框架做一个简单对比介绍。

1 概念

Dubbo：Apache Dubbo是一款高性能Java RPC框架，之前由阿里巴巴开源，现已成为 Apache 基金会孵化项目。

Spring Cloud：是一个基于Spring Boot实现的微服务架构开发工具，它使用一系列开源框架，为微服务架构中涉及的配置管理、服务治理、断路器、智能路由、微代理、控制总线、一次性token、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。

Dubbo具有调度、发现、监控、治理等功能，支持相当丰富的服务治理能力。而Spring Cloud 则满足了构建微服务所需的所有解决方案，其中包括了服务治理，因此可以说Dubbo是Spring Cloud的一个子集。

架构选型一般会考虑几个因素，如社区活跃度、功能完整度、技术特点和业务需求等。下面从这几个方面，对这两个框架进行对比介绍。

2. 社区活跃度

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

3.功能的完善度

在功能方面，Dubbo只是实现了服务的治理，而springcloud下面有24子项目以后还会更多。覆盖了微服务的方方面面比较完善，服务治理只是其中的一个方面。在选择框架上，方案完整度恰恰是一个需要重点关注的内容。

3.1 Dubbo 功能

Dubbo具有调度、治理、发现、监控等功能。支持相当丰富的服务治理的功能情况。Dubbo架构下，注册中心对等集群，并会缓存服务列表以备注册中心失效时继续提供发现功能，本身的服务发现结构有很强的可用性与健壮性，足够支持高访问量的网站。虽然，Dubbo自身只是实现了服务治理的基础，其他为保证集群安全、可维护、可测试等特性方面都没有很好的实现，但是几乎大部分关键组件都能找到第三方开源来实现，这些组件主要来自于国内各家大型互联网企业的开源产品。

3.2 Spring Cloud 功能

springcloud功能由众多子项目组成，如:speingcloudConfig、springCloudNetfilx、Spring Cloud Consul 等提供了搭建分布式系统及微服务常用的工具，如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性token、全局锁、选主、分布式会话和集群状态等，满足了构建微服务所需的所有解决方案。比如使用Spring Cloud Config 可以实现统一配置中心，对配置进行统一管理；使用Spring Cloud Netflix 可以实现Netflix 组件的功能 - 服务发现（Eureka）、智能路由（Zuul）、客户端负载均衡（Ribbon）。

3.3 功能对比

Dubbo 提供了各种 Filter，对于上述中“无”的要素，可以通过扩展 Filter 来完善。例如：

分布式配置：可以使用淘宝的 diamond、百度的 disconf 来实现分布式配置管理。
服务跟踪：可以使用京东开源的 Hydra，或者扩展 Filter 用 Zippin 来做服务跟踪。
批量任务：可以使用当当开源的 Elastic-Job、tbschedule。
从核心要素来看，Spring Cloud 更胜一筹，在开发过程中只要整合 Spring Cloud 的子项目就可以顺利的完成各种组件的融合，而 Dubbo 却需要通过实现各种 Filter 来做定制，开发成本以及技术难度略高。

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

4 技术特点

4.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实现
Spring Cloud：Spring Cloud 使用HTTP协议的REST API。

dubbo支持各种通信协议，而且消费方和服务方使用长链接方式交互，通信速度上略胜Spring Cloud，如果对于系统的响应时间有严格要求，长链接更合适。

4.2 服务依赖方式

Dubbo 使用面向接口代理的高性能RPC调用，使得服务提供方（抽象接口）与调用方在代码上产生了强依赖，服务提供者需要不断将包含抽象接口的 jar 包打包出来供消费者使用。一旦打包出现问题，就会导致服务调用出错，并且以后发布部署会成很大问题（太强的依赖关系）。

Spring Cloud 支持 REST 服务调用，相比于 RPC，更加轻量化和灵活（服务之间只依赖一纸契约，不存在代码级别的强依赖），有利于跨语言服务的实现，以及服务的发布部署。服务提供方和服务消费方通过json方式交互，因此只需要定义好相关json字段即可，消费方和提供方无接口依赖。

Dubbo服务依赖略重，需要有完善的版本管理机制，但是程序入侵少。而Spring Cloud通过Json交互，省略了版本管理的问题，但是具体字段含义需要统一管理，自身Rest API方式交互，为跨平台调用奠定了基础。这也是为什么当当网在dubbox（基于Dubbo的开源扩展）中增加了对REST支持的原因之一。

4.3 组件运行流程

dubbo

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

gateWay:前置网关，具体业务操作，gateWay通过dubbo提供的负载均衡机制自动完成

Service：原子服务，只提供该业务相关的原子服务

Zookeeper：原子服务注册到zk上

Spring Cloud

所有请求都统一通过 API 网关（Zuul）来访问内部服务。

网关接收到请求后，从注册中心（Eureka）获取可用服务。

由 Ribbon 进行均衡负载后，分发到后端的具体实例。

微服务之间通过 Feign 进行通信处理业务。

业务部署方式相同，都需要前置一个网关来隔绝外部直接调用原子服务的风险。Dubbo需要自己开发一套API 网关，而Spring Cloud则可以通过Zuul配置即可完成网关定制。使用方式上Spring Cloud略胜一筹。

5 业务需求

5.1 dubbo 适合的业务特点

根据Dubbo官方说法，在小数据量的情况下表现卓越。虽然Dubbo 支持短连接大数据量的服务提供模式，但绝大多数情况下都是使用长连接小数据量的模式提供服务使用的。所以，对于类似于电商等同步调用场景多并且能支撑搭建Dubbo 这套比较复杂环境的成本的产品而言，Dubbo 确实是一个可以考虑的选择。但如果产品业务中由于后台业务逻辑复杂、时间长而导致异步逻辑比较多的话，可能Dubbo 并不合适。

5.2 Spring Cloud 适合的业务特点

提起Spring Cloud，一些开发的第一印象是http+JSON的rest通信，性能上难堪重用，其实这也是一种误读。Spring Cloud也并不是和http+JSON强制绑定的，如有必要Thrift、protobuf等高效的RPC、序列化协议同样可以作为替代方案。

参考文章

【1】http://blog.itpub.net/31556476/viewspace-2645082/

【2】http://blog.didispace.com/microservice-framework/

【3】https://www.zhihu.com/question/45413135/answer/226794957

【4】https://cloud.tencent.com/developer/article/1116063

【5】https://www.zhihu.com/question/45413135