摘要: 本文我们就如何使用阿里云 ACM 这样的配置管理产品在 Spring Cloud 中替代 Spring Cloud Config 帮助简化环境配置管理做一个简单的示例,帮助你理解基于 ACM 来简化微服务环境配置管理的方案,并会简单比较一下 ACM 与 Spring Cloud Config 方案的优劣.
http://click.aliyun.com/m/41595/ 配置的环境属性
毫无疑问,在系统持续交付的过程中,系统最终运行环境的多样性及复杂性毫无疑问增加了我们在配置管理工作上的负担,有时候,甚至不夸张的说,配置就是因环境而生.
这在 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 在不同运行环境设置不同的数据源配置.
如下图所示:
创建微服务 Movie Service
新建 Spring Boot Starter 微服务应用 movie service
movie service 的业务逻辑很简单,从 MySQL(RDS) 里列出所有的 movie 列表,如下简图所示:
这里我们创建了一个标准的 jpa 应用(类似 Spring 官网的样例工程 Accessing data with MySQL ,我们的工程结构如下图所示:
引入 JPA,MySQL,连接池 HikariCP 以及 web 依赖
创建 MySQL(RDS) 数据库及用户
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>com.zaxxer</groupId>
<artifactId>HikariCP</artifactId>
<version>2.7.6</version>
</dependency>
具体可参考 Accessing data with MySQL 中的'Create the database'小节
mysql> create database db_example; -- Create the new database
mysql> create user 'springuser'@'localhost' identified by 'ThePassword'; -- Creates the user
mysql> grant all on db_example.* to 'springuser'@'localhost'; -- Gives all the privileges to the new user on the newly created database
创建 WEB Controller
在 ACM 中使用 Namespace 创建隔离的环境配置
package com.alibaba.demo.microsvc.controller;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.ResponseBody;
import org.springframework.web.bind.annotation.RestController;
import com.alibaba.demo.microsvc.dao.MovieRepository;
import com.alibaba.demo.microsvc.model.Movie;
@RestController
public class MovieController {
@Autowired
MovieRepository movieRepository;
@RequestMapping("/list-movies")
public @ResponseBody Iterable<Movie> listMovies() {
return movieRepository.findAll();
}
}
注: 在阿里云上使用 ACM 的前提是开通了该项服务,具体开通流程可以参考文档 ACM 快速入门,开通服务并登陆之后,即可进入 ACM 控制台 创建命名空间及配置
在 ACM 中创建 3 个环境 (dev,stage,prod)
为 dev,stage,prod 不同环境分别创建配置
注意 我们完成了什么
在上一步中,我们为相同配置项针对不同环境的设置了不同的值,例如'spring.datasource.url'这个配置项,我们通过设置不同的 url 来为各环境连接不同的数据库,并且仅在生产环境开启 SSL (useSSL=true)
同时,我们也为生产环境 (prod) 设置了更大的数据库连接池和更小的连接超时时间
dev:
spring.datasource.url=jdbc:mysql://localhost:3306/db_example?useSSL=false
>
prod:
spring.datasource.url=jdbc:mysql://30.5.101.169:3306/db_example?useSSL=true
>
而为了方便开发调试,我们仅在开发环境打开了 SQL Trace
dev:
spring.datasource.hikari.connection-timeout=60000
spring.datasource.hikari.maximum-pool-size=10
>
prod:
spring.datasource.hikari.connection-timeout=15000
spring.datasource.hikari.maximum-pool-size=200
>
Movie Service 与配置中心 ACM 集成
dev:
spring.jpa.show-sql=true
现在我们将集成 Movie Service 与 ACM 以便从 ACM 中获取对应环境的配置. 关于如何在 Spring Cloud 中使用 ACM,具体可以参考 ACM 官方文档 开发指南 > SDK 参考 > Spring Cloud ACM
为 movie service 引入 ACM 依赖
在 application.properties 配置 ACM 连接信息,namespace,accessKey,secretKey 等信息
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-acm</artifactId>
<version>1.0.1</version>
</dependency>
注意: 你可以在 ACM 的'命名空间详情'或者'配置的示例代码'里找到你的 namespace_id,accessKey,secretKey 等信息,如下图所示:
spring.application.name=movie-service
spring.application.group=com.alibaba.cloud.acm
alibaba.acm.endpoint=acm.aliyun.com
alibaba.acm.namespace=<your_namespace_id>
alibaba.acm.accessKey=<your_ak>
alibaba.acm.secretKey=<your_sk>
在浏览器里访问 Movie Service
查看 ACM 配置推送刷新信息
如果在 movie service 引入了 spring-boot-starter-actuator 依赖并且在 application.properties 设置了 management.security.enabled=false, 可以通过端点 http://<>/acm 看到应用的配置消费及刷新情况,如下图:
也可以在 ACM 控制台 上查看配置的推送轨迹,配置版本等信息,具体使用方法可参考 ACM 官方文档 ,在此不再赘述.
ACM 与 Spring Cloud Config 简单对比
扩展思考 - 为什么不把配置放到应用自身的 jar 包里?
在我的博文《 现代应用架构中的配置管理面临的挑战 》 里有长篇幅的侧面论述.
如果测试,生产因为配置打出来的包不一样,如何保证你的测试是有效的?
关注微服务的开发者一定拜读过下面这本微服务圣经
在上书中的第 6.7 及 6.8 小节对于环境和配置有非常精彩的阐述,这里将原文引用在此
6.8 服务配置
服务需要一些配置.理想情况下,这些配置的工作量应该很小,而且仅仅局限于环境间配置的差异.如果你的配置修改了很多服务的基本行为,或者不同环境之间的配置差异很大,那么你可能就只能在一套环境中发现某个特定的问题,这是极其痛苦的事情.
所以,如果存在不同环境之间的配置差异,应该如何在部署流程中对其进行处理呢?一种方法是对每个环境创建不同的构建物,并把配置内建在该构建物中.刚开始看这种方法好像挺有道理.配置已经被内建了,只需要简单的部署,它应该就能够正常工作了,对吧?其实这是有问题的.还记得持续交付的概念吗?我们想要创建一个构建物作为候选发布版本,并使其沿着流水线向前移动,最终确认它能够被发布到生产环境.想象一下,我构建了一个 Customer-Service-Test 构建物和 Customer-Service-Prod 构建物.如果 Customer-Service-Test 构建物通过了测试,但我真正要部署的构建物却是 Customer-Service-Prod,又要如何验证这个软件最终会真正运行在生产环境中呢?
还有一些其他的挑战.首先,创建这些构建物比较耗时.其次,你需要在构建的时候知道存在哪些环境.你要如何处理敏感的配置数据?我可不想把生产环境的数据库密码提交到源代码中,但是如果在创建这些构建物时需要的话,通常这也是难以避免的.
一个更好的方法是只创建一个构建物,并将其配置单独管理.从形式上来说,这针对的可能是每个环境一个属性文件,或者是传入到安装过程中的一些参数.还有一个在应对大量微服务时比较流行的方法是,使用专用系统来提供配置,第 11 章会详细讨论这个话题.
配置漂移
当应用部署之后运行过程中,尤其是部署在多台服务器上之后,如果使用开发人员或者运维人员手工维护配置文件的方式,日积月累之后,会产生我们所谓的 "配置飘移" 问题,即由于应用以及依赖的组件的版本变更带来的配置差异,以及不同的团队或者人的多次不同时间点做的不同的修改会导致数据中心中每台机器上的相同的应用的配置在各台机器上或多或少都有细微的差别,而这往往是 bug 和重大故障隐藏之所.
总结
在本文中,我们以一个测试和生产连接不同的数据库,配置不同的数据源 (包括连接池) 参数为例,介绍了如何将阿里云配置中心 ACM 与 Spring Cloud 一起使用,帮助你在微服务架构中简化你的环境配置管理.
来源: http://geek.csdn.net/news/detail/253616