核心概念
application(应用)
实际使用配置的应用，Apollo客户端在运行时需要知道当前应用是谁，从而可以去获取对应的配置，每个应用都需要有一个唯一的身份标识——appId。
environment(环境)
配置对应的环境，比如开发环境、测试环境、生产环境等，Apollo客户端在运行时需要知道当前应用处于哪个环境，从而获取相应的配置。同一份代码部署在不同的环境就应该能够获取到不同环境的配置。一般通过server.properties中的env属性指定。
cluster(集群)
一个应用下不同实例的分组，对不同的cluster，同一个配置可以有不一样的值。
namespace(命令空间)
一个应用下不同配置的分组，可以把namespace类比为文件，不同类型的配置存放在不同的文件中，比如数据库文件、RPC配置文件等。应用可以直接读取到公共组件的配置namespace，也可以通过集成公共组件的配置namespace对组件配置做调整。
整体架构
Config Service
给客户端Client提供配置的获取、推送等功能；
Admin service
给管理界面Portal提供配置的修改、发布等功能。相当于Portal的后台管理系统。
Meta Server
用于封装Eureka的服务发现接口。
Meta Server从Eureka获取Config Service和Admin Service的服务信息，然后Client和Portal通过http接口获取服务信息。
- Client通过域名访问Meta Server获取Config Service服务列表，而后直接通过IP+Port访问服务，同时在Client侧会做负载均衡、错误重试。
- Portal通过域名访问Meta Server获取Admin Service服务列表。
Eureka
提供服务注册和服务发现
- Config Service和Admin Service会向Eureka注册服务，并保持心跳；
- Eureka和Config Service时在一个JVM进程中的。
Portal
- 提供Web界面供用户管理配置
Client
- Apollo提供的客户端程序，为应用提供配置获取、实时更新等功能；
配置发布的大致过程
1、用户在Portal操作配置发布；
2、Portal调用Admin Service的接口操作发布；
3、Admin Service发布配置后，发送ReleaseMessage给各个Config Service；
4、Config Service收到ReleaseMessage后，通知对应的客户端。
发送ReleaseMessage的实现方式
Admin Service 在配置发布之后，需要通知所有的Config Service有配置发布。这个过程是一个典型的消息使用场景，为了尽可能减少外部依赖，没有采用外部消息中间件，而是通过数据库实现了一个简单的消息队列。
1、Admin Service在配置发布之后会往ReleaseMessage表中插入一条消息记录，内容就是配置发布的AppId+Cluster+Namespace。
2、Config Service每秒扫描一次ReleaseMessage表，看看是否有新的消息记录。
3、如果发现有新的记录，那么就会通知到所有的消息监听器。
4、消息监听器得到发布的ReleaseMessage后，会通知对应客户端。
Config Service通知客户端的实现方式
- 客户端会发起一个Http请求到Config Service的消息监听器；
- 消息监听器不会立即返回结果，而是通过长连接把请求挂起；
- 如果60秒内没有改客户端关心的配置发布，那么会返回304给客户端；
- 如果有该客户端关心的配置发布，消息监听器会调用方法传入有配置变化的namespace信息，同时该请求立即返回，客户端从所返回的结果中获取到namespace后，立即请求Config Service获取该namespace最新配置。