一、问题背景
1.1 场景概述
- 场景 A:运营活动项目,需要配置一些可动态调整的活动规则;
- 场景 B:信息展示页面,根据不同条件动态配置展示信息;
- 场景 C:业务流程上的动态配置,如根据不同业务类型等条件配置商品上架参数等;
- 场景 ...N:......。
诸如以上的场景,在日常的开发工作中随处可见。我们往往需要一个配置中心来实现业务功能上各种诉求的灵活支持。
在转转公司,普遍使用的是携程开源的Apollo配置中心(以下简称阿波罗),而在实际的业务开发中,我们遇到了如下的两类主要问题。
1.2 风险问题
- 前置因素 A:运营相关的动态配置往往需要由运营同学根据实时运营诉求不定时对配置进行修改和发布;
- 前置因素 B:阿波罗的配置格式通常是使用 JSON 结构描述的字符串,对运营同学有较高的学习理解成本;
- 前置因素 C:阿波罗配置的配置值信息,做不到基于结构化描述下的字段校验,如:配置项格式校验、必填校验...等等。
基于以上几点前置因素,在实际业务开发中,经常性地出现如下的主要风险点: - 风险点 a:必填字段缺失,代码中没有对相应字段校验导致出现线上问题;
- 风险点 b:字段格式错误,如:数字配置多写一个 1 导致数字范围溢出等等,从而引起线上问题或运营配置不生效;
- 风险点 c:JSON 结构格式错误,多了或少了"{"、"]"、","