应用配置中心Apollo
应用配置中心Apollo
- 应用配置中心Apollo-讲义
-
- 主要内容
- 1 配置中心简介
-
- 1.1 什么是配置
- 1.2 传统配置形式存在的问题
- 1.3 配置中心的作用
- 2 Apollo简介
-
- 2.1 主流配置中心产品
- 2.2 Apollo概况
- 2.3 Apollo特性
- 2.4 产品对比
- 2.5 Apollo初体验
-
- 2.5.1 访问控制台
- 2.5.2 添加/修改配置项
- 2.5.3 发布配置
- 2.5.4 浏览全貌
- 3 使用Apollo
-
- 3.1 运行环境
- 3.2 搭建数据库环境
- 3.3 启动Apollo
- 3.4 核心概念
- 3.5 玩转Apollo
-
- 3.5.1 基础设置
- 3.5.2 创建项目
- 3.5.3 添加公共Namespace
- 3.5.4 添加配置项
- 3.5.5 关联公共组件Namespace
- 3.5.6 添加私有Namespace
- 3.6 集群配置
- 4 微服务集成Apollo客户端
-
- 4.1 添加依赖
- 4.2 添加配置
-
- 4.2.1 配置文件
- 4.2.2 启动参数
应用配置中心Apollo-讲义
主要内容
1）了解配置中心的概念以及使用场景
2）了解主流配置中心和Apollo
3）掌握如何部署和使用Apollo
4）会通过springBoot集成Apollo
1 配置中心简介
1.1 什么是配置
配置是程序员最熟悉的代码之一，每天如影随形的陪伴着我们，也伴随着应用的整个生命周期。我们为什么要在应用程序中使用配置呢？主要用于提升应用程序的灵活性、可扩展性和可维护性。常见的配置形式有：
-
环境变量
-
启动参数
-
配置文件，例如：xxx.xml、xxx.properties、xxx.yml等
-
Shell脚本，例如：xxx.bat、xxx.sh等
-
基于数据库，就是把配置信息持久化到数据库中
1.2 传统配置形式存在的问题
- 缺少权限控制：由于配置能改变程序的行为，不正确的配置甚至能引起灾难，所以对配置的修改必须有比较完善的权限控制
- 缺少版本控制：在整个开发过程中，配置会经常发生修改，版本控制非常必要
- 缺少实时控制：配置发生变化后，需要重启才能生效，费时费力，迫切需要实时生效(热发布)
- 微服务化和分布式带来的挑战
-
当系统从一个单体应用，被拆分成分布式系统上一个个服务节点后，配置文件也必须跟着迁移（分割），这样配置就变得非常分散，造成使用和管理难度变大。不仅如此，各个节点服务的配置中难免会包含很多冗余代码。
-
同一个应用程序在不同的环境（开发，测试，生产）和不同的集群经常需要有不同的配置，需要能方便得进行动态切换。
1.3 配置中心的作用
配置中心将配置从各个应用中剥离出来，自成一体，对所有的配置进行单独的统一管理，优雅的解决了上述诸多问题。在系统架构中，和安全、日志、监控等非功能需求一样，配置管理也是一种非功能需求。配置中心是整个微服务基础架构体系中的一个组件。总得来说，配置中心就是一种统一管理各种应用配置的基础服务组件。
2 Apollo简介
2.1 主流配置中心产品
-
Disconf
2014年7月百度开源的配置管理中心，专注于各种「分布式系统配置管理」的「通用组件」和「通用平台」, 提供统一的「配置管理服务」。目前已经不再维护更新。
https://github.com/knightliao/disconf
-
Spring Cloud Config
2014年9月开源，Spring Cloud 生态组件，可以和Spring Cloud体系无缝整合。
https://github.com/spring-cloud/spring-cloud-config
-
Apollo
2016年5月，携程开源的配置管理中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。
https://github.com/ctripcorp/apollo
-
Nacos
2018年6月，阿里开源的配置中心，也可以做DNS和RPC的服务发现。
https://github.com/alibaba/nacos
2.2 Apollo概况
Apollo - A reliable configuration management system
Apollo（阿波罗）是携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。服务端基于Spring Boot和Spring Cloud开发，打包后可以直接运行，不需要额外安装Tomcat等应用容器。Java客户端不依赖任何框架，能够运行于所有Java运行时环境。
2.3 Apollo特性
基于配置的特殊性，所以Apollo从设计之初就立志于成为一个有治理能力的配置发布平台，目前提供了以下的特性：
- 统一管理不同环境、不同集群的配置
- Apollo提供了一个统一界面集中式管理不同环境（environment）、不同集群（cluster）、不同命名空间（namespace）的配置。
- 同一份代码部署在不同的集群，可以有不同的配置，比如zookeeper的地址等
- 通过命名空间（namespace）可以很方便地支持多个不同应用共享同一份配置，同时还允许应用对共享的配置进行覆盖
- 配置修改实时生效（热发布）
- 用户在Apollo修改完配置并发布后，客户端能实时（1秒）接收到最新的配置，并通知到应用程序
- 版本发布管理
- 所有的配置发布都有版本概念，从而可以方便地支持配置的回滚
- 灰度发布
- 支持配置的灰度发布，比如点了发布后，只对部分应用实例生效，等观察一段时间没问题后再推给所有应用实例
- 权限管理、发布审核、操作审计
- 应用和配置的管理都有完善的权限管理机制，对配置的管理还分为了编辑和发布两个环节，从而减少人为的错误。
- 所有的操作都有审计日志，可以方便地追踪问题
- 客户端配置信息监控
- 可以在界面上方便地看到配置在被哪些实例使用
- 提供Java和.Net原生客户端
- 提供了Java和.Net的原生客户端，方便应用集成
- 支持Spring Placeholder, Annotation和Spring Boot的ConfigurationProperties，方便应用使用（需要Spring 3.1.1+）
- 同时提供了Http接口，非Java和.Net应用也可以方便地使用
- 提供开放平台API
- Apollo自身提供了比较完善的统一配置管理界面，支持多环境、多数据中心配置管理、权限、流程治理等特性。不过Apollo出于通用性考虑，不会对配置的修改做过多限制，只要符合基本的格式就能保存，不会针对不同的配置值进行针对性的校验，如数据库用户名、密码，Redis服务地址等
- 对于这类应用配置，Apollo支持应用方通过开放平台API在Apollo进行配置的修改和发布，并且具备完善的授权和权限控制
一句话：Apollo集成了数据库+Eureka+版本控制+权限管理+Http Long Polling … …
2.4 产品对比
由于Disconf不再维护，下面主要对比一下Spring Cloud Config、Apollo和Nacos。
| 功能点 | Spring Cloud Config | Apollo | Nacos |
|---|---|---|---|
| 配置实时推送 | 支持(Spring Cloud Bus) | 支持(HTTP长轮询1s内) | 支持(HTTP长轮询1s内) |
| 版本管理 | 支持(Git) | 支持 | 支持 |
| 配置回滚 | 支持(Git) | 支持 | 支持 |
| 灰度发布 | 支持 | 支持 | 不支持 |
| 权限管理 | 支持(依赖Git) | 支持 | 不支持 |
| 多集群 | 支持 | 支持 | 支持 |
| 多环境 | 支持 | 支持 | 支持 |
| 监听查询 | 支持 | 支持 | 支持 |
| 配置格式校验 | 不支持 | 支持 | 支持 |
总的来说，Apollo和Nacos相对于Spring Cloud Config的生态支持更广，在配置管理流程上做的更好，其成熟度和企业级特性要强于Spring Cloud Config。Apollo相对于Nacos在配置管理做的更加全面，Nacos则使用起来相对比较简洁，在对性能要求比较高的大规模场景更适合。但对于一个开源项目的选型，项目上的人力投入（迭代进度、文档的完整性）、社区的活跃度（issue的数量和解决速度、Contributor数量、社群的交流频次等），这些因素也比较关键。Apollo目前在国内开发者社区比较热，在Github上有超过1w5颗星，在国内众多互联网公司有落地案例，可以说Apollo是目前配置中心产品领域Number1的产品，所以从目前来看Apollo是最合适的配置中心选型。
2.5 Apollo初体验
2.5.1 访问控制台
体验URL:106.12.25.204:8070，账号/密码: apollo/admin
上图是Apollo配置中心中一个项目的配置首页
- 在页面左上方的环境列表模块展示了所有的环境和集群，用户可以随时切换。
- 页面中央展示了两个namespace(application和FX.apollo)的配置信息，默认按照表格模式展示、编辑。用户也可以切换到文本模式，以文件形式查看、编辑。
- 页面上可以方便地进行发布、回滚、灰度、授权、查看更改历史和发布历史等操作
2.5.2 添加/修改配置项
用户可以通过配置中心界面方便的添加/修改配置项
输入配置信息：
2.5.3 发布配置
配置项发生变化后，必须进行发布才能生效
填写发布信息：
2.5.4 浏览全貌
3 使用Apollo
3.1 运行环境
- Java
-
Apollo服务端：JDK 1.8+
-
Apollo客户端：JDK 1.7+
由于需要同时运行服务端和客户端，所以应该安装JDK 1.8+，另外请配置JAVA_HOME环境变量。
- MySQL
- 版本要求：5.6.5+
3.2 搭建数据库环境
Apollo服务端共需要两个数据库：ApolloPortalDB和ApolloConfigDB，ApolloPortalDB只需要在生产环境部署一个即可，而ApolloConfigDB需要在每个环境部署一套。
-
执行ApolloConfigDB_initialization.sql创建ApolloPortalDB数据库
-
执行ApolloPortalDB_initialization.sql创建ApolloPortalDB数据库
3.3 启动Apollo
-
确保端口未被占用：
Apollo会在启动3个服务，分别使用8070, 8080, 8090端口，请确保这3个端口当前没有被使用
2.打开runApollo.bat，修改数据库连接地址，数据库以及密码
2. 运行启动脚本：runApollo.bat，等待三个服务全部启动完毕
- 访问管理页面：http://localhost:8070 账号密码：apollo/admin
3.4 核心概念
-
项目(应用)
这个很好理解，就是实际使用Apollo配置中心的应用，该应用一般指的就是我们自己的微服务工程。通过引入Apollo客户端，就可以在运行时去配置中心获取对应的配置
关键字：appId
-
environment (环境)
配置对应的环境，Apollo客户端在运行时需要知道当前应用处于哪个环境，从而可以去获取应用的配置
关键字：env
-
cluster (集群)
一个应用下不同实例的分组，比如典型的可以按照数据中心进行划分，把上海机房的应用实例分为一个集群，把北京机房的应用实例分为另一个集群。
关键字：cluster
-
namespace (命名空间)
一个应用下不同配置的分组，可以简单地把namespace类比为文件，不同类型的配置存放在不同的文件中，如数据库配置文件，RPC配置文件，应用自身的配置文件等
关键字：namespaces
3.5 玩转Apollo
3.5.1 基础设置
- 部门管理
apollo 默认有两个样例部门，一般都不用，可以自己修改部门，在系统参数中修改：
- 输入key查询已存在的部门设置：organizations
- 用户管理
账号apollo是默认的超级管理员，我们可以自己添加新用户。在“管理员工具”菜单中点击“用户管理”。
3.5.2 创建项目
-
打开apollo-portal主页：http://localhost:8070/
-
点击“创建项目”
3.输入项目信息
- 部门：选择应用所在的部门
- 应用AppId：用来标识应用身份的唯一id，格式为string，需要和项目配置文件applications.properties中配置的app.id对应
- 应用名称：应用名，仅用于界面展示
- 应用负责人：选择的人默认会成为该项目的管理员，具备项目权限管理、集群创建、Namespace创建等权限
4. 点击提交
创建成功后，会自动跳转到项目首页
3.5.3 添加公共Namespace
在项目开发中，有一些配置可能是通用的，我们可以通过把这些通用的配置放到公共的Namespace中，这样其他项目要使用时可以直接添加需要的Namespace
- 新建common-template项目
2.添加公共Namespace
进入common-template项目管理页面：http://localhost:8070/config.html?#/appid=common-template
3.5.4 添加配置项
- 通过表格模式添加配置
- 点击新增配置
- 输入配置项
2.通过文本模式编辑
Apollo除了支持表格模式，逐个添加、修改配置外，还提供文本模式批量添加、修改。 这个对于从已有的properties文件迁移尤其有用
- 切换到文本编辑模式
- 输入配置项，并点击提交修改
server.servlet.context-path = /
spring.http.encoding.enabled = true
spring.http.encoding.charset = UTF-8
spring.http.encoding.force = true
3.发布配置
3.5.5 关联公共组件Namespace
-
打开之前创建的account-service项目：http://localhost:8070/config.html?#/appid=account-service
-
点击左侧的添加Namespace
3.添加Namespace
4.根据需求可以覆盖引入公共Namespace中的配置，下面以覆盖server.servlet.context-path为例
5.修改server.servlet.context-path为：/account-service
6.发布修改的配置项
3.5.6 添加私有Namespace
-
添加项目私有Namespace
-
添加配置项
3.发布配置
3.6 集群配置
在有些特殊情况下，应用有需求对不同的集群做不同的配置，比如部署在A机房的应用连接的RocketMQ服务器地址和部署在B机房的应用连接的RocketMQ服务器地址不一样。在这种情况下，可以通过在Apollo创建不同的集群来解决。
- 点击页面左侧的“添加集群”按钮
2.输入集群名称，选择环境并提交：添加上海金桥数据中心为例
3.切换到对应的集群，修改配置并发布即可
4 微服务集成Apollo客户端
4.1 添加依赖
在pom.xml中添加Apollo客户端
<dependency>
<groupId>com.ctrip.framework.apollogroupId>
<artifactId>apollo-clientartifactId>
<version>1.1.0version>
dependency>
4.2 添加配置
4.2.1 配置文件
- 在resources目录下新建apollo-env.properties文件
# 开发环境
dev.meta=http://localhost:8080
# 功能验收测试环境
fat.meta=http://apollo.fat.xxx.com
# 用户验收测试环境
uat.meta=http://apollo.uat.xxx.com
# 生产环境
pro.meta=http://apollo.xxx.com
- application.properties中进行如下配置
# 项目ID
app.id=account-service
# 启动阶段就注入配置(提高优先级)
apollo.bootstrap.enabled = true
# 使用哪些命名空间中的配置项
apollo.bootstrap.namespaces = application,micro_service.spring-boot-http,spring-rocketmq
# 服务端口
server.port=63000
4.2.2 启动参数
完整的VM Options如下：
-Denv=DEV -Dapollo.cluster=DEFAULT
-
Environment
可以通过Java的System Property的env来指定环境：
-Denv=DEV -
Cluster（集群）
通过Java的System Property的apollo.cluste来指定集群：
-Dapollo.cluster=DEFAULT