Apollo 配置中心详细教程
一、简介
Apollo(阿波罗)是携程框架部门研发的分布式配置中心,能够集中化管理应用不同环境、不同集群的配置,配置修改后能够实时推送到应用端,并且具备规范的权限、流程治理等特性,适用于微服务配置管理场景。
服务端基于 Spring Boot 和 Spring Cloud 开发,打包后可以直接运行,不需要额外安装 Tomcat 等应用容器。
Java 客户端 不依赖任何框架,能够运行于所有 Java 运行时环境,同时对 Spring/Spring Boot 环境也有较好的支持。
.Net 客户端 不依赖任何框架,能够运行于所有.Net 运行时环境。
官方 GitHub: https://github.com/ctripcorp/apollo官方 Gitee: https://gitee.com/nobodyiam/apollo
二、安装部署
2.1 环境准备
java: JDK 1.8.+maven: 3.3.9mysql: 版本要求(5.6.5+)查看数据库版本:SHOW VARIABLES WHERE Variable_name = 'version';
Apollo 服务端: 1.9+Apollo 客户端: 1.7+
2.2 安装包下载
源码下载 从(Apollo-github) 下载最新的源码,也可以通过 git 命令下载到本地
git clone https://github.com/ctripcorp/apollo
注意: 本文中使用的方式为 1.源码下载,进行演示。
2.3 创建数据库
Apollo 服务端总共需要两个数据库:ApolloPortalDB
和 ApolloConfigDB
我们可以在下载的源码包里面找到,文件目录为:apollo\scripts\sql
,路径如下图所示:
或者通过下载地址来获取 SQL
ApolloPortalDB
SQL 下载地址:https://github.com/ctripcorp/apollo/tree/master/scripts/sql导入成功后,验证 SQL:select * from `ApolloPortalDB`.`ServerConfig`;
ApolloConfigDB
SQL 下载地址:https://github.com/ctripcorp/apollo/tree/master/scripts/sql导入成功后,验证 SQL:select * from `ApolloConfigDB`.`ServerConfig`;
2.4 服务端配置调整(可选项)
1. ApolloPortalDB 库配置
操作表:ServerConfig
2. ApolloConfigDB 库配置
操作表:ServerConfig
2.5 打开工程
将下载下来的 Apollo 源码导入 idea 中,需要关注的项目主要是下面这三个:
我们找到 /apollo/scripts/build.bat
的文件(Linux 是 bulid.sh)
修改数据库配置信息,注意这是两个库(ApolloPortalDB
和 ApolloConfigDB
):
注意: 数据库连接,需要添加serverTimezone=UTC
否则可能会报错
修改完上面的配置以后,我们就可以执行build.bat
批处理命令进行编译打包。在 windows 运行build.bat
文件,如果是 LInux 运行 build.sh
第一次会执行比较慢,需要下载 Maven jar
打包成功后,我们找到 apollo-configservice、apollo-adminservice、apollo-portal
下 target 目录,找到已经打好的三个 jar 包,copy 出来放到一个单独的目录,方便我们启动
如下图所示:
启动顺序为:apollo-configservice > apollo-adminservice > apollo-portal
三个服务
启动脚本,放到记事本,修改后缀名为 .bat
就可以一键启动三个服务了
全部启动成功之后,打开浏览器输入:http://localhost:8070/,看到 Apollo 登录页面说明启动成功
用户名密码: apollo/admin
输入 http://localhost:8080 ,如果出现 eureka 的管理界面,说明服务启动正常。
三、客户端使用
3.1 导入 jar 包
3.2 发布配置
创建应用
AppId:001
AppId:mxn-front-gateway
AppId 是应用的身份信息,是从服务端获取配置的一个重要信息。
AppId:001 的配置内容
AppId:mxn-front-gateway 的配置内容
上面的两张图,就是我们 Apollo 配置中心的详细配置页面
在页面左上方的环境列表模块展示了所有的环境和集群,用户可以自由切换。
页面中央展示了两个 namespace 的配置信息,默认按照表格模式展示、编辑。用户也可以切换到文本模式,以文件形式查看、编辑。
页面上可以方便地进行发布、回滚、灰度、授权、查看更改历史和发布历史等操作
3.3 操作配置项
输入配置内容
3.4 发布配置
添加发布信息
四、Spring Boot 集成 Apollo
在 Spring Boot 中使用 apollo 配置比较方便,我们只需要在对应的配置(yml 或者 properties)中设置 apollo 的(appid 和 meta)以及命名空间就行
application.yml 配置
Spring Boot 启动类,添加 @EnableApolloConfig
测试类,实时获取配置信息
这样我们就可以 从 meta 中 拉取两个命名空间(apollo-adminservice 和 apollo-configservice)的配置了
Apollo
四、实现配置热加载
创建配置热加载实现类
我们 输入地址 http://localhost:你的端口/test 就可以看到,对应的配置名字,然后修改 apollo 里面的信息,发布后,再不启动项目的情况下,就可以更新我们的配置信息了
Apollo 本地缓存
Linux:/opt/data/{appId}/config-cacheWindows:C:\opt\data{appId}\config-cache
五、什么是 Apollo
官方案例: 使用案例 Demo 可以参考Apollo使用场景和示例代码。
5.1 诞生背景
随着程序功能的日益复杂,程序的配置日益增多:各种功能的开关、参数的配置、服务器的地址……
对程序配置的期望值也越来越高:配置修改后实时生效,灰度发布,分环境、分集群管理配置,完善的权限、审核机制……
在这样的大环境下,传统的通过配置文件、数据库等方式已经越来越无法满足开发人员对配置管理的需求。
Apollo 配置中心应运而生!
5.2 Apollo 说明
Apollo(阿波罗)是携程框架部门研发的开源配置管理中心,能够集中化管理应用不同环境、不同集群的配置,配置修改后能够实时推送到应用端,并且具备规范的权限、流程治理等特性。
Apollo 支持 4 个维度管理 Key-Value 格式的配置:
application (应用)
environment (环境)
cluster (集群)
namespace (命名空间)
同时,Apollo 基于开源模式开发,开源地址:https://github.com/ctripcorp/apollo
5.3 基础模型
Apollo 的基础模型:
用户在配置中心对配置进行修改并发布
配置中心通知 Apollo 客户端有配置更新
Apollo 客户端从配置中心拉取最新的配置、更新本地配置并通知到应用
六、Apollo 特性
由于配置的特殊性,所以 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 对外部依赖尽可能地少
目前唯一的外部依赖是 MySQL,所以部署非常简单,只要安装好 Java 和 MySQL 就可以让 Apollo 跑起来
Apollo 还提供了打包脚本,一键就可以生成所有需要的安装包,并且支持自定义运行时参数
七、Apollo 原理
上图简要描述了 Apollo 客户端的实现原理:
客户端和服务端保持了一个长连接,从而能第一时间获得配置更新的推送。
客户端还会定时从 Apollo 配置中心服务端拉取应用的最新配置。
这是一个 fallback 机制,为了防止推送机制失效导致配置不更新
客户端定时拉取会上报本地版本,所以一般情况下,对于定时拉取的操作,服务端都会返回 304 - Not Modified
定时频率默认为每 5 分钟拉取一次,客户端也可以通过在运行时指定 System >Property:
apollo.refreshInterval
来覆盖,单位为分钟。客户端从 Apollo 配置中心服务端获取到应用的最新配置后,会保存在内存中
客户端会把从服务端获取到的配置在本地文件系统缓存一份
在遇到服务不可用,或网络不通的时候,依然能从本地恢复配置
应用程序从 Apollo 客户端获取最新的配置、订阅配置更新通知
八、自定义 Cluster
8.1 新建 Cluster
点击后就进入到集群添加页面,一般情况下可以按照数据中心来划分集群不过也支持自定义集群,比如可以为 A 机房的某一台机器和 B 机房的某一台机创建一个集群,使用一套配置。
Apollo 会默认使用应用实例所在的数据中心作为 cluster,所以如果两者一致的话,不需要额外配置。
如果 cluster 和数据中心不一致的话,那么就需要通过 System Property 方式来指定运行时 cluster:
-Dapollo.cluster=SomeCluster
这里注意
apollo.cluster
为全小写
九、配置获取规则
在有了 cluster 概念后,配置的规则就显得重要了。比如应用部署在 A 机房,但是并没有在 Apollo 新建 cluster,这个时候 Apollo 的行为是怎样的?或者在运行时指定了 cluster=SomeCluster,但是并没有在 Apollo 新建 cluster,这个时候 Apollo 的行为是怎样的?
9.1 应用自身配置的获取规则
当应用使用下面的语句获取配置时,我们称之为获取应用自身的配置,也就是应用自身的 application namespace 的配置。
Config config = ConfigService.getAppConfig();
对这种情况的配置获取规则,简而言之如下:
首先查找运行时 cluster 的配置(通过 apollo.cluster 指定)
如果没有找到,则查找数据中心 cluster 的配置
如果还是没有找到,则返回默认 cluster 的配置
图示如下:
所以如果应用部署在 A 数据中心,但是用户没有在 Apollo 创建 cluster,那么获取的配置就是默认 cluster(default)的。
如果应用部署在 A 数据中心,同时在运行时指定了 SomeCluster,但是没有在 Apollo 创建 cluster,那么获取的配置就是 A 数据中心 cluster 的配置,如果 A 数据中心 cluster 没有配置的话,那么获取的配置就是默认 cluster(default)的。
十、总体设计
上图来自网络
上图简要描述了 Apollo 的总体设计,我们可以从下往上看:
Config Service 提供配置的读取、推送等功能,服务对象是 Apollo 客户端
Admin Service 提供配置的修改、发布等功能,服务对象是 Apollo Portal(管理界面)
Config Service 和 Admin Service 都是多实例、无状态部署,所以需要将自己注册到 Eureka 中并保持心跳
在 Eureka 之上我们架了一层 Meta Server 用于封装 Eureka 的服务发现接口
Client 通过域名访问 Meta Server 获取 Config Service 服务列表(IP+Port),而后直接通过 IP+Port 访问服务,同时在 Client 侧会做 load balance、错误重试
Portal 通过域名访问 Meta Server 获取 Admin Service 服务列表(IP+Port),而后直接通过 IP+Port 访问服务,同时在 Portal 侧会做 load balance、错误重试
为了简化部署,我们实际上会把 Config Service、Eureka 和 Meta Server 三个逻辑角色部署在同一个 JVM 进程中
十一、总结
到这里 Apollo,就讲解完了,其实 Apollo 可以理解成一个好用的配置管理中心,这里小农也是了解了一点皮毛,大家有不懂的地方,欢迎留言。
我是牧小农,怕什么真理无穷,进一步有进一步的欢喜,大家加油~
版权声明: 本文为 InfoQ 作者【牧小农】的原创文章。
原文链接:【http://xie.infoq.cn/article/eb8b8c2d63f86ac26fae23692】。文章转载请联系作者。
评论