SpringCloud（6）Eureka架构与CAP原则与取舍策略

一：Eureka架构

Register(服务注册)：把自己的 IP 和端口注册给 Eureka。

Renew(服务续约)：发送心跳包，每 30 秒发送一次，告诉 Eureka 自己还活着。如果 90 秒还未发送心跳，宕

机。

Cancel(服务下线)：当 Provider 关闭时会向 Eureka 发送消息，把自己从服务列表中删除。防止 Consumer 调

用到不存在的服务。

Get Registry(获取服务注册列表)：获取其他服务列表。

Replicate(集群中数据同步)：Eureka 集群中的数据复制与同步。

Make Remote Call(远程调用)：完成服务的远程调用。

二： CAP原则与取舍策略

C（一致性）：代表的是：数据不管微服务的节点有多少个，最终数据和所有节点数据是一致的。

A（可用性）：不超时，立马响应

P（分区容错）： 多块区域的数据

CAP 原则又称 CAP 定理，指的是在一个分布式系统中具有以下其中两个特性：

Consistency （一致性）

Availability （可用性）

Partition tolerance（分区容错性）

CAP 由 Eric Brewer 在 2000 年 PODC 会议上提出。该猜想在提出两年后被证明成立，成为我们熟知的 CAP 定

理。CAP 三者不可兼得。

 

取舍策略

CAP 三个特性只能满足其中两个，那么取舍的策略就共有三种：

CA without P：如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但放弃 P 的同

时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，这是违背分布式系统设计的

初衷的。

CP without A：如果不要求A（可用），相当于每个请求都需要在服务器之间保持强一致，而P（分区）会导致

同步时间无限延长（也就是等待数据同步完才能正常访问服务），一旦发生网络故障或者消息丢失等情况，就

要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。设计成 CP 的系统其实不少，最典型的就

是分布式数据库，如 Redis、HBase 等。对于这些分布式数据库来说，数据的一致性是最基本的要求，因为如

果连这个标准都达不到，那么直接采用关系型数据库就好，没必要再浪费资源来部署分布式数据库。

AP without C：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可

用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。典型的应用就如某米的抢购手机

场景，可能前几秒你浏览商品的时候页面提示是有库存的，当你选择完商品准备下单的时候，系统提示你下单

失败，商品已售完。这其实就是先在 A（可用性）方面保证系统可以正常的服务，然后在数据的一致性方面做

了些牺牲，虽然多少会影响一些用户体验，但也不至于造成用户购物流程的严重阻塞。

总结

现如今，对于多数大型互联网应用的场景，主机众多、部署分散，而且现在的集群规模越来越大，节点只会越来

越多，所以节点故障、网络故障是常态，因此分区容错性也就成为了一个分布式系统必然要面对的问题。那么就只能

在 C 和 A 之间进行取舍。但对于传统的项目就可能有所不同，拿银行的转账系统来说，涉及到金钱的对于数据一致

性不能做出一丝的让步，C 必须保证，出现网络故障的话，宁可停止服务，可以在 A 和 P 之间做取舍。

总而言之，没有最好的策略，好的系统应该是根据业务场景来进行架构设计的，只有适合的才是最好的。