Eureka源码剖析之七：架构&面试题【总结】

源码剖析目录：

Eureka源码剖析之一：初始化-启动

Eureka源码剖析之二：服务注册

Eureka源码剖析之三： 服务拉取

Eureka源码剖析之四： 服务续约

Eureka源码剖析之五： 服务下线

Eureka源码剖析之六： 自我保护机制

总结下eureka系统架构和相关面试题。

〓一、定时任务汇总

客户端定时任务

1）每30秒刷新缓存（服务拉取）

2）每30秒发送心跳（服务续约）

服务端定时任务

1）每10分钟更新集群节点数据

2）每15分钟更新续约数及阈值

3）每1分钟剔除过期注册信息

〓二、Eureka系统架构交互图

来自网上更详细的图：

〓三、常见（面试）问题汇总

1、Server节点能否在配置文件里配置自身的Server地址？

可以的！当一个Server解析配置的集群地址时，会过滤掉自身的地址，这样服务同步时就不需要同步自身了。我们配置多个Server时，不需要手动的排除Server自身的发现地址。

2、Server是否配置registerWithEureka和fetchRegistry有什么区别？

其实每一个Eureka Server Node都内置了一个Eureka Client，也就是说一个Server Node节点可以接受其他Client的注册，也可以作为一个Client注册到其他Server上，被其他Client发现和调用。Server Node上的Server和Client可以理解为两个容器，他们仅仅在初始化时打交道，之后就没有什么关联了。

registerWithEureka和fetchRegistry的默认值都是true，他们都是客户端配置，也就是eureka.client开头的配置信息。

通过上述说明就很好理解这两个参数设置与否的区别了：

registerWithEureka：是否要注册到其他Server上。如果我的Server上其实开放了一些Http接口供调用，那么就需要注册，这样其他的Client才能发现我的服务，才能通过RPC调用我提供的Http接口。如果我的Server没有提供对外Http接口，那么这个参数可以设置为false。

fetchRegistry：是否需要拉取服务信息。和是否注册一样，如果我的Server需要调用其他的Client的Http接口，那么就需要获取相应的服务发现信息，这样才能正常的调用。同时这个参数还有一个重要的作用，就是决定Server在初始化时是否立即全量同步其他节点的服务信息！！！Server初始化时会先初始化其内置的Client。若配置了fetchRegistry=true，那么Client在初始化时会从其他Server全量拉取服务信息，放进Client容器中。Server在初始化时会尝试同步Client容器里的服务信息，如果fetchRegistry=false，服务信息不存在，只能被动的等其他Server节点以增量的形式同步过来(Client在执行注册和心跳时对应的注册Server节点会广播此事件，同步给其他的Server节点。当其他Server节点还没有此服务信息时，改为注册此服务信息)。当然正常的通过心跳来同步，最多也仅需要30S而已，是否需要设置此参数就看各自的需求了。

3、Server和Client节点配置全部的Server地址和部分Server地址有什么区别？

Client在与Server交互时，只会与其中的一个Server进行交互。

Server之间的数据同步和Server与Client间的数据交互使用的是同一个Http接口，比如注册，心跳，状态更新，关闭服务等等。只是Server与Server之间同步时，会有一个Header参数，x-netflix-discovery-replication = true ,Server通过这个标识来判断当前请求是来自Server还是来自Client。如果 x-netflix-discovery-replication不存在，则指明请求来自Client，Server在处理此请求时还会将请求广播给配置上的其他Server节点，在广播请求时，Header带上x-netflix-discovery-replication=true。当其他Server节点接受到此请求时，通过此Header参数判断是一个Server同步请求，因此只处理此请求，而不再广播。Server之间的数据同步只传播一次！

4、Server回收服务信息的自我保护机制是什么？需要注意什么？

Server每隔60S执行一次服务信息回收，移除那些心跳时间超时的。能够回收有3个前提：

1）心跳信息超时，也就是回收时间距离上次心跳时间超过90S。

2）开启了租约过期功能，默认是开启的。

3）未触发自我保护机制。所谓的自我保护机制，指的是上一分钟内，服务实际发送心跳的总数超过预计总数的85%，可能近似理解为正常存活的Client超过85%。

需要注意些什么？如果你的Client个数较少，比如就5个，或者说同一个Server对应的Client就5个，那么当其中的一个宕机了，1/5=20%，直接就触发了自我保护机制，宕机的服务信息会一直存在，不会被回收。对于这种情况，可以设置Server触发自我保护机制的临界值，renewalPercentThreshold = 0.85，默认是85%，可以修改成适当的值，比如0.5。

5、Server节点间的服务信息同步的流程是怎么样的？

Server在初始化时，会根据配置信息生成与其他的Server同步的客户端。每当Server接收到Client的服务请求时，会先处理请求，然后将自身作为一个Client的角色，用相同的请求信息去请求配置里的那些Server节点。会将同步请求封装成一个Task，然后存入一个Queue中，Server定时的提取Queue里的任务，批量的处理它们。

也就是说Server之间的服务同步是异步执行的，而不像Zookeeper一样，每个操作都需要过半数的节点执行成功后才返回给Client。同时Server之间的同步只会传播一次，它们通过Header里的一个参数来表明是来自Client的请求还是Server的请求。如果是Server的请求，那么接收到此请求后不会再进行传播。

6、Eureka服务注册到发现最长需要多长时间？

最长需要2分钟。30秒：服务端响应缓存ResponseCache；30秒：Client缓存；30秒：Ribbon缓存，30秒：客户端启动心跳请求时注册（新版已优化可以启动马上注册）。

7、Eureka Server如何应对并发请求？

每分钟拉取服务2次，每分钟心跳请求2次，即每分钟会有4次请求。如果有2000个服务，那么每分钟就有8000次请求，即每秒有133次请求，约每分钟有150次。Eureka Server的应对方式是：①对注册表操作使用读写锁优化；②注册表的多级缓存机制。

参考资料

https://blog.csdn.net/qq_17164811/article/details/94773607

http://www.majunwei.com/view/201808131015366640.html

https://www.cnblogs.com/xishuai/p/spring-cloud-eureka-safe.html

https://blog.csdn.net/qq_38289534/article/details/82146939