Dubbo还是Spring-cloud？将来的架构你怎么选，两套方案对比

分布式架构方案的选择，目前很多，以阿里的dubbo为代表的服务治理方案，包括新浪的montan，rpcx,grpc，Thirft等等，都可以自身或集合其他第三方开源软件集合成一套优秀的分布式性能框架。另一类是正在出现在人们视线的Spring-cloud，spring以完善的功能和良好的口碑被开发认可，成为领域中不可或缺的一部分，spring-cloud依托其强大的功能和影响力，和其自身强大的功能方案集合，完全可以独立为企业应用构造一份品牌架构。目前哪个才是最合适的？下面对比有摘自一位大贤的博客，我也总结了一写特点的对比

Name	Dubbo	Spring-cloud
OpenSource	Yes	Yes
Source	alibaba,目前已贡献给apache	Spring
Reputation	国内知名度高	国内知名度不高，但依托Sping强大技术体系
文档	完善	完善
社区活跃度	更新慢	比较活跃
架构性	只提供服务治理	提供微服务架构的方方面面功能
分布式配置	可以使用淘宝的diamond、百度的disconf来实现分布式配置管理	pring Cloud中的Config组件除了提供配置管理之外，由于其存储可以使用git，因此它天然的实现了配置内容的版本管理，可以完美的与应用版本管理整合起来
服务跟踪	可以使用京东开源的Hydra
批量任务	可以使用当当开源的Elastic-Job
通讯	主RPC，Dubbox支持REST	REST
使用Dubbo的RPC来实现服务间调用的一些痛点	服务提供方与调用方接口依赖方式太强：我们为每个微服务定义了各自的service抽象接口，并通过持续集成发布到私有仓库中，调用方应用对微服务提供的抽象接口存在强依赖关系，因此不论开发、测试、集成环境都需要严格的管理版本依赖，才不会出现服务方与调用方的不一致导致应用无法编译成功等一系列问题，以及这也会直接影响本地开发的环境要求，往往一个依赖很多服务的上层应用，每天都要更新很多代码并install之后才能进行后续的开发。若没有严格的版本管理制度或开发一些自动化工具，这样的依赖关系会成为开发团队的一大噩梦。而REST接口相比RPC更为轻量化，服务提供方和调用方的依赖只是依靠一纸契约，不存在代码级别的强依赖，当然REST接口也有痛点，因为接口定义过轻，很容易导致定义文档与实际实现不一致导致服务集成时的问题，但是该问题很好解决，只需要通过每个服务整合swagger，让每个服务的代码与文档一体化，就能解决。所以在分布式环境下，REST方式的服务依赖要比RPC方式的依赖更为灵活。
	服务对平台敏感，难以简单复用：通常我们在提供对外服务时，都会以REST的方式提供出去，这样可以实现跨平台的特点，任何一个语言的调用方都可以根据接口定义来实现。那么在Dubbo中我们要提供REST接口时，不得不实现一层代理，用来将RPC接口转换成REST接口进行对外发布。若我们每个服务本身就以REST接口方式存在，当要对外提供服务时，主要在API网关中配置映射关系和权限控制就可实现服务的复用了
1、Dubbo实现了服务治理的基础，但是要完成一个完备的微服务架构，还需要在各环节去扩展和完善以保证集群的健康，以减轻开发、测试以及运维各个环节上增加出来的压力，这样才能让各环节人员真正的专注于业务逻辑。                     2、而Spring Cloud依然发扬了Spring Source整合一切的作风，以标准化的姿态将一些微服务架构的成熟产品与框架揉为一体，并继承了Spring Boot简单配置、快速开发、轻松部署的特点，让原本复杂的架构工作变得相对容易上手一些          3、所以，如果选择Dubbo请务必在各个环节做好整套解决方案的准备，不然很可能随着服务数量的增长，整个团队都将疲于应付各种架构上不足引起的困难。而如果选择Spring Cloud，相对来说每个环节都已经有了对应的组件支持，可能有些也不一定能满足你所有的需求，但是其活跃的社区与高速的迭代进度也会是你可以依靠的强大后盾。

其他分布式性能框架比较

仅供参考