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

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

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

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

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

Apollo 具备功能统一管理不同环境（Environment）、不同集群（Cluster）、不同命名空间（Namespace）的配置。配置修改实时生效（热发布）。版本发布管理灰度发布权限管理、发布审核、操作审计客户端配置信息监控提供Java和.Net原生客户端提供开放平台API部署简单（目前唯一的外部依赖是MySQL，所以部署非常简单，只要安装好Java和MySQL就可以让Apollo跑起来）Apollo 总体架构设计

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

上图简要描述了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进程中客户端设计

客户端设计如下图所示。

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

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

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

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

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

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

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

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

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

Apollo 的核心概念

application (应用)

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

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

Java 客户端通过 classpath:/META-INF/app.properties 来指定 appId.Net 客户端通过 app.config 来指定 appId

environment (环境)

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

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

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

Windows: C:\opt\settings\server.propertiesLinux/Mac: /opt/settings/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

可以通过Java的System Property env来指定环境在Java程序启动脚本中，可以指定-Denv=YOUR-ENVIRONMENT如果是运行jar文件，需要注意格式是java -Denv=YOUR-ENVIRONMENT -jar xxx.jar注意key为全小写

2. 通过操作系统的System Environment

还可以通过操作系统的System Environment ENV来指定注意key为全大写

3. 通过配置文件

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

对于Mac/Linux，文件位置为/opt/settings/server.properties对于Windows，文件位置为C:\opt\settings\server.properties

文件内容形如：

env=DEV

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

DEV-Development environmentFAT-Feature Acceptance Test environmentUAT-User Acceptance Test environmentPRO-Production environment

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