微服务架构是互联网很热门的话题，是互联网技术发展的必然结果。它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。
虽然微服务架构没有公认的技术标准和规范或者草案，但业界已经有一些很有影响力的开源微服务架构框架提供了微服务的关键思路，例如 Dubbo 和 Spring Cloud。
微服务主要的优势
1 降低复杂度
将原来耦合在一起的复杂业务拆分为单个服务，规避了原本复杂度无止境的积累。
每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界；
每个服务开发者只专注服务本身，通过使用缓存、DAL（data access layer） 等各种技术手段来提升系统的性能，
而对于消费方来说完全透明。
2 可独立部署
由于微服务具备独立的运行进程，所以每个微服务可以独立部署。
当业务迭代时只需要发布相关服务的迭代即可，
降低了测试的工作量同时也降低了服务发布的风险。
3 容错
在微服务架构下，当某一组件发生故障时，故障会被隔离在单个服务中。
比如通过限流、熔断等方式降低错误导致的危害，保障核心业务正常运行。
4 扩展
单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。
当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，
因为每个服务可以根据实际需求独立进行扩展。
下面主要围绕微服务的 技术选型、通讯协议、服务依赖模式、开始模式、运行模式等几方面来综合比较 Dubbo 和 Spring Cloud 这 2 种开发框架。
一 核心部件
微服务的核心要素在于服务的发现、注册、路由、熔断、降级、分布式配置，基于上述几种必要条件对 Dubbo 和 Spring Cloud 做出对比。
总体架构
Dubbo 核心部件（如下图）:
Dubbo 总体架构
Spring Cloud总体架构（如下图）：
Service Consumer：调用远程服务的服务消费方。
EureKa Server： 服务注册中心和服务发现中心。
Spring Cloud 总体架构
点评：从整体架构上来看，二者模式接近，都需要服务提供方，注册中心，服务消费方。
二 微服务架构核心要素
Dubbo 只是实现了服务治理，而 Spring Cloud 子项目分别覆盖了微服务架构下的众多部件，服务治理只是其中的一个方面。
Dubbo 提供了各种 Filter，对于上述中“无”的要素，可以通过扩展 Filter 来完善。例如：
服务跟踪： 可以使用京东开源的 Hydra，或者扩展 Filter 用 Zippin 来做服务跟踪。
批量任务： 可以使用当当开源的 Elastic-Job、tbschedule。
点评：从核心要素来看，Spring Cloud 更胜一筹，在开发过程中只要整合 Spring Cloud 的子项目就可以顺利的完成各种组件的融合，而 Dubbo 却需要通过实现各种 Filter 来做定制，开发成本以及技术难度略高。
三 通讯协议
基于通讯协议层面对 2 种框架支持的协议类型以及运行效率方面进行比较。
支持协议
Dubbo 使用 RPC 通讯协议，提供序列化方式如下：
RMI：RMI 协议采用 JDK 标准的 java.rmi.* 实现，采用阻塞式短连接和 JDK 标准序列化方式。
Hessian：Hessian 协议用于集成 Hessian 的服务，Hessian 底层采用 HTTP 通讯，采用 Servlet 暴露服务，Dubbo 缺省内嵌 Jetty 作为服务器实现。
HTTP：采用 Spring 的 Http Invoker 实现。
Webservice：基于 CXF 的 frontend-simple 和 transports-http 实现。
Spring Cloud
Spring Cloud 使用 HTTP 协议的 REST API。
性能比较
使用一个 Pojo 对象包含 10 个属性，请求 10 万次，Dubbo 和 Spring Cloud 在不同的线程数量下，每次请求耗时（ms）如下：
说明：客户端和服务端配置均采用阿里云的 ECS 服务器，4 核 8G 配置，Dubbo 采用默认的 Dubbo 协议。
点评：Dubbo 支持各种通信协议，而且消费方和服务方使用长链接方式交互，通信速度上略胜 Spring Cloud，如果对于系统的响应时间有严格要求，长链接更合适。
服务依赖方式
Dubbo
服务提供方与消费方通过接口的方式依赖，服务调用设计如下：
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 方式交互，为跨平台调用奠定了基础。
组件运行流程
Dubbo
下图中的每个组件都是需要部署在单独的服务器上，Gateway 用来接受前端请求、聚合服务，并批量调用后台原子服务。每个 Service 层和单独的 DB 交互。
Dubbo 组件运行流程
Dubbo 组件运行：
Service：原子服务，只提供该业务相关的原子服务。
Zookeeper：原子服务注册到 ZK 上。
Spring Cloud 组件运行
Spring Cloud组件运行：
网关接收到请求后，从注册中心（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。
注意事项：
缓存、缓存、缓存，系统中能使用缓存的地方尽量使用缓存，通过合理的使用缓存可以有效的提高系统的TPS。
服务拆分要合理，尽量避免因服务拆分而导致的服务循环依赖。
合理的设置线程池，避免设置过大或者过小导致系统异常。
总结
Dubbo 出生于阿里系，是阿里巴巴服务化治理的核心框架，并被广泛应用于中国各互联网公司；只需要通过 Spring 配置的方式即可完成服务化，对于应用无入侵，设计的目的还是服务于自身的业务为主。
虽然阿里内部原因 Dubbo 曾经一度暂停维护版本，但是框架本身的成熟度以及文档的完善程度，完全能满足各大互联网公司的业务需求。
如果我们使用配置中心、分布式跟踪这些内容都需要自己去集成，这样无形中增加了使用 Dubbo 的难度。
Spring Cloud 是大名鼎鼎的 Spring 家族的产品， 专注于企业级开源框架的研发。
Spring Cloud 自从发布到现在，仍然在不断的高速发展，几乎考虑了服务治理的方方面面，开发起来非常的便利和简单。
Dubbo 于 2017 年开始又重启维护，发布了更新后的 2.5.7 版本，而 Spring Cloud 更新的非常快，目前已经更新到 Finchley.M2。
因此，企业需要根据自身的研发水平和所处阶段选择合适的架构来解决业务问题，不管是 Dubbo 还是 Spring Cloud 都是实现微服务有效的工具。
微服务架构是互联网很热门的话题，是互联网技术发展的必然结果。它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。
==================================================
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：社区活跃度
我们选择一个开源框架，社区的活跃度是我们极为关注的一个要点。社区越活跃，解决问题的速度越快，框架也会越来越完善，不然当我们碰到问题，就不得不自己解决。而对于团队来说，也就意味着我们不得不自己去维护框架的源码，这对于团队来说也将会是一个很大的负担。
小结：在社区活跃度上，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自然对国内开发团队来说更有优势。
总结
通过上面再几个环节上的分析，相信大家对Dubbo和Spring Cloud有了一个初步的了解。就我个人对这两个框架的使用经验和理解，打个不恰当的比喻：使用Dubbo构建的微服务架构就像组装电脑，各环节我们的选择自由度很高，但是最终结果很有可能因为一条内存质量不行就点不亮了，总是让人不怎么放心，但是如果你是一名高手，那这些都不是问题；而Spring Cloud就像品牌机，在Spring Source的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性，但是如果要在使用非原装组件外的东西，就需要对其基础有足够的了解。
从目前Spring Cloud的被关注度和活跃度上来看，很有可能将来会成为微服务架构的标准框架。所以，Spring Cloud的系列文章，我会继续写下去。也欢迎各位朋友一起交流，共同进步。
