eureka

EurekaClient
EurekaClient为了简化开发人员的工作量，将很多与EurekaServer交互的工作隐藏起来，自主完成。具体完成的工作如下

应用启动阶段

1. 读取与 Eureka Server交互的配置信息,封装成 EurekaClientConfig
2. 读取自身服务实例配置信息,封装成EurekalnstanceConfig
3. 从Eureka server拉取注册表信息并缓存到本地
4. 服务注册
5. 初始化发送心跳、缓存刷新(拉取注册表信息更新本地缓存)和按需注册(监控服务实例信息变化,决定是否重新发起注册,更新注册表中的服务实例元数据)定时任务

应用执行阶段

1. 定时发送心跳到Eureka Server中维持在注册表的租约
2. 定时从 Eureka Server中拉取注册表信息,更新本地注册表缓存
3. 监控应用自身信息变化,若发生变化,需要重新发起服务注册

应用销毁阶段
从 Eureka Server注销自身服务实例

EurekaServer
是服务的注册中心，负责Eureka Client的相关信息注册，主要职责
 服务注册
 接受心跳服务
 服务剔除
 服务下线
 集群同步

public interface LeaseManager {
//注册
void register(T var1, int var2, boolean var3);
//下线
boolean cancel(String var1, String var2, boolean var3);
//跟新
boolean renew(String var1, String var2, boolean var3);
//服务剔除
void evict();
}

服务注册
com.netflix.eureka.registry.AbstractInstanceRegistry#register 这方法是负责服务的注册的。

接受心跳服务
在Eureka Client完成服务的注册后，需要定时向Eureka Server发送心跳请求（默认30s）,维持自己在EurekaServer的租约有效性

服务剔除
如果Eureka Client在注册后，由于服务的崩溃或网络异常导致既没有续约，也没有下线，那么服务就处于不可知的状态，需要剔除这些服务
com.netflix.eureka.registry.AbstractInstanceRegistry#evict(long)
这是个定时任务调用的方法
com.netflix.eureka.registry.AbstractInstanceRegistry#postInit中使用
AbstractInstanceRegistry.EvictionTask 负责调用(默认60s)

服务下线
EurekaClient在应用销毁时候，会向Eureka Server发送下线请求
对于服务端的服务下线，其主要代码对应在
com.netflix.eureka.registry.AbstractInstanceRegistry#cancel

集群同步
如果Eureka Server是通过集群方式进行部署，为了为维护整个集群中注册表数据一致性所以集群同步也是非常重要得事情。
集群同步分为两部分

1. EurekaServer在启动过程中从他的peer节点中拉取注册表信息，并讲这些服务实例注册到本地注册表中；

2. 另一部分是eureka server每次对本地注册表进行操作时，同时会讲操作同步到他的peer节点中，达到数据一致；

   Eureka Server初始化本地注册表信息
   在eureka server启动过程中，会从它的peer节点中拉取注册表来初始化本地注册表，这部分主要通过
   com.netflix.eureka.registry.PeerAwareInstanceRegistryImpl#syncUp
   他从可能存在的peer节点中，拉取peer节点中的注册表信息，并将其中的服务实例的信息注册到本地注册表中。

   Eureka Server之间注册表信息同步复制
   为了保证Eureka Server集群运行时候注册表的信息一致性，每个eureka server在对本地注册表进行管理操作时，会将相应的信息同步到peer节点中。
   com.netflix.eureka.registry.PeerAwareInstanceRegistryImpl#cancel
   com.netflix.eureka.registry.PeerAwareInstanceRegistryImpl#register
   com.netflix.eureka.registry.PeerAwareInstanceRegistryImpl#renew
   等方法中，都回调用方法
   com.netflix.eureka.registry.PeerAwareInstanceRegistryImpl#replicateToPeers

• Eureka和Zookepper的区别

并不是说哪个好，也不是说哪个不好，但毕竟我刚学Eureka,所以是这里主要夸一下Eureka

Eureka架构图的简单原理

