现代应用架构中的配置管理面临的挑战和应对之道
摘要：过去15年中，互联网产业开始蓬勃发展，基于互联网的各类应用大放异彩，而在信息技术上，企业应用架构也逐渐从传统的ERP，JavaEE集中式应用开始走向互联网、云计算、分布式服务化架构的转型，在这个过程中，数据中心及应用的配置管理这个领域也发生了深刻的变化。本文简单介绍了在现代企业应用架构中，传统的围绕分散的配置文件为中心的配置管理方式在面对诸如微服务、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”) 的配置管理方式。
而下面产品都是中心化管理配置思想的著名代表，虽然这些产品各自涵盖的领域和解决方案各不相同，但集中化管理应用配置的思想是惊人的一致
- 阿里巴巴 Diamond
- Puppet
Puppet是一个面向描述语言的配置管理工具，其在数据中心资源编排，帮助企业实现IaC，DevOps等方面有很大的价值，但其部署使用学习成本偏高，往往让人望而却步。 - Spring Cloud Config
- Hashicorp Consul
这其中，诞生于2007年淘宝进行服务化拆分和整体技术架构升级的配置中心产品Diamond，无疑是这条配置管理变革之路最早的践行者。
ACM 产品介绍
阿里集团在2007年进行从去IOE集中式应用架构升级为互联网分布式服务化架构的时候，就意识到在分布式环境中，传统的分散式的、基于配置文件的、应用自包含的配置管理方式将面临重大挑战，亟需设计匹配新架构的新的配置管理解决方案，解决诸如分布式服务治理，数据源容灾切换，异地多活，预案，限流规则等场景下的配置变更以及热生效问题，这直接导致了今天阿里集团内部被广泛使用的配置中心的诞生，而这也是目前世界上最大的生产配置中心，存储了超过100万的生产配置，在集团内部支持了包括淘宝、天猫、菜鸟、阿里云、高德等全网所有的应用，每天产生近10亿次的配置变更推送，可以说阿里集团的每一台生产机器每一刻都与配置中心有不间断的连接和交流。
阿里云开放公测的ACM产品就脱胎于阿里巴巴10年来的配置中心实践。该产品旨在帮助阿里云用户更好的管理应用的所有配置，通过提供诸如配置推送及推送状态追踪，配置历史版本管理，多环境管理，灰度发布，敏感配置加密等一系列的常用工具帮助企业提高配置管理效率和减少因配置变更引起的系统可用性风险，帮助企业更好的实施DevOps.
企业级应用配置中心
这里讨论一下一个可以用户企业级生产，大规模应用的配置中心产品，需要在哪些关键点上有必要的设计约束。
- SLA保障
当系统的调整了某个配置之后，我们期望配置变更立即生效，所以这对配置管理平台的SLA要求很高，配置变更一般要求起码是秒级生效，同时在配置变更的大规模推送(例如万台)场景下，收敛速度要越快越好，最好不要超过分钟级别。
- 容灾考虑
当应用在正常运行过程中，不涉及配置变更的时候，配置管理平台及时宕机应该也不影响应用正常运行甚至是应用重启。
- 灰度能力
每个配置项对业务系统的影响是不一样的，有的配置项如全局路由规则，全局限流规则是核武器级别的配置，一旦配置错误，很可能对生产全网产生毁灭性的影响，所以配置管理平台必须支持灰度推送配置的能力。
- 配置审计及历史追踪
在生产故障追踪中，知道故障时间段哪些系统修改了配置，由谁修改的，改成了什么对于故障恢复和追踪都有重大的意义。
ACM产品架构概览
ACM产品的架构整体非常简洁，这给用户带来了产品易用性，也让在产品在多数据中心及大规模企业生产中表现的非常稳定和容易运维。在刚过去的2017天猫双11大促狂欢节中，ACM服务轻松了支持当天过2亿次的配置变更推送。
ACM 开放公测功能列表
阿里巴巴配置中心10年实践过程中的经验既复杂又庞大，在面向外部更广泛的用户市场时，很多特性需要面向外部用户重构以让它们变得更容易理解和使用，所以，在第一期我们仅开放公测部分核心功能，完整的特性将在未来逐步开放给用户，下面是主要的特性列表：
ACM是免费的
- 是工具的极致而不是营收的极致
ACM产品的定位是阿里云的工具类产品，其主要旨在帮助用户更好的在阿里云上管理自己应用的配置，对于工具类产品，阿里云的目标只有一个，提供极致顺手易用的工具，不设营收目标，这能让产品更关注在本身要帮用户解决的问题上，所以在公有云上ACM产品是免费的! 免费! 免..的!
我们期待和欢迎大家提供宝贵的意见帮助我们持续改进产品，
可以通过扫下面钉钉二维码(或者搜索群号11724717)加入群反馈意见或者您也可以发邮件到guoping.gp@alibaba-inc.com咨询。
