17 | 如何识别服务节点是否存活？

感觉静态注册中心就完全去中心化了，没有中心的概念了，每个peer自己判断节点的死活，自己维护一套状态表，是这个意思吧？

你好，我们目前在上的新系统，使用的spring cloud微服务架构，目前刚刚计划改为eureka主动探测机制，目前没听过有设置保护机制，那么如果网络真出问题了，是不是很有可能出现您说的那个注册中心网络占满的问题？

只通知10%的用户，那么另外的90%的用户是让他们失败吗？还是后续会再次通知，只是分批次，每次通知10%，知道全部通知完毕？

应该以客服端为准，谁使用谁有发言权。 我觉得注册中心的主动心跳探测不应作为客户端摘除不可用服务端节点的依据，而是要作为参考值，比如将这种探测信息发给客户端，客户端在负载均衡时，将这种疑似问题节点降权重或作为备用节点，这样是不是比较好

相对于动态注册，静态注册的方式把探测任务分散到了服务消费者，在增加服务消费者工作量的同时，再考虑一个问题：如果某个服务被多个消费者调用，那么该服务提供者会收到大量探测请求，但这是不必要的。所以我认为被大量业务依赖的公共的服务提供方应尽可能采用动态注册的方式。敬请指正。

开关或者保护，怎么检测到网络抖动？

对于注册中心网络抖动问题，能否通过下面两种方法解决: 1.服务提供方定时上报心跳，注册中心进行ack确认，并且在ack中告知下次上报的时间间隔（该时间间隔为注册中心剔除节点最大不活跃时间的一半），如果服务提供方在超时时间后未收到ack，采用指数补偿策略进行重试上报n次（比如n＝3），这种重试的方式，有可能在网络抖动情况下，因此重试包网络风暴 2.双向探测，注册中心在节点达到剔除时间时，不直接剔除，而是进行主动探测n次（比如n等于3），探测几次还是失败，才剔除，然后通知订阅方更新

动态注册中心： “心跳开关保护机制”这种机制为了保护注册中心不被挤爆，但对服务消费者不太友善，也有可能会发生大面积消费者请求服务提供者失败的情况。当有 session_timeout 服务提供者节点被摘除时，只通知 10% 的服务消费者。 问题一：是每次随机取 10%，还是之前已通知的服务消费者就不再通知了？ 问题二：如何监控判断网络是否频繁抖动，并且如何打开这个开关？ 静态注册中心： 控制权反转，由服务消费者维护服务提供者的存活状态，服务提供者节点不再向注册中心汇报心跳信息。 注册中心不再维护服务提供者节点的心跳信息，只有消费者节点首次启动时，从注册中心拉取服务提供者节点信息，而后续便不再获取注册中心的提供者节点信息。即使消费者节点定时获取提供者节点信息，因为注册中心不维护提供者的心路信息，所以这些数据也是不可用的。 问题三：当有新的节点加入注册中心，或者需要从注册中心下线部分节点，服务消费者如何感知？ 谢谢古月老师！爱你么么哒~

我们公司是考虑动静结合的，这样添加节点也能主动推送给客户端

如果使用静态注册中心，虽然很好的解决了网络波动问题，那新增服务节点……还需要人工更新配置，感觉不是很自动化啊。如果是动态注册中心，启动的节点会自动接入集群里，免配置，更方便……唉，要是动态配置中心能根据请求行为自动探测出网络问题做一些决策就好了哈哈，我想多了