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

前言

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

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

配置的定义

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

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