查看原文
其他

服务注册中心 | 记一次Consul故障分析与优化

弹性计算团队 爱奇艺技术产品团队 2022-03-15

前言

在微服务体系中,服务注册中心是最基础的组件,它的稳定性会直接影响整个服务体系的稳定性。本文主要介绍了爱奇艺微服务平台基于Consul的服务注册中心建设方式,与内部容器平台、API网关的集成情况,并重点记录了Consul遇到的一次故障,分析解决的过程,以及针对这次故障从架构上的优化调整措施。


Consul 是近几年比较流行的服务发现工具,用于实现分布式系统的服务发现与配置。与其它分布式服务注册与发现的方案相比Consul 的方案更“一站式”,使用起来也较 为简单。他的主要应用场景为:服务发现、服务隔离、服务配置。

Consul传送门


01.

注册中心背景及Consul的使用

从微服务平台的角度出发希望提供统一的服务注册中心,让任何的业务和团队只要使用这套基础设施,相互发现只需要协商好服务名即可;还需要支持业务做多DC部署和故障切换。由于在扩展性和多DC支持上的良好设计,我们选择了Consul,并采用了Consul推荐的架构,单个DC内有Consul Server和Consul Agent,DC之间是WAN模式并且相互对等,结构如下图所示。

注:图中只画了四个DC,实际生产环境根据公司机房建设以及第三方云的接入情况,共有十几个DC。


02.

与 QAE 容器应用平台集成

爱奇艺内部的容器应用平台QAE与Consul进行了集成。由于早期是基于Mesos/Marathon体系开发,没有POD容器组概念,无法友好的注入sidecar的容器,因此我们选择了微服务模式中的第三方注册模式,即由QAE系统实时向Consul同步注册信息,如下图所示;并且使用了Consul的external service模式,这样可以避免两个系统状态不一致时引起故障,例如Consul已经将节点或服务实例判定为不健康,但是QAE没有感知到,也就不会重启或重新调度,导致没有健康实例可用。

其中QAE应用与服务的关系表示例如下:

每个QAE应用代表一组容器,应用与服务的映射关系是松耦合的,根据应用实际所在的DC将其关联到对应Consul DC即可,后续应用容器的更新、扩缩容、失败重启等状态变化都会实时体现在Consul的注册数据中。


03.

与API网关集成

微服务平台API网关是服务注册中心最重要的使用方之一。网关会根据地区、运营商等因素部署多个集群,每个网关集群会根据内网位置对应到一个Consul集群,并且从Consul查询最近的服务实例,如下图所示。

这里我们使用了Consul的PreparedQuery功能,对所有服务优先返回本DC服务实例,如果本DC没有则根据DC间RTT由近到远查询其它DC数据。


故障与分析优化

01.

Consul故障

Consul从2016年底上线开始,已经稳定运行超过三年时间,但是最近我们却遇到了故障,收到了某个DC多台Consul Server不响应请求、大量Consul Agent连不上Server的告警,并且没有自动恢复。Server端观察到的现象主要有:


1. raft协议不停选举失败,无法获得leader;

2. HTTP&DNS查询接口大量超时,观察到有些超过几十秒才返回(正常应当是毫秒级别返回);

3. goroutine快速线性上升,内存同步上升,最终触发系统OOM;在日志中没能找到明确的问题,从监控metrics则观察到PreparedQuery的执行耗时异常增大,如下图所示。

此时API网关查询服务信息也超时失败,我们将对应的网关集群切到了其它DC,之后重启Consul进程,恢复正常。


02.

故障分析

经过日志排查,发现故障前发生过DC间的网络抖动(RTT增加,伴随丢包),持续时间大约1分钟,我们初步分析是DC间网络抖动导致正常收到的PreparedQuery请求积压在Server中无法快速返回,随着时间积累越来越多,占用的goroutine和内存也越来越多,最终导致Server异常。


跟随这个想法,尝试在测试环境复现,共有4个DC,单台Server 的PreparedQuery QPS为1.5K,每个PreparedQuery查询都会触发3次跨DC查询,然后使用tc-netem工具模拟DC间的RTT增加的情况,得到了以下结果:


1. 当DC间RTT由正常的2ms变为800ms之后,Consul Server的goroutine、内存确实会线性增长,PreparedQuery执行耗时也线性增长,如下图所示;


2. 虽然goroutine、内存在增长,但是在OOM之前,Consul Server的其它功能未受影响,raft协议工作正常,本DC的数据查询请求也能正常响应;


