微信研发体系下的分布式配置系统设计概要

作者：ypaapyyang，腾讯 WXG 后台开发工程师，个人公众号：码农课代表。

本文旨在分析分布式配置系统的必要性、可行性，及其关键约束，并介绍一款基于该系列分析，在微信研发体系下的实践尝试。

前言

对很多的业务开发同学而言，对运营素材的处理不是一件轻松的事，通常需要定制化的进行数据的清理、格式的转换、工具的开发。笔者就曾过这样一段不愉快的回忆，为了导入一次性的近十种类型的配置数据，就耗去了两天的时间。如果说这段经历有何价值的话，那就是促使我思考分布式配置系统，并且在工作中实践，使自己避免再次陷入如此槽糕的过程中。

本文正是旨在分析分布式配置系统的必要性、可行性，及其关键约束，并介绍一款基于该系列分析，在微信研发体系下的实践尝试。

配置的定义

我们清楚软件建模的本质是对现实世界（人、事、物及规则）的映射，映射的产出物即包括编程系统和配置。配置为我们提供了动态修改程序运行时行为的能力，即常说的“系统运行时飞行姿态的动态调整”，究其根源则是“我们人类无法掌控和预知一切，映射到软件领域上，我们总是需要对系统的某些功能特性预留出一些控制的线头，以便我们在未来需要的时候，可以人为的拨弄这些线头从而控制系统的行为特征。”

因此，本文所指的配置特指内部运营人员产生的数据（广义的系统运营人员，包括产品、运营、研发等），并且作为输入参数而作用于编程系统（包括实时系统、批跑程序以及数据任务等）。

归纳而言，配置通常包含如下三种：

a. 环境配置，定义了应用程序运行的环境相关参数，如 IP、Port 等；

b. 应用配置，定义了应用程序自身相关的参数或者信息安全控制等，如初始内存分配大小、数据库连接池大小、日志级别、账号密码等；（密码、证书这类东西肯定不要放在配置系统中，而应当走统一加解密服务）

c. 业务配置，定义了应用程序所执行的业务行为数据，比如最常见的功能开关，参与活动的商户名单等。

系统约束

数据模型

配置最基本的数据单元是key=value（即配置项），比如功能开关通常就是最简单的类型，用 boolean 型值来影响程序执行链路（不考虑灰度的情况）。然而只有 key-value 类型是不足的，比如 DB 的连接配置就包含了 ip、port、username、password 等字段，在 ini 文件的实现中即是不同配置项来组成，它们在逻辑上是属于同一个配置对象，因此基于面向对象的设计思路，key=object才是更通用的配置模型，在物理实现中可以为 json 或者 xml，或者 protobuf message。

object 类型的数据即可以是平坦的，也可以是多层次（嵌套）的。在实际的业务应用中，平坦类型的数据有其特殊性，即其通常条目较多，最典型的数据是白名单，可能多达上万条。线下，内部运营人员通过excel进行这类数据的管理，如果我们只是粗暴的将其打包成一个对象，那么过大的数据可能会导致系统效率的下降（不是配置的写入效率下降，就是配置读出效率下降），因此我们会使用array of plain object来表达，即key=table类型的数据。

访问模型

相别于产品用户产生的数据，配置系统的数据流是单向的，离线系统与实时系统结合而读写分离（异步写、实时读）的。最终我们要搭建的分布式配置系统，它的系统设计，也必然是建立在这类访问模型上的。