一、项目背景

为什么需要架构升级

• promise时效包含两个子系统：内核时效计算系统（系统核心是时效计算）和组件化时效系统（系统核心是复杂业务处理以及多种时效业务聚合，承接结算下单黄金流程流量），后者依赖前者，分别由两组技术团队支持；因为有些业务的渗透造成两个系统的边界越来越不清晰；有些需求从PRD评审到项目上线，需要两组研发全程参与，耗费大量人力；
• promise时效计算业务逻辑经过多年的沉淀越来越复杂，时效计算系统中有很多业务逻辑，导致计算内核也需要跟随需求频繁更新；
• 时效计算分为预约和非预约，下单前和下单后，结算页时效和商详页时效。有共性也存在差异，导致共用一部分内核计算的同时存在大量冗余重复代码，需要同时维护和存储两份时效计算的缓存数据。
• 多种业务从内核系统中提供专用接口，导致系统严重腐化。
• 存在部分未采用RPC方式的依赖，导致jar包依赖和时效计算的切量开关需要配置在组件化时效系统中，影响开发和联调效率。

综上，决定这次技术驱动的重构，需要架构升级解决系统中存在的问题。

重构目标

业务边界更清晰

重构之后的需求边界从产品侧就能够确定，如果新增仓配时效计算规则需要修改或新增内核计算，其他业务的需求基本组件化时效中修改即可；

业务逻辑更聚合

组件化中整合业务逻辑；

内核计算逻辑更纯净

一套时效计算缓存，节省一半硬件资源费用；

增加系统复用性，一套计算模式同时支持预约和非预约两种模式，支持结算和商详，下单前和下单后的场景；维护一套内核计算逻辑代码，与具体业务分离，节省更多人力资源；

二、方案设计

内核计算业务梳理

现有业务接口：

• 标准达日历：考虑控单，产能，大宗禁止 标准达日历
• 京准达日历：考虑控单，产能，大宗禁止 京准达日历
• 无人车日历：无人车日历 仓自提/无人车日历
• 仓自提日历：仓自提日历，不走干支线 仓自提/无人车日历
• 自提日历：获取自提点四级地址，考虑控单，产能，大宗禁止 标准达日历
• Vxp日历：考虑控单，节假日，大宗禁止，不考虑产能，固定最大天数和可选天数 标准日历
• 7Fresh日历：标准达日历计算完成后根据门店波次替换日历波次 标准达日历
• 全球购报税日历：加上全球购报税备货buffer后走标准达日历计算 标准达日历
• B2B日历：B2B日历计算
• 夺宝岛日历：夺宝岛日历计算

根据业务特点，将原来的8种业务时效计算接口聚合为3个核心通用计算接口，消除了5种业务的特殊处理接口。重新定义设计新的内核计算接口：京准达时效、标准时效、仓自提时效。减少了大量重复代码，避免改一个需求就要改好多相同的地方，便于统一管理。

新core系统三个核心接口方法可以为多个业务系统提供服务

系统重构相关业务如下图所示，

主要变更点：

• core接口聚合，组件化系统适配，补充处理前置信息；
• 重构之前控单接口的调用和产能逻辑分散在组件化时效和base系统中，重构后产能提供新接口，控单和产能逻辑从core系统剥离，集中到组件化时效系统中；
• 大宗商品、二级仓、全球购清关、VXP节假日等业务逻辑上浮到组件化系统，减少了系统间报文大小和接口复杂度；

系统重构业务

三、项目实施

组件化业务梳理

• 考虑产能
• 考虑控单
• 考虑走干支线
• 判断是否大宗
• 新增全球购清关时长加buffer
• 新增产能白名单
• 新增产能白名单打标
• 新增自提波次格式转换
• 新增二级仓出参信息整合
• core新接口转单据类型
• 节能补贴增加默认buffer
• 增7鲜门店波次转换
• 新增全球购多仓屏蔽逻辑

组件化时效中对新接口进行适配，可用切量开关进行控制

四、稳定性保障

怎样保证系统重构的安全性和准确性，重构前后一致性验证上线前主要有两种方式：单测覆盖和流量回放验证；上线后通过多维度切量开关进行控制，保障系统的稳定性。

上线前

• 单测场景覆盖

1700+个测试用例，覆盖大部分单一业务场景和部分组合业务场景。

• 流量回放验证

通过实时引流线上流量，回放到重构后的系统中。流量回放过程中发现差异，分析具体原因，发现多个重构测试用例未覆盖到的复杂场景问题。

