携程Apollo（阿波罗）分布式配置中心-总体架构设计和核心概念

携程Apollo（阿波罗）分布式配置中心

Apollo（阿波罗）是携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。

服务端基于Spring Boot和Spring Cloud开发，打包后可以直接运行，不需要额外安装Tomcat等应用容器。

Java客户端不依赖任何框架，能够运行于所有Java运行时环境，同时对Spring/Spring Boot环境也有较好的支持。

.Net客户端不依赖任何框架，能够运行于所有.Net运行时环境。

Apollo 具备功能

Apollo 总体架构设计

下图是Apollo架构模块的概览。

上图简要描述了Apollo的总体设计，我们可以从下往上看：

客户端设计

客户端设计如下图所示。

1. 客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。（通过Http Long Polling实现）

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

* 这是一个fallback机制，为了防止推送机制失效导致配置不更新。

* 客户端定时拉取会上 本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回304 – Not Modified。

* 定时频率默认为每5分钟拉取一次，客户端也可以通过在运行时指定System Property: apollo.refreshInterval来覆盖，单位为分钟。

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

4. 客户端会把从服务端获取到的配置在本地文件系统缓存一份。

* 在遇到服务不可用，或 络不通的时候，依然能从本地恢复配置。

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

Apollo 的核心概念

application (应用)

这个很好理解，就是实际使用配置的应用，Apollo 客户端在运行时需要知道当前应用是谁，从而可以去获取对应的配置。

每个应用都需要有唯一的身份标识——appId，我们认为应用身份是跟着代码走的，所以需要在代码中配置：

environment (环境)

配置对应的环境，Apollo 客户端在运行时需要知道当前应用处于哪个环境，从而可以去获取应用的配置。

我们认为环境和代码无关，同一份代码部署在不同的环境就应该能够获取到不同环境的配置。所以环境默认是通过读取机器上的配置（server.properties 中的 env 属性）指定的。

不过为了开发方便，我们也支持运行时通过 System Property （-Denv=YOUR-ENVIRONMENT）等指定，server.properties 文件路径如下：

cluster (集群)

一个应用下不同实例的分组，比如典型的可以按照数据中心分，把上海机房的应用实例分为一个集群，把北京机房的应用实例分为另一个集群。对不同的 cluster，同一个配置可以有不一样的值，如 ZooKeeper 地址。

集群默认是通过读取机器上的配置（server.properties 中的 idc 属性）指定的，不过也支持运行时通过 System Property 指定。

namespace (命名空间)

一个应用下不同配置的分组，可以简单地把 namespace 类比为文件，不同类型的配置存放在不同的文件中，如数据库配置文件，RPC 配置文件，应用自身的配置文件等。

应用可以直接读取到公共组件的配置 namespace，如 DAL，RPC 等。应用也可以通过继承公共组件的配置 namespace 来对公共组件的配置做调整，如 DAL 的初始数据库连接数。

设置 Environment

Environment可以通过以下3种方式的任意一个配置：

1. 通过Java System Property

2. 通过操作系统的System Environment

3. 通过配置文件

最后一个推荐的方式是通过配置文件来指定env=YOUR-ENVIRONMENT

文件内容形如：

env=DEV

目前，env支持以下几个值（大小写不敏感）：

更多环境定义，可以参考Env.java