公司需要使用Apollo配置中心，下面会出现大段Apollo官网文字截取引用。

一、Apollo(配置中心)

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

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

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

二、Apollo特性

A、统一管理配置

Apollo提供了一个统一界面集中式管理不同环境(environment)、不同集群(cluster)、不同命名空间(namespace)的配置。

同一份代码部署在不同的集群，可以有不同的配置，比如zk的地址等。

通过命名空间(namespace)可以很方便的支持多个不同应用共享同一份配置，同时还允许应用对共享的配置进行覆盖。

B、配置修改实时生效(热发布)

用户在Apollo修改完配置并发布后，Apollo客户端能实时(1秒)接收到最新的配置，并通知到应用程序。

C、版本发布管理

所有的配置发布都有版本概念，从而可以方便的支持配置的回滚。

D、客户端配置信息监控

可以方便的看到配置在被哪些实例使用。

E、便于集成

支持Spring Placeholder，Annotation和Spring Boot的ConfigurationProperties，方便应用使用。

三、配置中心解决的痛点随着程序功能的日益复杂，程序的配置日益增多：各种功能的开关、参数的配置、服务器的地址....

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

天猫相关，可独立启动的应用17个，涉及到的作业52个，接口8个，web平台1个。

每个应用维护着一份自己的配置文件，平均每个应用配置文件数为4个，其中大量的配置项是相同的。

比如：appKey、secretKey、sessionKey、tmall.openapi.url等等。

冗余配置带来的问题很多：一致性难以保证

维护成本高

不同环境之间容易误用

四、Apollo原理

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

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

* fallback机制，防止推送机制失效导致配置不更新

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

* 拉取频率默认为5分钟/次，客户端可以指定

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

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

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

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

五、Apollo的安全性和可用性分析

A、安全性

配置文件除了改变程序行为之外，可能还包含一些敏感信息，比如：开放接口的tokenId、secretKey、数据库账号等。

Apollo有一个默认的超级用户，可以在安装的时候初始化密码。

Apollo登陆可以对接SSO，使用域账户登陆。具体参考：Portal实现用户登录功能。

Apollo在创建每个应用(映射到物理上的应用：转单、拉单)的时候，强制创建者指定一个owner，只有这个owner用户拥有该应用配置的编辑、发布权限。每个namespace(相当于.properties的概念)除了owner拥有全部权限，也可以给他人单独授权。这样就可以将配置项按照不同的安全级别划分到不同的namespace中，从而实现更小粒度的权限控制：比如db相关的namespace只有运维能编辑、发布。

B、可用性

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

1.某台config service下线，无影响，config service无状态，客户端重连其它config service。

2.所有config service下线，客户端无法读取最新配置，Portal无影响，客户端重启时，可以读取本地缓存配置文件。

3.某台admin service下线，无影响，Admin service无状态，Portal重连其它admin service。

4.所有admin service下线，客户端无影响，portal无法更新配置。

5.某台portal下线，无影响，Portal域名通过slb绑定多台服务器，重试后指向可用的服务器。

6.全部portal下线，客户端无影响，portal无法更新配置。

7.某个数据中心下线，无影响，多数据中心部署，数据完全同步，Meta Server/Portal域名通过slb自动切换到其它存活的数据中心。

按照官方的分析，只要部署时避免ConfigService(包含Meta Server)、AdminService、Protal Server单点。并且对各节点加上存活监控(以便短时间内dump节点的恢复)，就能在保证高可用性。

在admin可以看到哪些实例(具体到IP)应用了哪些配置，上面原理中有体现，客户端也会定时上报自己的配置版本，避免了「推送失败，而服务端不知道」的情况。

六、web-admin端部署

根据官方wiki，还是比较容易操作的，没有太多的依赖、环境的问题。

由于Apollo官方要求Mysql版本5.6.5+，但是生产环境是5.5的版本，所以需要修改官方提供的SQL文件，把timestamp相关的进行修改。

web-admin端口默认为8070，登录可以看到默认项目。

七、应用端接入

参考官方wiki，因为项目使用Spring，使用脚本进行启动，所以线上版本使用以下方式接入。

不管什么方式接入，有几个关键内容必须填写(环境，项目，配置中心URL，Namespace)。

A、Spring配置

xmlns:apollo="http://www.ctrip.com/schema/apollo"

B、配置文件方式接入

# windows环境，C:\opt\settings\server.properties

env=dev

# ci\src\main\resources\META-INF\app.properties

app.id=Ci

# ci\src\main\resources\apollo-env.properties

# 用于覆盖manen获取的jar中的apollo-env.properties配置

local.meta=http://10.255.242.168:8080

dev.meta=http://10.255.242.168:8080

fat.meta=${fat_meta}

uat.meta=${uat_meta}

lpt.meta=${lpt_meta}

pro.meta=http://10.255.242.168:8080

C、启动脚本方式接入

但是对于apollo-env.properties中的内容，还需要修改apollo-core中的apollo-env.properties，或者通过本地配置文件进行覆盖。

APOLLO_OPTS=" -Denv=dev -Dapp.id=Ci"

对于正常代码没有影响，spring-database.xml中的db配置，包括spring的@value注解都不收到影响。更高级的功能，还需要在未来实践过程中逐步探索。

参考：