转载

微服务化改造系列之三：配置中心

前情概要：

- 微服务化改造系列之一：总览

- 微服务化改造系列之二：服务注册中心

配置中心概述

这篇文章是微服务化改造系列的第三篇，主题是配置中心。上一篇我们谈到服务注册中心，即通过提供某种注册和发现的机制，解决服务互通的问题。那么问题来了，一个服务如何知道服务注册中心的地址呢？这就涉及到服务配置了。我们知道，大至一个PaaS平台，小至一个缓存框架，一般都依赖于特定的配置以正常提供服务，微服务也不例外。

配置分类

按配置的来源划分，主要有源代码（俗称hard-code），文件，数据库和远程调用。
按配置的适用环境划分，可分为开发环境，测试环境，预发布环境，生产环境等。
按配置的集成阶段划分，可分为编译时，打包时和运行时。编译时，最常见的有两种，一是源代码级的配置，二是把配置文件和源代码一起提交到代码仓库中。打包时，即在应用打包阶段通过某种方式将配置（一般是文件形式）打入最终的应用包中。运行时，是指应用启动前并不知道具体的配置，而是在启动时，先从本地或者远程获取配置，然后再正常启动。
按配置的加载方式划分，可分为单次加载型配置和动态加载型配置。

演变

随着业务复杂度的上升和技术架构的演变，对应用的配置方式也提出了越来越高的要求。一个典型的演变过程往往是这样的，起初所有配置跟源代码一起放在代码仓库中；之后出于安全性的考虑，将配置文件从代码仓库中分离出来，或者放在CI服务器上通过打包脚本打入应用包中，或者直接放到运行应用的服务器的特定目录下，剩下的非文件形式的关键配置则存入数据库中。上述这种方式，在单体应用阶段非常常见，也往往可以运行的很好，但到了微服务阶段，面对爆发式增长的应用数量和服务器数量，就显得无能为力了。这时，就轮到配置中心大显身手了。那什么是配置中心？简单来说，就是一种统一管理各种应用配置的基础服务组件。

可选框架

选型一个合格的配置中心，至少需要满足如下4个核心需求：

非开发环境下应用配置的保密性，避免将关键配置写入源代码
不同部署环境下应用配置的隔离性，比如非生产环境的配置不能用于生产环境
同一部署环境下的服务器应用配置的一致性，即所有服务器使用同一份配置
分布式环境下应用配置的可管理性，即提供远程管理配置的能力

现在开源社区主流的配置中心框架有Spring Cloud Config和disconf，两者都满足了上述4个核心需求，但又有所区别。

Spring Cloud Config

Spring Cloud Config 可以说是一个为Spring量身定做的轻量级配置中心，巧妙的将应用运行环境映射为profile，应用版本映射为label。在服务端，基于特定的外部系统（Git、文件系统或者Vault）存储和管理应用配置；在客户端，利用强大的Spring配置系统，在运行时加载应用配置。

disconf

disconf 是前百度资深研发工程师廖绮绮的开源作品。在服务端，提供了完善的操作界面管理各种运行环境，应用和配置文件；在客户端，深度集成Spring，通过Spring AOP实现应用配置的自动加载和刷新。

方案选型

不管是Spring Cloud Config还是disconf，默认提供的客户端都深度绑定了Spring框架，这对非Spring应用而言无疑增加了集成成本，即便它们都提供了获取应用配置的API。最终我们还是选用了微服务化改造之前自研的Matrix作为配置中心，一方面，可以保持新老系统使用同一套配置服务，降低维护成本，另一方面，在满足4个核心需求的前提下，Matrix还提供了一些独有的能力。

分离配置文件和配置项。对于配置文件，通过各类配套打包插件（sbt, maven, gradle），在打包时将配置文件打入应用包中，同时最小化对CI的侵入性；对于配置项，提供SDK，帮助应用从服务端获取配置项，同时支持简单的缓存机制。
增加应用版本维度，即对于同一应用，可以在服务端针对不同版本或版本区间维护不同的应用配置。
应用配置的版本化支持，类似于Git，可以将任一应用配置回退到任一历史版本。

进一步信息可参考我之前写的Matrix 设计文档。