转载

天啊！这就是技术中台配置中心的真相！

前言

近年来伴随着技术的不断进步，微服务概念的深入人心，微服务技术也被大家越来越多的应用在产品中。当企业还没有广泛应用微服务架构的时候，那时对于配置分发的解决方案多种多样，如脚本替换、环境变量读取、手工修改、重启应用等。但是随着微服务架构的盛行，配置管理的难度越来越大，企业亟需一套配置文件管理系统，将已有的应用配置有效管理起来。
   面对这个问题，我们可以借助配置中心来管理应用配置。配置中心实现了多套环境、多套版本、多个应用的配置管理。但是随着平台微服务业务的进一步发展，新的问题也随之而来。微服务应用越来越多，配置请求越来越频繁，同时有些微服务对配置的需求更讲究时效性。此外，业务上也希望能够更精确地控制配置替换的影响范围，例如能做到单点应用的配置修改。
   为了解决以上问题，我们基于微服务消息推送总线建设了配置中心实时配置推送系统。本文将基于该系统，深入分析配置推送的原理以及框架结构。

1. 核心业务介绍

配置推送业务需求

在建立配置中心推送系统前，我们先设计了一套基于平台微服务SDK的消息推送平台。将配置信息作为消息推送给微服务终端。我们希望该平台能够满足以下需求：

·高性价比，在有限的硬件资源下，尽可能的提高消息系统的性能和可用性；

·推送数据的一致性；

·推送消息的实时性；

·交互简单，学习门槛低，引入方便；

·结合配置分发的实际需求；

·推送失败后的补救处理；

·精确地控制推送范围。

作为消息推送平台的上层应用，配置中心实时推送则需要关注配置分发的业务需求：

·配置推送目标精确选择，包括特定租户、特定应用、特定环境等；

·保证配置推送的正确性；

·配置修改以后及时更新配置信息；

·应用掉线后能够重新获得推送信息。

配置推送服务流程

由配置中心决定置推送时机，如配置新建、配置更新、用户触发的时机等，配置信息发出后将交给终端微服务进行处理，如配置实时生效、重启等。

配置推送请求流程

消息推送平台由Inotify-Manager消息管理组件和Inotify-PushServer消息推送服务器组成。

其中Inotify-Manager负责接收配置中心、用户事件、Web管理页面传来的配置更新事件请求，对请求进行权限校验，并对通过权限校验的消息进行持久化保存。

Inotify-PushServer组件则负责接收Inotify-Manager传输的符合要求的消息信息，并且接收微服务终端中微服务SDK发送的注册请求，如果注册成功则为该终端保存一条消息传输通道，当其接到推送的消息时会根据推送过来的推送坐标选择相应的微服务终端进行推送。

配置推送接收SDK是微服务SDK功能的一部分，其主要逻辑由配置中心SDK和Inotify-SDK配合完成。Inotify-SDK负责根据微服务终端的配置生成消息通道ID（推送坐标）并将该id作为通道标识注册到Inotify-PushServer.当Inotify-PushServer推送消息时SDK也负责接收。接收到的消息为通用消息，配置中心SDK分析通用消息的类型，如果为配置类型则拦截消息进行处理。

2. 技术选型

系统架构图

根据配置分发业务的需求，我们的推送系统需要在硬件资源的有限的条件下具有较高的处理性能，并且满足大量的连接数场景。为此，在技术选型中传统的java.io被直接排除了，改为使用WebSocket协议的的长连接模式框架。Java的WebSocket框架选择比较有限，基本上就是在Netty，Undertow中二选一。Undertow的内存性能比Netty稍差，但是基于代码原因最终平台还是选择了Undertow作为推送服务的基础框架。

消息持久化

客户端上线之后需要将上线前一段时间的消息拉取消费，同时推送的历史消息也需要进行备份留待查询验证。因此消息持久化就成为了一个不可避免的问题。

目前消息推送平台数据量较小，且每次传输的数据多为服务元数据、配置信息、通知微服务终端消息等数据量较小的信息。目前这些信息在推送的同时也存储一份在数据库中，方便进行消息推送失败后的重发，以及后续数据的统计分析。

但是随着业务的日益增加，简单的持久化越来越满足不了需求，在这方面我们也正在积极开展工作。期望通过合理分表分库，使每个表的性能得到保障，并且保证总体的高分发量。在manager端也通过使用异步队列持久化的方式取代目前使用的同步方式，减少数据库的压力，提高消息推送的峰值。

数据传输协议

由于我们的消息推送平台需要维持长连接，因此在协议选择上就面临着两个选择：

·私有二进制协议

·基于HTTP的WebSocket

在综合多方面的考虑以后我们最终选择了WebSocket作为平台数据传输的协议，主要原因有以下几点。首先私有协议虽然性能较好，但是业务上的性能瓶颈往往并不在传输上，而使用WebSocket协议在安全校验、泛用性、开源工具等方面都有良好的支持，客户在使用时门槛也较低。

在传输数据格式方面我们选择了Json，这种格式比较简单、易于扩展且应用广泛。其实现在比较流行的Protobuf在性能上表现更好，序列化以后数据量大大减小，可以考虑在以后的版本中对其提供支持，由用户选择自己需要的序列化方式。

长连接

因为硬件资源有限，又要想维持尽可能多的连接数。在服务端我们采用了Undertow非阻塞时的维持长连接，提高单机所能维持的连接数。与此同时，还需要对失效连接及时进行清理，在高连接数的前提下提高有效连接的数量。

使用WebSocket的客户端与服务器端有可能因为一些情况导致连接中断，这种中断在客户端只有在再次发送消息时能被发现。但是在一些业务场景中，我们的客户端完全是消息的接收端，并不发送消息。在这种情况下，客户端下线后就永远不会再次连接。因此为了保证连接的可持续性和稳定性，我们使用了心跳检测机制，客户端定时发送心跳消息，用于检测网络和前后端连接问题。一旦发现异常，客户端端持续执行重连逻辑，直到重连成功。

3. 与配置推送结合的实现细节

分布式消息推送

消息推送随着业务量的增多，负载必然越来越重。为了满足业务需要，消息平台就需要在高性能的前提下具备水平扩展能力。因此分布式集群是消息平台一项必须的能力。

早期版本的消息推送平台由Nginx作为Router配合使用域名来为各个组件提供服务发现和负载均衡功能，示意图如下：