Apollo配置中心介绍

一、What is Apollo

1.1 背景

随着程序功能的日益复杂，程序的配置日益增多：各类功能的开关、参数的配置、服务器的地址……

对程序配置的指望值也愈来愈高：配置修改后实时生效，灰度发布，分环境、分集群管理配置，完善的权限、审核机制……

在这样的大环境下，传统的经过配置文件、数据库等方式已经愈来愈没法知足开发人员对配置管理的需求。

Apollo配置中心应运而生！

1.2 Apollo简介

Apollo（阿波罗）是携程框架部门研发的开源配置管理中心，可以集中化管理应用不一样环境、不一样集群的配置，配置修改后可以实时推送到应用端，而且具有规范的权限、流程治理等特性。

Apollo支持4个维度管理Key-Value格式的配置：

1. application (应用)
2. environment (环境)
3. cluster (集群)
4. namespace (命名空间)

同时，Apollo基于开源模式开发，开源地址：https://github.com/ctripcorp/apollo

1.3 配置基本概念

既然Apollo定位于配置中心，那么在这里有必要先简单介绍一下什么是配置。

按照咱们的理解，配置有如下几个属性：

• 配置是独立于程序的只读变量
  • 配置首先是独立于程序的，同一份程序在不一样的配置下会有不一样的行为。
  • 其次，配置对于程序是只读的，程序经过读取配置来改变本身的行为，可是程序不该该去改变配置。
  • 常见的配置有：DB Connection Str、Thread Pool Size、Buffer Size、Request Timeout、Feature Switch、Server Urls等。
• 配置伴随应用的整个生命周期
  • 配置贯穿于应用的整个生命周期，应用在启动时经过读取配置来初始化，在运行时根据配置调整行为。
• 配置能够有多种加载方式
  • 配置也有不少种加载方式，常见的有程序内部hard code，配置文件，环境变量，启动参数，基于数据库等
• 配置须要治理
  • 权限控制
    • 因为配置能改变程序的行为，不正确的配置甚至能引发灾难，因此对配置的修改必须有比较完善的权限控制
  • 不一样环境、集群配置管理
    • 同一份程序在不一样的环境（开发，测试，生产）、不一样的集群（如不一样的数据中心）常常须要有不一样的配置，因此须要有完善的环境、集群配置管理
  • 框架类组件配置管理
    • 还有一类比较特殊的配置 - 框架类组件配置，好比CAT客户端的配置。
    • 虽然这类框架类组件是由其余团队开发、维护，可是运行时是在业务实际应用内的，因此本质上能够认为框架类组件也是应用的一部分。
    • 这类组件对应的配置也须要有比较完善的管理方式。

二、Why Apollo

正是基于配置的特殊性，因此Apollo从设计之初就立志于成为一个有治理能力的配置管理平台，目前提供了如下的特性：

• 统一管理不一样环境、不一样集群的配置
  • Apollo提供了一个统一界面集中式管理不一样环境（environment）、不一样集群（cluster）、不一样命名空间（namespace）的配置。
  • 同一份代码部署在不一样的集群，能够有不一样的配置，好比zk的地址等
  • 经过命名空间（namespace）能够很方便的支持多个不一样应用共享同一份配置，同时还容许应用对共享的配置进行覆盖
• 配置修改实时生效（热发布）
  • 用户在Apollo修改完配置并发布后，客户端能实时（1秒）接收到最新的配置，并通知到应用程序
• 版本发布管理
  • 全部的配置发布都有版本概念，从而能够方便地支持配置的回滚
• 灰度发布
  • 支持配置的灰度发布，好比点了发布后，只对部分应用实例生效，等观察一段时间没问题后再推给全部应用实例
• 权限管理、发布审核、操做审计
  • 应用和配置的管理都有完善的权限管理机制，对配置的管理还分为了编辑和发布两个环节，从而减小人为的错误。
  • 全部的操做都有审计日志，能够方便的追踪问题
• 客户端配置信息监控
  • 能够在界面上方便地看到配置在被哪些实例使用
• 提供Java和.Net原生客户端
  • 提供了Java和.Net的原生客户端，方便应用集成
  • 支持Spring Placeholder, Annotation和Spring Boot的ConfigurationProperties，方便应用使用（须要Spring 3.1.1+）
  • 同时提供了Http接口，非Java和.Net应用也能够方便的使用