3. 在DC间RTT恢复到2ms的一瞬间,Consul Server丢失leader,接着raft不停选举失败,无法恢复;


以上操作能够稳定的复现故障,使分析工作有了方向。首先基本证实了goroutine和内存的增长是由于PreparedQuery请求积压导致的,而积压的原因在初期是网络请求阻塞,在网络恢复后仍然积压原因暂时未知,这时整个进程应当是处于异常状态;那么,为什么网络恢复之后Consul反而故障了呢?raft 只有DC内网络通信,为什么也异常了呢?是最让我们困惑的问题。


最开始的时候将重点放在了raft问题上,通过跟踪社区issue,找到了hashicorp/raft#6852,其中描述到我们的版本在高负载、网络抖动情况下可能出现raft死锁,现象与我们十分相似。但是按照issue更新raft库以及Consul相关代码之后,测试环境复现时故障依然存在。


之后尝试给raft库添加日志,以便看清楚raft工作的细节,这次我们发现raft成员从进入Candidate状态,到请求peer节点为自己投票,日志间隔了10s,而代码中仅仅是执行了一行metrics更新,如下图所示。

因此怀疑metrics调用出现了阻塞,导致整个系统运行异常,之后我们在发布历史中找到了相关优化,低版本的armon/go-metrics在prometheus实现中采用了全局锁 sync.Mutex,所有metrics更新都需要先获取这个锁,而v0.3.3版本改用了sync.Map,每个metric作为字典的一个键,只在键初始化的时候需要获取全局锁,之后不同metric更新值的时候就不存在锁竞争,相同metric更新时使用sync.Atomic保证原子操作,整体上效率更高。更新对应的依赖库之后,复现网络抖动之后,Consul Server可以自行恢复正常。


这样看来的确是由于metrics代码阻塞,导致了系统整体异常。但我们依然有疑问,复现环境下单台Server 的PreparedQuery QPS为1.5K,而稳定的网络环境下单台Server压测QPS到2.8K时依然工作正常。也就是说正常情况下原有代码是满足性能需求的,只有在故障时出现了性能问题。


接下来的排查陷入了困境,经过反复试验,我们发现了一个有趣的现象:使用go1.9编译的版本(也是生产环境使用的版本)能复现出故障;同样的代码使用go1.14编译就无法复现出故障。经过仔细查看,我们在go的发布历史中找到了以下两条记录:

根据代码我们找到了用户反馈在go1.9~1.13版本,在大量goroutine同时竞争一个sync.Mutex时,会出现性能急剧下降的情况,这能很好的解释我们的问题。由于Consul代码依赖了go1.9新增的内置库,我们无法用更低的版本编译,因此我们将go1.14中sync.Mutex相关的优化去掉,如下图所示,然后用这个版本的go编译Consul,果然又可以复现我们的故障了。

回顾语言的更新历史,go1.9版本添加了公平锁特性,在原有normal模式上添加了starvation模式,来避免锁等待的长尾效应。但是normal模式下新的goroutine在运行时有较高的几率竞争锁成功,从而免去goroutine的切换,整体效率是较高的;而在starvation模式下,新的goroutine不会直接竞争锁,而是会把自己排到等待队列末端,然后休眠等待唤醒,锁按照等待队列FIFO分配,获取到锁的goroutine被调度执行,这样会增加goroutine调度、切换的成本。在go1.14中针对性能问题进行了改善,在starvation模式下,当goroutine执行解锁操作时,会直接将CPU时间让给下一个等待锁的goroutine执行,整体上会使得被锁保护部分的代码得到加速执行。


到此故障的原因就清楚了,首先网络抖动,导致大量PreparedQuery请求积压在Server中,同时也造成了大量的goroutine和内存使用;在网络恢复之后,积压的PreparedQuery继续执行,在我们的复现场景下,积压的goroutine量会超过150K,这些goroutine在执行时都会更新metrics从而去获取全局的sync.Mutex,此时切换到starvation模式并且性能下降,大量时间都在等待sync.Mutex,请求阻塞超时;除了积压的goroutine,新的PreparedQuery还在不停接收,获取锁时同样被阻塞,结果是sync.Mutex保持在starvation模式无法自动恢复;另一方面raft代码运行会依赖定时器、超时、节点间消息的及时传递与处理,并且这些超时通常是秒、毫秒级别的,但metrics代码阻塞过久,直接导致时序相关的逻辑无法正常运行。