eg.全球购商品满足城配转普通时效走大宗时效的场景:正常逻辑是①全球购商品命中了城配逻辑；②全球购不支持城配时效，需要转普通时效；③转成普通时效后又命中大宗业务场景。重构时从①走到了③,城配时效和大宗时效是互斥的，所以无法转换成大宗时效，调整转换逻辑后导致和重构前时效不一致，这种场景负责涉及业务配置很多，很难通过测试用例覆盖，流量回放验证是很好的验证方案。

• 流量回放自定义对比差异

由于系统架构调整以及新接口的设计和老架构存在差异，导致采购、全球购、控单等业务场景下返回的起始日历日期不一致，实际可用日历和波次是一致的，所以这种是预期内的差异，导致流量回放时diff率较高，页面配置的忽略字段无法满足我们的需求；

首次采用自定义脚本进行差异对比，自定义实现排序和忽略项设置，将不影响时效的差异对象忽略掉，减少diff干扰。

• 业务方案确认

对未通过测试用、流量回放差异，研发测试分别列出清单，研发、测试、产品组会进行沟通，对系统现状和业务影响范围进行评审，确定最终处理方案。

测试中发现的问题验证修复后，确认达到业务要求和上线标准，才可以灰度上线。

上线后

灰度发布时，只接入一小部分流量，并及时跟踪和分析线上的 log 与监控告警，并关注用户反馈一有问题及时解决。当新系统趋于稳定时，逐渐加大灰度发布的范围和接入的流量，同时继续跟踪线上 log 与监控告警。

• 白名单验证

上线后用白名单用户进行验证。

• 流量切换控制

系统上线后，支持用户PIN的百分比进行切量，灰度验证实现平稳过渡。

• 组件切换开关

新老逻辑组件可以一键切换，如发现问题可快速切回原逻辑，快速止损，保证线上系统安全；

五、项目价值

系统优化

• 按项目预期实现了全新纯净的时效内核计算接口，内核系统具有更高的复用性；
• 组件化系统中重新组织部分逻辑，增加上浮的业务逻辑。系统逻辑更聚合，提升易读性、减小了系统维护成本；
• 降低上线风险，重塑业务边界后，交互系统逻辑更集中，减少了相互依赖配置，更利于把控风险；
• 重构修复测试用例和引流验证时，发现并修复多个线上BUG，保障并提高了系统的稳定性；
• 测试用例发现5个BUG，修复遗漏边缘业务逻辑和处理逻辑错误等问题；
• 流量回放中发现7个BUG，修复530标位、京准达时效类型等线上bug；
• 修正40+个测试用例；

遇到的困难

系统重构总能留下比较深刻的印象，不仅会碰到技术的挑战，需要思考用什么方案更合理；也会碰到难以理清的业务逻辑，需要将产品、研发、测试摇到一起追思忆往；还会发现历史的“bug”，让人纠结要不要“更正”；都很耗费发量。

1、流量回放阶段，由于出参数据填充方式变化，导致无法比较，通过自定义脚本的方式解决。

2、自提时效多仓场景新架构无法支持，协同产品、业务优化原有多仓场景的处理方式，既解决问题又优化了线上处理逻辑。

项目总结

重构有利于项目的健壮和精简，平时要养成重构的好习惯，“小步快走”，尽量避免留着统一重构的思想，积累很多技术债后重构精力、时间成本很大，风险也会大很多。如果重构任务艰巨，需要提前做好迭代计划，重构方案设计之初就要考虑如何分阶段实施，小步快走层层分离的策略就相当于搭建施工现场的脚手架，是一种把风险控制在可接受范围的有效手段。更多关注“明天价值”，当发现好的数据结构、好的思想的时候，甚至一个变量名或方法名，把以前写的代码重写一下；

何时进行重构最好遵循“三次法则”，如果一件事需要做一两次，可以不着急重构；但是如果需要重复三次甚至以上的话，就该考虑着手去重构了，保持系统的健康状态。

公司业务在快速发展中，系统重构期间，需继续保持业务需求的迭代速度，可以适当增加人员。

系统重构前需要对业务足够熟悉（包括边缘业务），重构时可能会遇到看着重构代码一样，实际代码的执行顺序影响业务的前后依赖或优先级，最后影响结果的输出，在复杂的业务处理流程中很难发现问题。

上线后跟踪系统运行实际性能变动、资源消耗、稳定性。重构中发现了系统中存在相似的业务处理逻辑、城配相关的逻辑过于复杂等问题，下一步与产品业务沟通是否可以进行精简，重构不是终点，更像是起点。