Spring Cloud与Dubbo,Eureka与ZooKeeper

一、Spring Cloud与Dubbo

1、先谈谈架构                                                                                                                                                                                    单一应用架构
当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM) 是关键。
垂直应用架构
当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC) 是关键。
分布式服务架构
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC) 是关键。
流动计算架构
当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA) 是关键。

2、Dubbo和Spring Cloud并不是完全的竞争关系，两者所解决的问题域不一样：Dubbo的定位始终是一款RPC框架，而Spring Cloud的目的是微服务架构下的一站式解决方案。Spring Cloud和Dubbo的最大区别：Spring Cloud抛弃了Dubbo的RPC通信，采用的是基于Http的Rest方式。

优缺点：                                                                                                                                                                                        1、dubbo由于是二进制的传输，占用带宽会更少。
springCloud是http协议传输，带宽会比较多，同时使用http协议一般会使用JSON报文，消耗会更大（但是在国内95%的公司内，网络消耗不是什么太大问题，如果真的成了问题，通过压缩、二进制、高速缓存、分段降级等方法，很容易解）。
2、dubbo的开发难度较大，原因是dubbo的jar包依赖问题很多大型工程无法解决。
springcloud的接口协议约定比较自由且松散，需要有强有力的行政措施来限制接口无序升级。
3、dubbo的注册中心可以选择zk,redis等多种，springcloud的注册中心只能用eureka或者自研。                                                   4、虽然Dubbo 支持短连接大数据量的服务提供模式，但绝大多数情况下都是使用长连接小数据量的模式提供服务使用的。
如果产品业务中由于后台业务逻辑复杂、时间长而导致异步逻辑比较多的话，可能Dubbo 并不合适

二、Eureka与ZooKeeper

著名的CAP理论指出，一个分布式系统不可能同时满足C(数据一致性)、A(服务可用性)和P(分区容错性)。这三个特性在任何分布式系统中不能同时满足，最多同时满足两个。由于分区容错性在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。在此Zookeeper保证的是CP, 而Eureka则是AP。

ZooKeeper是分布式协调服务，它的职责是保证数据（注：配置数据，状态数据）在其管辖下的所有服务之间保持同步、一致。而且，作为ZooKeeper的核心实现算法Zab，就是解决了分布式系统下数据如何在多个服务之间保持同步问题的。
当ZooKeeper的master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个ZooKeeper集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得ZooKeeper集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。而且，ZooKeeper在多于一半服务挂掉时会停止提供服务。                                                                  作为一个分布式协同服务，ZooKeeper非常好，但是对于Service发现服务来说就不合适了。因为对于Service发现服务来说就算是返回了包含不实的信息的结果也比什么都不返回要好。再者，对于Service发现服务而言，宁可返回某服务5分钟之前在哪几个服务器上可用的信息，也不能因为暂时的网络故障而找不到可用的服务器，而不返回任何结果。

Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，而不会像ZooKeeper那样使整个注册服务瘫痪，只不过查到的信息可能不是最新的(不保证强一致性)。
除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况： 
   1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务 
   2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用) 
   3. 当网络稳定时，当前实例新的注册信息会被同步到其它节点中
因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。

当然，具体情况具体分析使用。