SpringCloud-Eureka（一）

系列文章目录

springCloud实践
springCloud实践之浅谈Feign原理
springCloud-Eureka（一）
springCloud-Eureka—服务注册与服务续约（二）
springCloud-Eureka—服务同步与剔除（三）

---

    微服务架构中最核心的部分是服务治理,服务治理最基础的组件是注册中心，随着微服务架构的发展，出现了很多微服务架构的解决方案，其中包括我们熟知的dubbo和spring cloud。
    注册中心，dubbo支持了zookeeper、redis、multicast和simple，官方推荐zookeeper，spring cloud支持zookeeper、consul和eureka，官方推荐eureka。

两者之所以推荐不同的实现方式，原因是组件的特点和所适用的场景不同：
    zk的设计原则是CP，即强一致性和分区容错性。它保证数据的强一致性，舍弃了可用性，如果出现网络问题可能会影响zk的选举，，导致zk注册中心不可用。
    eureka的设计原则是AP，即可用性和分区容错性，它保证了注册中心的可用性，但舍弃了数据一致性，各服务器的数据可能是不一致的（但会最终一致）。

	Zookeeper	Eureka
设计原则	CP	AP
优点	数据强一致	服务高可用
缺点	网络分区会影响Leader选举，超过阈值后集群不可用	服务节点间的数据可能不一致；Client Server间的数据可能不一致
适用场景	单机房集群，对数据一致性要求较高	云机房集群，跨越多个机房部署，对注册中心服务可用性要求较高

    eureka除实现了注册中心的基本服务注册和发现外，极大的满足注册中心的可用性，即使只有一台服务可用，也可以保证注册中心的可用性。

数据存储结构

既然是服务注册中心，必然需要存储服务相关的信息，我们知道zk的存储结构是树形节点上，而eureka是这样存储的


Eureka数据存储分为两层：数据存储层和缓存层。Eureka Client在拉取服务信息时，先从缓存层获取，如果获取不到，先把数据存储层的数据加载到缓存层，再从缓存中获取。
注意：数据存储层的数据结构是服务信息，而缓存中保存的是经过处理的，可直接传输到Eureka Client的数据结构。

    Eureka这样的数据结构设计是把内部的数据存储结构与对外的数据结构隔离开了，就像我们平时设计接口一样，对外输出的数据结构和数据库中的数据结构往往是不一样的。

数据存储层

为什么说存储层不是持久层呢？因为registry本质上是一个双层的ConcurrentHashMap，是存储在内存中的。
    第一层的key是服务的名称，value是第二层ConcurrentHashMap；
    第二层ConcurrentHashMap的key是服务的Instanceid，value是Lease对象
Lease对象包含了服务详情和服务治理相关属性。

二级缓存层

Eureka实现了二级缓存来存储即将要对外传输的服务信息。
一级缓存：ConcurrentHashMap<key,value> readOnlyCacheMap，本质上是HashMap，无过期时间，保存服务信息和对外传输数据结构。
二级缓存：Loading<key,value> readWriteCacheMap，本质上是guava的缓存，包含失效机制，保存服务信息的对外输出数据结构。

既然是缓存，必然要有更新机制，来保证数据一致性，下面是缓存的更新机制：

更新机制包含删除和加载两部分，黑色箭头表示删除操作，绿色表示加载或触发加载的操作；

删除二级缓存

1. Eureka Client发送register、renew和cancel请求并更新registry注册表之后，删除二级缓存；
2. Eureka Server自身的Evict Task剔除服务后，删除二级缓存；
3. 二级缓存本身设置了guava的失效机制，隔一段时间后自动失效。

加载二级缓存

1. Eureka Client发送getRegistry请求后，如果二级缓存中没有，就会触发guava的load，即从registry中获取原始服务信息后进行加工处理，并加载到二级缓存中；
2. Eureka Server更新一级缓存的时候，如果二级缓存中没有数据，也会触发guava的load。

更新一级缓存

1. Eureka Server内置了一个TimerTask，定时将二级缓存中的数据同步到一级缓存中（包含删除和加载）

缓存的实现参考ResponseCacheImpl

Eureka架构

这是从网上摘的一个多机房部署的架构图

组件调用关系：
    服务提供者：

1. 启动后，像注册中心发起register请求，注册服务；
2. 在运行过程中，定时向注册中心发送renew心跳，证明“我还活着”；
3. 停止服务提供者，向注册中心发送cancel请求，清空当前服务注册信息。

    服务消费者：

1. 启动后，从注册中心拉取服务注册信息；
2. 在运行过程中，定时更新服务注册信息；
3. 服务消费者发送远程调用：
         a.服务消费者(北京)会从服务注册信息中选择同机房的服务提供者(北京)发起远程调用。只有同机房的服务挂掉之后才选择其他机房的服务提供者(青岛)
         b.服务消费者(天津)因为同机房没有部署服务提供者，则会按照负载均衡算法选择北京或者青岛的服务提供者，发起远程调用。

    注册中心：

1. 启动后，从其他节点拉取服务注册信息；
2. 在运行过程中，定时运行evict任务，剔除没有按时renew的服务（包括非正常停止和网络故障的服务）
3. 在运行过程中，接收的register、renew、cancel请求，都会同步至其他注册中心节点；

后文中我们会将从eureka的内部实现原理，从微服务架构部署图来介绍eureka的总体架构，然后剖析服务信息的存储结构，后续探究服务生命周期相关的服务注册、服务续约、服务注销、服务剔除、服务获取、服务同步机制。