左耳听风_054_53_管理设计篇之配置中心

你好，我是陈浩网名做耳朵house.这节课呢我们来讲一讲配置中心。

我们知道除了代码之外呢，软件还有一些配置信息，比如数据库的用户名和密码，还有一些我们不想写死在代码里的东西，像线程池大小啊、队列长度等运行参数，还有日志级别、算法策略等等。

那还有一些呢是软件运行环境的参数，比如java的内存大小应用启动参数，还包括操作系统的一些参数配置啊等等。

那所有的这些东西呢我们都叫做软件配置。

以前呢我们把软件配置啊写在一个配置文件中，就像window下下面的INI文件，或者是下面的linuucom文件。

但是在分布式系统下呢，这样的方式啊就变得非常不好管理，并且啊容易出错。

于是呢为了便于管理，我们就引入了一个集中式的。配置管理系统。

那这个呢就是配置中心的由来。

那现在呢软件的配置中心啊是分布式系统的一个必要组件。

这个系统听起来很简单，但是其实呢并不是我见过好多公司的配置中心，但是呢我觉得做的都不好，所以呢想写下这篇文章给你一些借鉴。

我们先来谈一谈配置中心的设计。

首先呢我们要区分软件的配置，软件配置的区分啊有多种方式。

有一种方式呢是把软件的配置分成静态配置和动态配置。

那所谓静态配置呢啊其实就是软件启动式的一些配置，运行的时候呢，基本不会进行修改啊，也可以理解成是软件或者环境初始化的时候需要用到的配置，比如操作系统的网络配置，软件运行时docker进程的配置。

那这些配置在软件环境初始化的时候呢，就确定了未来啊基本不会进行修改了。

而所谓动态配置呢，其实就是软件运行时的一些配置，在运行的时候呢会被修改。

比如说日志级别降级开关或者活动开关。

当然呢我们这里的内容啊主要针对的是动态配置的管理。

那对于动态配置的管理呢，我们还要做好区分。

那一般来说呢会有三个区分的维度。

那第一呢是按运行环境分，一般来说呢会有开发环境、测试环境、预发环境、生产环境。

那这些环境上的运行配置呢都不完全一样啊，但是理论上来说啊，应该是大同小异的那第二呢是按依赖区分，那一种呢是依赖配置。

那一种呢是不依赖的内部配置，比如说外部依赖的mysql或者REDIS的连接配置啊，还有一种呢是完全自己内部的配置。

那第三呢是按层次分，就像云计算一样，配置呢也可以分为las、 pass和sars三层。

那基础层的配置呢是操作系统的配置，中间平台层的配置呢是中间件的配置，比如tom taat的配置。

而上层软件层的配置呢是应用自己的配置。

那这些分类方式呢，其实是为了更好的管理我们的配置项，小公司呢无所谓。

而当一个公司变大了以后呢，如果这些东西没有被很好的管理起来，那么呢就会增加太多系统维护的复杂度。

那有了上面给配置项的分类，我们呢就可以设计软件配置模型了。

首先呢软件配置啊，基本上来说每个配置项就是t value的模型。

然后呢，我们把软件的配置分成三层，那操作系统层和平台层的配置项呢得由专门的运维人员或者架构师来配置。

那其中的value呢应该是选项，而不是让用户可以自由输入的那最好呢是有相关的模板来初始化全套的配置参数。

而应用层的配置项呢需要有相应的命名规范，最好呢有像c加加那样的命名空间的管理啊，确保不同应用的配置项不会冲突。

另外呢我们的配置参数中啊，如果有外部服务依赖的配置，强烈建议啊不要放在配置中心里，而要放在服务发现系统中。

因为一方面啊是在语义上更清楚一些。

那另外呢，这样也会减少，因为运行不同环境而导致配置不同的差异性。

那对于不同运行环境中配置的差异来说呢，比如说在开发环境和测试环境下，日志级别是第八个级。

