1. 配置的环境属性
毫无疑问，在系统持续交付的过程中，系统最终运行环境的多样性及复杂性毫无疑问增加了我们在配置管理工作上的负担，有时候，甚至不夸张的说，配置就是因环境而生。
这在Eugen Paraschiv的博文 Configuration Must Be Environment Specific里有简单的阐述，在我的博文《现代应用架构中的配置管理面临的挑战》 的容器化、调度与配置管理小节也有深入的阐述。
如果要问，是什么导致了我们应用的构建物(artifact)在各个环境不能保持一样，有时候Docker无法轻易达成“Build Once， Run Anywhere!"的承诺，其答案往往就是环境配置的差异，为帮助你理解，举一些简单的例子:
- 在开发环境中将logLevel设置为DEBUG,在预发环境logLevel设置为INFO,生产环境里logLevel设置为WARNING
- 在开发环境中使用4核8G的机器跑数据库，而在生产中用32核96G机器跑数据库
- 在日常环境执行线程池的最大线程数应该设置为15，而生产环境上这个值应该大一点，默认设为150
- 在线上环境中，中心机房，应用数据源需要连接A库，而深圳机房，应用应该就近连接使用B库
- 只有在小淘宝环境，双向同步开关才应该关闭
- 这次的改动有点大，新的特性仅在线上的杭州单元把该特性开放出来，其它的单元环境先不要开放出来
本文我们就如何使用阿里云ACM这样的配置管理产品在Spring Cloud中替代Spring Cloud Config帮助简化环境配置管理做一个简单的示例，帮助你理解基于ACM来简化微服务环境配置管理的方案，并会简单比较一下ACM与Spring Cloud Config方案的优劣。
2. 场景故事
为了帮助理解需求和场景，在日常工程实践中，我们一般会用用户故事（User Story）的方式，预设一个简单的场景，以此来做阐释和交流，熟悉微服务历史的兄弟一定熟悉下面这张早期的布道图:
本文中我们就以Movie Service为例，假设我们需要从关系数据库MySQL(RDS)检索所有电影信息列表，但是在测试环境、预发和生产环境我们需要使用不同的数据库，因为只有生产库才需要顶配的机器。这样我们的应用需要在不同的环境配置不同的数据源配置、连接池配置、数据库安全配置等等，我们会介绍如何基于阿里云ACM的Namespace映射不同环境的能力，为movie service在不同运行环境设置不同的数据源配置。