小学生也能看懂的微服务节点判活难题-CSDN博客

那你首先，了解注册中心摘除机制吗？

【服务Consumer】以【注册中心】的数据为准，当服务端的节点有变更时，【注册中心】会将变更通知给【Consumer】，【Consumer】就调用【注册中心】拉取最新节点信息。

这种机制一般也够用了，但当网络频繁抖动时，【服务Provider】向【注册中心】汇报心跳信息可能失败。若在规定时间内，【注册中心】都未收到【Provider】的心跳信息，就会把该节点从可用节点列表中移除。

更糟的是，在服务池拥有上百个节点时，每个节点都可能会被移除，导致【注册中心】可用节点的状态一直在变化，这该如何解决？

可考虑心跳开关保护机制。

在网络频繁抖动时，【注册中心】的可用节点不断变化，【Consumer】会频繁收到【Provider】节点变更信息，于是不断请求【注册中心】。
当很多【Consumer】同时请求【注册中心】，很容易把【注册中心】带宽打满。

所以需要措施保证，即使网络频繁抖动，【Consumer】也不至于同时请求【注册中心】。

就是给【注册中心】设置一个开关。
开关打开时，即使网络频繁抖动，【注册中心】也不会通知所有【Consumer】，比如只通知10%的【Consumer】，降低注册中心需要处理的请求量。

那这种方案有什么问题吗？

技术都是有利有弊的，开关的代价就是会导致【Consumer】感知最新服务节点信息延迟。所以应该作为一个紧急措施，在网络频繁抖动时，才打开开关。

综上，该机制是为避免【Provider】节点频繁变更，而导致【Consumer】同时请求【注册中心】。

那还有别的方案吗？

是的，还有服务节点摘除保护机制。
【Provider】在进程启动时，会注册服务到【注册中心】，并每隔一段时间，汇报心跳给【注册中心】，通知自己的存活状态。
若隔了一段固定时间后，【Provider】仍没有汇报心跳给【注册中心】，【注册中心】就会认为该节点已死，将其从可用节点中移除。

若遇到网络问题，大批【Provider】节点汇报给【注册中心】的心跳信息都可能会传达失败，【注册中心】就会把它们都从可用节点列表中移除，造成剩下可用节点难以承受所有调用，引起“雪崩”。但这种情况下，可能大部分【Provider】节点是可用的，仅因为网络原因无法汇报心跳给【注册中心】就被“无情”摘除。

这就需要根据实际业务，设定一个阈值比例，即使网络抖动，【注册中心】也不能摘除超过这个阈值比例的节点。通常设定在20%。因为绝大部分时间，节点变化也不会变化频繁，只有在如下情况才可能发生：

业务明确要下线大批节点
这种情况可预知，所以可以关闭阈值保护
网络抖动
一般正常时，应打开阈值保护，以防网络抖动时，大批量可用服务节点被摘除

综上，该机制是为避免【Provider】节点被大量摘除，而导致【Consumer】可调用节点不足。

所以这两种机制，都是因为【注册中心】的节点信息瞬息万变，所以也经常把【注册中心】称为【动态注册中心】。

我开始疑惑了，那是否能另辟蹊径，【Consumer】并不严格以【注册中心】中的服务节点信息为准，而是更多的以【Consumer】实际调用信息来判断【Provider】是否可用呢？

有的，这就是静态注册中心。
心跳机制能保证在【Provider】异常时，【注册中心】可以及时把不可用的【Provider】从可用节点列表中移除，这很好。
但仔细思考，为何不把这种心跳机制直接用在【Consumer】？

因为【Provider】是向【Consumer】提供服务，是否可用【Consumer】比【注册中心】更清楚，因此可直接在【Consumer】端根据调用【Provider】是否成功，以判定【Provider】是否可用。
若【Consumer】调用某一【Provider】连续失败超过一定次数，可在本地内存将该节点标记为不可用。
每隔一段固定时间，【Consumer】向标记为不可用的节点发起保活探测，若探测成功，就将标记为不可用的节点再恢复为可用态，重新发起调用。

这样【Provider】无需再向【注册中心】心跳汇报，【注册中心】中的服务节点信息也不会动态变化，这就是【静态注册中心】。

很多公司也是一开始采用动态注册中心，后来考虑到网络的复杂性，心跳机制不一定可靠，而后开始改为采用服务消费者端的保活机制，事实证明这种机制足以应对网络频繁抖动等复杂场景。

【静态注册中心】中的服务节点信息并不是一直不变，当在