一、流程图
二、客户端Client
- 服务启动，经过一系列的配置加载（过程参考）之后会实例化DiscoveryClient对象，在其构造方法中创建定时任务initScheduledTasks()，进行服务信息列表拉取和服务续约（eureka.client.registerWithEureka=true）
服务续约（HeartbeatThread）：发送心跳request，请求eureka server 端 ，如果接口返回值为404，就是说注册中心不存在该服务，则走注册流程Registry。默认是30s（eureka.instance.lease-renewal-interval-in-seconds）发送一次心跳
服务信息拉取（CacheRefreshThread）：调用fetchRegistry()，根据条件判断，进行全量或增量拉取Eureka服务端信息并缓存到本地（分别调用getAndStoreFullRegistry()或getAndUpdateDelta()方法）。默认是30s（eureka.client.registry-fetch-interval-seconds）拉取一次服务注册信息
- 服务注册，通过http rest请求eureka server端，把应用自身的InstanceInfo实例注册给server端
InstanceInfo（com.netflix.appinfo.InstanceInfo）核心属性
1.instanceId：实例id。在同一个应用appName的范围内是必须是惟一的
2.appName：应用名。如USER_SERVER（同一应用可以有N多个实例）
3.ipAddr：本实例的ip地址。如ipAddr=192.168.1.100
4.port：端口号。默认值是7001
5.healthCheckUrl：健康检查的URL（Rest）。如http://localhost:8080/actuator/health
6.leaseInfo：一个com.netflix.appinfo.LeaseInfo对象，表示续约相关信息
7.metadata：自定义元数据，可以是任何k-v
8.lastUpdatedTimestamp：上次修改时间
- 服务下线，及时通知服务端把自己剔除
调用cancelScheduledTasks()关闭各种定时任务，如续约、信息拉取等，同时向Eureka Server端发送下线请求
三、服务端Server
- 服务启动
经过一系列的配置加载（过程参考）之后会实例化EurekaServerBootstrap对象，该对象初始化方法中会创建一个定时任务来更新集群节点信息
检测集群中各个Server节点的可用性，进行不可用节点剔除和可用节点新建。定期更新频率默认值为10分钟，可以通过eureka.server.peerEurekaNodesUpdateIntervalMs配置）
集群原理
配置集群必须不同ip
相互之间不区分主节点和从节点，所有节点都是平等，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务
server也是client，所以几个server组成集群，要彼此互相注册
Client 在向某个 Eureka 注册时，如果发现连接失败，则会自动切换至其它节点。只要有一台 Eureka Server 还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。从这里可以看出client只会选择一个server进行注册，注册后由server根据配置中集群的信息用同样的方式注册到其他server上。
Client启动后注册一个server，之后如果这个Eureka Server挂了，才会切换Eureka Server，在当前使用的Eureka Server挂掉之前，不会切换
调用EurekaServerBootstrap类的contextInitialized()方法进行Eureka服务的初始化
初始化Eureka的环境变量（initEurekaEnvironment）
初始化Eureka的上下文（initEurekaServerContext），包括集群中同步相邻节点上的注册信息，开启一个定时任务，将没有续约的客户端服务实例（默认90秒没有续约ureka.instance.lease-expiration-duration-in-seconds）清理掉
- 服务注册
Eureka注册中心有一个Map来保存所有的服务及映射的机器信息：
private final ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>> registry = new ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>>();
- 服务注册时，会把服务的信息写到这个registry中
- 服务从治理中心拉取服务列表信息时，不会从这个registry中拉取，而是从一个ResponseCache中拉取，这样读写分离的原因应该是为了支持高并发。
为了提高Eureka Server注册中心的性能，Eureka Server提供了二级缓存机制，将服务注册信息保存在二级缓存中（eureka.server.shouldUseReadOnlyResponseCache = true）。
第一层缓存：readOnlyCacheMap，数据是从ReadWriteMap来的，当服务需要获取服务列表是，会直接取这个ReadOnlyMap的数据，当这个数据不存在时，才会从ReadWriteMap中更新。
第二层缓存：readWriteCacheMap，数据是从registry中来的，可以认为是registry的缓存，当服务注册时，除了把信息写到registry中外，还会让ReadWriteMap主动过期，使得会去从registry重新拉取数据
ReadWriteMap与registry的数据是实时一致的，但是ReadWriteMap与ReadOnlyMap不是实时一致的，而是通过TimerTask定时（eureka.server.responsecCacheUpdateIntervalMs，默认30S）将readWriteCacheMap同步到readOnlyCacheMap
- 数据同步
当我们启动一个客户端时，会调用PeerAwareInstanceRegistryImpl.register() 进行服务的注册，并调用replicateToPeers()方法复制给其他节点
当我关闭客户端服务时，则会进入cancel() 方法，进行服务的关闭，同时进行服务状态列表的更新以及各节点的注册信息同步
通过互相同步数据来做到数据同步，异步同步，达到最终一致。
当自己的节点发生变化就会同步，A-B-C同步过程如下：
如果client注册到A，A的节点就发生了变化，A会同步(这里不是像数据库一样的通过log之类的做同步，而是A中的client通过相同的方式注册到B和C)到B和C，此时B、C的节点也变化了，但是是因为A同步过来导致的变化，所以B、C不会再同步给其他
区别：Client-A: Header信息中isReplication=true, A-BC: isReplication=false，防止循环复制
