很多人说配置中心很简单啊，我分分钟给你撸一个出来。
说简单是可以很简单，
方式一：
写配置到redis，使用方定时从redis拿一下就好，简单到爆。
方式二：
就是业界很通用的zookeeper了，用个zookeeper其实也不复杂。
但是下面我们会逐一分析配置中心的需求，看看最后的配置中心是怎么样的，我会更加侧重于说需求，具体实现大家可以一起思考。
需求1：配置导入导出
很多都是在测试环境测试ok，难道上生产的时候，还要一个个配置手输吗，肯定要支持导入导出啦。
实现：导入导出都用一个json做媒介就好。
需求2：审批
配置下发必然不能是想下发就下发，必须要走流程，经过层层审核。
实现：很多公司都有自己的流程审核系统，接入这些系统就好
需求3：内容对比功能
下发的内容可能是很多配置，每个配置还可能是个大json，你让审核的人一点点去看，会死人的，那自然就要有内容对比功能，不同的地方标记出来，一目了然。
实现：前端都有比较成熟的对比高亮框架了。
需求4：灰度
灰度就不用多说了，配置的修改风险也是很大，先找一两台机器当小白鼠。
实现：小白鼠机器如何找，这个就要对接cmdb系统，找到这个域名的所有机器，然后从中选择一两台机器。
需求5：回滚
下发配置出了问题，首先就是回滚了。这是个救命的功能。
实现：实际上我们是用历史的一个版本覆盖到当前，同样可以实现回滚的功能。为什么要这么做呢，如果要回滚3个版本之前，那就要连续回滚3次，很不灵活。
需求6：预案
在大促比较紧急情况下，我们是希望非常快的降级一个功能。但是普通下发要经过审批流程，就根本快不起来。所以需要提前审批通过的一些下发，这就是预案了。
实现：预案不用再审核直接下发，注意预案是改某一个配置，所以要拿到当前的配置，merge进去预案配置，然后再下发。
需求7：分区隔离
在测试环境，很多人在做测试，你肯定不想你在测一个功能，结果被别人下发一个配置，影响了你的测试。所以我们需要能隔离开配置。很多地方也叫namesapce，zookeeper叫分区，我们就沿用zookeeper的说法了。
实现：数据库重要的表都有分区字段，每个请求都有分区这个参数，页面上用户可以切换分区。
需求8：自动化测试openApi
对于自动化测试的时候，要修改下发一个配置肯定是不能页面上各种点流程，所以要给自动化测试单独提供一些api。
实现：openApi是要做特殊处理的，会绕过很多的流程
需求9：权限控制
一个域的配置只能自己域的负责人能修改，其他人只能看。系统负责人或者运维能改所有的。
实现：权限控制实现上也是接入权限系统的，不过权限系统拿到的是角色，还是要在代码中处理很大的，特别是前端的页面都要根据角色显示内容。
