聊聊 分布式配置中心 Apollo

今天深入聊一聊携程开源的一款分布式配置中心Apollo，在功能上和Nacos不相上下。

1. 基本概念

由于 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:\opt\data\目录存在，且应用有读写权限。

• Mac/Linux： /opt/data/{appId}/config-cache
• Windows： C:\opt\data{appId}\config-cache

本地配置文件会以下面的文件名格式放置于本地缓存路径下：

{appId}+{cluster}+{namespace}.properties

7、客户端设计

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

• 客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。

• 客户端还会定时从 Apollo 配置中心服务端拉取应用的最新配置。

• 
  
• 这是一个 fallback 机制，为了防止推送机制失效导致配置不更新
• 客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回 304 - Not Modified
• 定时频率默认为每 5 分钟拉取一次，客户端也可以通过在运行时指定 apollo.refreshInterval 来覆盖，单位为分钟。

• 客户端从 Apollo 配置中心服务端获取到应用的最新配置后，会保存在内存中。

• 客户端会把从服务端获取到的配置在本地文件系统缓存一份 在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置。

• 应用程序从 Apollo 客户端获取最新的配置、订阅配置更新通知。

配置更新推送实现

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

• 客户端发起一个 Http 请求到服务端

• 服务端会保持住这个连接 60 秒

• 
  
• 如果在 60 秒内有客户端关心的配置变化，被保持住的客户端请求会立即返回，并告知客户端有配置变化的 namespace 信息，客户端会据此拉取对应 namespace 的最新配置
• 如果在 60 秒内没有客户端关心的配置变化，那么会返回 Http 状态码 304 给客户端

• 客户端在收到服务端请求后会立即重新发起连接，回到第一步

• 考虑到会有数万客户端向服务端发起长连，在服务端我们使用了 async servlet(Spring DeferredResult) 来服务 Http Long Polling 请求。

8、总体设计

上图简要描述了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 进程中

9、可用性考虑

配置中心作为基础服务，可用性要求非常高，下面的表格描述了不同场景下Apollo的可用性：