• 提供开放平台API
  • Apollo自身提供了比较完善的统一配置管理界面，支持多环境、多数据中心配置管理、权限、流程治理等特性。
  • 不过Apollo出于通用性考虑，对配置的修改不会作过多限制，只要符合基本的格式就可以保存。
  • 在咱们的调研中发现，对于有些使用方，它们的配置可能会有比较复杂的格式，并且对输入的值也须要进行校验后方可保存，如检查数据库、用户名和密码是否匹配。
  • 对于这类应用，Apollo支持应用方经过开放接口在Apollo进行配置的修改和发布，而且具有完善的受权和权限控制
• 部署简单
  • 配置中心做为基础服务，可用性要求很是高，这就要求Apollo对外部依赖尽量地少
  • 目前惟一的外部依赖是MySQL，因此部署很是简单，只要安装好Java和MySQL就可让Apollo跑起来
  • Apollo还提供了打包脚本，一键就能够生成全部须要的安装包，而且支持自定义运行时参数

三、Apollo at a glance

3.1 基础模型

以下便是Apollo的基础模型：

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

3.2 界面概览

上图是Apollo配置中心中一个项目的配置首页

• 在页面左上方的环境列表模块展现了全部的环境和集群，用户能够随时切换。
• 页面中央展现了两个namespace(application和FX.apollo)的配置信息，默认按照表格模式展现、编辑。用户也能够切换到文本模式，以文件形式查看、编辑。
• 页面上能够方便地进行发布、回滚、灰度、受权、查看更改历史和发布历史等操做

3.3 添加/修改配置项

用户能够经过配置中心界面方便的添加/修改配置项：

输入配置信息：

3.4 发布配置

经过配置中心发布配置：

填写发布信息：

3.5 客户端获取配置（Java API样例）

配置发布后，就能在客户端获取到了，以Java API方式为例，获取配置的示例代码以下。更多客户端使用说明请参见Java客户端使用指南。

Config config = ConfigService.getAppConfig(); Integer defaultRequestTimeout = 200; Integer requestTimeout = config.getIntProperty("request.timeout",defaultRequestTimeout); 

3.6 客户端监听配置变化（Java API样例）

经过上述获取配置代码，应用就能实时获取到最新的配置了。

不过在某些场景下，应用还须要在配置变化时得到通知，好比数据库链接的切换等，因此Apollo还提供了监听配置变化的功能，Java示例以下：

Config config = ConfigService.getAppConfig(); config.addChangeListener(new ConfigChangeListener() { @Override public void onChange(ConfigChangeEvent changeEvent) { for (String key : changeEvent.changedKeys()) { ConfigChange change = changeEvent.getChange(key); System.out.println(String.format( "Found change - key: %s, oldValue: %s, newValue: %s, changeType: %s", change.getPropertyName(), change.getOldValue(), change.getNewValue(), change.getChangeType())); } } }); 

3.7 Spring集成样例

Apollo和Spring也能够很方便地集成，只须要标注@EnableApolloConfig后就能够经过@Value获取配置信息：

@Configuration @EnableApolloConfig public class AppConfig {} 

@Component public class SomeBean { @Value("${request.timeout:200}") private int timeout; @ApolloConfigChangeListener private void someChangeHandler(ConfigChangeEvent changeEvent) { if (changeEvent.isChanged("request.timeout")) { refreshTimeout(); } } } 

四、Apollo in depth

经过上面的介绍，相信你们已经对Apollo有了一个初步的了解，而且相信已经覆盖到了大部分的使用场景。

接下来会主要介绍Apollo的cluster管理（集群）、namespace管理（命名空间）和对应的配置获取规则。

4.1 Core Concepts

在介绍高级特性前，咱们有必要先来了解一下Apollo中的几个核心概念：

1. application (应用)
   • 这个很好理解，就是实际使用配置的应用，Apollo客户端在运行时须要知道当前应用是谁，从而能够去获取对应的配置
   • 每一个应用都须要有惟一的身份标识 - appId，咱们认为应用身份是跟着代码走的，因此须要在代码中配置，具体信息请参见Java客户端使用指南。
2. environment (环境)
   • 配置对应的环境，Apollo客户端在运行时须要知道当前应用处于哪一个环境，从而能够去获取应用的配置
   • 咱们认为环境和代码无关，同一份代码部署在不一样的环境就应该可以获取到不一样环境的配置
   • 因此环境默认是经过读取机器上的配置（server.properties中的env属性）指定的，不过为了开发方便，咱们也支持运行时经过System Property等指定，具体信息请参见Java客户端使用指南。
3. cluster (集群)
   • 一个应用下不一样实例的分组，好比典型的能够按照数据中心分，把上海机房的应用实例分为一个集群，把北京机房的应用实例分为另外一个集群。
   • 对不一样的cluster，同一个配置能够有不同的值，如zookeeper地址。
   • 集群默认是经过读取机器上的配置（server.properties中的idc属性）指定的，不过也支持运行时经过System Property指定，具体信息请参见Java客户端使用指南。
