promise时效架构升级方案的实施及落地 | 京东物流技术团队

一、项目背景

为什么需要架构升级

  • 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、自提时效多仓场景新架构无法支持,协同产品、业务优化原有多仓场景的处理方式,既解决问题又优化了线上处理逻辑。

项目总结

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

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

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

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

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

作者:京东物流 崔海君

来源:京东云开发者社区 自猿其说 Tech 转载请注明来源

相关推荐
javaDocker15 小时前
业务架构、数据架构、应用架构和技术架构
架构
JosieBook17 小时前
【架构】主流企业架构Zachman、ToGAF、FEA、DoDAF介绍
架构
.生产的驴18 小时前
SpringCloud OpenFeign用户转发在请求头中添加用户信息 微服务内部调用
spring boot·后端·spring·spring cloud·微服务·架构
丁总学Java18 小时前
ARM 架构(Advanced RISC Machine)精简指令集计算机(Reduced Instruction Set Computer)
arm开发·架构
ZOMI酱20 小时前
【AI系统】GPU 架构与 CUDA 关系
人工智能·架构
天天扭码1 天前
五天SpringCloud计划——DAY2之单体架构和微服务架构的选择和转换原则
java·spring cloud·微服务·架构
余生H1 天前
transformer.js(三):底层架构及性能优化指南
javascript·深度学习·架构·transformer