分布式配置中心导论

一、分布式配置中心使用背景

故名思议，配置中心就是集中管理各个系统的配置。

当系统数量不多的时候，一般是各系统自己管理自己的配置，但系统数量多了以后，这样的处理方式会有问题：

• 某个功能上线时，需要多个系统配合一起上线，分散配置时，配置检查、沟通协调需要耗费较多时间。

• 处理线上问题时，需要多个系统配合查询相关信息，分散配置时，操作效率很低，沟通协调也需要耗费较多时间。

• 各系统自己管理配置时，一般是通过文本编辑的方式修改的，没有自动的校验机制，容易配置错误，而且很难发现。

例如，我曾经遇到将 IP 地址的数字 0 误敲成了键盘的字母 O，肉眼非常难发现，但程序检查其实就很容易。

实现配置中心主要就是为了解决上面这些问题，将配置中心做成通用的系统的好处有：

• 集中配置多个系统，操作效率高。

• 所有配置都在一个集中的地方，检查方便，协作效率高。

• 配置中心可以实现程序化的规则检查，避免常见的错误。比如说检查最小值、最大值、是否 IP 地址、是否 URL 地址，都可以用正则表达式完成。

• 配置中心相当于备份了系统的配置，当某些情况下需要搭建新的环境时，能够快速搭建环境和恢复业务。

整机磁盘坏掉、机器主板坏掉……遇到这些不可恢复的故障时，基本上只能重新搭建新的环境。程序包肯定是已经有的，加上配置中心的配置，能够很快搭建新的运行环境，恢复业务。否则几十个配置文件重新一个个去 Vim 中修改，耗时很长，还很容易出错。

下面是配置中心简单的设计，其中通过“系统标识 + host + port”来标识唯一一个系统运行实例是常见的设计方法。

 

二、轻量级实现自定义分布式配置

1.基于数据表

这是早期的字典表设计，为了解决枚举值变更后能够实现立即生效，不用重启服务的目的，常见的表设计如下：

CREATE TABLE `sys_dict_type` (
  `code` varchar(50) CHARACTER SET utf8mb3 COLLATE utf8_bin DEFAULT NULL COMMENT '编码',
  `name` varchar(100) CHARACTER SET utf8mb3 COLLATE utf8_bin DEFAULT NULL COMMENT '名称'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 COLLATE=utf8_bin COMMENT='字典类型表';

CREATE TABLE `sys_dict` (
  `code` varchar(50) CHARACTER SET utf8mb3 COLLATE utf8_bin NOT NULL COMMENT '编码',
  `type_code` varchar(50) CHARACTER SET utf8mb3 COLLATE utf8_bin DEFAULT NULL COMMENT '字典类型值',
  `name` varchar(100) CHARACTER SET utf8mb3 COLLATE utf8_bin DEFAULT NULL COMMENT '名称',
  `sort_num` int DEFAULT NULL COMMENT '排序',
  `create_time` datetime DEFAULT NULL COMMENT '创建时间',
  `is_del` bit(1) DEFAULT b'0' COMMENT '是否删除',
  `parent_code` varchar(50) CHARACTER SET utf8mb3 COLLATE utf8_bin DEFAULT NULL COMMENT '父节点code',
  PRIMARY KEY (`code`),
  KEY `key__code` (`parent_code`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 COLLATE=utf8_bin COMMENT='字典表';

在配置中心的设计上也是同样原理，可以直接在字典表注册我们需要的配置。

缺点：

1.为了减轻数据库io压力，可能会将配置项存入到缓存，但配置项发生变更，无法立即通知缓存失效，需要人工手动清理缓存，效率比较低。缺少自动发现机制。