4. namespace (命名空间)
   • 一个应用下不一样配置的分组，能够简单地把namespace类比为文件，不一样类型的配置存放在不一样的文件中，如数据库配置文件，rpc配置文件，应用自身的配置文件等
   • 应用能够直接读取到公共组件的配置namespace，如DAL，RPC等
   • 应用也能够经过继承公共组件的配置namespace来对公共组件的配置作调整，如DAL的初始数据库链接数

4.2 自定义Cluster

【本节内容仅对应用须要对不一样集群应用不一样配置才须要，如没有相关需求，能够跳过本节】

好比咱们有应用在A数据中心和B数据中心都有部署，那么若是但愿两个数据中心的配置不同的话，咱们能够经过新建cluster来解决。

4.2.1 新建Cluster

新建Cluster只有项目的管理员才有权限，管理员能够在页面左侧看到“添加集群”按钮。

点击后就进入到集群添加页面，通常状况下能够按照数据中心来划分集群，如SHAJQ、SHAOY等。

不过也支持自定义集群，好比能够为A机房的某一台机器和B机房的某一台机建立一个集群，使用一套配置。

4.2.2 在Cluster中添加配置并发布

集群添加成功后，就能够为该集群添加配置了，首选须要按照下图所示切换到SHAJQ集群，以后配置添加流程和3.2添加/修改配置项同样，这里就再也不赘述了。

4.2.3 指定应用实例所属的Cluster

Apollo会默认使用应用实例所在的数据中心做为cluster，因此若是二者一致的话，不须要额外配置。

若是cluster和数据中心不一致的话，那么就须要经过System Property方式来指定运行时cluster：

• -Dapollo.cluster=SomeCluster
• 这里注意apollo.cluster为全小写

4.3 自定义Namespace

【本节仅对公共组件配置或须要多个应用共享配置才须要，如没有相关需求，能够跳过本节】

若是应用有公共组件（如hermes-producer，cat-client等）供其它应用使用，就须要经过自定义namespace来实现公共组件的配置。

4.3.1 新建Namespace

以hermes-producer为例，须要先新建一个namespace，新建namespace只有项目的管理员才有权限，管理员能够在页面左侧看到“添加Namespace”按钮。

点击后就进入namespace添加页面，Apollo会把应用所属的部门做为namespace的前缀，如FX。

4.3.2 关联到环境和集群

Namespace建立完，须要选择在哪些环境和集群下使用

4.3.3 在Namespace中添加配置项

接下来在这个新建的namespace下添加配置项

添加完成后就能在FX.Hermes.Producer的namespace中看到配置。

4.3.4 发布namespace的配置

4.3.5 客户端获取Namespace配置

对自定义namespace的配置获取，稍有不一样，须要程序传入namespace的名字。更多客户端使用说明请参见Java客户端使用指南。

Config config = ConfigService.getConfig("FX.Hermes.Producer"); Integer defaultSenderBatchSize = 200; Integer senderBatchSize = config.getIntProperty("sender.batchsize", defaultSenderBatchSize); 

4.3.6 客户端监听Namespace配置变化

Config config = ConfigService.getConfig("FX.Hermes.Producer"); config.addChangeListener(new ConfigChangeListener() { @Override public void onChange(ConfigChangeEvent changeEvent) { System.out.println("Changes for namespace " + changeEvent.getNamespace()); for (String key : changeEvent.changedKeys()) { ConfigChange change = changeEvent.getChange(key); System.out.println(String.format( "Found change - key: %s, oldValue: %s, newValue: %s, changeType: %s", change.getPropertyName(), change.getOldValue(), change.getNewValue(), change.getChangeType())); } } }); 

4.3.7 Spring集成样例

@Configuration @EnableApolloConfig("FX.Hermes.Producer") public class AppConfig {} 

@Component public class SomeBean { @Value("${request.timeout:200}") private int timeout; @ApolloConfigChangeListener("FX.Hermes.Producer") private void someChangeHandler(ConfigChangeEvent changeEvent) { if (changeEvent.isChanged("request.timeout")) { refreshTimeout(); } } } 

4.4 配置获取规则

【本节仅当应用自定义了集群或namespace才须要，如无相关需求，能够跳过本节】

在有了cluster概念后，配置的规则就显得重要了。

好比应用部署在A机房，可是并无在Apollo新建cluster，这个时候Apollo的行为是怎样的？

或者在运行时指定了cluster=SomeCluster，可是并无在Apollo新建cluster，这个时候Apollo的行为是怎样的？

接下来就来介绍一下配置获取的规则。

