一：背景描述
大家在日常的Java后台开发，少不了各式各样的配置文件，例如spring的xml配置文件和properties配置文件。
一般来说，预期会时不时改变的数据都会抽取放入到配置文件中，而不是写死。例如线程池的corePoolSize，maxPoolSize等等，当发现段时间任务数量迅速上升，而硬件资源利用率不高时，一般都会将线程池的线程数量调大点。
但是，spring的properties文件有个缺陷，必须得重启才能生效。对于频繁变化的配置信息，并不合适。
为了解决这么个问题，一般各大公司都会开发全局的配置中心组件。各个系统通过接入配置中心，将频繁变化的配置信息放入其中，组件会定时的通过RPC获取远端配置的最新数据。这样，配置的改动不需要通过重启机器就能及时的体现在系统中。
假设现在有这么的场景，某系统有多个业务模块，每个模块都有各自专用的线程池，线程池的参数设置需要通过配置中心进行快速的调整，怎么搞？
二：一种不太合理的解决方案
最简单的直接的方式，就是当配置文件变化时，主动调用对应线程池相关参数的set方法进行参数设置。模拟代码如下：
这种方案有两点明显的缺陷：
2.1 模块的依赖不合理
在每个项目工程中，都会按照功能或者业务进行明确的模块划分，高层的模块依赖低层的模块，底层的模块不应该依赖高层的模块，这样可以降低模块之间的耦合，避免循环依赖，降低项目代码的复杂度。
配置中心属于基础设施，一般位于项目架构的底层，而各个业务模块使用的专属线程池位于上层，所有应该是业务模块依赖于配置中心模块，而不是反过来，简要的示意图如下。
2.2 扩展性较差
每当有新增的业务模块的时候，需要改动配置中心基础模块。在较为复杂的企业系统中，模块数量一般都不会太少，所以这种方案扩展性较差。导致这一原因，说白了，其实还是因为配置模块强依赖了上游的业务模块，所以依然是模块的依赖不合理。
三：使用观察者模式
较为合理的一种解决方案可以这样：通过观察者模式，上游的业务模块作为观察者对底层的配置变化进行监听，当配置发生变化时，配置模块作为被观察对象及时的notifyObservers。模拟代码如下。
