我们的系统集成了携程的配置中心Apollo 让我们在开发和迭代中得到了很大的方便。尤其是配置的热加载。让我们避免了多次生产发布的情况。他拥有可视化的配置界面（以Key-value的形势）。这篇文章的主要目的是看apollo是如何实现热更新的

1. 接入apollo

• pom文件中引入meven依赖

<dependency>
            <groupId>com.ctrip.framework.apollo</groupId>
            <artifactId>apollo-client</artifactId>
            <version>1.4.0</version>
        </dependency>

• 在代码中引入apollo的注解 @EnableApolloConfig
  在配置的客户端创建你的nameSpace且将妳的Resource里面的YML或者properity文件配置文件同步到你的namespace里面的各个环境（在apollo里面都是properity文件格式的key-value）
• 在JVM参数中配置apollo的启动参数，我是使用jekins发布的，所以会在下图的地方进行配置
  
  其中有三个参数，分别是apollo server的域名地址，还有所对应的环境名，接下来就是你的项目名
• 启动我们的项目，就会在/opt/data/projectname 里面就会生成一个本地的配置文件（当我们发布发现配置有问题一般会在这个文件内查看apollo的配置文件是否更新到本地）
• apollo 支持热更新，当生产环境还在跑的时候，我想修改配置，一般情况下我们是需要重新build和deploy的。但是现在不需要了，修改后直接发布就可以了。 在我个人项目的实践中使用@value 可以实现热加载，但是直接使用@ConfigurationProperties不可以。（只是我个人在使用的时候遇到的问题），其实也大概不是apollo的问题吧。这两个注解在实现上的区别。在排查不能更新的的时候，查看本地的磁盘配置文件都是改掉的了而内存中的属性值确实是一直没有变化的。

1. 架构图
   
2. 上图是一个简单版本的图 从图中我们可以看出

• ConfigService是一个独立的微服务，服务于Client进行配置获取。
• Client和ConfigService保持长连接，通过一种拖拉结合(push & pull)的模式，实现配置实时更新的同时，保证配置更新不丢失。
• AdminService是一个独立的微服务，服务于Portal进行配置管理。Portal通过调用AdminService进行配置管理和发布。
• ConfigService和AdminService共享ConfigDB，ConfigDB中存放项目在某个环境的配置信息。ConfigService/AdminService/ConfigDB三者在每个环境(DEV/FAT/UAT/PRO)中都要部署一份。
• Protal有一个独立的PortalDB，存放用户权限、项目和配置的元数据信息。Protal只需部署一份，它可以管理多套环境。

3. 实时更新
   其中ConfigService 和 Clent时间是推拉组合，也就是上面我们所说的，长链接，当我们服务在启动的时候我们会进行拉，当我们服务在正在running的时候修改配置文件进行推到我们本地磁盘且实现重新注入到内存中。
4. 上面所说的我们使用@Value和@ConfigurationPropertie其中@Value达到了热更新的效果另一个则没有。@ConfigurationProperties如果需要在Apollo配置变化时自动更新注入的值，需要配合使用EnvironmentChangeEvent或RefreshScope。相关代码实现，可以参考apollo-use-cases项目中的ZuulPropertiesRefresher.java和apollo-demo项目中的SampleRedisConfig.java以及SpringBootApolloRefreshConfig.java
5. 再仔细想想，也就是将apollo中的数据交给Spring服务进行修改其bean的属性。看一下下面这张图也许我们就能大概了解到了整合SpringBoot 的apollo的具体实现的细节
   

1. apollo 是一个分布式的文件配置中心
2. 可实现配置的热更新
3. 在整合SpringBoot得时候直接使用@Value可以实现热更新，而使用@ConfigurationPropertie需要热更新则需要做特殊的配置
4. Apollo在spring中配置中心动态生效机制，是基于Http长轮询请求和Spring扩展机制实现的，在Spring容器启动过程中，Apollo通过自定义的BeanPostProcessor和BeanFactoryPostProcessor將参数中包含${…}占位符和@Value注解的Bean注册到Apollo框架中定义的注册表中。然后通过Http长轮询不断的去获取服务端的配置信息，一旦配置发生变化，Apollo会根据变化的配置的Key找到对应的Bean，然后修改Bean的属性，从而实现了配置动态生效的特性。

https://blog.csdn.net/Rongbo_J/article/details/93379683（Apollo配置中心动态生效实现原理）
https://juejin.im/entry/5b19e718e51d45067a72941a（apolo配置中心架构深度刨析）
https://www.jianshu.com/p/7d91cb5109a4 （在apollo中遇到的坑）