由于 Apollo 概念比较多,刚开始使用比较复杂,最好先过一遍概念再动手实践尝试使用。
1、背景
随着程序功能的日益复杂,程序的配置日益增多,各种功能的开关、参数的配置、服务器的地址……对程序配置的期望值也越来越高,配置修改后实时生效,灰度发布,分环境、分集群管理配置,完善的权限、审核机制…… 在这样的大环境下,传统的通过配置文件、数据库等方式已经越来越无法满足开发人员对配置管理的需求。因此 Apollo 配置中心应运而生!
2、简介
Apollo(阿波罗)是携程框架部门研发的开源配置管理中心,能够集中化管理应用不同环境、不同集群的配置,配置修改后能够实时推送到应用端,并且具备规范的权限、流程治理等特性。
3、特点
- 部署简单
- 灰度发布
- 版本发布管理
- 提供开放平台API
- 客户端配置信息监控
- 提供Java和.Net原生客户端
- 配置修改实时生效(热发布)
- 权限管理、发布审核、操作审计
- 统一管理不同环境、不同集群的配置
4、基础模型
如下即是 Apollo 的基础模型:
- (1)、用户在配置中心对配置进行修改并发布
- (2)、配置中心通知Apollo客户端有配置更新
- (3)、Apollo客户端从配置中心拉取最新的配置、更新本地配置并通知到应用
![ffc4fbc5de26d8afd8755d0d2829764b.png](https://i-blog.csdnimg.cn/blog_migrate/0f575578603943d7b2585cb2304f1f72.jpeg)
5、Apollo 的四个维度
Apollo支持4个维度管理Key-Value格式的配置:
- application (应用)
- environment (环境)
- cluster (集群)
- namespace (命名空间)
(1)、application
- Apollo 客户端在运行时需要知道当前应用是谁,从而可以根据不同的应用来获取对应应用的配置。
- 每个应用都需要有唯一的身份标识,可以在代码中配置 app.id 参数来标识当前应用,Apollo 会根据此指来辨别当前应用。
(2)、environment
在实际开发中,我们的应用经常要部署在不同的环境中,一般情况下分为开发、测试、生产等等不同环境,不同环境中的配置也是不同的,在 Apollo 中默认提供了四种环境:
- FAT(Feature Acceptance Test):功能测试环境
- UAT(User Acceptance Test):集成测试环境
- DEV(Develop):开发环境
- PRO(Produce):生产环境
在程序中如果想指定使用哪个环境,可以配置变量 env 的值为对应环境名称即可。
(3)、cluster
- 一个应用下不同实例的分组,比如典型的可以按照数据中心分,把上海机房的应用实例分为一个集群,把北京机房的应用实例分为另一个集群。
- 对不同的集群,同一个配置可以有不一样的值,比如说上面所指的两个北京、上海两个机房设置两个集群,两个集群中都有 mysql 配置参数,其中参数中配置的地址是不一样的。
(4)、namespace
一个应用中不同配置的分组,可以简单地把 namespace 类比为不同的配置文件,不同类型的配置存放在不同的文件中,如数据库配置文件,RPC 配置文件,应用自身的配置文件等。
熟悉 SpringBoot 的都知道,SpringBoot 项目都有一个默认配置文件 application.yml,如果还想用多个配置,可以创建多个配置文件来存放不同的配置信息,通过指定 spring.profiles.active 参数指定应用不同的配置文件。这里的 namespace 概念与其类似,将不同的配置放到不同的配置 namespace 中。
Namespace 分为两种权限,分别为:
- public(公共的): public权限的 Namespace,能被任何应用获取。
- private(私有的): 只能被所属的应用获取到。一个应用尝试获取其它应用 private 的 Namespace,Apollo 会报 “404” 异常。
Namespace 分为三种类型,分别为:
- 私有类型: 私有类型的 Namespace 具有 private 权限。例如 application Namespace 为私有类型。
- 公共类型: 公共类型的 Namespace 具有 public 权限。公共类型的N amespace 相当于游离于应用之外的配置,且通过 Namespace 的名称去标识公共 Namespace,所以公共的 Namespace 的名称必须全局唯一。
- 关联类型(继承类型): 关联类型又可称为继承类型,关联类型具有 private 权限。关联类型的 Namespace 继承于公共类型的 Namespace,将里面的配置全部继承,并且可以用于覆盖公共 Namespace 的某些配置。
6、本地缓存
Apollo客户端会把从服务端获取到的配置在本地文件系统缓存一份,用于在遇到服务不可用,或网络不通的时候,依然能从本地恢复配置,不影响应用正常运行。
本地缓存路径默认位于以下路径,所以请确保/opt/data或C:optdata目录存在,且应用有读写权限。
- Mac/Linux: /opt/data/{appId}/config-cache
- Windows: C:optdata{appId}config-cache
本地配置文件会以下面的文件名格式放置于本地缓存路径下:
1{appId}+{cluster}+{namespace}.properties
7、客户端设计
![aa4eb23d6b36b165eb7244d0bf05bb95.png](https://i-blog.csdnimg.cn/blog_migrate/0e6751a8ab4fa555ed27478fedd25f96.jpeg)
上图简要描述了Apollo客户端的实现原理
- 客户端和服务端保持了一个长连接,从而能第一时间获得配置更新的推送。
- 客户端还会定时从 Apollo 配置中心服务端拉取应用的最新配置。
- 这是一个 fallback 机制,为了防止推送机制失效导致配置不更新
- 客户端定时拉取会上报本地版本,所以一般情况下,对于定时拉取的操作,服务端都会返回 304 - Not Modified
- 定时频率默认为每 5 分钟拉取一次,客户端也可以通过在运行时指定 apollo.refreshInterval 来覆盖,单位为分钟。
- 客户端从 Apollo 配置中心服务端获取到应用的最新配置后,会保存在内存中。
- 客户端会把从服务端获取到的配置在本地文件系统缓存一份 在遇到服务不可用,或网络不通的时候,依然能从本地恢复配置。
- 应用程序从 Apollo 客户端获取最新的配置、订阅配置更新通知。
配置更新推送实现
前面提到了 Apollo 客户端和服务端保持了一个长连接,从而能第一时间获得配置更新的推送。长连接实际上我们是通过 Http