导航菜单
路很长,又很短
博主信息
昵   称:Cocodroid ->关于我
Q     Q:2531075716
博文数:327
阅读量:979512
访问量:102853
至今:
×
云标签 标签球>>
云标签 - Su的技术博客
博文->>首页 博主的更多博文>>
Eureka源码剖析之七:总结
Tags : Eureka,源码发表时间: 2020-01-31 14:16:10
原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。
比如: 转自:Su的技术博客  原文地址:
点击上方蓝色字关注我们~

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

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

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

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

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

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

〓一、Eureka系统架构交互图

来自网上更详细的图:

〓二、定时任务汇总
客户端定时任务

1)每30秒刷新缓存(服务拉取)
2)每30秒发送心跳(服务续约)

服务端定时任务

1)每10分钟更新集群节点数据
2)每15分钟更新续约数及阈值
3)每1分钟剔除过期注册信息

〓三、常见(面试)问题汇总
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



推荐阅读




打赏
打赏
关注公众号
公众号
类别:源码| 阅读(106)| 赞 (0)
评论
暂无评论!
发表评论
昵  称:

验证码:

内  容:

    同时赞一个 赞