【管理设计篇】聊聊分布式配置中心

为什么需要配置中心

对于一个软件系统来说，除了数据、代码，还有就是软件配置，比如操作系统、数据库配置、服务配置 端口 ip 、邮箱配置、中间件软件配置、启动参数配置等。如果说是一个小型项目的话，可以使用Spring Boot yml文件管理，但是对于分布式系统来说，这种方式很容易出错。
所以就需要一个全局化的配置中心。 一般企业用的比较多，携程的Apollo等。

配置中心的设计

区分软件的配置

静态配置&动态配置
对于项目启动的一些比如端口号，软件初始化就确定的，基本都不会修改，这种就是静态配置。而对于软件运行时，我们会进行修改配置，运营参数配置、日志级别、业务开关、配置等，这种就是动态配置。
对于动态配置来说的化，主要就是三个区分的纬度

• 运行环境：对于一般正规的系统来说的话，开发环境（dev）、测试环境（test）、预发布环境（staging)、生产环境（prod）。所以对于开发功能的时候，需要提前做上线准备功能，列好需要修改的参数配置。
• 依赖区分：外部依赖的配置，一般都是中间件配置，MySQL、Redis等。或者自己内部业务配置。开关什么的。
• 层次分：基础层、中间层、应用层。基础层主要就是操作系统配置，中间层就是各种依赖的中间件 Redis、MySQL、Kafka、ES等。应用层都是和业务相关的配置。

所以一般来说，最好按照对应的分类进行管理，这样当系统越来越大的时候，就可以通过软件配置进行集中化管理。不然后期配置管理的复杂度就会上升。

配置中心的模型

配置中心一般来说的话，基本就是Key-value模型，value可以支持多种数据格式，比如JSON，字符串、数组、map等结构。
对于不同的配置来说，我们应该进行区分管理，基础层和中间件层应该运维人员进行管理，而应用层由研发人员进行管理。
不同环境的配置可能会有所差异。然后需要有对应的修改和发布记录，可以回溯历史，这样即时出现问题，可以快速查看修改点。
对了对于不同环境的话 应该有权限管理，生产环境应该由少数几个人管控。
一般目录级别的话 服务名-模块名称-配置的环境 配置等。

配置中心的架构

从整体来说的话，项目启动的时候 会通过依赖对应的中间件引入到项目中，然后统一配置初始化。但是对于在软件运行过程中，应该怎么让应用层序感知到配置变更呢。

其实比较简单，就是修改配置之后，配置中心会推送一个配置变更信息到配置变更控制器，通知对应的服务配置修改。然后服务主动去读取配置。整个过程就是一推一拉的过程。

为什么不直接配置中心推送对应修改的配置呢，因为可能应用太多会导致推送不过来，而应用服务主动拉取是一个不错的方式。另外也可以校验请求者的权限，以及对应的证书问题等。

配置中心主要的作用就是统一和规范化所有服务配置。设计重点就是如何统一和标准化软件的配置项。比如如何管理等，以及配置更新的时候事务操作。

小结

本篇主要介绍了配置中心，对于一般有点规模的系统都会引入配置中心来使用，但是大多数也都是不规范化，如何在实际的项目中更加规范化其实很重要，也有通过MySQL表结构进行管理配置的，其实各种方式都有。