分布式配置中心产生的背景

一、前言

       对于配置文件，我们并不陌生，它提供我们可以动态修改程序运行的能力。引用别人的一句话就是：系统运行时（runtime）飞行姿态的动态调整！

       我可以把我们的工作称之为在快速飞行的飞机上修理零件。我们人类总是无法掌控和预知一切。对于我们系统来说，我们总是需要预留一些控制线条，以便在我们需要的时候做出调整，控制系统方向（如灰度控制、限流调整），这对于拥抱变化的互联网行业尤为重要。

        对于单机版，我们称之为配置（文件），对于分布式集群系统，我们称之为配置中心（系统）。

二、背景

2.1 项目背景

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

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

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

2.2 需求一

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

       此时，就辛苦开发的小哥了，他们需要等到半夜凌晨没有流量的时候，才能去修改application.properties配置文件，并将系统进行重启。

       另外，公司采用的是集群部署，进行了负载均衡，那么开发小哥需要一台台的进行修改。

2.3 需求二

       我们在进行业务开发的时候，一般会有多个环境：开发（dev）、测试（sit）、验收（uat）、生产（prd），这些环境之间的配置文件肯定是有不同的，比如说它们之间的数据库是可定不同的。例如：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

那么我们如何进行不同环境文件进行隔离呢？答案很简单，指定三个不同的文件，然后在项目启动的时候指定不同的环境就行了，修改如下：

2.4 什么是分布式配置中心

       通过上面的需求，我们可以看出来，传统的配置方式已经暴露了很多的问题，诸如：历史版本的管理、权限控制、安全性等等问题，是传统的配置文件无法解决的。

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

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

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

三、配置演进

3.1 单机配置文件

       当我们是一个单机服务时，我们配置通常写在一个文件中，代码发布的时候，把配置文件和程序推送到机器上。

3.2 多机器配置

      随着业务量的增加，通常我们会把服务进行多机器（集群）部署。这时候，配置发布如下：

3.3 分布式集群部署配置文件

       这样去部署配置简直是异常噩梦，而且无法做到快速的动态调整，失去了配置主要意义了。

四、简版配置中心

4.1 配置中心特点

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

4.2 配置中心

设计说明点：

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

很多时候，这样可以基本上满足我们对配置系统的基本需求，对配置的增删改查，能容忍一段时间的数据不一致性。

这种设计，由于所有的配置都存放在集中式缓存中，这样集中式的缓存也会有性能瓶颈。而且，每次配置的访问都需要发起rpc请求，因此考虑在客户端引入本地缓存（localCache，例如Ehcache）。

五、改进版配置中心

5.1 配置中心之性能可用性改进

     考虑到，减少网络请求的因素，在客户端引入localcache，来解决系统的高可用，高性能、可伸缩性。本地缓存配置中心如下：

相对于第一版，在客户端引入localcache，开启线程异步调用配置服务，更新本地配置。这样减少rpc调用。

基于数据的CAP原理，该方式只做到了AP，这里会存在数据的一段时间的不一致性，但最终会保证是配置的最终一致性。如何解决这个数据不一致性的问题呢？

5.2 配置中心之数据一致性改进

        通常配置都只有一个入口修改，因此可以考虑在配置修改后，通知应用服务清理本地缓存和分布式缓存。这里可以引入mq或zookeeper。

最后通过，推拉相结合的方式，完成数据的一致性。

参考：

• https://www.cnblogs.com/xuliugen/p/10422330.html