又被“大数据杀熟”了
当然这个流程中也会有意外情况发生,比如由于网络情况,某个服务节点上报心跳失败,但是服务是在正常运行的,这种场景下,最直接的解决方案是:注册中心判断服务存活的时间窗口大于上报时间间隔即可,比如:心跳上报时间是10秒的话,注册中心判定服务不可用的时间窗口设置为30秒,既:三次心跳时间都没有上报心跳,就判定服务不可用。 当然以上只是注册中心的一个假设而已,其实系统可以结合主动探测的方式来判定服务是否可用,这样的话,结果的正确率会更高。也就是说:当服务的某个节点,超过配置的N次心跳时间仍然没有上报心跳数据,注册中心可以通过主动探测的方式来再次确定服务是否处于正常运行状态,当然,这在设计上增加了一定的复杂度,需要编写更多的代码。 还有一个不太常见的但是我们需要考虑的场景,假如所有的服务节点都因为网络异常情况而发生心跳上报超时,而且主动探测失败的情况,按照约定,注册中心会逐步移除所有的节点信息,这样造成的后果是系统肯定会出问题,有的时候系统设计的同时可以考虑一些保护措施,比如:当节点信息移除的数目大于一定比率的时候,就停止移除操作并且发送报警信息,这在一定程度上可以避免注册中心无节点数据的情况发生,当然客户端也可以有这样的保护策略。 通知风暴
虽然这个问题在多数情况下不算是个问题,但是还是有必要提及一下。当注册中心随着项目的升级承担起越来越多的服务节点的时候,服务间的调用链复杂度也随之上升,伴随而来的是新增一个节点可能要通知数十个客户端,移除一个节点也会有类似情况发生,如果有多个服务同时发生新增或移除节点操作,注册中心推送的消息将会更多。这样的场景下就需要系统设计者控制注册中心服务节点的数量来避免产生网络风暴,这个数量具体多少可以根据服务器的峰值带宽来确定。 那些坑 服务中心虽然在整体架构模式上解决了很多问题,但是在使用中我们也要直面它所带来的一些副作用,而且这些副作用有时候会成为整个系统瘫痪的导火线。 数据一致性问题 数据的一致性好像是所有系统都要面对的问题,注册中心也不例外。这里的一致性是指注册中心内存储的可用节点数据和后端真实可用节点以及客户端存储的可用节点之间的差异性问题。举个栗子:假如注册中心中存储了ABC三个服务节点信息,而这个时候节点A由于某种原因下线了,注册中心必须要及时把A节点移除掉,并且通知客户端也把A节点移除。 从理论上来讲,以上过程跨越了注册中心和调用方以及被调用方的交互流程,属于分布式中的事务问题,即:分布式事务问题。在之前菜菜的文章中也说过,分布式的事务要想保证严格的一致性必然会影响可用性 分布式下,我想要一致性 而且从目前主流的注册中心技术来看,注册中心和双方的通信流程属于异步流程,所以做不到实时的事务性要求。 目前注册中心在通知客户端变化的方面可以做到近乎于实时(其实并非实时),但是在监测后端服务节点是否可用的过程中,却很难做到近乎实时。其中的原因一是因为网络的不可靠特性,一次网络通信失败,并非意味着下次网络通信失败,二是监测后端服务可用的方式并非实时的。目前流行的两种探测后端服务可用的方式为: 注册中心主动探测 很多注册中心的组件都支持这种方式,在这种方式下,后端的每个服务需要提供一个可供探测的接口或者端口,注册中心根据配置每隔一段时间去调用一次服务的接口或端口,如果返回正常就认为服务处于正常运行状态,否则则认为服务不可用,不可用的情况下注册中心会主动把当前服务移除列表,并通知客户端。 虽然这种方式看似很完美,其实还是有坑:
后端服务主动心跳 相比较注册中心主动探测的模式,我更喜欢使用服务主动上报心跳的模式。采用心跳的模式大体流程是这样的:
(编辑:信阳站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |