存在即合理，为什么需要配置中心

为什么需要配置中心，搭建一套服务管理配置有必要吗？配置放在配置文件或者数据库它不香吗？不是应该做减法吗?

• 随着程序功能的日益复杂，程序的配置日益增多：各种功能的开关、参数的配置、服务器的地址等等
• 一套系统需要配置多个环境，我们有开发环境，测试环境，预上线环境，线上环境，如何统一管理
• 对配置的期望也越来越高，配置修改后实时生效，灰度发布，分环境、分集群管理配置，完善的权限、审核机制等等
• 随着采用分布式的开发模式，项目之间的相互引用随着服务的不断增多，相互之间的调用复杂度成指数升高，每次投产或者上线新的项目时苦不堪言，因此需要引用配置中心治理

成熟的配置中心产品对比

配置中心对比

我们着重来看下nacos，这是阿里开源的新的一款配置中心（原来的配置中心为diamond，现在已经不维护了），下面看下它的架构设计：

nacos基本架构

再看下nacos的逻辑架构及组件：

nacos组件

2、注册中心：用于服务管理，配置变更通知等等；
3、客户端：提供配置获取、注册服务等；

ok，那下面我们就自己手动设计一个简单的配置中心。

整体设计图

整体设计图

特征

具备统一的管理配置能力、配置发布回滚能力、配置更新秒级推送能力、客户端配置缓存能力、对敏感配置设置访问权限能力、配置灰度发布能力、管理员权限管理能力。

• 统一的管理配置能力：提供配置管理页面，可管理不同应用在不同环境中的配置。
• 配置发布回滚能力：配置可一按照版本进行发布回滚。
• 配置更新秒级推送能力：新配置发布后可秒级的推送到应用。
• 客户端配置缓存能力：如果应用启动时无法连接服务端，可使用预先- 存储在缓存文件中的配置，保证应用正常启动。
• 对敏感配置设置访问权限能力：可对一些重要或敏感的配置设置访问权限，防止配置被泄漏。
• 配置灰度发布能力：满足各种配置灰度发布场景（传统部署方式、容器化部署方式、多重配置灰度发布等）。
• 管理员权限管理能力：可对不同管理员设置对应的配置管理权限，让合适的人管理合适的配置。

角色

configcenter中的角色包含：服务端、客户端、MySQL数据库、Redis、Nginx、应用、配置管理员

• 服务端--服务端用于集中管理应用的配置。配置数据落地到MySQL数据库，允许客户端通过http请求查询配置，允许客户端通过Http Long Polling（长轮询）接收配置变更通知。当应用的配置有了变更（增删改），则会通知客户端（秒级）。
• 客户端--客户端用于协助应用获取配置。客户端刚启动时会通过http请求服务端读取应用的最新配置。如果从服务端读取失败，则客户端会尝试从本地缓存文件中读取配置；如果本地无缓存文件，则启动失败。客户端启动成功后，会通过Http Long Polling（长轮询）接收服务端配置变更通知。当监听到配置有变更时，客户端会再次通过http请求服务端读取最新配置，然后把最新配置保存到缓存文件，最后将最新配置和当前客户端中旧配置进行比较，将变化部分通知给应用。
• MySQL数据库--MySQL数据库用于存储服务端管理的配置。
• Redis--Redis有两个作用：1、缓存数据库存储的配置，提高系统响应效率；2、存储管理员登录的session；
• Nginx--Nginx用于对多个服务端进行负载均衡。由于服务端使用Redis存储所有的管理员登录的session，所以Nginx的负载均衡策略可以使用随机策略，而不需要使用根据sessionId的策略。如果你有其他更好的负载均衡器，只要它能支持http协议，则完全可以使用它替代Nginx。
  应用--应用是从服务端获取配置的系统。应用可以通过客户端的协助获取配置；当然它也可以抛弃客户端，自己直接发起http请求服务端，获取配置。
• 配置管理员--配置管理员管理配置，分为两个级别：普通管理员、超级管理员。普通管理员只能管理分配给他的配置；超级管理员既能管理所有配置，也能管理其他管理员。管理员可以是运维人员，也可以是开发人员。给开发人员分配相应的权限，让其可以自助的管理配置，提高工作效率。

设计的原则

• 简约--从架构设计、服务端设计、客户端设计、数据库设计到页面设计，都遵从这个原则。
• 部署简单--只依赖MySQL和Redis，部署时只需一个jar包+MySQL+Redis。
• 配置治理--具有完善权限管理并且支持标记敏感配置，让你可以把非敏感配置放权给开发人员，让他们自助的管理配置，提高工作效率。
• 配置共享--支持应用、环境两个纬度的继承关系（配置共享），让你可以去设计你的配置，让它变得优雅易管理。从开发的角度来看，就像从面向过程开发迈入面向对象开发一样。
• 灰度发布--满足各种配置灰度发布场景（传统部署方式、容器化部署方式、多重配置灰度发布等）