前言：
Dubbo+Zookeeper vs Spring Cloud：
框架比较的方面 | Dubbo+zookeeper | Spring Cloud |
性能方面 | 注：2017年之前阿里巴巴没有对其进行更新维护，但是2017年Dubbo项目官网宣布重新对其进行更新维护，并且在2018年Dubbo项目正式进入了Apache孵化器） | Spring Cloud是最近才兴起的一个分布式服务框架，现在它的社区十分的火爆，代码的更新迭代十分的快；它一般适合于中小型企业，并且性能比Dubbo低一些； |
具有的特点 | Dubbo有良好的连通性、健壮性、伸缩性、升级性。结合Dubbo可以相对于单体系统提升系统整体的扩展性。 Dubbo提供了多种协议给用户选择， 如dubbo、hessian、rmi 。 并可为每个服务指定不同的传输协议，粒度可以细化到方法， 不同服务在性能上适用不同协议进行传输，比如大数据用短连接协议，小数据大并发用长连接协议。 | Spring Cloud来源于Spring，质量、稳定性、持续性都可以得到保证 Spirng Cloud天然支持Spring Boot，更加便于业务落地。 Spring Cloud是Java领域最适合做微服务的框架。 相比于其它框架,Spring Cloud对微服务周边环境的支持力度最大。 |
框架结构 (自身支持的组件) |
注：(dubbo本身自带的组件不够支持搭建分布式系统的架构，但是其可以集成第三方的开源项目，从而完善分布式系统的架构。) | |
方便性 | Dubbo使用起来不太方便，由于许多组件其本身不支持，所以我们在搭建架构环境时，需要集成一些其他的开源组件，集成时会遇到种种的困难，并且在以后的项目维护和升级也不方便。
Dubbo服务调用的方式是RPC，服务提供方与调用方接口依赖方式太强：我们需要将调用的抽象接口依赖到消费者项目中才能调用服务，这会导致在以后的开发、测试、版本管理上很麻烦。 | SpringCloud自身的组件可以搭建成一个完整的微服务架构，并且搭建起来稍微简单一些； SpringCloud调用的方式是REST，REST接口相比RPC更为轻量化，服务提供方和调用方的依赖只是依靠一纸契约，不存在代码级别的强依赖，当然REST接口也有缺点，很容易导致定义文档与实际实现不一致导致服务集成时的问题。 |
灵活性 | 由于dubbo许多组件都是集成的第三方，所以dubbo组件之间的自由度很高，dubbo更加的灵活。 | SpringCloud自身支持了组件，各个组件之间的关联关系已经配置好了，所以它的灵活度不是很好，如果想要用第三方组件代替其中的一个组件的话会有一些困难。 |
服务注册中心 | Zookeeper保证C(一致性)P(分区容错性) 当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。 | Eureka保证A(可用性)P(分区容错性) Eureka各个节点都是平等的，几个节点挂掉不会影响正常工作。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性) |
代码开发角度 | Dubbo常与Spring、zookeeper结合，而且实现只是通过xml来配置服务地址、名称、端口，代码的侵入性是很小的，可以说几乎没有代码入侵。 | Spring Cloud，由于它的实现需要类注解等，所以多少具有一定代码侵入。 |
| Dubbo | SpringCloud |
服务注册中心 | Zookeeper | SpringCloud Netflix Eureka |
服务调用方式 | RPC | REST API |
服务网关 | 无 | SpringCloudNetflix Zuul |
断路器 | 不完善 | SpringCloud Netflix Hystrix |
分布式配置 | 无 | SpringCloud Config |
服务跟踪 | 无 | SpringCloud Sleuth |
消息总线 | 无 | SpringCloud Bus |
......... | ........ | ............. |
总结：
总的来说这两个搭建分布式系统的框架各有各的好处，在选择时要根据自己的需求等情况综合做选择；
专业”，因为注册服务更重要的是高可用性，可以接受短期内达不到一致性的状况。
