做一个集中化配置管理系统，根据运维团队的需求，要考虑应用灰度发布时配置部分变更的可能，需求是首先变更某个机房的某台服务器上的配置，进一步地，修改该机房所有服务器的配置，最后修改全局服务器的配置。这样的需求和通常理解的灰度发布有一定区别，暂且叫他灰度配置。本文主要理解下两种灰度的差异，并且简要说明两种灰度的实现方案。
集中管理和灰度概念
集中化配置管理系统：指的是指将原本散乱存放在各个服务器上的配置（通常的配置文件），集中在统一的平台进行管理，配置管理员可以在该平台上对配置进行增删改查，而每一个需要配置的节点在启动时主动向平台获取。进一步地，在配置发生变化时，主动通知到所有使用该配置的节点，以达到动态配置变更的目的。现在大的互联网公司都有自己的一套集中化配置管理系统，比如阿里巴巴的diamond系统，Apache的zookeeper等。
灰度发布
应用的灰度发布指的是，新系统发布时不直接废止旧的系统，而是有一段新旧系统的共存时间。通过逐渐增加新系统承担的负载权重，直到完全替代旧的系统。这样的好处在于避免因为新系统存在功能异常或者设计上的不合理导致的服务完全中断，通过渐进式观测新系统替代旧系统的效果，达到平缓升级的目的。理解来说，就是在一段时间内，通过流量源头的开关控制，动态调整新旧系统承担的负载。
灰度配置
一个系统的服务器集群中，不同机器使用不同的配置，每一次，调整一批机器的配置，最终达到全系统配置统一。可以这么理解，相同系统的不同服务节点使用不同的配置，叫他灰度配置。
灰度发布和灰度配置的差异和实现
差异
灰度发布和灰度配置概念完全不同，灰度发布的过程，大家都是一样的标准，一视同仁。恢复配置特点是只是针对一部分人，但每一个被选中的人都要一分不剩。
灰度发布设计
关于灰度发布业界已经有比较成熟的实现，在需要灰度系统系统的前置流量入口系统上增加一个选择功能，先做一次发布。然后需要灰度发布的下游系统，将新系统部署上去，和老系统共存。灰度发布过程中，通过修改一个权重配置并推送到控制流量的前置入口系统上，将部分流量引向新的系统，并观察新系统的表现。逐渐地，继续修改权重配置，增加新系统承担的流程，直到新系统完全承担所有流量，下线老系统。
灰度配置设计
关于灰度配置，有一个种设计是，将配置做一个层级的划分。一共分为6层，包括：全局配置，全局灰度配置，机房配置，机房灰度配置，节点配置，节点灰度配置。优先级是，节点灰度配置>节点配置>机房灰度配置>机房配置>全局灰度配置>全局配置。也即是说对业务来说的一个配置，在底层存储实际上是6个配置。对于一个配置的需求者，每次启动获取6个配置的内容，然后根据优先级选择自己应该加载的配置。进一步地，他需要关注6个配置的变更情况，一旦当前配置被删除，需要重新根据优先级选择自己应该加载的配置内容。
灰度配置设计的思考
灰度配置方案存在的缺点
灰度配置方案缺陷分析
以上2个缺点，核心的问题在于一个配置管理系统做了一些可能不应该由他做的事情，比如负责节点的定义，机房的定义，灰度的定义等等，导致了设计上复杂和维护上的难度。当然，业务方有这样的需求，自然是要想方设法去做满足，以下提供一种新的设计方案，可以解决或者部分解决以上2个问题。
发表评论