(一)Eureka和Zookeeper的区别

Eureka入门使用介绍参见：

https://blog.csdn.net/A7_A8_A9/article/details/104336729

https://blog.csdn.net/A7_A8_A9/article/details/104385643

CAP:

• C（一致性）：所有的节点上的数据时刻保持同步
• A（可用性）：每个请求都能接受到一个响应，无论响应成功或失败
• P（分区容错）：系统应该能持续提供服务，即使系统内部有消息丢失（分区）

• C：一致性被称为原子对象，任何的读写都应该看起来是“原子“的，或串行的。写后面的读一定能读到前面写的内容。所有的读写请求都好像被全局排序。
  A：对任何非失败节点都应该在有限时间内给出请求的回应。（请求的可终止性）
  P：允许节点之间丢失任意多的消息，当网络分区发生时，节点之间的消息可能会完全丢失
  
  

高可用、数据一致是很多系统设计的目标，但是分区又是不可避免的事情：
CA without P：如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但其实分区不是你想不想的问题，而是始终会存在，因此CA的系统更多的是允许分区后各子系统依然保持CA。
CP without A：如果不要求A（可用），相当于每个请求都需要在Server之间强一致，而P（分区）会导致同步时间无限延长，如此CP也是可以保证的。很多传统的数据库分布式事务都属于这种模式。
AP wihtout C：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。

Eureka是满足AP的。

注册中心规则

每一个微服务启动的时候，都需要去注册中心注册（eureka或zookeeper或其他）

同类服务注册的服务名必须相同，不同类服务注册的服务名一定不能相同
（订单服务部署5台服务器，那么这5台微服务在注册中心中注册的服务名必须一致，例如ORDER）
（商品服务部署4台服务器，那么这4台微服务在注册中心中注册的服务名必须一致，例如GOODS）
（订单服务和商品服务注册的服务名一定不能相同，不能同为ORDER,也不能同为GOODS）

eureka是什么

eureka作为分布式系统的注册中心，主要作用是用于服务治理

eureka分为eureka server和eureka client

eureka原理

每一个微服务中都有eureka client，用于服务的注册于发现
（服务的注册：把自己注册到eureka server）
（服务的发现：从eureka server获取自己需要的服务列表）

每一个微服务启动的时候，都需要去eureka server注册

当A服务需要调用B服务时，需要从eureka服务端获取B服务的服务列表，然后把列表缓存到本地，然后根据ribbon的客户端负载均衡规则，从服务列表中取到一个B服务，然后去调用此B服务
当A服务下次再此调用B服务时，如果发现本地已经存储了B的服务列表，就不需要再从eureka服务端获取B服务列表，直接根据ribbon的客户端负载均衡规则，从服务列表中取到一个B服务，然后去调用B服务

微服务，默认每30秒，就会从eureka服务端获取一次最新的服务列表

如果某台微服务down机，或者添加了几台机器，
此时eureka server会通知订阅他的客户端，并让客户端更新服务列表，
而且还会通知其他eureka server更新此信息

心跳检测，微服务每30秒向eureka server发送心跳，
eureka server若90s之内都没有收到某个客户端的心跳，则认为此服务出了问题，
会从注册的服务列表中将其删除，并通知订阅它的客户端更新服务列表，
而且还会通知其他eureka server更新此信息

eureka server保护机制，通过打卡开关，可以让eureka server处于保护状态，主要是用于某eureka server由于网络或其他原因，导致接收不到其他微服务的心跳，此时不能盲目的将其他微服务从服务列表中删除。
具体规则：如果一段时间内，85%的服务都没有发送心跳，则此server进入保护状态，此状态下，可以正常接受注册，可以正常提供查询服务，但是不与其他server同步信息，也不会通知订阅它的客户端，这样就不会误杀其他微服务

zookeeper原理

zookeeper也可以作为注册中心，用于服务治理（zookeeper还有其他用途，例如：分布式事务锁等）	
每启动一个微服务，就会去zk中注册一个临时子节点，
例如：5台订单服务，4台商品服务
（5台订单服务在zk中的订单目录下创建的5个临时节点）
（4台商品服务在zk中的商品目录下创建的4个临时接点）

每当有一个服务down机，由于是临时接点，此节点会立即被删除，并通知订阅该服务的微服务更新服务列表
（zk上有watch，每当有节点更新，都会通知订阅该服务的微服务更新服务列表）

每当有一个新的微服务注册进来，就会在对应的目录下创建临时子节点，并通知订阅该服务的微服务更新服务列表
（zk上有watch，每当有节点更新，都会通知订阅该服务的微服务更新服务列表）

每个微服务30s向zk获取新的服务列表

CAP基本概念

分布式系统的三个指标
1、Consistency	一致性

2、Availability	可用性

3、Partition tolerance	分区容错性

eureka和zookeeper区别

eureka基于AP

zookeeper基于CP

由于作为注册中心可用性的需求要高于一致性，所以eureka貌似要比zookeeper更合理一些