关于Eureka的自我保护模式

Eureka客户试图在同一区域与Eureka服务器进行对话。
如果存在与服务器对话的问题,或者服务器在同一区域中不存在,则客户端会在其他区域的服务器上失败。

一旦服务器开始接收流量,在服务器上执行的所有操作都将被复制到服务器所知道的所有节点节点。
如果某个操作由于某种原因失败了,那么该信息将在下一次在服务器之间复制的heartbeat上进行协调。

当Eureka服务器出现时,它试图从相邻节点获取所有实例注册信息。
如果从节点获取信息有问题,服务器在放弃之前尝试所有的节点。
如果服务器能够成功地获得所有实例,它将根据该信息设置它应该接收的更新阈值。
如果任何时候,更新都低于为该值配置的百分比(在15分钟内低于85%),服务器停止过期实例以保护当前实例注册表信息。

在Netflix上,上述保障被称为“自我保护模式”,它主要用于在一组客户端和Eureka服务器之间存在网络划分的场景中作为一种保护。
在这些场景中,服务器试图保护它已经拥有的信息。
可能出现大规模中断的情况,这可能导致客户端获得不再存在的实例。
客户端必须确保他们对eureka服务器返回一个不存在或没有响应的实例有弹性。
在这些场景中,最好的保护是快速超时并尝试其他服务器。

在这种情况下,服务器无法从邻近节点获得注册表信息,它等待几分钟(5分钟),以便客户端可以注册他们的信息。
服务器努力不向客户端提供部分信息,只向一组实例倾斜流量并造成容量问题。
Eureka服务器使用Eureka客户端和服务器之间使用的相同机制进行通信。
同样值得注意的是,有几种配置可以在服务器上进行调整,包括在需要时服务器之间的通信。

在对等网络中断的情况下,可能会发生以下情况:
对等点之间的心跳复制可能失败,服务器检测到这种情况,并进入保护当前状态的自我保护模式。
在孤立的服务器中可能会发生注册,一些客户可能会反映新的注册,而其他的可能不会。
在网络连接恢复到稳定状态后,情况自动更正。当对等点能够进行良好的通信时,注册信息就会自动转移到没有它们的服务器上。
底线是,在网络中断期间,服务器试图尽可能地恢复弹性,但在此期间客户可能会有不同的服务器视图。
原文地址:https://github.com/Netflix/eureka/wiki/Understanding-Eureka-Peer-to-Peer-Communication

猜你喜欢

转载自blog.csdn.net/pp_fzp/article/details/78831716
今日推荐