前言
之前聊了客户端的一些功能，例如融入 Spring， @value 注解的自动刷新实现，长轮询等，这次从客户端的整体设计来聊聊。
设计
上图是 client 项目的包结构。
其中，核心包就是 internals 包，包含了客户端的主要功能逻辑。主要有以下功能：
- 获取 ConfigService 服务的远程配置。
- 长轮询/定时轮询 ConfigService。
- 监听机制——更新后，立即通知应用程序。
- 兼容 Spring 各个版本（这个是在 spring 包中，但我认为也算重要功能
^_^）。
首先说第一个功能：获取 ConfigService 服务的远程配置：
实现此功能的类为：RemoteConfigRepository。该类有以下几个重要的方法：
- 构造方法：该方法里包含了很多初始化的过程，虽然我觉得应该放在 init 之类的方法中
- getConfig() 根据 namespace 获取配置
- onLongPollNotified() 当收到长连接通知时触发响应
- addChangeListener() 添加监听器
- removeChangeListener() 删除监听器
注意：setUpstreamRepository 是空的。看注释，是个 fallback 设计。
其中，getConfig 方法是获取这个 namespace 的配置，返回的是 Properties 对象（就是个 Map）。然后，从这个对象中取出对应的值，就 ok 了。
第二个功能：长轮询/定时轮询 ConfigService。
这个功能的主要实现类是：RemoteConfigLongPollService。
该类主要的方法有 2 个，构造方法和 submit 方法。注意，这个类是单例的（由 google 的 inject 实现）。
构造方法中，做了很多的初始化工作。而 submit 方法则是开启长轮询，轮询的方式是：携带 AppId 去请求 ConfigServcie，得到所有的 namespace 更新通知，然后通知对应的 RemoteConfigRepository 去请求真正的数据。大概的设计如下图：
每一个 namespace 在一个应用中，都对应一个 RemoteConfigRepository，所有的 RemoteConfigRepository 都归属 RemoteConfigLongPollService 长轮询服务管理，当长轮询得到通知，便通知对应的 RemoteConfigRepository 进行服务请求以便执行更新本地缓存和通知监听器操作。
通知，作为 fallback 方案—— 定时轮询也充当了长轮询失效的最后屏障。
第三个功能：监听机制——更新后，立即通知应用程序。
从上图可以看出，轮询之后，如果有更新响应，则立即通知 RemoteConfigRepository，然后，RemoteConfigRepository 再次从配置中心拉取配置，从而更新本地 Config 对象的内容。
更新完毕后，则通知 Config 的“配置变化监听器”。也就是 ConfigChangeListener 的 onChange 方法。这个监听器是监听 Config 对象的。
实际上，每个 Config 对象在初始化的时候，都会往 RemoteConfigRepository 对象里添加一个监听器，实际上就是添加自己。
当 RemoteConfigRepository 发生变化的时候，触发 onRepositoryChange 方法，onRepositoryChange 又会触发 onChange 方法。大概的设计图就是下面这个样子：
上图中，紫色的 DefaultConfig 是核心，他依赖了 RemoteConfigRepository， 而 RemoteConfigRepository 反过来组合了他，同时 DefaultConfig 也聚合了用户实现的监听器 ConfigChangeListener 的子类。
那么，当远程 Repository 变化的时候，就可以通知 Client 的缓存 Config 对象，而 Config 缓存对象变化的时候，就可以通知用户的程序（监听器）。实现整体的监听机制。
总的来说，就是通过两层监听机制来实现的。其中 DefaultConfig 实现了两个角色，既是观察者，也是被观察者。
第四个功能：兼容 Spring 各个版本
首先，如果没有这个功能，Apollo 也会能够正常运行的，不过，你只能使用 API 的方式，不能使用注解，标签等 Spring 应用熟悉的方式。
如果想用 Spring 的方式使用 Apollo ，那么就得遵守 Spring 的约定，实现 Spring 的接口，将自己融入到 Spring 中。
其中，主要解决的问题就是，如何在 Spring 初始化的时候，Apollo 也初始化？这点我们在之前的文章中说了，也就是 Spring 的 3 个入口。在这些入口里初始化。
另外，将配置放置到 Spring 的环境中，也是一个工作，因为，如果不放到环境中，Spring 初始时需要的那些参数就无法取到了。
所以，要将 Config 对象包装成 Spring 熟悉的 ConfigPropertySource 对象，算是一个适配器模式吧。
在初始化配置的时候，会从远程配置中心拿到配置，包装成 ConfigPropertySource 对象，再利用 CompositePropertySource 组合属性配置（多个 namespace）聚合所有 Config 对象。
CompositePropertySource 最后会添加到 ConfigurableEnvironment 环境对象中，spring 就可以从这个对象 中取出配置进行初始化。
并且，在 SpringBoot 环境下，Apollo 可以优先加载指定的配置，这些配置在 SpringContext 容器初始化的时候就开始被注入到环境中，这样就可以将一些系统初始化的配置也放到配置中心了，尽量让本地少一点配置。这个功能的启用需要参数：apollo.bootstrap.enabled=true，配置的namespace 则是 apollo.bootstrap.namespaces = XXX。
并且，该配置的优先级是最高的，Apollo 将这个配置放在了 Spring 环境对象中的第一个位置，当循环获取配置的时候，优先获取这个配置。
总结
好了，关于 Apollo 客户端的设计，大概就是这些，总体来讲比较简单， 4 个功能：
- 获取远程配置
- 长轮询/定时轮询
- 配置更新监听机制。
- 兼容 Spring。
抛出一个问题：
Apollo 似乎没有给用户留扩展接口？如果能像 Spring，Mybatis 一样，留一个或者多个切面给用户，让用户能够在加载配置的时候，做一些事情啥的，或许更好。
