Spring Cloud 是一整套分布式解决方案。
Spring Boot 专心于单一应用的开发，Spring Cloud 专心于微服务的部署与管理。
Spring Cloud 与 dubbo
定位不一样：dubbo 定位是 RPC 框架，而 Spring Cloud 是微服务框架下的一站式解决方案。
在这定位下呢，dubbo 的使用通常需要集成其他分布式框架，比如 zookeeper。
其次两个服务间的调用方式不一样，dubbo 使用的是 RPC， Spring Cloud 使用的是 REST API。
最后，Spring Cloud 拥有许多 dubbo 不支持的功能或者组件（这不是废话，两个定位都不一样）。
我们可以直接调用 REST api，也可以使用 Eureka 去管理我们的服务。
以 dubbo 架构为例，提供者向注册中心注册自己，表明能提供哪些服务。消费者向注册中心异步订阅需要的服务，注册中心将相应的服务信息异步返回给消费者，当需要调用时，根据注册中心返回的信息同步调用提供者。
Eureka server 就是 dubbo 架构中的注册中心。
这是 Eureka 的高可用架构示意图：提供者向 Eureka server 注册自身的服务；消费者从 Eureka server 获取注册的服务信息；Eureka server 集群之间进行同步、复制注册信息；消费者远程调用提供者。这个 Get Registry 画的是一条线，其实像 dubbo 那样画成两条线就比较好理解了。
CAP:
传统 ACID 数据库事务特性：
- A（Atomicity）原子性：一个事务中所有操作要么全部成功，要么全部失败。
- C(Consistency) 一致性：不管操作多少次，事务前后数据的完整性必须保持一致。
- I（Isolation）隔离性：多个并发事务之间要相互隔离，也可理解为不见。不隔离，就会发生读脏数据、不可重复读、幻读、更新丢失问题。
- D（Durability）持久性：在事务完成以后，该事务对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。
CAP 为 分布式系统有三个指标：
- C（Consistency）强一致性：在分布式系统中的所有数据备份，在同一时刻是否同样的值。
- A（Availability）可用性：某一节点故障后，集群整体是否还能响应客户端的读写请求。
- P（Partition tolerance）分区容错性：各个节点之间做数据同步的时效性是否能达到要求。
为啥不能同时满足 CAP
Eric Brewer 说，这三个指标不可能同时做到。这个结论就叫做 CAP 定理。
C 与 A 不能同时满足，就是因为网络通信延迟或者故障的存在，一般来说，分区容错无法避免，所以只能在 C 与 A 之间进行选择。
BASE：
是在CAP理论的基础之上的延伸。
基本可用（Basically Available）：分布式系统出现故障的时候，允许损失一部分可用性。比如，京东618大促的时候，对一些非核心链路的功能进行降级处理。
柔性状态（Soft State）：允许系统存在中间状态，这个中间状态又不会影响系统整体可用性。比如，数据库读写分离，写库同步到读库（主库同步到从库）会有一个延时，这样实际是一种柔性状态。
最终一致性（Eventual Consistency）：数据库主从复制，经过数据同步延时之后，最终数据能达到一致。
zookeeper 保证CP：
当向注册中心查询服务列表时，可以容忍注册中心返回的是之前的注册信息，但是不能容忍注册中心挂掉不可用。也就是说对于注册中心来讲可用性的要求大于强一致性。但是，zookeeper 有中心的 ，也就是leader，leader 是需要投票选举的，如果节点太多，时间可能会达到 30~120s，由于选举期间整个 zk 集群不可用，就会导致在选举期间注册服务瘫痪，可用性得不到保证。-
Eureka 保证AP：
Eureka 各个节点机会是平等的。只要节点没有全部瘫痪，就可以提供注册、查询服务，只不过可能查询的信息不是最新的。除此之外，Eureka 还有自我保护机制，如果在15分钟内超过85%的节点都没有心跳，那么 Eureka 就认为客户端与注册中心出现了网络故障，此时就会采取以下措施：- Eureka 不再从注册列表中移除因为长时间没有收到心跳而应该过期的服务；
- Eureka 仍然能够接受新服务的注册和查询要求，但是不会同步到其他节点上（即保证当前节点可用）；
- 当网络稳定时，当前节点新的注册信息会同步到其他节点。
