1、背景
1）新业务：随着业务形态的丰富，购物车在不断支持各种新业务，依赖的外部接口也随之增加；
3）前置：结算流程很多业务前置到购物车中，如优惠券、京豆；
这些导致购物车依赖的RPC接口数量及分页调用次数都在不断增加。购物车作为交易流程开端，本身流量较大，在业务复杂化的背景下，如何提高性能保证用户体验，成为购物车面临的较大挑战。
2、全异步化改造方案
1）不同RPC并行
购物车依赖接口多为批量接口，且单次调用有数据量限制，需将数据拆分为多个分页调用。那么多个分页间也可以并行，改造中封装了异步分页工具，使业务层对分页逻辑无感知，异步工具自动将超过接口上限的数据拆分为多个分页并行调用，提升单接口响应速度。
异步调用基于京东RPC框架JSF，推荐使用1.7.5以后版本，支持CompletableFuture。
3、问题及解决
1）异常重试需精细化
另外，多分页并行时，当某一页请求超时后，应该只重试出错的分页。底层对分页调用进行了封装，上层业务代码在获取数据时无法感知是哪一页超时，所以必须在异步调用时将现场信息保存在包装类中，一起返回给业务层，在Get数据超时后，单独重试出错的分页。
2）异步RPC监控更复杂
除了需要监控RPC耗时外，还需要监控结果处理阶段Get等待时长，这个时间才是真正对应用性能有影响的时间。由于底层是分页调用，所以业务调用次数和底层RPC调用次数并不相同。
底层异步调用结果，必须通过包装类原样返回给上层，除了上边提到的需要单分页重试外，另一个原因是必须保留异步结果，在分页超时后才能输出超时的Provider信息。这是由于Provider信息依赖JSF框架的JSFCompletableFuture，如果在底层合并结果，会导致信息丢失。
超时=RPC超时时间 > (当前时间-异步调用开始时间) ? RPC超时时间 – (当前时间-异步调用开始时间) : 0
为避免最后一页数据过少造成数据倾斜，需要将请求数据均分到每一页，以最大限度提高整个请求的性能。
4、收益
内容来源：京东云开发者社区