一种复杂业务场景的解决方案（代码结构）

背景

我个人负责交易线的一些服务优化工作，如购物车、预购单等，这些服务是前台服务，需要基于很多中台服务能力来实现业务功能，中台服务如商品中心、协议中心、用户中心、营销活动等，前台服务通过RPC调用中台服务获取数据。

在2020年度的优化工作汇报中，我统计了一组数据，有50%的接口是因为重复或者循环RPC导致的慢接口，其中重复RPC非常常见，鉴于此问题以及基于我们的优化方式，最终提出了一套适用的解决方案。

解决方案

优点

• 有效规避重复PRC，所有数据都在context中，读写方便
• 有效规避事务中RPC，加事务注解的方法如果需要某个RPC的数据，只需从context中取，否则容易造成事务中RPC，或者需要调整代码结构
• 结构清晰，业务逻辑大致可分为五个模块，每个模块功能独立且统一
• 业务扩展性好，如业务需求新增一项校验，依赖了商品数据，从context中取非常方便；否然为了规避重复查询，需要大改结构
• 便于并行查询，如遇到多个耗时RPC，可以快速选择并行查询，提高整体查询速度
• 便于做耗时统计，耗时通常发生在RPC和DB，统一的模块便于开发快速定位耗时点

最后

该方法并非适用于所有场景，比如我们的PRC B依赖RPC A的业务处理结果，这个时候需要做一些判断，比如RPC B的代价是否很大，如果不大，直接查询是OK的；但如果RPC B代价很大且多半经过业务处理后，RPC B只在极少数场景下才会需要执行，这时我们就会选择将RPC B放到具体的业务处理中，而不是context中。

最后再把我全年的优化感悟贴在下方

关注我们的接口性能，不要循环RPC、不要重复RPC、不要复杂SQL，写简洁干净的代码