在以往开发中，有很多的配置文件选择记录数据库、项目配置文件中，缺点是不易维护、不能实时生效，甚至需要重新打包发布应用。
对于配置文件的最理想的状态：配置修改后可以实时生效、拥有权限管理、可以区分环境、灰度发布、管理历史改动记录、与应用实现解耦甚至提供简易API；Apollo是依赖Spring boot和Spring cloud实现，内嵌tomcat启动，更加简便了使用，唯一外部依赖是mysql数据库。
Apollo wiki地址：github.com/ctripcorp/a…
总体设计
架构设计
Portal：配置中心后台页面，用于操作配置
ProtalDB：包含后台用户、权限基本信息
AdminService：包括修改、发布配置功能
ConfigService：包括查询、推送配置功能
Eureka：注册中心，用于保证AdminService、ConfigService的高可用性
Meta Server：封装eureka服务发现接口
Portal和client根据访问meta server来获取AdminService或者ConfigService服务的IP和端口直接请求服务，Portal和client端做load balance
基础流程
- 用户在配置中心修改配置并发布
- 配置中心通知客户端配置更新
- 客户端获取最新配置
工作原理
服务端设计
AdminService与ConfigService之间的交互，摒弃了第三方消息队列依赖，采用了更简单的方式。
- AdminService在发布配置时，将ReleaseMessage消息，消息包括appId+cluster+environment，保存到数据库中
- ConfigService创建一个线程，一秒钟扫描一次数据库，检查是否有更新内容
- 如有更新内容，对应监听器将通知客户端（ConfigService与客户端存在长连接）
客户端设计
- 客户端与ConfigService存在长连接，当ConfigService查询到有发布新内容的情况下，会通知到客户端
- 为防止长连接出现问题，提供了一个fallback策略
- 定时拉取新配置，默认为5分钟（可修改），在正常情况下，当http请求到服务端后，如果存在新配置立即返回结果，如果不存在则异步保存请求60s，如无结果则返回304
3. 当客户端拿到最新配置后，先缓存在内存中，并同步到应用的本地文件中（系统出现崩溃并服务不可用时可自动恢复）
附数据库内容
ReleaseMessage是用于AdminService和ConfigService之间有配置更新用的。ID作为版本号，appId+cluster+namespace只存在一个，有异步线程清理多余数据信息
