1 重构背景
原有的开发人员早已离职,代码细节没人知道,经过了一段时间的维护,发现有以下问题:

个人中心系统的特征就是组装各个业务的接口,输出个人中心业务需要的数据,整个系统调用了几十个第三方业务线的接口,如果编排不合理,可能会导致响应时间急剧上涨,尤其是弹窗业务,新的弹窗会不断接入,整个接口可能会不可用。
2 整体架构

service:是最小的业务编排单元,request方法对infrastructure第三方接口进行编排调用;apply 方法对第三方接口调用的结果进行组装,结果是service的业务返回;
infrastructure:是对第三方的异步非阻塞调用,不包含业务逻辑。一个service内部根据实际业务可以编排0个或者多个infrastructure服务。
在实际优化过程中我们抽象了30多个infrastructure第三方调用,40多个service。他们都是小而且独立的类,减轻了开发同学尤其是新同学熟悉的成本。边界也比较清晰,逻辑内聚。
2 编排举例
每个 service 内部都是由一个或者多个 infrastructure 第三方调用组装编排的业务单元,内部处理能异步处理的全是使用异步处理,实在不能异步处理的使用串行+并行的方式。
2.1 串行
需要串行的可以使用 flatMap 方法,可以参考以下格式。
这种方式会执行S1,然后S2。

伪代码如下:
Mono.from(service1.func())
.flatMap(service1Res-> {
return service2.func();
})
2.2 并行
zip 和 zipWith,zipWith一次组装一个Mono,zip

文章讲述了在原有个人中心系统中,由于代码复杂性和接口调用问题导致响应时间增长。通过重构,将系统拆分为小而独立的service和infrastructure服务,利用异步处理和并行调用来优化性能。特别是使用flatMapSequential解决了弹窗业务的优先级和耗时问题,显著提高了接口响应速度,简化了新需求的开发和维护流程,同时利用SpringWebFlux响应式框架提升了开发效率。
最低0.47元/天 解锁文章
1354






