本文简单介绍了在现代企业应用架构中，传统的围绕分散的配置文件为中心的配置管理方式在面对诸如微服务、DevOps、容器服务、云计算等新技术形式下面临的挑战，同时会探讨如何通过独立的配置中心服务集中式管理数据中心中的所有配置来解决这一挑战，同时会简单介绍在阿里云上，应用配置管理产品 ACM 如何帮助阿里云用户更轻松的管理应用配置来应对这些挑战。
配置
配置(Configuration) 这个概念每个技术人都不陌生，可以说一个不提供几个配置参数的系统都不好意思上线跟别的系统打招呼。那么为什么会是这个样子呢，究其本质是我们人类无法掌控和预知一切，映射到软件领域上，我们总是需要对系统的某些功能特性预留出一些控制的线头(配置项)，以便我们在未来需要的时候，可以人为的拨弄这些线头(配置项变更)从而控制系统的行为特征，我们把它叫做 “系统运行时(runtime)飞行姿态的动态调整”
配置管理
配置管理是软件生命周期的重要组成部分
在过去的大约15年左右，软件工程学在如何持续演进软件以满足不断变化的业务需求的方法论上有了很多的突破和大量的实践，在这个领域里，从最初的面向对象设计方法论，到后来出现的极限编程，到敏捷开发、单元测试驱动、持续集成，再到后来的DevOps等等，其理论和实践都已经比较成熟，而无论是在持续交付还是在DevOps中，配置管理都是其中极其重要的一个环节,在这个环节中我们会完成构建的“静态”软件与“动态”的实际的运行环境的适配过程，完成软件以及依赖的资源的部署过程，使静态的软件代码变成可以满足业务需求的在线运行的业务系统。如下图所示:
云计算与配置管理
利用云计算在云上构建现代企业应用已经被无数事例证明是极为有效地方式，在这个过程中可以方面的利用云计算提供的按需购买和使用，基础设施虚拟化带来的弹性和自动化以及易生成和易运维等特性大大的降低了维护基础设施的成本，同时也为用户在云计算上实施更为有效、更为自动化以及更为低成本的配置管理带来的可能性，从广义上讲，在云上，配置管理涵盖了包括硬件基础计算资源如主机和网络设备配置，主机、操作系统和基础软件配置以及应用自身配置三个方面的配置。而前两者一般已经包含在云计算基础设施交付的过程中，应用只需要更关注应用自身的配置。而利用云计算无疑可以更好的实施和真正实现Infrastructure as Code(IaC)。
分布式系统中的配置管理
分布式系统给配置管理带来的挑战
关于什么是分布式系统，本文不再赘述。关于分布式系统的一个重要论题是如何演进系统(Software Evolution),一个系统或者说软件从被创造出来之后会经历研发、测试、到最后的go live，上了生产系统。那么这个之后，如何持续并且无痛的为其添加新行为或者调整已有行为的表现特征? 这确实非常复杂，尤其是要达到无痛(Painless)的这个目标，毕竟线上系统，调整即意味着可能出故障。而系统的动态配置管理毫无疑问是其中的一个小部分，如果每一个系统行为的任何一个微调都需要将整个系统停机，重启或者甚至重新构建、发布部署来实现，那要达到无痛这个目标恐怕难度更高。
在分布式系统中，一次构建、发布、上线是非常非常重的一个过程，它不像单机时代那样重启一台机器、一个进程就可以了，在分布式系统中，它涉及到将软件包(例如war)分发到可能超过几千台机器，然后将几千台机器上的应用进程一一重启这么一个过程，如何通过更有效的动态配置管理手段介绍分布式系统发布值得认真思考。
传统的软件开发方式中，配置以配置文件的方式将随着软件构建过程中打包在构建的工件里(Artifact)，这意味着配置是分散在各个工件里的，这种管理配置的方式，在分布式系统中，将面临诸多挑战
配置变更的热生效
配置的本质是为调整应用运行时的飞行姿态，修改配置文件之后，如何让配置在多台生产机器上热生效？如果每次对生产环境配置的微调都要触发一次完整的应用构建、发布、灰度、上线的pipeline无疑是不可接受的。
配置文件在哪里？
分布式架构和微服务架构都倡导对于单块复杂系统的拆分，并由独立的团队自治的负责每个子系统的演进和发展，甚至允许选择不同的技术栈，但从整个分布式系统的角度看，当需要整体控制分布式系统的行为时，这种方式给配置管理带来了很大的麻烦，我们甚至无法知道每个应用开放了哪些配置? 配置文件在哪个目录?
登上20台机器改配置文件？
当机器多于2台时，一一登上机器修改配置文件将变得不可接受，并且往往需要依靠运维人员的自律性来并确保每台机器配置状态的一致性。
配置值生效了么?
配置变更之后，变更生效了么？什么时间点生效的? 应用运行一段时间后，当前的所有配置值是什么?
配置变更审计
系统故障是否与某次不恰当的配置变更有关?如果是，是谁修改的?何时修改的?
配置如何容灾
配置文件如何防止误删除，保证多级容灾?
如何在整个数据中心层面控制配置变更?
当业务计划或者需要一次大规模的诸如双11大促，新品发布这种活动时，在诸如关系国计民生的系统在诸如重大政治活动期间（如19大），控制系统的稳定性风险将变得非常重要，而如何在封网期间，禁止所有的配置变更也就成了理所当然的诉求。
微服务与配置中心
微服务架构的主旨在于将大的单块应用通过合理的服务化拆分为一个个独立的微服务，并授权给不同的小规模团队负责来实现系统之间更好的解耦合和独立演进，微服务系统天然是个分布式系统。在分布式系统中配置管理遇到的挑战微服务架构同样会遇到,在微服务架构关注点上,配置管理同样是不可或缺的一部分。
在微服务架构中，将配置管理服务独立抽象成一个服务，成为其它微服务的基础依赖，有助于实现配置状态的分离，从而使其它提供业务服务的微服务无状态化，利于每个服务快速的弹性部署和水平扩展，即时响应业务需求。
容器化、调度与配置管理
在著名的 十二要素应用宣言 中无论是关于应用无状态化还是多环境一致性
Execute the app as one or more stateless processes (以一个或多个无状态进程运行应用)
而在容器服务与调度中，当服务因为机器故障需要迁移或者需要实施水平扩展的过程中，配置状态的迁移会给调度系统带来极大的挑战。而严格实施代码与配置状态的分离是智能的自动调度应用的前提，配置是一种状态，一个微服务在bootstrap的时候，应该向配置中心询问其应该达到的配置状态，从而与已经在运行的其它服务副本保持一致。所以我们相信在未来，面向容器和调度亲和的应用应该满足如下的结构:
Keep development, staging, and production as similar as possible (尽可能的保持开发、预发布、线上环境相同)
如过要问，是什么导致了应用在各个环境不能保持一样，其答案往往就是配置! 举几个容易理解的表述，来帮助理解配置的环境属性
在开发环境中将logLevel设置为DEBUG,在预发环境logLevel设置为INFO,生产环境里logLevel设置为WARNING
在开发环境中使用4核8G的机器跑数据库，而在生产中用32核96G机器跑数据库
在日常环境执行线程池的最大线程数应该设置为15，而生产环境上这个值应该大一点，默认设为150
在线上环境中，中心机房，应用数据源需要连接A库，而深圳机房，应用应该就近连接使用B库
只有在小淘宝环境，双向同步开关才应该关闭
这次的改动有点大，新的特性仅在线上的杭州单元把该特性开放出来，其它的单元环境先不要开放出来
相信你一定发现了，某个配置项，其具体的值域的定义往往跟具体的环境相关联，现实中相当一部分配置在不同的环境必须设定不同的值，但是也有相当的另一部分配置在不同的环境要设定为完全一致的值。所以从应用的视角看，其100个配置项，可能有50个是每个环境要不同的值的，而另50个是不区分环境，所有环境其配置值都是需要完全一致的。这种异化给配置管理系统的设计带来了复杂性，而且这个最终语义的解释，很显然不应该在配置管理系统本身，应该交给应用，配置管理系统应该做的是提供方便的交互方式保证这两种不同的一致性诉求同时得到很好的满足，这种诉求分为3个方面，如下示意图:
从配置文件到配置中心
前面我们详细介绍了传统的围绕分散的配置文件为中心的配置管理方式，在这种方式中，应用开发和运维人员需要登录应用部署的机器上编辑，修改保存配置，为了配置生效，往往需要随之重新部署或者重启应用进程。
这种方式在面对诸如微服务、DevOps、容器服务、云计算等新技术形式下面临的挑战.
在这些年中，行业内在配置管理方面做出了很多被证明是有益的探索和实践，逐渐走向了外部化(Externalized)、集中化(Centralized)、不只是文件的(Not just a “file”) 的配置管理方式。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
