任何业务系统在高速成长的过程中都需要快速的迭代交付，验货宝业务也不例外。这个过程中不可避免的会在系统代码中不断引入「坏味道」。
下面我们来看看验货宝近期做的一个微小的优化和一些思考。
什么是「验货宝」
这里首先介（ān）绍（lì）一下闲鱼的验货宝服务。
在闲鱼购买数码产品、潮鞋、奢侈品包包等贵重物品时，买家可能会担心买到假货或者与卖家描述不符的宝贝，卖家也希望自己的优质宝贝能卖个好价格。
为了解决买卖双方的信任问题，闲鱼和专业机构合作，为所有的验货宝商品提供权威的验货报告。
当买家下单购买验货宝商品后，卖家将宝贝发货至验货中心，验货中心出具验货报告后，买家可以根据报告决定购买或者不购买。
验货宝服务一上线就深受用户喜爱，短时间内圈粉无数。
那女（运）孩（营）对我说，再再再来个新类目
验货宝上线也半年有余，需求迭代速度也趋于平稳，得益于优良的整体架构设计，目前后端开发由我一个人即可 Cover 住。但在需求迭代的过程中还是有一些「痛点」，比如：我希望当运营同学后面不断来找我新增类目时，我可以更快更简单一点搞定。
验货宝目前首批上线支持的品类有：手机、平板、笔记本、潮鞋、奢侈品包包、奢侈品腕表、奢侈品饰品、奢侈品服装。后续验货宝服务还将覆盖更多品类，让大家卖得舒心买得放心。
不同类目有着不同的验货费计算策略、不同的介绍页 URL、不同的服务商、不同的可升级的价格区间（指定价格段的商品才可以升级验货宝服务）、不同的内部 Code 等等。当然这些大部分内容是通过配置进行管理的，但配置散落在多个系统、多个 key 中，还有一部分是硬编码在代码中的。
配置分布在多个系统中主要是因为不同配置系统侧重有所不同，比如有的配置系统面向开发同学、有的面向运营同学；硬编码在代码中主要是如一些全局的常量 Code 需要打到依赖的 JAR 包中。硬编码的配置带来的问题是上线新的品类需要进行服务端代码发布，会受节假日、封网等的影响，发布周期长、不够灵活。
其实这个一个常见同时也容易忽视的场景，一条链路中相关联的配置需要收口到一个「原子配置」（指的就是一个最小的下发单位）中，配置项过多且分散可能带来的诸多负面影响：
•增加维护成本：变更流程繁琐，需要修改多个配置；
•易出错：容易出现错配、漏配而不自知的情况；
•变更时间延长：每个配置都需要修改、走流程审批等；
•一致性问题：如果一条链路多个配置有时序依赖，那么配置系统下发的延时可能引发一致性问题，需要额外的手段保障最终一致性，但原子配置就不存在这个问题。
为了优化这个问题，同时为了支撑后面新类目能够快速上线，验货宝刚刚做了个专项优化：配置的归一化改造。目标是新类目上线免发布，同时配置统一按类目收口一处。
简单点，新增类目的方式简单点
首先从两大主要链路入手梳理：
•商品升级链路
•订单履约链路
整个链路涉及多个应用，配置的类型也多种多样：String、Boolean、Map、Integer 等等。现有「Mach 云投放平台」刚好可以满足这个配置中心的需求。
Mach 提供独立的配置定义和配置实例能力。配置定义采用 JSON Schema 对配置内容进行类型约束，配置实例可以创建不同投放时间段、不同优先级、不同环境的多个实例。
这里我通过一个简化的例子说明下这条链路，比如我梳理出来每个类目应有这 3 个配置：
•验货宝服务说明页面 URL：字符串类型
•应收取的验货费金额：数值类型
•该类目可以升级验货宝服务的分类：字符串列表类型（这项我解释一下，是用来配置多个分类如篮球鞋、板鞋、帆布鞋等都可以开启验货宝潮鞋类目验货服务）
那么我在 Mach 上创建一个新配置：「验货宝配置集」，首先定义 JSON Schema：
然后新建一个配置的实例，设定生效时间区间、优先级等信息。最后就填这 3 个配置的具体内容，Mach 会根据配置项的数据类型生成对应的 GUI 填写页面，比如 string 类型就是一个文本输入框；array 是一个带 + 按钮的文本框列表；number 类型是一个带数值校验的文本输入框。
这里例子就不贴页面截图了，用文本示意下：
•introductionPageUrl: www.taobao.com/yanhuobao/introduction-page.html[1]
•platformServiceFee: 39
•cateIdUnderScene: [123, 234, 345]
OK，现在我们就可以通过 Mach 的服务接口拉取这个配置信息了，我们可以从接口获取到这个配置实例的 JSON 字符串，通过 fastjson 就可以解析到对应的配置内容了。
当然我们对配置定义的结构和实际使用的数据结构不一定完全一致，我们会将以上配置解析为一个包含如下 3 个变量的配置 DO 对象：
线上业务 QPS 非常高，同时这些配置不要求实时获取最新值，因此我们在本地做一份缓存，当然将解析好的 ConfigDO 对象保存下来是最好的选择。
烟花易冷，轮子少造
一个应用中会引用非常多的 Mach 配置，每个配置解析出来的 DO 数据结构各不相同，但如果每处使用都自己缓存势必造成重复开发和资源的浪费。那么我们这里顺带引入了一个通用的配置缓存池。
缓存池采用的是 Guava 的 LoadingCache，通过抽象出一个 ConfigValueParser，各个配置使用者可以实现其对应的解析逻辑。
在 parseConfig 实现解析逻辑，返回上面提到的配置解析后的 YhbConfigDO 对象即可。
在使用的时候就可以直接获取：YhbConfigDO yhbConfigDO = configMachReader.get(CONFIG_MACH_ID);
总结
本文通过一个验货宝近期的一个配置归一化的优化介绍了产品链路中相关联的配置分散可能会产生的问题，以及优化方案。
希望能对大家有所帮助。
