多场景环境下配置中心的设计

2018-12-13 13:58


为什么需要集中配置?

随着程序功能的日益复杂,程序的配置日益增多:

  1. 各种功能的开关、参数的配置、服务器的地址等;
  2. 对配置的期望也越来越高,配置修改后实时生效,灰度发布,分环境、分集群管理配置,完善的权限、审核机制等;
  3. 随着采用分布式的开发模式,项目之间的相互引用随着服务的不断增多,相互之间的调用复杂度成指数升高,每次投产或者上线新的项目时苦不堪言,因此需要引用配置中心治理。

同时,我们对程序配置的期望值也越来越高:配置修改后实时生效,灰度发布,分环境、分集群管理,完善的权限、审核机制等。

同时此下文不进行微服务的深入谈论,比如Apollo、Etcd等比较成熟的方案,我们还是考虑如何自己设计满足大部分的场景设计(不是千万级别的)的配置管理,(不考虑日志权限等)

配置中心不同阶段:

一、单一应用

将配置写到文件里,采用xml、yaml、json等格式存储,能够满足服务要求,如果要改配置,登录服务器,修改配置可以完成

二、单一应用需要更新

比如网站的维护开关,不能每次登录服务器去操作,通过数据库来设计,方案也比较简单。

config_key对应键,config_value对应键值,一般为字符或者json格式存储,应用已经能顺利运行,老板说开发个功能,瞬间开关配置完成。-_-

三、多应用

公司发展到一定阶段,产品是很多的,今天要做个直播,明天要做个电商,每个产品一个配置数据中心,有没有一个数据中心解决方案。看如下设计思路。

应用(App)和配置(Config)通过app_id关联,每个应用对应一个配置,目前这一的设计也可扩展为单一产品的不同终端,比如H5、Wap、Pc等可以算一个独立App,这样的配置满足大部分的业务场景需要。

三、多应用Saas

产品是提供saas服务的,比如电商平台,有多商户,如何存储商户配置,商户的手续费、上线等配置。

2个策略:

1、因为此配置和应用非常关联,可以跟着应用走,不走配置中心,使用单一应用的设计中增加商户(company_id)

2、配置中心维护,核心是config_key需要可以新增、更新(建议不要更新和删除),所以维护config_key需要谈论清楚后添加

为什么config_key需要单独维护?因为新增加一个配置后,Conig数据表里所有的商户(company_id)的配置都需要新增加一条或者删除一条


Search
Categories
Friendlinks