Apollo简介
Apollo（阿波罗）是携程框架部门研发的开源配置管理中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性。
Apollo支持4个维度管理Key-Value格式的配置：
- application (应用)
- environment (环境)
- cluster (集群)
- namespace (命名空间)
同时，Apollo基于开源模式开发，开源地址：https://github.com/ctripcorp/apollo
总的来看，Apollo和Nacos相对于Spring Cloud Config的生态支持更广，在配置管理流程上做的更好。Apollo相对于Nacos在配置管理做的更加全面，Nacos则使用起来相对比较简洁，在对性能要求比较高的大规模场景更适合。但对于一个开源项目的选型，项目上的人力投入(迭代进度、文档的完整性)、社区的活跃度（ issue的数量和解决速度、Contributor数量、社群的交流频次等），这些因素也比较关键，考虑到Nacos开源时间不长和社区活跃度，所以从目前来看Apollo应该是最合适的配置中心选型。
Apollo(阿波罗）是携程框架部门研发的分布式配置中心，能够集中化管理应用的不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。
Apollo包括服务端和客户端两部分︰
服务端基于Spring Boot和Spring Cloud开发，打包后可以直接运行，不需要额外安装Tomcat等应用容器。
Java客户端不依赖任何框架，能够运行于所有Java运行时环境，同时对Spring/Spring Boot环境也有较好的支持。
Apollo特性
正是基于配置的特殊性，所以Apollo从设计之初就立志于成为一个有治理能力的配置发布平台，目前提供了以下的特性：
统一管理不同环境、不同集群的配置
- Apollo提供了一个统一界面集中式管理不同环境（environment）、不同集群（cluster）、不同命名空间（namespace）的配置。
- 同一份代码部署在不同的集群，可以有不同的配置，比如zookeeper的地址等
- 通过命名空间（namespace）可以很方便地支持多个不同应用共享同一份配置，同时还允许应用对共享的配置进行覆盖
配置修改实时生效（热发布）
- 用户在Apollo修改完配置并发布后，客户端能实时（1秒）接收到最新的配置，并通知到应用程序
版本发布管理
- 所有的配置发布都有版本概念，从而可以方便地支持配置的回滚
灰度发布
- 支持配置的灰度发布，比如点了发布后，只对部分应用实例生效，等观察一段时间没问题后再推给所有应用实例
权限管理、发布审核、操作审计
- 应用和配置的管理都有完善的权限管理机制，对配置的管理还分为了编辑和发布两个环节，从而减少人为的错误。
- 所有的操作都有审计日志，可以方便地追踪问题
客户端配置信息监控
- 可以在界面上方便地看到配置在被哪些实例使用
提供Java和.Net原生客户端
- 提供了Java和.Net的原生客户端，方便应用集成
- 支持Spring Placeholder, Annotation和Spring Boot的ConfigurationProperties，方便应用使用（需要Spring 3.1.1+）
- 同时提供了Http接口，非Java和.Net应用也可以方便地使用
提供开放平台API
- Apollo自身提供了比较完善的统一配置管理界面，支持多环境、多数据中心配置管理、权限、流程治理等特性。不过Apollo出于通用性考虑，不会对配置的修改做过多限制，只要符合基本的格式就能保存，不会针对不同的配置值进行针对性的校验，如数据库用户名、密码，Redis服务地址等
- 对于这类应用配置，Apollo支持应用方通过开放平台API在Apollo进行配置的修改和发布，并且具备完善的授权和权限控制
部署简单
- 配置中心作为基础服务，可用性要求非常高，这就要求Apollo对外部依赖尽可能地少
- 目前唯一的外部依赖是MySQL，所以部署非常简单，只要安装好Java和MySQL就可以让Apollo跑起来
- Apollo还提供了打包脚本，一键就可以生成所有需要的安装包，并且支持自定义运行时参数
Apollo架构
核心概念
1，application（应用）
实际使用配置的应用，Apollo客户端在运行时需要知道当前应用是谁，从而可以去获取对应的配置。
关键字：appld
2，environment（环境）
配置对应的环境，Apollo客户端在运行时需要知道当前应用处于哪个环境，从而可以去获取应用的配置
关键字：env
3，cluster（集群）
一个应用下不同实例的分组，比如典型的可以按照数据中心分，把北京机房的应用实例分为一个集群，把西安的应用实例分为另一个集群
关键字：cluster
4，namespace（命名空间）
一个应用下不同配置的分组，可以简单的把namespace类比为文件，不同类型的配置存放在不同的文件中，如数据库配置文件，RPC配置文件，应用自身的配置文件等。
关键字：namespace
关系图：
项目管理：
基础设置：
1，部门管理
Apollo默认部门有两个，要增加自己的部门，可在系统参数中修改：
管理员工具--》系统参数--》key中搜索organizations--》配置部门信息--》保存
2，用户管理
添加用户：管理员工具--》用户管理--》添加新用户
创建项目
添加项目，填写基本项目信息
删除项目
管理员工具--》删除应用--》应用AppID--》查询后删除应用
配置管理
添加发布配置项
新增配置--》填写信息--》提交--》发布
修改配置
找到对应配置项，点击修改--》修改为需要的值，点击提交--》发布配置
删除配置
找到需要删除的配置项，点击深处--》确认删除后，点击发布
添加namespace(相当于一个配置文件)
进到项目--》左下角添加namespace--》创建namespace（取名，确定共有私有）
回到首页，可以看见新添加的namespace，然后可以在namespace里添加配置
（可以以文本的形式添加配置）
公共配置：
1，添加公共namespace
在项目开发中，有一些配置可能是通用的，我们可以通过把这些通用的配置放到公共的namespace中，这样其他的项目要使用时可以直接添加需要的namespace。
1.新建common-template项目
2.添加公共namespace：spring-boot-http
点击文本快速添加配置信息--》发布
3.其他项目关联公共namespace
选择其他项目---》添加namespace---》关联公共namespace
公共namespace的信息其他项目不能改原件，但可以做覆盖修改做个性化。
查看用命名空间查看
集群管理
添加集群
左下角添加集群--》取集群名，选择环境--》提交
新增的集群会默认创建本应用的私有namespace
集群同步配置
同步过来的项目需要手动点击发布
读取配置
读取某个集群的配置，需要启动应用时指定具体的应用，环境和集群
发布配置原理
主要流程：
1.用户在Portal操作配置发布。
2.Portal调用Admin Service的接口操作发布
3.Admin Service 发布配置后，发送ReleaseMessage给各个Config Service
4.Config Service 收到ReleaseMessage后，通知对应的客户端
发送ReleaseMessage
Apollo会在数据库里创建一个ReleaseMessage的表存储发布配置的消息
Apollo通过数据库是西安了一个简单的消息队列
具体实现方法如下：
1.Admin Service在配置发布后会往ReleaseMessage表插入一条消息记录，消息内容就是配置发布的Appled+Cluster+Namespace
2.Config Service有一个线程会每秒扫描一次ReleaseMessage表，看看是否有新的消息记录
3.Config Service如果发现有新的消息记录，那么就会通知到所有的消息监听器
4.NotificationControllerV2得到配置发布的Appld+Cluster+Namespace后，会通知对应的客户端
Config Service通知客户端
具体实现方法：
1.客户端会发起一个Http请求到Config Service
2.如果没有结果的话，不会立即返回，而是把请求挂起。由于这是个长连接（长连接占用网络资源）因此在服务端采用了async servlet异步的方式来回应请求
3.如果60秒内没有客户端关心的配置发布，那么返回http状态码304给客户端
4.如果有客户关心的配置发布，客户端拿到namespace信息后会主动获取namespace下的配置信息
客户端读取设计：
客户端会定时从Apollo配置中心服务端拉去应用的最新配置（五分钟拉取一次）