架构图解释: Eureka是SpringCloud中常用的注册中心，采用去中心 化的。不存在Leader,每个Eureka都可以认为是老大，在集群中是平级的。 当服务提供者启动之后，会把服务的信息注册到Eureka中，即Eureka缓存服务列表。服务调用方调用服务时，先去Eureka中查询需要的服务注册列表， 然后再完成一次远程的服务调用。

结论：

• 1.Eureka和Zookepper都可以作为注册中心
• 2.Eureka取CAP中的AP，注重可用性。Zookepper取CAP理论中的CP强调高的一致性
• 3.Cloud官网Eureka架构图指出，Eureka是去中心化的，当网络出现分区故障时，可以独立的为各自的子网下的机器提供服务。 Zookepper中，当出现分区故障，Zookepper集群进行各自服务的提出，然后根据规定在各自的集群下进行Leader选举， 但参选人数不过半时，此集群挂掉。(脑裂中就存在这种问题导致它不具有可用性)
• 4.Eureka常用于SpringCloud下产物的注册中心,如：微服务的注册中心
  Zookepper是分布式下的注册中心，如：Dubbo、Hadoop类似的集群的服务注册中心
• 5.Eureka和Zookeeper的选取：看自己程序的需要，是需要AP还是CP,根据具体的场景来选取
• 6.对于Zookepper和Eureka中关于宕掉服务的可用问题：
  首先：宕掉指的是什么宕掉？如果是提供服务的机器宕掉，即注册一个服务到Zookepper中的那个服务宕掉，那么就是不可用的
  反之：如果宕掉的是Zookepper或者Eureka，那么服务调用方还是有可能调用成功服务的。因为存在本地缓存的服务列表。
  当提供服务的机器宕掉之后，服务就不可以访问了。大家一般说的宕掉后服务可用指的不是服务宕掉，而是指服务注册中心宕掉时 可访问，因为调用服务者本地会缓存之前的服务调用列表。
  SpringCloud官网

Eureka的优势

• 1、在Eureka集群中，如果某台服务器挂掉宕机，Eureka不会有类似于ZooKeeper的选举leader的过程(因为在Eureka集群中的机器，不存在Leader,大家是平级的，所以不存在选举Leader)；客户端请求会自动切换到新的Eureka节点；当宕机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理之中；新启动的机器，只需要同步新的服务注册信息。（多个zookeeper之间网络出现问题,造成出现多个leader，发生脑裂(脑裂指：一个集群被分割为多个集群，每个集群有各自的统帅即Leader)）当网络分割故障发生时，每个Eureka节点，会持续的对外提供服务（注：ZooKeeper不会,少于Zookepper的选举可用可数时，Zookepper集群会挂掉，至此不对外提供服务）
• 2、正常配置下，Eureka内置了心跳服务，用于淘汰一些“濒死”的服务器；如果在Eureka中注册的服务，它的“心跳”变得迟缓时，Eureka会将其整个剔除出管理范围。这是个很好的功能，但是当网络分割故障发生时，这也是非常危险的；因为，那些因为网络问题（注：心跳慢被剔除了）而被剔除出去的服务器本身是很”健康“的，只是因为网络分割故障把Eureka集群分割成了独立的子网而不能互访而已。Netflix考虑到了这个缺陷。如果Eureka服务节点在短时间里丢失了大量的心跳连接（注：可能发生了网络故障），那么这个Eureka节点会进入”自我保护模式“，同时保留那些“心跳死亡“的服务注册信息不过期。此时，这个Eureka节点对于新的服务还能提供注册服务，对于”死亡“的仍然保留，以防还有客户端向其发起请求。当网络故障恢复后，这个Eureka节点会退出”自我保护模式“。所以Eureka的哲学是，宁可放过这可坏的服务，也不会误杀掉正常的服务。
• 3、Eureka还有客户端缓存功能（注：Eureka分为客户端程序与服务器端程序两个部分，客户端程序负责向外提供注册与发现服务接口）。所以即便Eureka集群中所有节点都失效，或者发生网络分割故障导致客户端不能访问任何一台Eureka服务器；Eureka服务的消费者仍然可以通过Eureka客户端缓存来获取现有的服务注册信息。甚至最极端的环境下，所有正常的Eureka节点都不对请求产生相应，也没有更好的服务器解决方案来解决这种问题 时；得益于Eureka的客户端缓存技术，消费者服务仍然可以通过Eureka客户端查询与获取注册服务信息，这点很重要。
• 4、Eureka的构架保证了它能够成为Service发现服务。它相对与ZooKeeper来说剔除了Leader节点的选取或者事务日志机制，这样做有利于减少使用者维护的难度也保证了Eureka的在运行时的健壮性。而且Eureka就是为发现服务所设计的，它有独立的客户端程序库，同时提供心跳服务、服务健康监测、自动发布服务与自动刷新缓存的功能。但是，如果使用ZooKeeper你必须自己来实现这些功能。Eureka的所有库都是开源的，所有人都能看到与使用这些源代码，这比那些只有一两个人能看或者维护的客户端库要好。

