服务注册中心对整个微服务架构起着最核心的整合作用，因此对Eureka还是有很大的必要进行深入研究。

CAP

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

CAP分布式开发中有一个著名的CAP原理，C（一致性），A（可用性），P（分区容错性），这三者在开发中不可兼得，因此我们只能在A和C之间进行权衡。在此Zookeeper保证的是CP, 而Eureka则是AP。很容易的可以理解，如果要保证一致性，如zookeeper，需要选举leader的过程，并完成数据一致的同步，在这个过程中，zookeeper就是不可用的。一致性和可用性好理解，分布容错性是什么呢？所谓分布式容错性，就是在一个分布式集群中，一个节点崩溃，对整个分布式不会产生影响，又由于分区容错性是一个分布式系统所必须的条件，所以人们往往会在AC之间取舍。

zookeeper保证cp

当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

Eureka保证AP

Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

  1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
  2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)
  3. 当网络稳定时，当前实例新的注册信息会被同步到其它节点中

一、注册中心原理

注册中心主要涉及到三大角色：
服务提供者
服务消费者
注册中心
它们之间的关系大致如下：
1、各个微服务在启动时，将自己的网络地址等信息注册到注册中心，注册中心存储这些数据。
2、服务消费者从注册中心查询服务提供者的地址，并通过该地址调用服务提供者的接口。
3、各个微服务与注册中心使用一定机制（例如心跳）通信。如果注册中心与某微服务长时间无法通信，就会注销该实例。
4、微服务网络地址发送变化（例如实例增加或IP变动等）时，会重新注册到注册中心。这样，服务消费者就无需人工修改提供者的网络地址了。

注册中心实现过程

注册中心有什么需求？
1、启动过后的服务进行注册，告诉注册中心我已经启动完毕，可以进行访问了
2、想调用服务方要访问注册中心获取调用对象的信息，然后再进行访问
3、不需要的服务需要进行注销。

所以注册中心会有至少以下功能：
1、注册功能
2、查询功能
3、注销功能

在调用的过程中，我访问需要的功能需要一些什么信息呢？
1、服务器的IP、端口、path信息，离开了这些信息我无法进行访问。
2、服务器的名称信息，你提供的服务内容是什么，是否是需求方需要进行调用的服务。

于是双方就要进行约定传输的内容，我提供的服务名称是什么，我的访问路径是什么，提供者将注册信息发送给注册中心进行注册保存，供消费者进行查询使用。

在实现最基础的功能之后还会存在什么问题？
1、通常提供服务的不会是一台服务器，会是一个集群。
2、如果服务提供者在提供的过程中当机，那么它无法再提供服务，如果数据在保存在注册中心中的话，消费者调用服务将会一直获得错误的信息，无法实现需求的功能。

如何来解决这个问题
1、将集群后的信息存放到map中
2、为注册者加入心跳（定时任务，过一段时间就向服务中心发送一次请求信息，注册中心更新注册时间，以便后续进行判断服务提供者是否需要注销。如在5个单位时间都没有收到服务提供者发送来的信息的话，就认为该服务提供者已经停止工作，从注册中心中移除该服务内容。）

实现之后还会存在什么问题？
1、注册中心会成为系统的瓶颈点，因为消费者和提供者都会对注册中心进行访问。
2、之前仅一次的请求，经过注册服务中心会变成两次（从消费者直接访问服务提供者变成了，消费者访问注册中心之后获取服务提供者的信息，向服务提供者发送请求）。

如何解决这个问题，实现服务的高可用？
1、为注册中心进行集群（CAP选择），Eureka采用的方式为当一台服务中心获取到服务信息后，同步到其他的注册中心，保持信息一致。
2、采用缓存的机制，将服务信息缓存至本地，已定时任务的方式获取更新后的服务信息。