Apollo-配置如何热更新

1. 背景

一般情况下，可以不加这个配置热更新。但是如果遇到动态数据维护在配置中的话，热更新还是比较方便的，例如在配置中维护黑白名单数据等等，这样测试环境不用每次都叫测试进行重启。

2. 介绍

2.1 基础架构

1. 用户在配置中心对配置进行修改并发布。
2. 配置中心通知Apollo客户端有配置更新(这里的主动推送哪里可以考究，从代码上看应该不是主动推送到客户端，因为客户端是定时任务和长轮询去做的)。
3. Apollo客户端从配置中心拉取最新的配置、更新本地配置并通知到应用。 

2.2 结构模块

看到这里，整个架构看起来就比较清晰了。接下来从上往下简单介绍一下：

Portal服务：提供Web界面供用户管理配置，通过MetaServer获取AdminService服务列表（IP+Port），通过IP+Port访问AdminService服务。

Client：实际上就是我们创建的SpringBoot项目，引入ApolloClient的maven依赖，为应用提供配置获取、实时更新等功能。

Meta Server：从Eureka获取Config Service和Admin Service的服务信息，相当于是一个Eureka Client。主要是为了封装服务发现的细节，对Portal和Client而言，永远通过一个Http接口获取Admin Service和Config Service的服务信息，而不需要关心背后实际的服务注册和发现组件。Meta Server只是一个逻辑角色，在部署时和Config Service是在一个JVM进程中的，所以IP、端口和Config Service一致。

Eureka：注册中心。Config Service和Admin Service会向Eureka注册服务。为了简单起见，目前Eureka在部署时和Config Service是在一个JVM进程中的。

Config Service：提供配置获取接口。提供配置更新推送接口(基于Http long polling)。服务对象为Apollo客户端(Client)。

Admin Service：提供配置管理接口。提供配置发布、修改等接口。服务对象为Portal。

2.3 配置发布后实时推送设计

上图简要描述了配置发布的大致过程：

1. 用户在Portal操作配置发布。

2. Portal调用Admin Service的接口操作发布。

3. Admin Service发布配置后，发送ReleaseMessage给各个Config Service（这里的理解并不能说是异步通知，apollo并没有采用外部依赖的中间件，而是利用数据库作为中介，Config Service每秒去轮询）。

4. Config Service收到ReleaseMessage后，通知对应的客户端(Client)（我觉得正常的是客户端去轮询ReleaseMessage，看配置是否有变化，如果有则去更新配置）。

如何异步

• Admin Service在配置发布后会往ReleaseMessage表插入一条消息记录，消息内容就是配置发布的AppId+Cluster+Namespace。
• 然后Config Service有一个线程会每秒扫描一次ReleaseMessage表，看看是否有新的消息记录。
• Config Service如果发现有新的消息记录，那么就会通知到所有的消息监听器，监听器得到配置发布的AppId+Cluster+Namespace后，会通知对应的客户端。