如何用ACM简化你的Spring Cloud微服务环境配置管理

摘要： 本文我们就如何使用阿里云ACM这样的配置管理产品在Spring Cloud中替代Spring Cloud Config帮助简化环境配置管理做一个简单的示例，帮助你理解基于ACM来简化微服务环境配置管理的方案，并会简单比较一下ACM与Spring Cloud Config方案的优劣。

毫无疑问，在系统持续交付的过程中，系统最终运行环境的多样性及复杂性毫无疑问增加了我们在配置管理工作上的负担，有时候，甚至不夸张的说，配置就是因环境而生.

这在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方案的优劣。

为了帮助理解需求和场景，在日常工程实践中，我们一般会用用户故事（User Story）的方式，预设一个简单的场景，以此来做阐释和交流，熟悉微服务历史的兄弟一定熟悉下面这张早期的布道图:

本文中我们就以Movie Service为例，假设我们需要从关系数据库MySQL(RDS)检索所有电影信息列表，但是在测试环境、预发和生产环境我们需要使用不同的数据库，因为只有生产库才需要顶配的机器。这样我们的应用需要在不同的环境配置不同的数据源配置、连接池配置、数据库安全配置等等，我们会介绍如何基于阿里云ACM的Namespace映射不同环境的能力，为movie service在不同运行环境设置不同的数据源配置。

如下图所示:

• 新建Spring Boot Starter 微服务应用 movie service

  
  

movie service的业务逻辑很简单，从MySQL(RDS)里列出所有的movie列表，如下简图所示:

这里我们创建了一个标准的jpa应用（类似Spring官网的样例工程 Accessing data with MySQL，我们的工程结构如下图所示:

• 引入JPA、MySQL、连接池HikariCP以及WEB依赖

  
  

• 创建 MySQL(RDS) 数据库及用户

  
  

具体可参考 Accessing data with MySQL 中的 'Create the database'小节

• 创建 WEB Controller

  
  

注: 在阿里云上使用ACM的前提是开通了该项服务，具体开通流程可以参考文档ACM 快速入门，开通服务并登陆之后，即可进入 ACM 控制台 创建命名空间及配置

• 在ACM中创建3个环境 (dev,stage,prod)

  
  

• 为 dev,stage,prod 不同环境分别创建配置

  
  

注意 我们完成了什么?
在上一步中，我们为相同配置项针对不同环境的设置了不同的值，例如 'spring.datasource.url'这个配置项，我们通过设置不同的url来为各环境连接不同的数据库，并且仅在生产环境开启SSL (useSSL=true)

同时，我们也为生产环境(prod)设置了更大的数据库连接池和更小的连接超时时间

而为了方便开发调试，我们仅在开发环境打开了SQL Trace

现在我们将集成Movie Service与ACM以便从ACM中获取对应环境的配置. 关于如何在Spring Cloud中使用ACM，具体可以参考ACM官方文档 开发指南 > SDK 参考 > Spring Cloud ACM

• 为movie service引入ACM依赖

  
  

• 在application.properties配置ACM连接信息、namespace、accessKey、secretKey等信息

  
  

注意: 你可以在ACM的'命名空间详情'或者'配置的示例代码'里找到你的namespace_id，accessKey，secretKey等信息，如下图所示:

如果在movie service引入了spring-boot-starter-actuator依赖并且在application.properties设置了management.security.enabled=false,可以通过端点 http://<>/acm 看到应用的配置消费及刷新情况，如下图:

也可以在ACM控制台上查看配置的推送轨迹、配置版本等信息，具体使用方法可参考ACM官方文档，在此不再赘述。

• 在我的博文《现代应用架构中的配置管理面临的挑战》 里有长篇幅的侧面论述。

• 如果测试、生产因为配置打出来的包不一样，如何保证你的测试是有效的？

  
  

关注微服务的开发者一定拜读过下面这本微服务圣经

在上书中的第6.7及6.8小节对于环境和配置有非常精彩的阐述，这里将原文引用在此

6.8 服务配置

服务需要一些配置。理想情况下，这些配置的工作量应该很小，而且仅仅局限于环境间配置的差异。如果你的配置修改了很多服务的基本行为，或者不同环境之间的配置差异很大，那么你可能就只能在一套环境中发现某个特定的问题，这是极其痛苦的事情。

所以，如果存在不同环境之间的配置差异，应该如何在部署流程中对其进行处理呢？一种方法是对每个环境创建不同的构建物，并把配置内建在该构建物中。刚开始看这种方法好像挺有道理。配置已经被内建了，只需要简单的部署，它应该就能够正常工作了，对吧？其实这是有问题的。还记得持续交付的概念吗？我们想要创建一个构建物作为候选发布版本，并使其沿着流水线向前移动，最终确认它能够被发布到生产环境。想象一下，我构建了一个Customer-Service-Test构建物和Customer-Service-Prod构建物。如果Customer-Service-Test构建物通过了测试，但我真正要部署的构建物却是Customer-Service-Prod，又要如何验证这个软件最终会真正运行在生产环境中呢？

还有一些其他的挑战。首先，创建这些构建物比较耗时。其次，你需要在构建的时候知道存在哪些环境。你要如何处理敏感的配置数据？我可不想把生产环境的数据库密码提交到源代码中，但是如果在创建这些构建物时需要的话，通常这也是难以避免的。

一个更好的方法是只创建一个构建物，并将其配置单独管理。从形式上来说，这针对的可能是每个环境一个属性文件，或者是传入到安装过程中的一些参数。还有一个在应对大量微服务时比较流行的方法是，使用专用系统来提供配置，第11章会详细讨论这个话题。

当应用部署之后运行过程中，尤其是部署在多台服务器上之后，如果使用开发人员或者运维人员手工维护配置文件的方式，日积月累之后，会产生我们所谓的"配置飘移"问题，即由于应用以及依赖的组件的版本变更带来的配置差异，以及不同的团队或者人的多次不同时间点做的不同的修改会导致数据中心中每台机器上的相同的应用的配置在各台机器上或多或少都有细微的差别，而这往往是bug和重大故障隐藏之所。

在本文中，我们以一个测试和生产连接不同的数据库，配置不同的数据源(包括连接池)参数为例，介绍了如何将阿里云配置中心ACM与Spring Cloud一起使用，帮助你在微服务架构中简化你的环境配置管理。

本文的样例工程可以从movie-service.tar.gz下载

该工程我们在以下版本环境测试通过:

• Spring Cloud Edgware . RELEASE

• Spring Boot 1.5.9.RELEASE

• HikariCP 2.7.6

• MySQL 5.7.11

• ACM 4.2.0

• ACM Spring Cloud SDK 1.0.1

  
  

在你本地运行该工程前，请注意在application.properties里面设置你自己的ACM accessKey和secretKey.