【微服务>>>注册中心】
一、简介
Eureka是Netflix公司开源的服务发现组件，其完整体系包含两个部分，Eureka Server 和 Eureka Client。
Eureka的目标是一方面给内部服务做服务发现，另一方面可以结合ribbon（负载均衡）组件提供各种个性化的负载均衡算法。
二、服务发现技术选型
Eurake Server端采用的是P2P的复制模式，属于AP模式，因为它不能保证复制操作一定能成功，因此它提供的是最终一致性。
Eureka的Server端和Client端采用 心跳 + 租约 的机制来保障有效沟通，Cilent端在Server端的注册信息有一个带期限的租约，一旦Server端在指定期间没有收到Client的心跳信息，那么Server端就会认为Client端注册的服务是不健康的，定时任务会将其从注册中删除。
采用Eurake的理由：
1 选择AP而不是CP，原因后面会阐述；
2 对Java语言体系的团队更友好；
3 Eureka属于Netflix一部分，和其它Netflix的组件融合的很好，形成一套闭环的微服务架构。
三、Eurake的核心对象
Eureka一共有4个核心对象，下面一一介绍：
1 InstanceInfo对象：代表服务的注册实例；
2 LeaseInfo对象：代表应用实例的租约信息；
3 ServiceInstance接口：约定了服务发现实例应该有哪些通用的信息；
4 InstanceStatus枚举：用于标识服务实例的状态。
四、服务的核心操作
对于服务发现来说，围绕服务实例主要有如下几个重要的操作：
1 服务注册（Register）
2 服务下线（Cancel）
3 服务续租（Renew）
4 服务剔除（Evict）
围绕这几个重要功能，Eureka设计了几个核心操作类，其中LeaseManager和LookupService是Eureka关于服务发现相关操作定义的接口类，前者定义了服务写操作相关的方法，后者定义了查询操作相关的方法，其中LeaseManager中定义了应用实例在服务中心的几个操作方法：register、cancel、renew和evict，LookupService则定义了Client从服务中心获取服务实例的查询方法。
五、Eureka的设计理念
作为一个服务注册、服务发现中心，Eureka主要解决以下几个问题：
1 服务实例如何注册到服务中心
在Client服务启动的时候，需要调用Eureka的Rest API 的 register方法，去注册该应用实例的信息。
2 服务实例如何从服务中心删除
正常情况下服务实例在关闭应用的时候，应该通过钩子方法或其他生命周期回调方法去调用Eureka Server的 Rest API 的 de-register方法，来删除自身服务实例的信息。另外为了解决服务实例挂掉或其他异常情况没有及时删除自身信息的问题，Eureka Server 要求 Client端定时进行续租，也就是发送心跳，来证明该服务实例还活着，并且可以健康的提供服务。如果超过租期一定时间后还没有续租的话，Eureka Server端会主动剔除，这是典型的心跳模式场景。
3 服务实例信息的一致性问题
下面主要从三·个方面来阐述Eureka Server集群如何保持一致性：
3.1 AP 优于 CP
分布式系统的设计都是在AP和CP之间进行选择，Eureka的设计者认为，大规模集群条件下，失败是不可避免的，无论什么原因，都不能回避这个问题，要面对这个问题，就需要在网络分区的时候，还能够正常提供服务注册、服务发现功能，因此Eureka选择了AP。其实在实际生产环境中，注册中心保留可用及过期的数据总比丢失掉可用的数据好。所以，应用实例的注册信息在集群的所有节点间并不是强一致的，这就需要客户端能够支持负载均衡及失败重试。在Netflix生态中，由ribbon提供这个功能。
3.2 Peer to Peer 架构
一般而言，分布式系统的数据在多个副本之间的复制方式，可分为主从复制和对等复制。
主从复制也就是Master-Slave模式，即有一个主副本、其他副本为从副本。所有对数据的写操作都是先提交到主副本、然后主副本再更新到从副本。具体更新方式有同步、异步、同步异步混合。对于主从模式来讲，最大问题在于写操作的压力都在主副本上，它是整个系统的瓶颈，但是从副本可以帮助主副本分担读请求。
对等复制即Peer to Peer的模式，副本之间不分主从，任何副本都可以接收写操作，然后每个副本之间相互进行数据更新。对于对等复制模式来讲，由于任何副本都可以接收写操作请求，所以不存在写操作压力的瓶颈。但是由于每个副本都可以进行写操作处理，各个副本之间的数据同步及冲突处理是一个比较棘手的问题。Eureka 采用的就是P2P复制模式，我们从客户端和服务端两个角度来阐述。
3.2.1 客户端
客户端使用quarantineSet维护了一个不可用的Eureka Server列表，进行重试的时候，会优先从可用的列表中进行选择，如果请求失败则切换到下一个Eureka Server进行重试，默认重试次数是3次。
另外为了防止每个Client端都按配置文件指定的顺序进行请求造成Eureka Server节点请求不均衡，Client端有个定时任务（默认5分钟一次）来刷新并随机化Eureka Server可用列表。
3.2.2 服务端
当集群中的单个Eureka Server启动的时候，会有一个syncUp的操作，通过Eureka Client请求其他Eureka Server节点中的一个节点来获取注册的应用实例信息，然后复制到其它Peer节点。
Eureka Server在进行复制操作的时候，使用HEADER_REPLICATION的http_header来将整个请求操作与普通应用实例的正常请求操作区分开来。通过HEADER_REPLICATION 来标识是复制请求，这样其它节点接收到请求的时候，就不会再对它的Peer节点进行复制操作，从而避免死循环。
由于采用了P2P复制模式，其重点要解决的另外一个问题就是数据复制冲突的问题。这蒙迪欧这几个问头，Eureka采用两个方式来解决：lastDirtyTimestamp标识 和 heartbeat
首先Eureka Server默认开启了SyncWhenTimestampDiffers配置，如果请求参数的lastDirtyTimestamp 值 大于 Server本地实例的lastDirtyTimestamp值，那就标识Eureka Server之间的数据有冲突，返回404，要求应用实例重新进行register操作。如果请求参数的 lastDirtyTimestamp 值 小于 Server本地实例的 lastDirtyTimestamp值， 如果是peer节点的复制请求，则表示数据出现冲突，返回409给peer节点，要求其同步自己最新的数据信息。
其次peer节点之间的相互复制也不能保证所有操作都能成功，因此Eureka还通过应用实例与Server之间的heartbeat也就是renewLease操作来进行数据的最终修复，即如果发现应用实例数据与某个Server的数据出现不一致，则Server返回404，告知应用实例重新进行register操作。
3.2.3 SELF PRESERVATION
在分布式系统设计中，通常需要对应用实例的存活进行检查，这里比较关键的问题就是要处理好网络偶尔抖动或短暂不可用时造成的误判。另外Eureka Server端与Client端之间如果出现网络区分问题，在极端情况下可能会使得Eureka Server清空部分服务的实例列表，造成不可用性。所以Eureka引入了SELF PRESERVATION。
Eureka的Client端与Server端有个租约，Client端要定时发送心跳到Server端，来维持这个租约，告知Server端自己仍然健康的活着。Eureka通过当前注册的实例数，去计算每分钟应该从应用实例接收到的心跳数，如果最近一分钟接收到的续约的次数小于等于指定阈值的话，则关闭租约失效剔除，进制定时任务删除失效的实例，从而保护注册信息。
