Eureka

Netflix Eureka 是由Netflix开源的一款基于REST的服务发现组件，包括Eureka Server及Eureka Client。

服务实例如何注册到服务中心？

在服务启动的时候，需要调用Eureka Server 的REST API的register方法，去注册该应用实例的信息。对于 Spring Cloud 应用，可以使用spring-cloud-netflix-Eureka-client,基于Spring Boot的自动配置，自动实现服务信息的注册。

服务实例如何从服务中心剔除？

正常情况下服务实例在关闭应用的时候，应该通过钩子方法或其他生命周期回调方法去调用Eureka

Server的REST API的de-register方法，来删除自身服务实例的信息。另外为了解决服务实例挂掉或其他异常情况没有及时删除自身信息的问题，Eureka Server要求Client端进行续约，也就是发送心跳，来证明服务实例还是存活的，是健康的，是可以调用的。如果租约超过一定时间没有进行续约操作，Eureka Server端会主动剔除。

AP优于CP

分布式系统领域CAP理论

Consistency：数据一致性，即数据在存在多副本的情况下，可能由于网络，机器故障，软件系统等问题导致数据写入部分副本成功，部分副本失败，进而造成副本之间数据不一致，存在冲突。满足一致性要求则要求对数据的更新操作成功之后，多副本的数据保持一致。

Availability：在任何时候客户端对集群进行读写操作时，请求能够正常响应，即在一定的延时内完成。

Partition Tolerance：分区容忍性，即发生通信故障的时候，整个集群被分割为多个无法相互通信的分区时，集群仍然可用。

对于分布式系统来讲，一般网络条件相对不可控，出现网络分区是不可避免的，因此系统必须剧本分区容忍性。在这个前提下分布式系统的设计则在AP及CP之间进行选择。

Eureka是在部署在AWS的背景下设计的，在实际生产中，服务注册及发现中心保留可用及过期的数据总比丢失掉可用的数据好。这样的话，应用实例的注册信息在集群的所有节点间并不是强一致的，这就需要客户端能够支持复杂均衡及失败重试。

Peer to Peer架构

一般而言，分布式系统的数据在多个副本之间的复制方式，可分为主从复制和对等复制。

主从复制Master-Slave

有一个主副本，其他副本    为从副本。所有对数据的写操作都是提交到主副本，最后再由主副本更新到其他从副本。具体更新的方式还可以细分为同步更新异步更新，同步及异步混合。对于主从复制模式来讲，写操作的压力都在主副本上，它是整个系统的瓶颈，但是从副本可以帮主副本分担读请求。

对等复制Peer to Peer

副本之间不分主从，任何副本都可以接收写操作，然后每个副本之间互相进行数据更新。由于任何副本都可以进行写操作处理，各个副本之间的数据同步及冲突处理是一个比较棘手的问题。

Eureka Server采用的就是Peer to Peer 的复制模式。

客户端

客户端使用quarantineSet维护了一个不可用的Eureka Server列表，进行请求的时候，优先从可用的列表中进行选择，如果请求失败则切换到下一个Eureka Server进行重试，默认次数为3.。为了放置每个Client都按照配置文件进行请求造成Eureka Server节点请求分布不均衡的情况，Client端有个定时任务来刷新并随机化Eureka Server列表。

服务端

Eureka Server本身依赖了Eureka Client，也就是每个Eureka Server是作为其他Eureka Server的Client。在单个Eureka Server启动的时候，会有一个syncUp的操作，通过Eureka Client请求其他Eureka Server节点中的一个节点获取注册的应用实例信息，然后复制到其他peer节点。

Eureka Server在执行复制操作时，使用HEADER_REPLICATION的http header来将这个请求操作与普通应用实例的正常请求操作区分开。这样其他peer节点接收到请求的时候，就不会对它的peer节点进行复制，从而避免死循环。

Eureka高可用原理

Client端高可用

在Client启动之前，如果没有Eureka Server，则可通过配置Eureka.client.backup-registry-impl从备份registry读取关键服务的信息

]在client启动之后，若运行时出现Eureka Server全部挂掉的情况：本地内存有localRegion之前获取的数据，在Eureka Server都不可用的情况下，从Server端定时拉取注册信息回来更新的线程CacheRefreshThread会执行失败，本地localRegion信息不会被更新。

在client启动后，若运行时出现Eureka Server出现部分挂掉的情况，如果预计恢复时间比较长，可以人工介入，可以通过配置文件剔除掉挂掉的Eureka Server地址，Client端会定时刷新serviceUrI。除此之外，Client维护了一个Eureka Server的不可用列表，一旦请求发生Connection error或者5xx的情况则会被列入该列表，当该列表的大小超过指定阈值则会被重新清空。在重新清空的情况下，Client默认是采用RetryableEurekaHttpClient进行请求，numberOfRetries为3.因此也能够在一定程度保障Client的高可用。

Server端高可用

由于Eureka Server采用的是peer to peer的架构模式，因而也就无所谓Server端的高可用，主要的高可用都在Client端进行处理了。不过server端也支持了跨region基本的高可用，可以通过配置remoteRegionUrlsWithName来支持拉取远程region的实力信息。如果当期region要访问扥服务实例都挂了，那么Server端就会fallback到远程region的该服务实例