一、项目背景
为什么需要架构升级
- promise时效包含两个子系统:内核时效计算系统(系统核心是时效计算)和组件化时效系统(系统核心是复杂业务处理以及多种时效业务聚合,承接结算下单黄金流程流量),后者依赖前者,分别由两组技术团队支持;因为有些业务的渗透造成两个系统的边界越来越不清晰;有些需求从PRD评审到项目上线,需要两组研发全程参与,耗费大量人力;
- promise时效计算业务逻辑经过多年的沉淀越来越复杂,时效计算系统中有很多业务逻辑,导致计算内核也需要跟随需求频繁更新;
- 时效计算分为预约和非预约,下单前和下单后,结算页时效和商详页时效。有共性也存在差异,导致共用一部分内核计算的同时存在大量冗余重复代码,需要同时维护和存储两份时效计算的缓存数据。
- 多种业务从内核系统中提供专用接口,导致系统严重腐化。
- 存在部分未采用RPC方式的依赖,导致jar包依赖和时效计算的切量开关需要配置在组件化时效系统中,影响开发和联调效率。
综上,决定这次技术驱动的重构,需要架构升级解决系统中存在的问题。
重构目标
业务边界更清晰
重构之后的需求边界从产品侧就能够确定,如果新增仓配时效计算规则需要修改或新增内核计算,其他业务的需求基本组件化时效中修改即可;
业务逻辑更聚合
组件化中整合业务逻辑;
内核计算逻辑更纯净