接着生产环境中我们将发现的问题都进行了更新,升级到go1.14,armon/go-metrics v0.3.3,以及hashicorp/raft v1.1.2版本,使Consul达到一个稳定状态。此外还整理完善了监控指标,核心监控包括以下维度:


1. 进程:CPU、内存、goroutine、连接数

2. raft:成员状态变动、提交速率、提交耗时、同步心跳、同步延时

3. RPC:连接数、跨DC请求数

4. 写负载:注册&解注册速率

5. 读负载:Catalog/Health/PreparedQuery请求量,执行耗时


03.

冗余注册

根据Consul的故障期间的故障现象,我们对服务注册中心的架构进行了重新审视。


在Consul的架构中,某个DC Consul Server全部故障了就代表这个DC故障,要靠其它DC来做灾备。但是实际情况中,很多不在关键路径上的服务、SLA要求不是特别高的服务并没有多DC部署,这时如果所在DC的Consul故障,那么整个服务就会故障。


针对本身并没有做多DC部署的服务,如果可以在冗余DC注册,那么单个DC Consul故障时,其它DC还可以正常发现。因此我们修改了QAE注册关系表,对于本身只有单DC部署的服务,系统自动在其它DC也注册一份,如下图所示。

QAE这种冗余注册相当于在上层做了数据多写操作。Consul本身不会在各DC间同步服务注册数据,因此直接通过Consul Agent方式注册的服务还没有较好的冗余注册方法,还是依赖服务本身做好多DC部署。


04.

保障API网关

目前API网关的正常工作依赖于Consul PreparedQuery查询结果在本地的缓存,目前的交互方式有两方面问题:


1. 网关缓存是lazy的,网关第一次用到时才会从Consul查询加载,Consul故障时查询失败会导致请求转发失败;


2. PreparedQuery内部可能会涉及多次跨DC查询,耗时较多,属于复杂查询,由于每个网关节点需要单独构建缓存,并且缓存有TTL,会导致相同的PreparedQuery查询执行很多次,查询QPS会随着网关集群规模线性增长。


为了提高网关查询Consul的稳定性和效率,我们选择为每个网关集群部署一个单独的Consul集群,如下图所示。

图中红色的是原有的Consul集群,绿色的是为网关单独部署的Consul集群,它只在单DC内部工作。我们开发了Gateway-Consul-Sync组件,它会周期性的从公共Consul集群读取服务的PreparedQuery查询结果,然后写入到绿色的Consul集群,网关则直接访问绿色的Consul进行数据查询。这样改造之后有以下几方面好处:


1. 从支持网关的角度看,公共集群的负载原来是随网关节点数线性增长,改造后变成随服务个数线性增长,并且单个服务在同步周期内只会执行一次PreparedQuery查询,整体负载会降低;


2. 图中绿色Consul只供网关使用,其PreparedQuery执行时所有数据都在本地,不涉及跨DC查询,因此复杂度降低,不受跨DC网络影响,并且集群整体的读写负载更可控,稳定性更好;


3. 当公共集群故障时,Gateway-Consul-Sync无法正常工作,但绿色的Consul仍然可以返回之前同步好的数据,网关还可以继续工作;


4. 由于网关在改造前后查询Consul的接口和数据格式是完全一致的,当图中绿色Consul集群故障时,可以切回到公共Consul集群,作为一个备用方案。


总结与展望

作为统一的服务注册中心,稳定性、可靠性始终是我们的首要目标。一方面在保证服务注册中心本身的稳定性,另一方面也会在架构上通过部署、数据、组件等多维度的冗余来提高整个技术体系的稳定性。


目前我们有了一系列监控指标,可以帮助我们评估系统整体的容量、饱和度。随着接入服务越来越多,还要继续完善服务维度的监控指标,当系统负载发生预期外的变化时,能够快速定位到具体的服务、节点。


引用

1.爱奇艺微服务API网关

https://mp.weixin.qq.com/s/joaYcdmeelGZmpMcEo-mpw

2.Consul raft deadlock https://github.com/hashicorp/consul/issues/6852

3.Consul prometheus update https://github.com/hashicorp/consul/pull/8372

4.Go sync.Mutex performance issue https://github.com/golang/go/issues/33747

5.Go sync.Mutex update 

https://go-review.googlesource.com/c/go/+/206180/

也许你还想看

基于微服务成熟度模型的高可用优化实践

爱奇艺号基于Prometheus的微服务应用监控实践



扫一扫下方二维码,更多精彩内容陪伴你!



您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存