ZooKeeper的劣势

• 1、强调高的一致性，对于Service发现服务来说就算是返回了包含不实的信息的结果也比什么都不返回要好；再者，对于Service发现服务而言，宁可返回某服务5分钟之前在哪几个服务器上可用的信息，也不能因为暂时的网络故障而找不到可用的服务器，而不返回任何结果。在ZooKeeper中，如果在同一个网络分区（partition）的节点数（nodes）数达不到ZooKeeper选取Leader节点的“规定人数”时，此时Zookepper的服务中心就会挂掉，当然同时也就不能提供Service发现服务了。

• 2、ZooKeeper下所有节点不可能保证任何时候都能缓存所有的服务注册信息。如果ZooKeeper下所有节点都断开了，或者集群中出现了网络分割的故障（注：由于交换机故障导致交换机底下的子网间不能互访）；由于必须进行选举Leader,不是一个去中心化的，选举人数不符合要求，集群挂掉服务不可用

• 3、ZooKeeper是按照CP原则构建的，也就是说它能保证每个节点的数据保持一致，而为ZooKeeper加上缓存的做法的目的是为了让ZooKeeper变得更加可靠（available）；但是，ZooKeeper设计的本意是保持节点的数据一致，也就是CP。所以，这样一来，你可能既得不到一个数据一致的（CP）也得不到一个高可用的（AP）的Service发现服务了；因为，这相当于你在一个已有的CP系统上强制栓了一个AP的系统，这在本质上就行不通的！一个Service发现服务应该从一开始就被设计成高可用的才行！

  注：
  在分布式系统领域有个著名的CAP定理（C-数据一致性；A-服务可用性；P-服务对网络分区故障的容错性，这三个特性在任何分布式系统中不能同时满足，最多同时满足两个）；ZooKeeper是CP的，即任何时刻对ZooKeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性；但是它不能保证每次服务请求的可用性。因为ZooKeeper是分布式协调服务，它的职责是保证数据（注：配置数据，状态数据）在其管辖下的所有服务之间保持同步、一致，而且，作为ZooKeeper的核心实现算法Zab，就是解决了分布式系统下数据如何在多个服务之间保持同步问题的。
  注：ZAB（ZooKeeper Atomic Broadcast ） 全称为：原子消息广播协议；ZAB可以说是在Paxos算法基础上进行了扩展改造而来的，ZAB协议设计了支持崩溃恢复，ZooKeeper使用单一主进程Leader用于处理客户端所有事务请求，采用ZAB协议将服务器数状态以事务形式广播到所有Follower上；由于事务间可能存在着依赖关系，ZAB协议保证Leader广播的变更序列被顺序的处理，：一个状态被处理那么它所依赖的状态也已经提前被处理；ZAB协议支持的崩溃恢复可以保证在Leader进程崩溃的时候可以重新选出Leader并且保证数据的完整性；
  过半数（>=N/2+1） 的Follower反馈信息后，Leader将再次向集群内Follower广播Commit信息，Commit为将之前的Proposal提交；