斗鱼配置管理中心 Minerva 的设计与实现

本文字数：5809 字

精读时间：12 分钟

也可在 5 分钟内完成速读

伴随微服务的推广，程序粒度的日趋小型化，配置文件的数量成几何级数增长，采用传统的本地文件方式管理应用，凸显的问题越来越多，很难适应于快速发展的微服务架构和容器虚拟化技术。我们需要对配置进行治理，能够对配置进行下发管理、版本管理、安全管理、权限管理等，因此斗鱼的Minerva配置中心应运而生。

Minerva配置中心是斗鱼研发的配置管理中心，集中化管理在不同机房、不同环境的应用配置，配置采用Key-Value 的数据结构，存储使用MySQL和ETCD，支持配置快速搜索，支持配置修改实时生效、 支持K8S 下使用配置中心、支持配置关系可视化等功能，适用于微服务的配置管理。

00

前言

为什么需要配置中心

	应用数量	配置数量	配置体积	变更频率
单体应用时代	较少	较少	内容少	低
微服务时代	增多，机器节点增多	与应用数量呈正相关增加	增加大量依赖关系配置	变更频率远大于版本发布频率

在单体应用时代，应用特点是：集成化、中心化、总量少；服务间依赖关系简单，较少考虑上下游依赖配置，迭代速度慢，配置变更频率低，只需要维护一个集成类型的配置文件，部署在数量可控的高性能机器上即可，遇到紧急情况可以让运维同事之间上机器操作便可以快速解决问题。

到微服务时代，应用开始进行功能化拆分，总量呈几何上升；采用低配置机器，注重弹性扩容，部署节点显著增多；更关注上下游服务相关配置，且配置文件的修改频率因为精细化操作、依赖管理等远高于代码本身的修改频率。

所有的这些麻烦是由于我们对配置和代码在管理和发布过程中不加区分造成的。配置本身源于代码，是为了提高代码的灵活性而提取出来的一些经常变化的或需要定制的内容，正是配置的这种天生的变化特征给我们带了很大的麻烦。

因此，在借鉴了业内其他分布式配置中心的设计和实现后，我们设计了下面的分布式配置管理系统，致力于将配置内容从代码中完全分离出来，及时可靠高效地提供配置访问和更新服务。

主流产品差异性

	优点	缺点
QConf 方案	设计简单清晰	重度依赖 ZK 集群 横向扩展困难
淘宝 Diamond 方案	简单 可靠 易用	过于依赖 MYSQL 数据库 客户端性能存在瓶颈 高可用性受限
携程 Apollo 方案	基于 JAVA+Eureka 集群 多层负载，多级缓存保证高可用 权限管理，审计操作完善	设计复杂，部署维护成本高

综合各种方案调研，考虑到现有的技术积累，在斗鱼实际业务场景中没有大规模使用ZK集群，实际服务部署架构上存在大量多机房部署的现象，我们希望配置中心：设计简单清晰；可靠易用；支持多机房高可用。携程的Apollo是不错的实现方案，功能完善设计完整。但是对斗鱼而言略显臃肿、维护成本高、对斗鱼的多机房架构和k8s结构支持不友好，所以我们必须要有一套更加适合斗鱼的配置中心。

01

Minerva 配置中心简介

Minerva 配置中心理念

Minerva配置中心有三个核心理念：配置完整性定义；配置下发回显功能；配置缓存优先级设计。

配置完整性定义

配置完整性定义是：环境变量、编译注入配置、命令行配置、文本文件、远端配置，这五类数据共同构成了一份完整配置，形成一份完整配置。配置中心会对以下五类配置进行管理&