整体设计
配置就是不同应用在不同环境的一些键值对。configcenter让你可以优雅的管理配置。
configcenter中的角色包含：服务端、客户端、MySQL数据库、Redis、Nginx、应用、配置管理员
- 服务端--服务端用于集中管理应用的配置。配置数据落地到MySQL数据库，允许客户端通过http请求查询配置，允许客户端通过Http Long Polling（长轮询）接收配置变更通知。当应用的配置有了变更（增删改），则会通知客户端（秒级）。
- 客户端--客户端用于协助应用获取配置。客户端刚启动时会通过http请求服务端读取应用的最新配置。如果从服务端读取失败，则客户端会尝试从本地缓存文件中读取配置；如果本地无缓存文件，则启动失败。客户端启动成功后，会通过Http Long Polling（长轮询）接收服务端配置变更通知。当监听到配置有变更时，客户端会再次通过http请求服务端读取最新配置，然后把最新配置保存到缓存文件，最后将最新配置和当前客户端中旧配置进行比较，将变化部分通知给应用。
- MySQL数据库--MySQL数据库用于存储服务端管理的配置。
- Redis--Redis有三个作用：1、缓存数据库存储的配置，提高系统响应效率；2、存储管理员登录的session；3、小型MQ，服务端之间使用它进行相互通信。
- Nginx--Nginx用于对多个服务端进行负载均衡。由于服务端使用Redis存储所有的管理员登录的session，所以Nginx的负载均衡策略可以使用轮询策略。如果你有其他更好的负载均衡器，只要它能支持http协议，则完全可以使用它替代Nginx。
- 应用--应用是从服务端获取配置的系统。应用可以通过客户端的协助获取配置；当然它也可以抛弃客户端，自己直接发起http请求服务端，获取配置。
- 配置管理员--配置管理员管理配置，分为两个级别：普通管理员、超级管理员。普通管理员只能管理分配给他的配置；超级管理员既能管理所有配置，也能管理其他管理员。管理员可以是运维人员，也可以是开发人员。给开发人员创建普通管理员，并分配相应应用的权限，让其可以自助的管理配置，提高工作效率。
配置可以从应用和环境两个纬度进行共享，让你的配置管理变得像面向对象开发一样简单和高效。 应用纬度的共享产生应用树，环境纬度的共享产生环境树。
- 应用树--应用树是各个应用之间的继承关系图，类似Java类的继承关系。应用可以多层继承，比如：customer（会员系统）--> core-domain（核心领域）--> common（公共配置）。应用的继承特性可以使不同应用之间共享配置。
- 环境树--环境树是各个环境之间的继承关系图，类似Java类的继承关系。环境可以多层继承，比如：featureTest1（特性测试环境1）--> test（测试环境）--> offline（线下环境）。环境的继承特性可以使一个应用在不同环境之间共享配置。不同集群在这里可以看成是不同的子环境，而不同集群间往往大部分配置是一样的，只有少数配置是不同的。有了继承特性，新增一个集群只需要进行继承，然后覆盖掉少数的不同配置就可以，而不需要从头开始建配置。
环境树存在的另一个原因：我们使用的环境变成树形结构可能更好。假设你在进行一个特性测试时，为了不影响公共测试环境，你需要单独部署一套独立的测试环境。可能你只修改了系统A，但系统A依赖了系统B和系统C，为了让系统A运行起来，你需要把系统B、C都部署起来。而系统B、C可能还会依赖其他系统，那么为了完整的测试你有可能会部署很多系统。如果你只是修改了系统A很小的一个功能点，为了测试再部署那么多套系统，那就显得得不偿失了。所以如果我们的环境是树形结构（有继承特性），那么你只需要在独立测试环境中部署系统A，当系统A需要调用系统B、C的服务时，只需要先判断当前环境中有没有B、C的服务，如果有则调用当前环境的服务；如果没有则调用父环境（公共测试环境）的服务。要实现这点还需要RPC框架的支持，支持也并不复杂：所有环境的服务注册到统一的一个服务注册中心，每个服务标识自己所在的是哪个环境，然后服务消费者在消费服务前，优先消费当前环境的服务，如果当前环境没有服务，则根据环境继承结构，依次往上查找可用的服务，直到找到为止，然后消费。利用RPC框架的扩展机制，可以完成上述功能。环境树怎么获取？可以直接调用配置中心获取。
可以给每个配置项指定一个作用域：私有、可继承、公开。
- 私有--私有的配置只能被当前应用读取，其他应用无法读取，类似面向对象开发中的private访问级别字段。这种作用域可以保护配置不被暴露到其他应用。
- 可继承--可继承的配置既能被当前应用读取，也能被子应用读取，类似面向对象开发中的protected访问级别字段。这种作用域方便让同一个继承体系的应用共享配置，也让配置共享不扩大到所有应用。
- 公开--公开的配置能被所有应用读取，类似面向对象开发中的public访问级别字段。这种作用域能方便有些配置可以被所有应用读取，但又不适合将这种配置放到公共配置里。比如应用需要提供一个客户端给其他应用使用，而且客户端需要读取这个应用的一些配置，那么这些配置就可以作为公开配置。
可以给每个配置项指定普通管理的访问权限：读写、只读、无。该访问权限只约束普通管理，超级管理员能访问和修改所有的配置。
- 读写--普通管理员既能查看该配置项，也能修改该配置项。
- 只读--普通管理员只能查看该配置项，不能修改该配置项。
- 无--普通管理员既不能查看该配置项，也不能修改该配置项。
建议：运维人员使用超级管理员账号把敏感配置的权限设置为“只读”或“无”，然后给开发人员创建普通管理员账号，让开发人员也能查看和修改非敏感配置（比如一些业务开关配置）， 而不需要再通过运维人员。这样既提高了开发人员效率，也减轻了运维人员负担。
可以给应用在具体环境中新建、合并、删除分支，类似git中的分支。基于分支，可满足各种配置灰度发布场景（传统部署方式、容器化部署方式、多重配置灰度发布等）。