江苏龙网

  1. 主页 > 生活百科 > >

微信后台开发工程师：微信研发体系下的分布式配置系统设计概要

分布式

作者：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类型的数据 。
访问模型相别于产品用户产生的数据，配置系统的数据流是单向的，离线系统与实时系统结合而读写分离（异步写、实时读）的 。最终我们要搭建的分布式配置系统，它的系统设计，也必然是建立在这类访问模型上的 。
微信后台开发工程师：微信研发体系下的分布式配置系统设计概要

文章插图
 
系统约束显然，内部运营人员作为生产者，所有的配置肯定都是文本类型的（Readable），并且数据量少(相对于用户、系统等生产数据而言），对存储空间需求少，更新频次低 。可以这么理解，在整个配置系统架构中，输入方就如同键盘相对于 CPU 而言是超慢速设备，他们对系统的易用性、易操作性、安全性要求更高 。


    推荐阅读


    上一篇：安吉白茶历史,福鼎白茶和安吉白茶有什么区别

    下一篇：保证茶叶新鲜度的方法,碧螺春的储存方法