分布式配置中心

为什么要有分布式配置中心：

1、项目背景

　　现在有一个项目，使用SSM进行开发的，配置文件的话我们知道是一个叫做application.properties的文件。

#业务参数相关配置
user.register.default.name=小强
user.register.default.sex=男

　　这个配置文件会在项目启动的时候被加载到内存中进行使用的。

2、需求一

　　由于业务的变动，用户在以前进行注册的时候默认的用户名是“小强”，但是新的领导来了，需要把这个改成“小明”。因为，业务的流量还是比较大的，所以，没有办法在白天流量高峰期修改配置文件，进行重启！

　　此时，就辛苦开发小哥了，他们需要等到半夜里凌晨三四点，没有流量的时候，去修改application.properties配置文件，必将系统进行重启。另外，公司采用的是集群，进行了负载均衡，系统部署在了多台服务器上，那么开发小哥需要一台台的进行修改.

　　开发小哥是在忍受不了这种变更了，修改一个配置就需要如此周折的去完成这件事情！

3、需求二

　　我们在进行业务开发的时候，一般会有多个环境，至少应该有三个：开发、测试、线上。那这三个环境之间的配置文件肯定是有不同的，比如说他们之间的数据库是肯定不同的！application.properties例如：

#数据库相关配置
spring.datasource.type=com.alibaba.druid.pool.DruidDataSource
spring.datasource.driverClassName=com.mysql.jdbc.Driver
spring.datasource.url=jdbc:mysql://192.168.1.128:3306/ufind
spring.datasource.username=root
spring.datasource.password=123456

　　那我们如何使不同环境之间进行隔离哪？答案很简单，不就是指定三个不同的文件，然后在项目启动的时候指定不同的环境不就行了吗？于是开发小哥就动起来了，修改如下：

　　修改之后，运维的小哥不愿意了！一开始没有进行环境隔离的时候，只有一个环境（开发完成之后，直接修改配置文件，合并到主干，线上发布），运维小哥在使用Jenkins+Git+Maven进行自动化集成的时候，只需要配置一下就行了！在Jenkins启动的脚本命令是：java -jar ssm.jar 就可以搞定了，经开发小哥这样一搞，修改启动的命令不说，新增了环境，还要创建不同环境的自动化集成。

　　分别需要设置的命令如下：

java -jar -Dspring.profiles.active=dev nssas.jar
java -jar -Dspring.profiles.active=beta nssas.jar
java -jar -Dspring.profiles.active=prod nssas.jar

　　运维小哥的工作量直接翻了一倍多。

4、什么是分布式配置中心

　　从上边两个小需求，已经可以看出，传统配置的方式已经暴露出了很多问题，其他的诸如：历史版本管理，权限控制，安全性等等问题，是传统配置文件无法解决的！

　　随着业务的发展、微服务架构的升级，服务的数量、程序的配置日益增多（各种微服务、各种服务器地址、各种参数），传统的配置文件方式和数据库的方式已无法满足开发人员对配置管理的要求：

安全性：配置跟随源代码保存在代码库中，容易造成配置泄漏；
时效性：修改配置，需要重启服务才能生效；
局限性：无法支持动态调整：例如日志开关、功能开关；

　　因此，我们需要配置中心来统一管理配置！把业务开发者从复杂以及繁琐的配置中解脱出来，只需专注于业务代码本身，从而能够显著提升开发以及运维效率。同时将配置和发布包解藕也进一步提升发布的成功率，并为运维的细力度管控、应急处理等提供强有力的支持。

分布式架构带来的问题:

多个用户服务的节点，都会存在一份本地配置 (application.yaml/application.properties)。这样的情况导致如果节点越来越多的话，会需要维护与节点数相同甚至更多的配置文件。
用户服务与商品服务可能会有一些相同的配置，如关系型数据库配置信息，非关系型数据库配置信息。但是这部分配置不能共享，只能各个服务做配置冗余。
如果配置需要更新，无法保证同服务的多个节点全部更新，也无法保证不同服务间冗余的配置同步更新。带来了一定的不确定性。
配置更新还需要重新服务，无法满足高可用的需求。
多环境需要维护不同的配置，但无法做到配置的隔离。

分布式配置中心的主要优点：
（1）中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。
（2）消除了配置变更时重新部署应用和服务的需要，让配置管理变得更加高效和敏捷。
（3）配置中心化管理让实现无状态服务变得更简单，让服务按需弹性扩展变得更容易。
（4）实现配置隔离，多环境配置也可统一管理。
（5）减少开发和运维很大的工作量。

一个简版的配置中心是什么样的

1、配置中心的特点

配置的增删改查；
不同环境配置隔离（开发、测试、预发布、灰度/线上）；
高性能、高可用性；
请求量多、高并发；
读多写少；

2、简版配置系统

我们可以设计出如下的简版配置中心：

通过OA系统对每一条配置（每一个配置有唯一的配置ID）进行增删改查；
区分不同环境的配置，每个环境同一配置ID对应不同数据库记录；
配置最终以json格式（便于编辑和理解）储存在mysql数据库中；
引入redis集群，做配置的缓存（比如可以设置配置修改后1分钟后生效）；
配置对外服务，多机器部署，满足性能需要；
如果有必要，可以引入配置历史修改记录；

配置中心原理及实现方式

分布式配置中心需要哪些要素：

同服务的多个节点仅需要维护一份配置 —— 配置内容中心化存储
服务动态扩缩 —— 持久化存储
应用需要从中心化配置中心获取配置 —— 提供对外 API
配置变更无需重新部署应用 —— 数据变化通知给客户端
配置中心异常时保证可用 —— 配置高可用及本地缓存

根据这些要素，我们来看看目前大多数配置中心的实现

　　上图中，使用 git/zookepper/mysql 等存储作为配置内容的持久化存储。通过本地缓存及配置服务器集群实现配置中心的高可用。通过定时监听服务端配置，完成数据变化的通知。这样的架构就可以完成大多分布式配置中心需要提供的功能。