那对于生产环境呢则是warning或者erroage.因为环境的不一样会导致我们啊需要不同的配置项的值。

那这一点呢我们需要考虑到。

那还有呢我们的配置啊需要有一个整体的版本管理，每次变动啊都能将版本差异记录下来。

那当然呢如果可能最好能和软件的版本号做关联，我们可以看到啊，那其中有些配置呢是通过模板来选择的那有的配置呢需要在不同环境下配置不同的值，所以呢还需要一个配置管理的工具，可能是命令行的啊，也可能是web的。

我在文中呢放了这个工具的界面图。

用户呢可以根据不同的机器型号啊，还有不同的环境，直接调出后台配置好的相关标准配置的模板。

那对于一些用户需要自己调整的参数呢，也可以在这个模板上进行调整和配置。

然后呢，用户可以在下面的那个表格中啊填写好自己的应用，要用的参数和各个环境中的值。

嗯，这样一来呢，这个工具啊就可以非常方便的让开发人员来配置他们自己的软件配置。

而我们的配置中心呢还需要提供API来让应用获取配置。

那这个API上面啊，至少需要有服务名、配置的版本号，还有配置的环境这些参数。

那接下来呢我们要来解决配置落地的问题。

我们可以看到和一个软件运行有关系的各种配置呢隶属于不同的地方。

所以呢要让他们落地啊，还需要一些不一样的细节要处理。

文中呢我给你画了一个大概的架构图。

在这个图中呢，我们可以看到我们把配置录入之后呢，配置中心发出变更的通知。

那配置变更控制器呢会来读取最新的配置，然后呢应用配置这一点看上去很简单，但是呢有很多的细节问题啊，接着我来一一说明。

第一，为什么需要一个变更通知的组件，而不是让配置中心直接推送呢？那这个原因啊就是在分布式环境下，服务器太多了，推算不太现实。

而采用一个pub sub的通知服务呢，可以让数据交换经济一些。

第二个问题，为什么不直接pub数据过去，还要订阅方反向拉数据呢？直接推出去啊，当然可以，但是让程序反过来用API读配置。

那它的好处啊在一方面啊，API可以校验请求者的权限。

那另一方面呢，有时候啊还是需要调配配置中心的基本PI,比如下载最新的证书之类的。

还有呢就是服务启动的时候啊，需要从服务中心拉一份配置下来。

那第三个问题，配置变更控制器部署在哪里呢？是在每个服务器上呢，还是在一个中心的地方呢？我觉得啊因为这个事儿是要变更配置，变更配置呢又是有很多步骤的，所以这些步骤啊算是一个事务。

那为了执行效率更好，事务成功率更大。

所以呢我建议把这个配置变更的控制啊放在每一台主机上。

那第四个问题，平台层的配置变更，有的参数是在服务启动的命令行上。

那这个怎么变更呢？那一般来说呢，命令行上的参数啊需要通过shell环境变量做成配置项，然后呢通过更改系统环境变量并重启服务，达到配置变更。

那第五点呢，操作系统的配置变更和平台层的配置变更啊，最好模块化掉，就像云服务中不同尺寸的主机型号一样。

那这样呢有利于维护减少配置的复杂性。

那另外呢就是应用服务配置更新的标准化。

因为一个公司的应用由不同的团队来完成，所以呢可能它的配置啊会因为应用的属性不同而不一样。

那为了便于管理呢，最好有一个统一的配置更新。

一般来说呢，有的应用服务的配置是在配置文件中有的。

应用服务的配置呢是通过调用admin API的方式来变更不同的应用系统。

完全不一样啊，你似乎完全没有办法做成统一的那这里呢我给几个方案。

那第一个方案呢就是可以通过一个开发框架或者SDK的方式来解决啊，也就是应用代码呢找你这个SDK来要配置，并通过observer模式订阅配置修改的事件，或者呢直接提供配置变更的admmin API.那这种方式的好处呢在于在开发期标准化啊，并可以规范开发。

