一、项目背景
为什么需要架构升级
- 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；
遇到的困难
系统重构总能留下比较深刻的印象，不仅会碰到技术的挑战，需要思考用什么方案更合理；也会碰到难以理清的业务逻辑，需要将产品、研发、测试摇到一起追思忆往；还会发现历史的“bug”，让人纠结要不要“更正”；都很耗费发量。
1、流量回放阶段，由于出参数据填充方式变化，导致无法比较，通过自定义脚本的方式解决。
2、自提时效多仓场景新架构无法支持，协同产品、业务优化原有多仓场景的处理方式，既解决问题又优化了线上处理逻辑。
项目总结
重构有利于项目的健壮和精简，平时要养成重构的好习惯，“小步快走”，尽量避免留着统一重构的思想，积累很多技术债后重构精力、时间成本很大，风险也会大很多。如果重构任务艰巨，需要提前做好迭代计划，重构方案设计之初就要考虑如何分阶段实施，小步快走层层分离的策略就相当于搭建施工现场的脚手架，是一种把风险控制在可接受范围的有效手段。更多关注“明天价值”，当发现好的数据结构、好的思想的时候，甚至一个变量名或方法名，把以前写的代码重写一下；
何时进行重构最好遵循“三次法则”，如果一件事需要做一两次，可以不着急重构；但是如果需要重复三次甚至以上的话，就该考虑着手去重构了，保持系统的健康状态。
公司业务在快速发展中，系统重构期间，需继续保持业务需求的迭代速度，可以适当增加人员。
系统重构前需要对业务足够熟悉（包括边缘业务），重构时可能会遇到看着重构代码一样，实际代码的执行顺序影响业务的前后依赖或优先级，最后影响结果的输出，在复杂的业务处理流程中很难发现问题。
上线后跟踪系统运行实际性能变动、资源消耗、稳定性。重构中发现了系统中存在相似的业务处理逻辑、城配相关的逻辑过于复杂等问题，下一步与产品业务沟通是否可以进行精简，重构不是终点，更像是起点。
作者：京东物流 崔海君
来源：京东云开发者社区 自猿其说 Tech 转载请注明来源
