为什么要使用Apollo分布式配置中心
随着程序功能的日益复杂，程序的配置日益增多：各种功能的开关、参数的配置、服务器的地址等对程序配置的期望值也越来越高。配置修改后实时生效，灰度发布，分环境、分集群管理配置，完善的权限、审核机制等。在这样的大环境下，传统的通过配置文件、数据库等方式已经越来越无法满足开发人员对配置管理的需求。
Apollo是什么？
Apollo（阿波罗）是携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。配置中心基于SpringBoot和SpringCloud开发，打包后可以直接运行，不需要额外安装Tomcat等应用容器。
Java客户端不依赖任何框架，能够运行于所有Java运行时环境，同时对Spring/SpringBoot环境也有较好的支持。
Apollo 的基础模型：
1、用户在配置中心对配置进行修改并发布。
2、配置中心通知 Apollo客户端有配置更新。
3、Apollo客户端从配置中心拉取最新的配置、更新本地配置并通知到应用。
配置中心的部署
配置中心git地址：https://github.com/ctripcorp/apollo/releases
下载配置中心jar包，配置中心是一个微服务架构，分为三个jar项目。
apollo-adminservice.jar提供配置的修改、发布等功能，服务对象是 Apollo Portal（管理界面）,端口8090
apollo-configservice.jar提供配置的读取、推送等功能，服务对象是 Apollo 客户端，端口8080
apollo-portal.jar提供页面操作管理配置信息，端口8070
配置中心的部署步骤：
1、检查8090,8080,8070端口是否被占有。
2、导入配置中心sql脚本。
3、修改三个应用中数据库配置文件。
4、通过启动脚本启动三个应用。
通过浏览器访问http://ip:8070
默认登录账号/密码:apollo/admin
至此总共配置中心配置、启动成功。
客户端实现原理及配置
Apollo 客户端的实现原理：
客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。（通过Http Long Polling 实现）；
客户端还会定时从Apollo 配置中心服务端拉取应用的最新配置；
这是一个 fallback机制，为了防止推送机制失效导致配置不更新；
客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回304 - Not Modified。
客户端从 Apollo配置中心服务端获取到应用的最新配置后，会保存在内存中，所以我们的应用程序来获取配置的时候其实始终是从内存中获取的；
客户端还会把从服务端获取到的配置在本地文件系统缓存一份；
这主要是为了容灾，假设应用程序重启的时候，恰好远端服务全挂了，或者网络有故障，应用程序依然能从本地恢复配置。
通过这种推拉结合的机制，以及内存和本地文件双缓存的方式，有效地保证了客户端的可用性。
客户端配置以spring-boot项目架构为例
客户端配置文件配置如下
客户端启动入口、配置@EnableApolloConfig注解
编写测试类调用，直接获取到的配置文件中属性
通过apollo去下发、创建项目
Appid必须跟客户端保持一致
然后新增发布配置
再次请求下测试类、内容实时修改为apollo下发的配置
配置已经缓存到前面配置好的缓存路径中，后续配置中心网络不通或者宕机，也无使用影响
实际应用案例
动态日志级别
问题：
服务运行过程中，经常会遇到需要通过日志来排查定位问题的情况，然而这里却有个两难：
如果日志级别很高（如：ERROR），可能对排查问题也不会有太大帮助。
如果日志级别很低（如：DEBUG），日常运行会带来非常大的日志量，造成系统性能下降。
解决方案：
为了兼顾性能和排查问题，我们可以借助于日志组件和配置中心实现日志级别动态调整。
通过Apollo配置中心配置logging.level属性，客户端监听配置变化，根据运维场景需求实时动态调整日志级别。已到达无需频繁修改配置文件、重启应用来修改日志级别。并且对于客户端使用配置属性前台支持可视化查看。