动态配置开发模式在转转的落地实践

一、问题背景

1.1 场景概述

• 场景 A：运营活动项目，需要配置一些可动态调整的活动规则；

• 场景 B：信息展示页面，根据不同条件动态配置展示信息；

• 场景 C：业务流程上的动态配置，如根据不同业务类型等条件配置商品上架参数等；

• 场景 ...N：......。诸如以上的场景，在日常的开发工作中随处可见。

我们往往需要一个配置中心来实现业务功能上各种诉求的灵活支持。在转转公司，普遍使用的是携程开源的 Apollo 配置中心（以下简称阿波罗），而在实际的业务开发中，我们遇到了如下的两类主要问题。

1.2 风险问题

• 前置因素 A：运营相关的动态配置往往需要由运营同学根据实时运营诉求不定时对配置进行修改和发布；

• 前置因素 B：阿波罗的配置格式通常是使用 JSON 结构描述的字符串，对运营同学有较高的学习理解成本；

• 前置因素 C：阿波罗配置的配置值信息，做不到基于结构化描述下的字段校验，如：配置项格式校验、必填校验...等等。

基于以上几点前置因素，在实际业务开发中，经常性地出现如下的主要风险点：

• 风险点 a：必填字段缺失，代码中没有对相应字段校验导致出现线上问题；

• 风险点 b：字段格式错误，如：数字配置多写一个 1 导致数字范围溢出等等，从而引起线上问题或运营配置不生效；

• 风险点 c：JSON 结构格式错误，多了或少了"{"、"]"、","、"\n"......种种的结构化格式描述符或特殊符号，导致配置失效；

• 风险点 d：缺少细粒度的单配置项权限控制，多人并发更新导致实际配置结果不符合运营预期，大型活动开始前夕的大量配置发布行为更甚；

• 风险点 e：开发同学需要对所有配置字段做详尽的繁琐的校验逻辑才能保证服务运行的稳定；

• 风险点...n：......。

诸如此类的 CASE 还有很多，在此不作过多赘述。

1.3 效率问题

除了以上所描述的风险问题，还存在一些影响效率的主要问题：

• 负责业务运营的同学需要一定的学习 JSON 结构的成本；

• 业务运营的同学需要较高的针对配置项的沟通理解成本，如"{aaa:1,bbb:333,ccc:[{c1:1,c2:2}]}"这样的配置值，并不能直观描述其业务含义；

• 对于负责项目开发的 RD 来说，工作中非常多的时间花费在协助他人理解配置意义上。例如：在项目开发过程中需要跟 QA、PM 同学反复同步；项目上线后，产品、运营同学往往需要每次更新配置都需要找对应 RD 同学反复确认配置规则；随着相关人员的工作变动，相关运营配置规则还得从代码层面重新理解拉齐认识。

二、问题剖析

2.1 以往的应对方式

以往的应对方式，主要有两种：

1. 配置发布权限统一收拢到相关 RD，配置修改后由 RD 人工检验和发布更新。该方式在转转基础生态部门试行过一段时间，后由于影响配置修改的效率以及对 RD 造成的负担太重而没有长期实行；

2. 编写相关的配置文档。该方式在转转 B2C 业务部门长期实行，针对每一个配置编写专门的操作手册，但对风险问题没有帮助，仅在效率问题上有较小的缓解效果。

2.2 主要矛盾点与问题本质的探索

2.2.1 主要矛盾点

• 从 RD 视角：希望沿用基于阿波罗的配置开发方式。主要意义在于开发提效，极大节省了配置后台开发成本；

• 从运营视角：希望有完善的直观的图形配置后台视图。主要意义在于运营提效，极大的降低配置风险以及反复繁琐的理解沟通成本。

我们发现：基于原本的配置开发方式，开发效率与运营效率似乎站到了对立面。那么是否，真的鱼与熊掌不可兼得？

2.2.2 问题本质的探索

回顾以往的应对方式，会发现现有的解法更多的是缓解问题而不是解决问题。以前的方向更多是一定程度上在有限范围内去接近目标而不是达成目的解决问题。

如下图示意，将原本的配置相关的反复沟通确认过程抽象为一种信息的传达过程，会发现问题可以描述为：内容信息传达过程中的各环节的认知差与信息差导致最终内容的变更或丢失。

信息源：本问题中指的是 RD 同学，配置的开发者。

*手信息接收者：本问题中指的是 QA、PM、运营等角色。

结合上述的思考过程，我们试图通过一种清晰易懂的信息视图的呈现方式：实现信息制造方与信息接受方在同等认知下的同频对话，借此避免认知差异以及信息的多次转述过程中的丢失。

三、方案设计

3.1 视图展示的标准化

如下图示意，提炼了从代码层面的配置信息到视图信息的标准化过程。

3.2 视图构建的自动化

首先，我们认为视图构建中最初的依据是描述视图的确定性结构化信息。从代码定义到最终的视图呈现过程可以概括为一个标准流程：生成结构化信息-提取结构化信息-应用结构化信息。

所以，我们希望通过自动化能力实现最大程度降低流程对人（开发者）的依赖，从而延续原先的高效开发体验（对开发者而言）。

3.3 开发体验的沉浸化

从开发者视角，希望保持原先基于 IDE 的开发体验不被打断，保证开发过程的连续。

3.4 整体架构设计

四、落地现状

该动态配置开发方案的通用版本已完成，实现 100% 覆盖原先的阿波罗配置开发场景。在转转 B2C 业务部门应用近一年来 0 线上配置错误，同时避免了额外的诸如编写文档之类的工作以及在配置规则理解上的反复沟通确认成本。

基于本方案，我们延续原先的高效开发体验，即：

1. 定义你的配置 Key，如：smart_apo_config_test3

2. 定义你的配置类结构，正常完成业务逻辑开发

框架将自动生成对应配置 Key 的视图，示例如下：

<

,

>

五、结语

本文侧重于介绍在工作中关于动态配置开发模式的演进历程，讲述了基于对问题的理解再理解的探索过程去寻找当前最佳解决方案的思路，也是转转公司复仇者联盟技术生态系列之凯蒂组件的由来。

关于作者：陈奇恩，转转 B2C 业务供应链后端负责人。

转转研发中心及业界小伙伴们的技术学习交流平台，定期分享一线的实战经验及业界前沿的技术话题。关注公众号「转转技术」（综合性）、「大转转 FE」（专注于 FE）、「转转 QA」（专注于 QA），更多干货实践，欢迎交流分享~