CAP定理是分布式系统设计中最基础、最关键的理论，CAP定理又称CAP原则，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），最多只能同时三个特性中的两个，三者不可兼得
CAP的定义
Consistency (一致性)：
“all nodes see the same data at the same time”，即更新操作成功并返回客户端后，所有节点在同一时间的数据完全一致，这就是分布式的一致性。一致性的问题在并发系统中不可避免，对于客户端来说，一致性指的是并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。即每次读取要么获得最近写入的数据，要么获得一个错误。
Availability (可用性):
可用性指“Reads and writes always succeed”，即服务一直可用，而且是正常响应时间。好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。也就是每次请求都能获得一个响应，这个响应是非错误的，但是不确保返回的是最新写入的数据。
Partition Tolerance (分区容错性):
即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务。
分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了，其他剩下的机器还能够正常运转满足系统需求，对于用户而言并没有什么体验上的影响。
取舍策略
CAP三个特性只能满足其中两个，那么取舍的策略就共有三种：
CA without P：如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但放弃P的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，这是违背分布式系统设计的初衷的。比如两阶段提交（2PC）
CP without A：如果不要求A（可用），相当于每个请求都需要在服务器之间保持强一致，而P（分区）会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务)，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。注意，CP关注的是系统中大多数人的一致性协议，比如Paxos 算法 (Quorum 类的算法)。设计成CP的系统其实不少，最典型的就是分布式数据库，如Redis、HBase等。对于这些分布式数据库来说，数据的一致性是最基本的要求，因为如果连这个标准都达不到，那么直接采用关系型数据库就好，没必要再浪费资源来部署分布式数据库。eg. Zookeeper
AP without C：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。典型的应用就如某米的抢购手机场景，可能前几秒你浏览商品的时候页面提示是有库存的，当你选择完商品准备下单的时候，系统提示你下单失败，商品已售完。这其实就是先在 A（可用性）方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，虽然多少会影响一些用户体验，但也不至于造成用户购物流程的严重阻塞。eg. Eureka
作为服务发现产品，可用性优先级较高，一致性的特点则不重要，哪怕返回错误的数据，也比不返回结果要好一些。
服务列表变更Zookeeper服务端会有通知，Eureka则通过长轮询来实现，将来会实现watch机制。
我司使用了Zookeeper作为服务注册发现中间件，但是如上文所述，Zookeeper是CP系统，无法保证分布式下的可用性，需要使用AP系统。因此，公司大佬们实现AP系统服务注册发现，保证了数据的最终一致性。根据 Netflix Eureka 研发并优化的golang版本服务注册发现系统Discovery，与caster平台进行结合，基于k8s pod(k8s项目中的原子调度单位)实现滚动发布、蓝绿发布等，客户端使用HTTP协议与注册中心交互。 网络闪断时服务可开启自我保护，保证健康的服务可用。由于公司各部门开发语言不一致，有golang、java、python、php、C++等，再实现各个语言的sdk，基于http协议保证交互简易。