一、流程图
二、客户端Client
- 服务启动，经过一系列的配置加载（过程参考）之后会实例化DiscoveryClient对象，在其构造方法中创建定时任务initScheduledTasks()，进行服务信息列表拉取和服务续约（eureka.client.registerWithEureka=true）
- 服务注册，通过http rest请求eureka server端，把应用自身的InstanceInfo实例注册给server端
- 服务下线，及时通知服务端把自己剔除
三、服务端Server
- 服务启动
经过一系列的配置加载（过程参考）之后会实例化EurekaServerBootstrap对象，该对象初始化方法中会创建一个定时任务来更新集群节点信息
调用EurekaServerBootstrap类的contextInitialized()方法进行Eureka服务的初始化
- 服务注册
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() 方法，进行服务的关闭，同时进行服务状态列表的更新以及各节点的注册信息同步
