1.Euraka的注册原理
1.首先在应用启动时，系统会读取Euraka的相关配置，从而加载Euraka所配置的相关信息，以保证后续注册使用。
2.接着去加载自身配置信息，并且封装成Euraka客户端实例，并且将此实例发送给Euraka服务端。
3.然后获取Euraka服务端的注册信息，缓存至本地服务中。
4.最后将自身实例注册到Euraka注册中心内。
5.从上一步结束其实就已经是Euraka的注册流程了，但是成功注册之后，还会存在一个续约的情况，因为客户端和服务端需要频繁去获知对方是否可用；这里就牵扯到Euraka的服务续约功能了。
6.Euraka客户端还会定时的获取Euraka注册中心的注册信息，以保证本地注册信息与服务端一致度；这里就是获取注册信息功能了。
7.当Euraka客户端需要销毁当前实例时，需要执行内部代码块方可在Euraka注册中心内进行消除；这里说的就是服务下线功能。
8.在发生状况下，当服务提供方连续一段时间（这个时间默认是90s，但是可以自行设置）没有向注册中心进行续约操作时，注册中心会将该服务从服务注册列表中剔除；这里就是服务剔除功能。
服务注册
Euraka客户端向Euraka注册中心提供ip、port等一系列基础信息，以注册至注册中心。
服务续约
Euraka提供了一个心跳监测的功能，Euraka客户端通过定期的心跳时间，与注册中心进行一个续约操作，这个时间默认为30s，Euraka也提供了相关的配置项来供开发者配置。
服务剔除
若超过90s时间没有进行续约操作，则注册中心不会再保存Euraka客户端的相关信息，会进行一个剔除操作。时间默认为90s，Euraka也提供了相关的配置项来供开发者配置。
服务下线
Euraka客户端在程序关闭时向注册中心发起服务下线操作，注册中心接到通知，会将其所有信息删除，但是这个服务下线操作需要开发者自行编写代码进行调用。
获取注册信息
获取注册信息就比较好理解了，Euraka各实例都会在需要的时候想注册中心发起请求，注册中心也会反馈给实例当前所有的注册信息。
2.自我保护机制
自我保护模式正是一种针对网络异常波动时的安全保护措施，使用自我保护模式能使Eureka集群更加健壮稳定的运行。
自我保护模式的工作机制
如果15分钟内超过85%的客户端节点都没有正常的心跳，那么Eureka Server就会认为客户端与注册中心发生了网络故障，Eureka Server进入自我保护机制。
自我保护机制的缺点
如果在自我保护机制中，刚好某些服务节点非正常下线，但是Eureka Server并不会剔除该服务节点，服务消费者就会获取到一个无效的服务实例。
解决方案
① ：关闭自我保护机制(不推荐)
② ：切换请求或断路器，使用负载均衡的方式，设置当一个请求超过多少秒还未得到响应，速度切换请求到下一个注册服务，例如使用Ribbon+Hystrix配置负载均衡和断路器。
Eureka Server 进入自我保护机制后
1、Eureka Server不在从注册表中剔除因为长时间没有和注册中心续约的服务节点
2、Eureka Server仍然能够接受新服务的注册和查询请求，但是不会同步到其他Eureka Server节点上
3、网络正常后，当前Eureka Server节点会将新的服务节点信息同步到其他Eureka Server节点上
解除自我保护机制
1.当服务的网络分区故障解除之后，客户端能够和服务进行交互时，在续约的时候，更新每分钟的续约数，当每分钟的续约数大于85%时，则自动解除。
2.重启服务
3.Eureka 的多级缓存机制
Eureka Server 为了避免同事读取内存数据造成的并发冲突问题，采用了多级缓存机制提升服务请求的响应速度。
Eureka Server的缓存是通过一个只读，一个读写缓存来实现的。
一级缓存：concurrentHashMap<key,value>readOnlyCacheMap本质是HashMap，无过期时间，保存数据信息对外输出。readOnlyCacheMap依赖于定时器的更新，通过与readWriteCacheMap的值做对比，以readWriteCacheMap为准。readOnlyCacheMap缓存更新间隔，默认30s
二级缓存：LoaDing<key,value>readWriteCacheMap本质是Guava缓存，包含失效机制，保护数据信息对外输出。readWriteCacheMap 缓存过期时间，默认180s。
当服务节点发生注册，下线，过期，状态变更等变化时
1.在内存中更新注册表信息
2.同时过期掉readWriteCacheMap缓存，缓存清除只是会去清除readWriteCacheMap这个缓存， readOnlyCacheMap 只读 缓存并没有更新，也就说当客户端的信息发生变化之后， 只读缓存不是第一时间感知到的。只读缓存的更新只能依赖那个30秒的定时任务来更新。
3.一段时间后（默认30s），后台线程发现readWriteCacheMap缓存为空，于是也将readOnlyCacheMap中的缓存清空
4.当有服务消费者拉取注册表信息时，会调用ClassLoader的load方法，将内存中的注册表信息加载到各级缓存中，并返回注册表信息。
在Eureka Server 中会有两个线程，一个是定时同步两个缓存的数据，默认30s，一个是定时检测心跳故障，默认90s。
服务拉取
1.服务消费者，默认每30s，拉取注册表信息
2.从readOnlyCacheMap中获取信息，如果获取为空
3.从readWriteCacheMap中获取，如果还是为空
4.调用ClassLoader的load方法，将内存中的注册表信息加载到各级缓存中，并返回注册表信息。
4.集群怎么保持数据一致
对等复制
就是 Peer to Peer 模式，副本间不分主从，任何副本都可以接收写操作，然后每个副本间互相进行数据更新。
对等复制模式，任何副本都可以接收写请求，不存在写压力瓶颈，但各个副本间数据同步时可能产生数据冲突。
同步过程
1.Eureka Server 本身依赖了 Eureka Client，也就是每个 Eureka Server 是作为其他 Eureka Server 的 Client。
2.Eureka Server 启动后，会通过 Eureka Client 请求其他 Eureka Server 节点中的一个节点，获取注册的服务信息，然后复制到其他 peer 节点。
3.Eureka Server 每当自己的信息变更后，例如 Client 向自己发起注册、续约、注销请求， 就会把自己的最新信息通知给其他 Eureka Server，保持数据同步。
避免死循环
Eureka Server 在执行复制操作的时候，使用 HEADER_REPLICATION 这个 http header 来区分普通应用实例的正常请求，说明这是一个复制请求，这样其他 peer 节点收到请求时，就不会再对其进行复制操作，从而避免死循环。
数据冲突
还有一个问题，就是数据冲突，比如 server A 向 server B 发起同步请求，如果 A 的数据比 B 的还旧，B 不可能接受 A 的数据，那么 B 是如何知道 A 的数据是旧的呢？这时 A 又应该怎么办呢？
数据的新旧一般是通过版本号来定义的，Eureka 是通过 lastDirtyTimestamp 这个类似版本号的属性来实现的。
lastDirtyTimestamp 是注册中心里面服务实例的一个属性，表示此服务实例最近一次变更时间。
最终修复
hearbeat 心跳，即续约操作，来进行数据的最终修复，因为节点间的复制可能会出错，通过心跳就可以发现错误，进行弥补。
例如发现某个应用实例数据与某个server不一致，则server放回404，实例重新注册即可。