做一个集中化配置管理系统，根据运维团队的需求，要考虑应用灰度发布时配置部分变更的可能，需求是首先变更某个机房的某台服务器上的配置，进一步地，修改该机房所有服务器的配置，最后修改全局服务器的配置。这样的需求和通常理解的灰度发布有一定区别，暂且叫他灰度配置。本文主要理解下两种灰度的差异，并且简要说明两种灰度的实现方案。

集中管理和灰度概念

集中化配置管理系统：指的是指将原本散乱存放在各个服务器上的配置（通常的配置文件），集中在统一的平台进行管理，配置管理员可以在该平台上对配置进行增删改查，而每一个需要配置的节点在启动时主动向平台获取。进一步地，在配置发生变化时，主动通知到所有使用该配置的节点，以达到动态配置变更的目的。现在大的互联网公司都有自己的一套集中化配置管理系统，比如阿里巴巴的diamond系统，apache的zookeeper等。

灰度发布

应用的灰度发布指的是，新系统发布时不直接废止旧的系统，而是有一段新旧系统的共存时间。通过逐渐增加新系统承担的负载权重，直到完全替代旧的系统。这样的好处在于避免因为新系统存在功能异常或者设计上的不合理导致的服务完全中断，通过渐进式观测新系统替代旧系统的效果，达到平缓升级的目的。理解来说，就是在一段时间内，通过流量源头的开关控制，动态调整新旧系统承担的负载。

灰度配置

一个系统的服务器集群中，不同机器使用不同的配置，每一次，调整一批机器的配置，最终达到全系统配置统一。可以这么理解，相同系统的不同服务节点使用不同的配置，叫他灰度配置。

灰度发布和灰度配置的差异和实现

差异

灰度发布和灰度配置概念完全不同，灰度发布的过程，大家都是一样的标准，一视同仁。恢复配置特点是只是针对一部分人，但每一个被选中的人都要一分不剩。

灰度发布设计

关于灰度发布业界已经有比较成熟的实现，在需要灰度系统系统的前置流量入口系统上增加一个选择功能，先做一次发布。然后需要灰度发布的下游系统，将新系统部署上去，和老系统共存。灰度发布过程中，通过修改一个权重配置并推送到控制流量的前置入口系统上，将部分流量引向新的系统，并观察新系统的表现。逐渐地，继续修改权重配置，增加新系统承担的流程，直到新系统完全承担所有流量，下线老系统。

灰度配置设计

关于灰度配置，有一个种设计是，将配置做一个层级的划分。一共分为6层，包括：全局配置，全局灰度配置，机房配置，机房灰度配置，节点配置，节点灰度配置。优先级是，节点灰度配置>节点配置>机房灰度配置>机房配置>全局灰度配置>全局配置。也即是说对业务来说的一个配置，在底层存储实际上是6个配置。对于一个配置的需求者，每次启动获取6个配置的内容，然后根据优先级选择自己应该加载的配置。进一步地，他需要关注6个配置的变更情况，一旦当前配置被删除，需要重新根据优先级选择自己应该加载的配置内容。

灰度配置设计的思考

灰度配置方案存在的缺点

1. 配置的设计过于复杂，6个配置很可能让运维人员陷入混乱。
2. 配置级别不灵活，比如新增一个城市级别的配置就足够让所有应用跳脚；又在比如，因为服务器可能存在上线，下线或者迁移的情况，一次机房级别的配置变更，如何确认变更的服务器列表是否正确。

灰度配置方案缺陷分析

以上2个缺点，核心的问题在于一个配置管理系统做了一些可能不应该由他做的事情，比如负责节点的定义，机房的定义，灰度的定义等等，导致了设计上复杂和维护上的难度。当然，业务方有这样的需求，自然是要想方设法去做满足，以下提供一种新的设计方案，可以解决或者部分解决以上2个问题。

灰度配置新方案

新方案及运行时状态描述

1. 去掉6个级别的配置，改成2个级别，即全局配置和临时配置，优先级为临时配置>全局配置。
2. 增加机器分组的功能，该功能只在灰度发布时候临时使用。

• 正常运行时，一个配置需求者只需要关注全局配置以及自身的分组信息，灰度发布前，所有机器使用全局配置正常运行。
• 当灰度发布的时候，建立一个空的群组，为该群组设置临时配置信息，逐渐地，往该群组中添加机器信息，直到机房所有节点或者全局所有节点都放入。事情发生的时候，每个配置需求者发现自己的分组信息发生变化（即加入某个群组），就去获取该群组的临时配置信息，优先使用。
• 直到所有机器都归入该群组后，即表示灰度完成，所有节点配置一致。这时候，将全局配置更新为灰度配置，并取消组群关系。事情发生时，每个配置需求者发现自己的分组信息发生变化（即分组被删除），就去获取全局配置，正常地，因为全局配置的内容和灰度配置内容一致，配置需求者不产生任何变化（因为变化已经在灰度的过程中发生过了）。

新方案的优劣分析

1. 该方案将原来多级别的配置设计改成全局和临时2个级别，而且临时配置只在灰度发布时使用，设计上简单可控。
2. 群组功能足够灵活，将机器分组属性的判断抽象出来（重点），在满足业务灰度配置功能的前提下，保持自身的逻辑足够简单。

• 对于分组功能，刚开始可以由运维人员手动添加一些模板，每个模板组保存一个机房的服务器列表，然后在实际发布的过程中，可以直接copy模板组的内容，也可以根据实际需要构建一些临时的分组，以组为单位变更配置，这样就满足了运维人员分批推送配置的需求。
• 进一步地，可以构建一个运维管理系统，专门负责管理服务器的信息。将该系统和集中化配置管理系统进行对接，在每次发布时动态地获取分组信息，就能免去人工维护分组的麻烦。
• 当然，既然是分组，就会遇到一个问题，当遇到一台机器被归入多个临时分组的情况应该怎么办。有一种方法是对临时分组设置优先级，根据优先级决定读取哪个临时分组的配置信息，不过这种方法比较复杂，而且优先级很难定义且有存在重复的可能。另一种方法就是直接互斥，针对同一个配置，一台机器只能被放入一个临时分组中，这样逻辑会更简单。