Apollo（阿波罗）是携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。
Apollo服务端基于Spring Boot和Spring Cloud开发，打包后可以直接运行，不需要额外部署Tomcat等应用容器。
Apollo客户端不依赖任何框架，能够运行于所有Java运行时环境，同时对Spring/Spring Boot环境也有较好的支持。
Apollo提供了一个统一界面集中式管理不同环境（environment）、不同集群（cluster）、不同命名空间（namespace）的配置。
同一份代码部署在不同的集群，可以有不同的配置，比如zk的地址等。
通过命名空间（namespace）可以很方便的支持多个不同应用共享同一份配置，同时还允许应用对共享的配置进行覆盖。
用户在Apollo修改完配置并发布后，Apollo客户端能实时（1秒）接收到最新的配置，并通知到应用程序。
所有的配置发布都有版本概念，从而可以方便的支持配置的回滚。
可以方便的看到配置在被哪些实例使用。
支持Spring Placeholder，Annotation和Spring Boot的ConfigurationProperties，方便应用使用。
1.Apollo客户端和Apollo服务端保持长连接，从而能第一时间获得配置更新的推送
2.Apollo客户端会定时从Apollo服务端拉取应用的最新配置
* fallback机制，防止推送机制失效导致配置不更新
* Apollo客户端定时拉取上报本地版本，所以一般情况下，对于定时拉取的操作，服务端会返回304-Not Modified
* 拉取频率默认为5分钟/次，客户端可以指定
3.Apollo客户端从Apollo服务端获取到应用的最新配置后，会保存在内存中
4.客户端会把从服务端获取到的配置在本地文件系统缓存一份
* 在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置
5.应用程序从Apollo客户端获取最新的配置、订阅配置更新通知
配置文件除了改变程序行为之外，可能还包含一些敏感信息，比如：开放接口的tokenId、secretKey、数据库账号等。
Apollo有一个默认的超级用户，可以在安装的时候初始化密码。
Apollo登陆可以对接SSO，使用域账户登陆。具体参考：Portal实现用户登录功能。
Apollo在创建每个应用（映射到物理上的应用：转单、拉单）的时候，强制创建者指定一个owner，只有这个owner用户拥有该应用配置的编辑、发布权限。每个namespace（相当于.properties的概念）除了owner拥有全部权限，也可以给他人单独授权。这样就可以将配置项按照不同的安全级别划分到不同的namespace中，从而实现更小粒度的权限控制：比如db相关的namespace只有运维能编辑、发布。
配置中心作为基础服务，可用性要求非常高，下面描述了不同场景下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自动切换到其它存活的数据中心。
按照官方的分析，只要部署时避免ConfigService（包含Meta Server）、AdminService、Protal Server单点。并且对各节点加上存活监控（以便短时间内dump节点的恢复），就能在保证高可用性。
在admin可以看到哪些实例（具体到IP）应用了哪些配置，上面原理中有体现，客户端也会定时上报自己的配置版本，避免了「推送失败，而服务端不知道」的情况。
原文链接: https://www.yukx.com/hangshuo/article/details/2069.html 优科学习网Apollo介绍
