本文通过一个案例，介绍 配置文件 和 配置中心 的必要性
案例：这是你自己的一个项目
一个 java web 项目
需求：通过一个请求返回你女朋友的名字name（支持null）
这个项目很简单，于是你开始进行开发实现：
1. 实现：在代码中将女朋友名字赋值给name，作为响应内容，打jar包，部署运行；
2. 访问：打开浏览器，输入对应链接，返回你女朋友名字；
over, so easy ...
...
针对一些情况，你的开发可以说非常成功，如：
a. 你是一个单身狗，name为null；你若想打一辈子光棍，ok，我服，代码中name写死为null，over
b. 你有一个挚爱，而且你是一个从一而终的人，一辈子就只要她一个，我也服，代码中name写死为你女朋友名字，over
c. 你换的女朋友名字都一样，我更服，代码中name写死，over
...
but . . . （配置文件引入）
现实并没有那么极端，现实就是现实，假如你被绿了,分手了，重新找个女朋友。那么怎么办呢，请求返回的名字并不是你现在女朋友的名字，改程序吧：
1. 停掉服务
2. 改写代码，将name改为现在女朋友的名字
3. 打jar包，部署运行
4. 访问，显示你现在女朋友的名字
...
但是作为一名合格的开发人员，应该尽量避免这种重新部署和更改源码的事请发生；
现实中，这种问题的出现也不是大问题，停就停下呗，改就改下呗，不就是麻烦一下吗
...
but...
此处做个不合理的假设，你若是频繁被绿呢，相信你也能感觉到的不仅仅是一种被绿的痛苦，还要频繁的更改源码和打包部署的痛苦
所以你变聪明了，你将name放在配置文件中，如下：
# green.properties
name=如花
这样，实现了数据和代码的解耦，每次被绿，你只需要更改配置文件，然后重新部署。是不是感觉到了一丝幸福。
but...
目前还存在一个问题——重新部署，总是要重新部署肯定是一个非常失败的开发选择
避免重新部署：
你可能想到避免重新部署的方式，肯定需要在配置文件更改时，应用自动感知，并更新name值
实现方式可能是：代码中设计配置文件更改的监听器，并实现name的更新。
问题解决，既不用更改源码，也不用重新部署，再也不用担心被绿了
...
but...
因为你的频繁被绿，使你备受大家的关注，关注量很高很高，他们都想通过这个请求来了解你的被绿情况，以至于服务其无法承载如此高的并发访问量（即时你在服务器上做了很好的并发请求处理逻辑，但硬件上确实已经到达上限）；
所以你将应用部署到200个服务器上，结果很nice，多个服务器可以承载如此高的访问量，满足了大家的需求；
but...
你又被绿了...改配置文件吧...
1. 连接服务器1，更改服务器1中应用的配置文件的name值
2. 连接服务器2，更改服务器2中应用的配置文件的name值
3. 连接服务器3，更改服务器3中应用的配置文件的name值
4. 连接服务器4，更改服务器4中应用的配置文件的name值
...
200. 连接服务器200，更改服务器200中应用的配置文件的name值
ok. 更改完毕！
简单的更改name，却要更改200次，累么？？？ 200 个服务器，一个一个改配置，耗时，耗力，更何况是频繁。并且在更改期间，部分服务器上name已改，部分服务器上name未改，就会导致数据一致性问题
解决方案——配置中心
200个服务器上的该应用都依赖于一个配置文件，这样的话，每次只需更改这一个配置文件便可！
于是：
1. 将所有服务器上的该配置文件删除
2. 将一个地方创建一个该配置文件
3. 将所有服务器上的应用的配置源改为此地方的此配置文件，这个地方被称为配置中心，这个文件被称为中心配置文件
完美：目前应用，不用改源码、不用重启、支持高并发、没有在每个服务器上更改配置的冗余操作
相信你已经对配置文件和配置中心有了一定的感性认识，对于单机版，我们称之为配置（文件）；对于分布式集群系统，将配置文件抽出为核心配置文件，我们称之为配置中心（系统）;
关于分布式配置中心，网上已经有很多开源的解决方案。nacos作为其中一种，在另一篇博文中有详细介绍。