由服务注册中心故障引起的思考

CAP和BASE理论

Posted by Liangjf on February 6, 2021

由服务注册中心故障引起的思考

由于某个bug(不方便说,请见谅),公司的服务注册中心不可用,故障持续15分钟,期间,新发版的服务由于不可注册,造成新发版服务不可用,在线服务仍旧可用。

如今,大型商业项目,一般都是微服务架构,服务注册中心这个组件是必不可少的。它的作用在这里就不说了,本文单纯讨论下服务注册中心的可用性,可靠性。

服务注册中心必须是集群架构的,由于是分布式架构,从而就会涉及到CAP理论。我们可知,P是必不可少的。所以实现方案一般是CP或者AP。

在实际中,服务注册中心这个组件有没有必要满足C(强一致性)?

如上图,若服务注册中心是CP系统,当系统发生网络分区,机房3由于是单节点,那么就和leader失去联系,是不能接收写请求的。这时候服务serverB3就不能注册,造成原有的服务serverA3即使在同机房, 也不能请求服务serverB3。

这样是否合理?个人认为,这样是不合理的,服务注册中心是微服务架构中的一个组件,我们的业务服务不应该强依赖它,而只是在发版注册服务,订阅/拉取服务列表时依赖它,这样才能使我们的服务之间的通信减少对外界的依赖,从而,我们的服务才能更加健壮,可用性更高。

如上图,若服务注册中心是AP系统,即使系统发生网络分区,服务serverB3还是能向node3注册服务,服务serverA3也能拉取到服务serverB3,所以服务serverA3能请求服务serverB3。可见,AP系统,在发生网络分区,还是可以很少的支持我们的服务通信,大大提高了服务的可用性。

但是,虽然服务注册中心是AP系统,发生网络分区,网络好了之后,并不代表服务注册中心节点之间的数据不一致。所以在这里引出分布式中的BASE理论(基本可用,软状态,最终一致性)。我们可依赖最终一致性, 让我们的系统在一定的时间内数据收敛,所有节点间的数据达到一致。

如上图,在网络分区恢复后,服务注册中心集群节点间的数据还是能够在一定时间达到一致的,最终整个系统又能够正常的对外工作了。

据所知,服务注册中心的实现可以借助zookeeper,etcd,consul,Eureka,Nacos等。其中zookeeper,etcd,consul都是CP系统,因为它们的分布式一致性协议ZAB,Raft都是强一致性的。Eureka是AP系统,也是业界服务注册中心的标杆,它是去中心化的架构,节点间对等通信,同步数据。

为了提高服务注册中心的可用性,减少服务对服务注册中心的依赖,服务注册中心的客户端一般会把订阅的服务列表缓存到本地,并且写入文件中。当服务注册中心不可用时,就会使用缓存的服务列表,这样可以提高服务的可用性,在提高性能(定时更新,减少频繁的请求服务注册中心)的同时,降低对服务注册中心的依赖。

其实,以上的讨论,其实质就是分布式系统的CAP理论和BASE理论的思考,和在实际中的应用。知行合一,学习经典的分布式理论,在实际中应用,学习,才能更深刻的理解这些经典的理论。任重而道远!!!