apollo修改配置刷新bean_SpringBoot 集成 Apollo 配置中心，一文搞定！（万字长文）

由于 Apollo 概念比较多，刚开始使用比较复杂，最好先过一遍概念再动手实践尝试使用。

1、背景

随着程序功能的日益复杂，程序的配置日益增多，各种功能的开关、参数的配置、服务器的地址……对程序配置的期望值也越来越高，配置修改后实时生效，灰度发布，分环境、分集群管理配置，完善的权限、审核机制…… 在这样的大环境下，传统的通过配置文件、数据库等方式已经越来越无法满足开发人员对配置管理的需求。因此 Apollo 配置中心应运而生！

2、简介

Apollo(阿波罗)是携程框架部门研发的开源配置管理中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性。

3、特点

• 部署简单
• 灰度发布
• 版本发布管理
• 提供开放平台API
• 客户端配置信息监控
• 提供Java和.Net原生客户端
• 配置修改实时生效(热发布)
• 权限管理、发布审核、操作审计
• 统一管理不同环境、不同集群的配置

4、基础模型

如下即是 Apollo 的基础模型：

• (1)、用户在配置中心对配置进行修改并发布
• (2)、配置中心通知Apollo客户端有配置更新
• (3)、Apollo客户端从配置中心拉取最新的配置、更新本地配置并通知到应用

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、客户端设计

上图简要描述了Apollo客户端的实现原理

• 客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。
• 客户端还会定时从 Apollo 配置中心服务端拉取应用的最新配置。
• 这是一个 fallback 机制，为了防止推送机制失效导致配置不更新
• 客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回 304 - Not Modified
• 定时频率默认为每 5 分钟拉取一次，客户端也可以通过在运行时指定 apollo.refreshInterval 来覆盖，单位为分钟。
• 客户端从 Apollo 配置中心服务端获取到应用的最新配置后，会保存在内存中。
• 客户端会把从服务端获取到的配置在本地文件系统缓存一份 在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置。
• 应用程序从 Apollo 客户端获取最新的配置、订阅配置更新通知。

配置更新推送实现

前面提到了 Apollo 客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。长连接实际上我们是通过 Http