4.4.1 应用自身配置的获取规则

当应用使用下面的语句获取配置时，咱们称之为获取应用自身的配置，也就是应用自身的application namespace的配置。

Config config = ConfigService.getAppConfig(); 

对这种状况的配置获取规则，简而言之以下：

1. 首先查找运行时cluster的配置（经过apollo.cluster指定）
2. 若是没有找到，则查找数据中心cluster的配置
3. 若是仍是没有找到，则返回默认cluster的配置

图示以下：

因此若是应用部署在A数据中心，可是用户没有在Apollo建立cluster，那么获取的配置就是默认cluster（default）的。

若是应用部署在A数据中心，同时在运行时指定了SomeCluster，可是没有在Apollo建立cluster，那么获取的配置就是A数据中心cluster的配置，若是A数据中心cluster没有配置的话，那么获取的配置就是默认cluster（default）的。

4.4.2 公共组件配置的获取规则

以FX.Hermes.Producer为例，hermes producer是hermes发布的公共组件。当使用下面的语句获取配置时，咱们称之为获取公共组件的配置。

Config config = ConfigService.getConfig("FX.Hermes.Producer"); 

对这种状况的配置获取规则，简而言之以下：

1. 首先获取当前应用下的FX.Hermes.Producer namespace的配置
2. 而后获取hermes应用下FX.Hermes.Producer namespace的配置
3. 上面两部分配置的并集就是最终使用的配置，若有key同样的部分，以当前应用优先

图示以下：

经过这种方式，就实现了对框架类组件的配置管理，框架组件提供方提供配置的默认值，应用若是有特殊需求，能够自行覆盖。

4.5 整体设计

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

4.5.1 Why Eureka

为何咱们采用Eureka做为服务注册中心，而不是使用传统的zk、etcd呢？我大体总结了一下，有如下几方面的缘由：

• 它提供了完整的Service Registry和Service Discovery实现
  • 首先是提供了完整的实现，而且也经受住了Netflix本身的生产环境考验，相对使用起来会比较省心。
• 和Spring Cloud无缝集成
  • 咱们的项目自己就使用了Spring Cloud和Spring Boot，同时Spring Cloud还有一套很是完善的开源代码来整合Eureka，因此使用起来很是方便。
  • 另外，Eureka还支持在咱们应用自身的容器中启动，也就是说咱们的应用启动完以后，既充当了Eureka的角色，同时也是服务的提供者。这样就极大的提升了服务的可用性。
  • 这一点是咱们选择Eureka而不是zk、etcd等的主要缘由，为了提升配置中心的可用性和下降部署复杂度，咱们须要尽量地减小外部依赖。
• Open Source
  • 最后一点是开源，因为代码是开源的，因此很是便于咱们了解它的实现原理和排查问题。

4.6 客户端设计

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

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

4.6.1 配置更新推送实现

前面提到了Apollo客户端和服务端保持了一个长链接，从而能第一时间得到配置更新的推送。

长链接实际上咱们是经过Http Long Polling实现的，具体而言：

• 客户端发起一个Http请求到服务端
• 服务端会保持住这个链接30秒
• 若是在30秒内有客户端关心的配置变化，被保持住的客户端请求会当即返回，并告知客户端有配置变化的namespace信息，客户端会据此拉取对应namespace的最新配置
• 若是在30秒内没有客户端关心的配置变化，那么会返回Http状态码304给客户端
• 客户端在服务端请求返回后会自动重连

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

4.7 可用性考虑

配置中心做为基础服务，可用性要求很是高，下面的表格描述了不一样场景下Apollo的可用性：

场景	影响	降级	缘由
某台config service下线	无影响		Config service无状态，客户端重连其它config service
全部config service下线	客户端没法读取最新配置，Portal无影响	客户端重启时,能够读取本地缓存配置文件
某台admin service下线	无影响		Admin service无状态，Portal重连其它admin service
全部admin service下线	客户端无影响，portal没法更新配置
某台portal下线	无影响		Portal域名经过slb绑定多台服务器，重试后指向可用的服务器
所有portal下线	客户端无影响，portal没法更新配置
某个数据中心下线	无影响		多数据中心部署，数据彻底同步，Meta Server/Portal域名经过slb自动切换到其它存活的数据中心

五、Contribute to Apollo

Apollo从开发之初就是以开源模式开发的，因此也很是欢迎有兴趣、有余力的朋友一块儿加入进来。

服务端开发使用的是Java，基于Spring Cloud和Spring Boot框架。客户端目前提供了Java和.Net两种实现。

Github地址：https://github.com/ctripcorp/apollo

原文：http://nobodyiam.com/2016/07/09/introduction-to-apollo/