• oddrock
    2018-09-29
    应该以客服端为准,谁使用谁有发言权。
    我觉得注册中心的主动心跳探测不应作为客户端摘除不可用服务端节点的依据,而是要作为参考值,比如将这种探测信息发给客户端,客户端在负载均衡时,将这种疑似问题节点降权重或作为备用节点,这样是不是比较好
    
     21
  • xiaoxi
    2018-09-29
    相对于动态注册,静态注册的方式把探测任务分散到了服务消费者,在增加服务消费者工作量的同时,再考虑一个问题:如果某个服务被多个消费者调用,那么该服务提供者会收到大量探测请求,但这是不必要的。所以我认为被大量业务依赖的公共的服务提供方应尽可能采用动态注册的方式。敬请指正。
     1
     13
  • feimeng0532
    2018-09-29
    开关或者保护,怎么检测到网络抖动?
    
     8
  • 王鸿运
    2019-01-14
    对于注册中心网络抖动问题,能否通过下面两种方法解决:
    1.服务提供方定时上报心跳,注册中心进行ack确认,并且在ack中告知下次上报的时间间隔(该时间间隔为注册中心剔除节点最大不活跃时间的一半),如果服务提供方在超时时间后未收到ack,采用指数补偿策略进行重试上报n次(比如n=3),这种重试的方式,有可能在网络抖动情况下,因此重试包网络风暴
    2.双向探测,注册中心在节点达到剔除时间时,不直接剔除,而是进行主动探测n次(比如n等于3),探测几次还是失败,才剔除,然后通知订阅方更新
    
     3
  • pscj
    2018-11-16
    感觉静态注册中心就完全去中心化了,没有中心的概念了,每个peer自己判断节点的死活,自己维护一套状态表,是这个意思吧?

    作者回复: 对,这个时候注册中心类似一个配置中心了

    
     2
  • null
    2018-09-29
    动态注册中心:
    “心跳开关保护机制”这种机制为了保护注册中心不被挤爆,但对服务消费者不太友善,也有可能会发生大面积消费者请求服务提供者失败的情况。当有 session_timeout 服务提供者节点被摘除时,只通知 10% 的服务消费者。

    问题一:是每次随机取 10%,还是之前已通知的服务消费者就不再通知了?
    问题二:如何监控判断网络是否频繁抖动,并且如何打开这个开关?


    静态注册中心:
    控制权反转,由服务消费者维护服务提供者的存活状态,服务提供者节点不再向注册中心汇报心跳信息。
    注册中心不再维护服务提供者节点的心跳信息,只有消费者节点首次启动时,从注册中心拉取服务提供者节点信息,而后续便不再获取注册中心的提供者节点信息。即使消费者节点定时获取提供者节点信息,因为注册中心不维护提供者的心路信息,所以这些数据也是不可用的。

    问题三:当有新的节点加入注册中心,或者需要从注册中心下线部分节点,服务消费者如何感知?

    谢谢古月老师!爱你么么哒~
    展开
    
     2
  • 松花皮蛋me
    2019-02-17
    我们公司是考虑动静结合的,这样添加节点也能主动推送给客户端
    
     1
  • echo_陈
    2018-09-29
    如果使用静态注册中心,虽然很好的解决了网络波动问题,那新增服务节点……还需要人工更新配置,感觉不是很自动化啊。如果是动态注册中心,启动的节点会自动接入集群里,免配置,更方便……唉,要是动态配置中心能根据请求行为自动探测出网络问题做一些决策就好了哈哈,我想多了
    
     1
  • 拉欧
    2018-09-29
    当然要以服务消费端为准,服务消费者才是真实的调用方
    
     1
  • Geek_6ea8f7
    2020-01-04
    注册中心心跳检测和客户端摘除在主流的开源框架中是如何选择的?
    这些框架中是否包含心跳开关保护和摘除保护的支持?
    如果支持怎样修改配置?如果不支持要如何二次开发实现?
    同时使用注册中心摘除和客户端摘除,二者信息不一致时,权衡的方案又该如何设计?
    
    
  • 满力
    2019-07-13
    你好老师!我记得服务提供者不可用了,是zk主动推送给消费端的吧,你这里说的是消费端主动去拉取
    
    
  • godtrue
    2019-06-15
    如果华夏村的村委会告诉张三李四去世了,但是张三去李四家拿东西又碰见了李四。
    那么问题来了,李四到底死没死?张三开始了思考。
     1
    
  • 风翱
    2019-05-29
    应该以服务消费者的为准,做为服务消费者调用成功了,说明服务提供者是可以提供服务的。注册中心未收到心跳汇报,可能是与注册中心的网络连通性的问题,并不意味着服务提供者不可提供服务。
    
    
  • 亚林
    2019-05-29
    以【服务消费者又调用这个服务节点成功】为准,因为服务提供者与注册中心之间通信不佳,可能是网络原因导致的。
    
    
  • Final不基
    2018-11-17
    你好,我们目前在上的新系统,使用的spring cloud微服务架构,目前刚刚计划改为eureka主动探测机制,目前没听过有设置保护机制,那么如果网络真出问题了,是不是很有可能出现您说的那个注册中心网络占满的问题?

    作者回复: 是的,我记得spring cloud也是有类似的摘除保护机制的

    
    
  • yan
    2018-10-18
    只通知10%的用户,那么另外的90%的用户是让他们失败吗?还是后续会再次通知,只是分批次,每次通知10%,知道全部通知完毕?

    作者回复: 因为客户端会隔一段时间来请求,这一次请求没有变化,下一次请求可能就有变化了

    
    
  • 波波安
    2018-10-14
    老师,有个疑问,如果采用静态注册中心,那服务超时时间,重试次数这些服务配置信息的改变怎么及时通知到消费端呢?
    
    
  • 冬末未末
    2018-09-29
    静态注册中心添加节点怎么自动推送给客户端呢?
    
    
我们在线,来聊聊吧