promise时效架构升级方案的实施及落地

promise时效架构升级方案的实施及落地
重构有利于项目的健壮和精简,平时要养成重构的好习惯,“小步快走”,尽量避免留着统一重构的思想,积累很多技术债后重构精力、时间成本很大,风险也会大很多

一、项目背景

为什么需要架构升级

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

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

重构目标

业务边界更清晰

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

业务逻辑更聚合

组件化中整合业务逻辑;

内核计算逻辑更纯净

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

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

二、方案设计

内核计算业务梳理

现有业务接口:

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

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

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

promise时效架构升级方案的实施及落地

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

主要变更点:

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

promise时效架构升级方案的实施及落地

系统重构业务

三、项目实施

组件化业务梳理

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

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

promise时效架构升级方案的实施及落地

四、稳定性保障

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

上线前

  • 单测场景覆盖

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

  • 流量回放验证

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

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

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

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

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

  • 业务方案确认

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

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

上线后

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

  • 白名单验证

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

  • 流量切换控制

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

  • 组件切换开关

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

五、项目价值

系统优化

  • 按项目预期实现了全新纯净的时效内核计算接口,内核系统具有更高的复用性;
  • 组件化系统中重新组织部分逻辑,增加上浮的业务逻辑。系统逻辑更聚合,提升易读性、减小了系统维护成本;
  • 降低上线风险,重塑业务边界后,交互系统逻辑更集中,减少了相互依赖配置,更利于把控风险;
  • 重构修复测试用例和引流验证时,发现并修复多个线上BUG,保障并提高了系统的稳定性;

◦ 测试用例发现5个BUG,修复遗漏边缘业务逻辑和处理逻辑错误等问题;

◦ 流量回放中发现7个BUG,修复530标位、京准达时效类型等线上bug;

  • 修正40+个测试用例;

遇到的困难

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

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

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

项目总结

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

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

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

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

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

作者:物流 崔海君

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

给TA打赏
共{{data.count}}人
人已打赏
运维笔记

又该换Linux版本了!

2023-10-10 18:35:29

软件设计

设计模式—结构型模式之代理模式

2023-11-18 14:24:31

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索