定服装网站建设,网页制作动态模板,重庆美邦 网站建设,微商怎么做_和淘宝网站一样吗?一、项目背景
为什么需要架构升级
promise时效包含两个子系统#xff1a;内核时效计算系统#xff08;系统核心是时效计算#xff09;和组件化时效系统#xff08;系统核心是复杂业务处理以及多种时效业务聚合#xff0c;承接结算下单黄金流程流量#xff09;#xff…一、项目背景
为什么需要架构升级
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 转载请注明来源
