consul 日志配置_技术分享|自主研发平台POIN4.2微服务揭秘系列（一） “注册中心/配置中心多活部署方案”...

柳朝晖

平台开发处

钟  方

平台开发处

为响应我行分布式架构转型，践行“敏捷、科技、生态”的发展战略，自主研发平台“稳重求进，进中求新”，突破微服务关键技术，持续打造POIN4.2微服务版本，以开源技术为基础进行自主研发与扩展，完成了注册中心/配置中心多活方案，增强了微服务关键技术组件，有效提升了微服务架构的可用性、可靠性，为重点应用系统的微服务化转型和业务功能的快速迭代提供了更有效的底层技术支撑。本文主要介绍POIN平台注册中心/配置中心基于我行网络架构的多活部署方案。

Consul作为POIN平台微服务架构中的注册中心和配置中心，提供“一站式”的方案：内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案等能力。在部署架构上，consul原生提供高可用client部署模式，即consul的client作为应用的sidecar，由client和consul server集群进行通讯。基于我行cpaas网络分区，部署架构图如下：

采用此部署架构可能带来的问题：当出现网络分区时(如单边切换)，一个consul集群分为两个集群，如果此时主在酒仙桥，那么切换后的上地consul集群不可用，需要手工在上地启动2个备用节点，在上地生成新的集群；带来运维的复杂度。因此，基于我行两地三中心(或者同城三中心)特有的网络架构现状，需要引入多数据中心部署模式，在多数据中心模式下，每个consul数据中心节点都在一个私有的、低延迟的网络环境中，节点不会跨网络域，当发生网络分区时，不会影响consul集群，无需手工运维，待网络恢复时候，自动恢复多数据中心监听访问。

01

consul多活方案问题与需求

采用原生consul多数据中心部署模式后，由于springcloud原生对consul多中心模式支持有限，spring cloud 同步机制为在第一次访问服务时，向consul集群查询服务信息，那么当交易为第一次访问服务时，如果此时consul某个数据中心不可用，则会影响服务发现，导致交易失败。基于以上需求背景，平台对consul多数据中心模式下的服务注册发现以及配置中心同步功能增强，从而进一步提升微服务架构的可靠性，降低运维复杂度。采用consul多活部署方案，POIN主要从以下两方面进行了功能增强：

1、服务注册发现优化：由于consul的CP的特性，当consul集群不可用时，可能会影响已注册成功过的服务间的调用，平台需要扩展增强服务发现的能力，保证consul集群故障恢复或raft选举不对外提供服务期间，不影响已有服务间的调用访问。

2、配置中心优化：consul作为POIN的配置中心，在consul多数据中心模式下，每个数据中心会存在一个配置中心，本中心的应用都使用该配置中心的配置信息，原生consul对配置中心同步支持有限，平台需要扩展功能，支持所有配置中心的配置信息同步，保证各中心的应用使用的配置信息最终一致性。

Poin consul多活方案部署架构图：

如上图所示，多活方案中：

1、采用consul client模式，client作为服务的sidecar部署，应用服务通过client和consul server交互，进行服务注册，服务同步，监控状态上送等。

2、consul通过server在CPAAS上的servicename进行集群创建；client通过servicename加入consul集群。集群建立成功后，集群中所有节点之间的通讯都是基于podip。

3、跨数据中心查询服务时，需向本数据中心发送请求并上送指定查询的数据中心名称，由本数据中心forward到指定的数据中心去查询服务信息。

4、该方案同时支持同城两中心或者三中心，每个网络域为一个数据中心。

5、针对异地灾备，建议异地部署独立consul集群，避免出现跨城市的服务调用。

02

关键技术设计与实现

方案中关键设计主要包括服务注册发现和配置信息同步两部分：

1.consul多数据中心-服务注册发现

如上图所示：

(1)在consul原生多数据中心模式下，每个网络域的应用都注册到当前的consul数据中心，consul数据中心之间不会同步服务列表。

(2)平台扩展springcloud服务发现机制，应用启动时依次同步各数据中心的服务列表至本地缓存。应用启动后，依赖springcloud定时从consul集群同步服务列表机制来更新本地的服务列表信息。即：应用本地缓存所有数据中心服务列表的全量，平台扩展ribbon负载机制，支持服务间的调用时，优先调用本中心域的服务，当本中心的服务不可用时，再按照优先级调用其他数据中心的服务，保证当consul集群故障恢复或者raft选举拒绝对外提供服务期间，微服务之间的调用不受影响。

2.多数据中心-配置中心信息同步

多数据中心下，每个数据中心有一个配置中心，当前中心的应用内都使用该配置中心的配置。当配置被修改时，需要将最新的配置同步给所有的配置中心，保证每个中心下的应用使用的配置都是最新的。

整体处理流程：

1、平台提供配置管理服务功能，主要包括两部分功能：(1)提供通过管理台页面修改配置信息的功能；(2)提供守护任务，定时扫描数据库中未同步成功到consul数据中心的记录并进行重做。

2、新系统初次投产时，将配置信息初始化到数据库的配置信息表中，然后由配置管理服务的守护任务会将配置push到各数据中心。

3、用户通过配置管理台页面，修改配置信息时，配置管理服务会修改库中的配置信息，并记录版本信息到配置同步日志表。

4、配置管理服务启动时会启动守护任务，定时扫描配置同步日志表，将push失败的异常记录重做，保证配置最终一致性。

该方案保证数据的安全性前提下，通过版本匹配、守护线程等技术手段保证配置信息的最终一致性。

03

总  结

以上主要介绍了POIN注册中心/配置中心多活部署方案，后续将持续给大家带来POIN4.2微服务体系其他核心技术组件的分享，以开放的心态，持续打造自主研发平台，推进我行分布式技术的发展。