前言
响应发布大致流程如下图，下面将从客户端响应ConfigServer配置发布和client启动Apollo监听两个模块讲解Apollo热发布原理。
源码追踪
源码maven坐标：
<dependency>
<groupId>com.ctrip.framework.apollo</groupId>
<artifactId>apollo-client</artifactId>
<version>1.6.1</version>
</dependency>
- com.ctrip.framework.apollo.spring.boot.ApolloApplicationContextInitializer这个类是初始化配置的入口。
2. com.ctrip.framework.apollo.internals.DefaultConfigManager#getConfig 里面有个获取config工厂的方法，从工厂里面获取config，工厂模式，不做分析。
3. com.ctrip.framework.apollo.spi.DefaultConfigFactory#create 这个是初始化本地的配置LocalFileConfigRepository 这个类，这个时候看的有点懵了，来看一个图。
- com.ctrip.framework.apollo.internals.RemoteConfigRepository#RemoteConfigRepository 看下这个构造方法，干了什么。
- 先分析下这个sync方法都干了什么
- com.ctrip.framework.apollo.util.http.HttpUtil#doGetWithSerializeFunction 这个是长轮训的客户端请求方式实现。
Long Polling的实现很简单，可分为四个过程：
发起Polling
发起Polling很简单，只需向服务器发起请求，此时服务端还未应答，所以客户端与服务端之间一直处于连接状态。
数据推送
如果服务器端有相关数据，此时服务端会将数据通过此前建立的通道发回客户端。
Polling终止
Polling终止情况有三种：
- 若服务端返回相关数据，此时客户端收到数据后，关闭请求连接，结束此次Polling过程。
- 若客户端等待设定的超时时间后，服务端依然没有返回数据，此时客户端需要主动终止此次Polling请求。
- 若客户端收到网络故障或异常，此时客户端自然也是需要主动终止此次Polling请求。
重新Polling
终止上次Polling后，客户端需要立即再次发起Polling请求。这样才能保证拉取数据的及时性。
客户端是如何更新数据
1.com.ctrip.framework.apollo.internals.RemoteConfigRepository#sync ,还是先看同步配置做了什么。
- com.ctrip.framework.apollo.internals.AbstractConfig#fireConfigChange 交给一个线程池去处理更新。
可以看到，直接通过反射更新的值，这里有个问题，@RefreshScope怎么更新的，好像是通过更新上线文切换的，这个之后再分析。
有个疑问，这个频繁更新的话一直创建线程，不怕OOM么，大胆猜想下，其实不会的，一个实例只会有一个长轮询，你批量修改和单个修改配置，这里应该只会触发一个线程。
服务端是如何处理的
- com.ctrip.framework.apollo.configservice.controller.NotificationControllerV2#pollNotification 这里可以看到
使用DeferredResult的流程：
- 请求到达服务端被挂起（使用浏览器查看请求状态，此时为pending）
- 向客户端进行响应，分为两种情况：
- 调用DeferredResult.setResult()，请求被唤醒，返回结果
- 超时，返回一个你设定的结果
给人一种异步处理业务，但是却同步返回的感觉。