Spring Cloud系列 - Eureka架构篇
文章目录
一、前言
1. Poll vs Push
push方式：服务端主动将消息推送给客户端。
- 优点：消息的及时性比较好。
- 缺点：当客户端的消费能力远低于服务端生产能力时，会造成消息大量堆积，客户端处理缓慢，甚至造成服务崩溃。服务端需要维护每次传输状态，防止消息传递失败而需要重试。
poll方式：客户端从服务端拉取消息。
- 优点：客户端根据自己的消费能力从服务端拉取消息进行消费。传输失败，消息依旧保留在服务端中。
- 缺点：拉取消息的间隔如果过长，会导致数据滞后；如果过短，会导致对服务端的请求压力过大。
2. 服务端维护服务提供者的地址列表
服务端更容易做到如下两个方面：
- 服务上下线的动态感知。
- 维护服务调用者。
如果客户端来做这个事情的话，每个服务调用者本地都要存储对应的服务提供者的地址列表。如果说，多个服务之间调用比较复杂，那么客户端对于维护服务调用者的工作就会变得非常复杂。此外，对于的服务上下线，客户端的动态感知性较差。
二、源码解析
服务注册
1. EurekaAutoServiceRegistration
这个类本身实现SmartLifecycle接口（在Spring容器加载完所有的bean，并且初始化完成之后执行其关于生命周期的方法）
SmartLifecycle在Spring Boot中如何应用，这里不展开分析。
接下来重点关注EurekaAutoServiceRegistration这个类的start方法。
- 使用EurekaServiceRegistry注册一个EurekaRegistration实例。
- 发布一个InstanceRegisteredEvent事件。
- 对running属性设置为true。
2. EurekaServiceRegistry
接下来看下如何注册EurekaRegistration实例的。
- 可能会对CloudEurekaClient进行初始化。
- 设置实例状态。触发状态改变事件。
- 注册健康检查。
可能会对CloudEurekaClient进行初始化。
可能会对CloudEurekaClient进行初始化。
获取代理对象。
设置实例状态。触发状态改变事件。
注册健康检查。
取消上一次的调度更新。
调用InstanceInfoReplicator的run方法。
3. InstanceInfoReplicator
- 刷新本地缓存的InstanceInfo。
- DiscoveryClient注册InstanceInfo。
- 周期调度该run方法。
根据EurekaInstanceConfig信息更新本地缓存的InstanceInfo信息。
4. DiscoveryClient
注册InstanceInfo。
发起一个post调用。
5. ApplicationResource
（注：Application -> ApplicationResource）
6. PeerAwareInstanceRegistryImpl
- DEFAULT_DURATION_IN_SECS = 90。
同步数据到peer节点。
执行register的逻辑。
peer节点完成数据复制。
服务存储
7. AbstractInstanceRegistry
- registry:
ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>>类型。