记一次Consul故障分析与优化

【编者的话】在微服务体系中，服务注册中心是最基础的组件，它的稳定性会直接影响整个服务体系的稳定性。本文主要介绍了爱奇艺微服务平台基于Consul的服务注册中心建设方式，与内部容器平台、API网关的集成情况，并重点记录了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查询最近的服务实例，如下图所示：