动态配置中心

为什么需要配置中心：

• 开关：

  a. 发布开关：依赖其他系统，但是其他系统还没有上线。新功能风险比较大，可以做个开关有问题的话就关掉这部分功能

  b.实验开关

  c.功能验证：加些白名单，某些功能只对内部人员ID有效，来做测试。等功能稳定后全量打开

  d.运维开关 ：大促前会把一些非核心功能问题关掉

• 配置即控制：服务运行在线上环境可能随时需要做一些调整和变更。（公共组件的配置）

• 微服务比较复杂：

  a.单体应用时代：应用数量少；配置简单；运维可以登机器修改配置文件

  b.微服务时代：应用数量多，配置数量也急剧增长，人工登机器修改配置不仅效率低而且容易出错

美团统一配置中心（mtConfig）的整体设计和学习心得

整体结构：

• 功能划分： 动态配置 & 文件配置
  

 

• 模块划分：SDK，sg_agent，sg_Notify(哨兵)，mcc_server，存储（zookeeper 、 mysql 、 cellar）

 【图片补充】

 

模块介绍：

【SDK】（mtConfig client）

1、动态配置初始化和更新流程。

2、文件配置初始化。

3、SDK总结：

对外提供读写配置和listener回调的API，支持高并发读、读写分离和配置容灾。

• 高并发读：因为缓存的加入，可以支持高并发读。

• 读写分离：读请求走cache；写请求走zk，zk的voter负责写操作。

• 配置容灾：SDK层会有cache和落盘（写文件）操作，极端状况也能支持读操作。

 

【sg_agent】 的功能：

• 流量控制：能够控制与MCC Server的连接数（短连接），防止连接过多而压垮MCC Server。

• 数据透传：起到一个代理的角色。将一些易变的逻辑放到的sg_agent，而不易变的逻辑放到sdk中。

• 数据缓存与容灾：Sg_agent本身也有Cache和File，也起到了容灾的作用。

• 心跳连接：定期向MCC Server汇报本台机器感兴趣的配置列表。

• 哨兵：Sg_sentinel远程哨兵，功能与Sg_agent相似的远程代理，在Sg_agent失效时，自动访问Sg_sentinel。

tips：为了去中心化，SDK定时从Sg_agent拉取最新配置，更新缓存（500ms拉取一次），Sg_agent定时从MCC Server拉取最新配置，更新缓存（20s拉取一次）。这两个定时时间差别很大是因为SDK与Sg_agent在同一台机器中（Sg_agent已经提前部署到机器中），二者之间的通信属于进程间通信，速度很快，所以拉取频率很高；而Sg_agent与MCC Server之间属于机器间通信，频繁的通信不太合理。

Sg_agent与MCC Server建立的连接是短连接。

SDK和Sg_agent各自将缓存持久化到磁盘，作为backup，以实现动态配置的缓存与容灾，提高读操作的可用性。

 

【mtConfig Server】 —— mccServer 和 sg_agent 的调用关系

MCC Server提供thrift接口，Sg_agent基于thrift协议调用MCC Server接口，具体接口定义如下：

1. 根据appkey、env、path获取配置文件： ConfigDataResponse getMergeData(GetMergeDataRequest request)

string getMergeData (string appkey, string env, string path, string ip, int version);

2. 配置更新时，通过MCC Server通知SgNotify，回调Sg_agent接口进行更新配置（实现配置push操作）：

string callBackMCC(1:i32 cmdType, 2:string sData);

3. Sg_agent轮询监听配置是否更新，pull拉取配置接口：

string updateConfigByTime(string appkey, string env, string path, int version = 0);

维护需要轮询监听的appkey与zknode对应列表，每隔一段时间就去轮询check是否更新

4. Sg_agent缓存配置到本地文件：

string ansyUpdateConfig2File(string appkey, string zknode, int version = 0);

从MCC成功获取到配置后，如果配置内容有更新，则异步写本地文件进行缓存容灾；

当MCC Server访问失败时，则从本地文件中读取配置。

 

1、动态变更流程

【图片】

 

2、动态存储流程

2.1存储介质：zookeeper

tips：在zookeeper中，一个ZNode的默认大小限制为1M，因此导致了MCC中一个appkey + 一个环境（prod/test/dev）的动态配置存储最大只支持1M。

路径格式：appKey + env + path

path:

1. group.[subGroup].swimlane

2. swimlane

3. setGroup.swimlane

 

2.2存储介质： Celler

通过Celler的prefixGet获取某个appkey下的所有文件

1. 获取一个appkey的所有filepath

   key: env|appkey|filename

   value: current_version|filepath

2. 获取一个appkey某个文件的所有version

   key: env|appkey|filename|version

   value: content

3. 获取一个appkey的最新文件

   key: env|appkey|filename[|version]

   value: content

3、MySQL

a. MCC Server的管理数据

b. review管理

c. 权限控制

d. 配置回滚

e. client同步记录等信息

【sg_notify】

SgNotify通过配置变更通知和与Sg_agent的定时同步实现消息的及时感知。

• 动态配置：配置修改后，会周知该配置关联的机器，以提高各个client对配置变更的感知速度。

• 文件配置：主动将配置文件下发到指定的机器。