那不好的点啊在于它耦合语言。

那第二个方案呢就是通过一个标准应用的运维脚本，让应用方自己啊来提供应用变更式的脚本动作。

这种方式虽然通过运维的方式标准化掉了，配置变更的接口就可以通过一个配置控制器来统一操作各个应用变更。

但是呢在这个脚本中啊，各个应用方啊依然使用着各种不同的方式来变更配置。

这种方式的好处呢是布偶合语言啊比较灵活。

但是呢对于标准化的建设啊可能不利，而且呢使用或者调用脚本是bug,很多的东西容易出问题。

那第三个方案呢就是结合上述两个方案，不使用开发阶段的SDK方式嵌入到应用服务中，而是为每个应用服务啊单独做一个agent.那这个agent呢对外以admin API的方式来服务，后面呢则适配应用的配置变更的手段啊，比如更新配置文件或者调用应用的API等等。

那这种方式在落地方面是很不错的那最后呢我们来谈一谈配置中心的设计重点。

配置中心它主要的用处呢是统一和规范化管理，所有的服务配置也算是一种配置上的治理活动。

所以呢配置中心的设计重点应该放在如何统一和标准化软件的配置下。

那它呢还会涉及到软件版本、运行环境、平台、中间件等一系列的配置参数。

如果你觉得软件配置非常复杂，那么呢你应该静下心来仔细梳理啊，或者治理一下现有的配置参数，并简化相应的配置。

那使用模块呢会是一种比较好的简化手段。

根据我们前面编程范式，游记中所说的编程的本质呢是对logic和control的分离。

所以呢对于配置啊也一样，它呢也有控制面上的配置和业务逻辑面上的配置。

那控制面上的配置啊最好能够标准统一配置，更新的时候啊，是一个事务处理啊，需要考虑事物的问题。

那如果变更不能继续的话啊，需要回滚到上个版本的配置。

那配置版本啊最好和软件版本对应上配置更新控制器呢需要应用服务的配合，比如配置的reload服务的优雅，重启服务的admin API,或者呢通过环境变量等等。

那这些呢最好是由一个统一的开发框架来搞定。

配置更新控制器呢还担有服务启动的责任，由配置更新控制器啊来启动服务。

那这样呢配置控制器啊会从配置中心拉去所有的配置更新操作系统设置好启动时用的环境变量，并更新好服务需要的配置文件啊，然后呢启动服务。

那当然呢你也可以在服务启动的脚本中，真正的启动服务之前啊，放上一段让配置更新控制器更新配置的脚本。

无论怎么样，这些啊都可以在运维层面来实现啊，不需要让业务开发人员知道。

好了，我们来总结一下今天分享的主要内容。

首先呢，传统单机软件的配置啊通常保存在文件中。

但是呢在分布式系统下，为了管理方便，必须有一个配置中心。

然后呢，我讲了配置的区分，分别是按静态和动态运行、环境依赖和层次来区分。

那进一步呢从区分出的情况出发，在层次方面，平台中间件和应用三个层次，由不同职责的运维人员来配置。

外部依赖的配置呢并不适合放在配置中心里，而最好呢是由服务发现系统来提供开发环境和生产环境的日志级别啊，配置也会不同。

那出于这些特点啊，我们可以用一个配置管理工具来管理这些配置。

那接着呢我介绍了配置管理架构中几个关键问题的解决思路。

最后呢我介绍了配置中心的几个设计重点，在下一节课啊，我们会讲述编车模式，希望能对你有帮助。

也欢迎你分享一下你的分布式系统用到配置中心了吗？它是怎样实现的呢？配置的动态更新又是怎么处理的呢？有没有版本管理和服务的版本又是怎么关联的呢？文末呢我给出了分布式系统模式系列文章的目录，希望你能在这个列表里啊找到自己感兴趣的内容。