您现在的位置是:主页 > 数据库技术 > 数据库技术

Consul故障分析与优化是怎么样的

IDCBT2022-01-14服务器技术人已围观

简介Consul故障分析与优化是怎么样的,针对这个问题,这篇文章详细介绍了相对应的分析和解答,希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。 注册中心背景及Consul的

Consul故障分析与优化是怎么样的,针对这个问题,这篇文章详细介绍了相对应的分析和解答,希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。

注册中心背景及Consul的使用

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

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

与QAE容器应用平台集成

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

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

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

与API网关集成

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

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

故障与分析优化

Consul故障

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

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

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

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

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

标签:

很赞哦! ()

本栏推荐