微服务架构的基础框架选择：Spring Cloud还是Dubbo？
Round 1：概览
SpringCloud 与Dubbo
Round 2：架构完整度
或许很多人会说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 2：两者运行流程对比
dubbo：
每个组件都是需要部署在单独的服务器上，GateWay用来接收前端请求、聚合服务，并批量调用后台原子服务、每个Service单独与DB交互。
①GateWay：前置网关，具体业务操作，GateWay通过Dubbo提供的负载均衡机制自动完成（Dubbo本身并没有提供网关）
②Service：原子服务，只提供该业务相关的原子服务
③Zookeeper：原子服务注册到ZK上。
SpringCloud：
①所有请求都统一通过网关（Zuul）来访问内部服务
②网关接收到请求后，从注册中心（Eureka）获取可用服务
③由Ribbon进行负载均衡后，分发到后端的具体实例
④微服务之间通过Feign进行通信业务处理
Round 3：优缺点
Dubbo优点：
①支持RPC调用，性能较好
②支持多种序列化协议，如Hessian、Http、WebService
③Dubbo Admin后台管理功能强大，提供了权重调节、负载均衡等
④中文文档比较全面
Dubbo不足：
①Registry严重依赖第三方组件（Zookeeper、Redis等），当这些组件出现问题时，服务调用很快就会中断。
②Dubbo只是实现了服务治理，其他微服务框架并未包含，如果需要使用则需要结合第三方框架实现（百度分布式配置Disconf、京东服务跟踪Hydra）、开发成本较大
Spring Cloud优点：
①有强大的Spring社区、NetFlix等公司支持，且开源社区贡献非常活跃
②分布式微服务架构下的一站式解决方案，是各个微服务架构落地技术的集合体
③基于SpringBoot，具有简单配置、快速开发、轻松部署、方便测试的优点
④支持REST服务调用，相对于RPC，更加轻量化和灵活，有利于跨语言服务的实现以及服务的发布部署，结合Swagger实现服务的文档一体化
⑤提供了Docker及Kubernetes微服务编排支持
Spring Cloud不足：
①REST服务调用性能会比RPC性能较低
②Spring Cloud整合了大量的组件，相关文档比较复杂，需要针对性的阅读
③支持REST服务调用，可能因为接口定义过轻，导致定义文档与实际实现不一致导致服务集成时的问题（可以使用统一文档和版本管理解决，比如Swagger）
总结
目前Spring Cloud也是非常火热的，社区更新也比较快，所以什么都学一点，生活更多彩一些。下面正式开始demo学习Spring Cloud，并附上结构图。
