京东购物车如何提升30%性能
![]()
Tech 导读
本文主要介绍在业务复杂化背景下，京东零售购物车团队努力践行工匠精神，通过全异步化改造提升系统性能、提升用户体验。通过本文，读者可以了解购物车中台进行全异步化改造的总体方案，以及方案落地过程中遇到的问题及解决方法，读者可重点关注文中提到的多分页并行后，分页精细控制及底层RPC异常信息问题。
导读
本文主要介绍在业务复杂化背景下，京东零售购物车团队努力践行工匠精神，通过全异步化改造提升系统性能、提升用户体验。通过本文，读者可以了解购物车中台进行全异步化改造的总体方案，以及方案落地过程中遇到的问题及解决方法，读者可重点关注文中提到的多分页并行后，分页精细控制及底层RPC异常信息问题。
购物车面临的挑战：
通过增加服务器资源虽然能在一定程度上解决问题，但会带来较大的成本开销，也与工匠精神相悖。能否通过技术手段提升性能呢？通过分析，异步化改造成为解决这一问题的有效手段。
1）不同RPC并行
购物车依赖接口达几十个，各接口间存在复杂依赖关系。必须先梳理各接口间依赖，识别哪些可以并行。然后将原有代码拆分为两部分：RPC异步请求和结果处理，按照依赖关系，让RPC最大限度并行执行，减少在结果处理阶段异步响应等待时间，从而达到提升性能的目的。
2）批量接口多分页并行
异步化改造的总体方案并不复杂，但是在实际落地过程中，遇到了很多细节问题：
1）异常重试需精细化
同步调用时，如果超时会重试调用。改为异步后重试会失效，因为在调用时一般不会报错，需要在结果处理阶段获取异步响应超时后，再进行重试。
另外，多分页并行时，当某一页请求超时后，应该只重试出错的分页。底层对分页调用进行了封装，上层业务代码在获取数据时无法感知是哪一页超时，所以必须在异步调用时将现场信息保存在包装类中，一起返回给业务层，在Get数据超时后，单独重试出错的分页。
发生异常时，并不是所有情况都需要重试，当遇到限流等异常时，不能进行重试。底层工具需要自动过滤限流异常，当然也支持自定义规则。
2）异步RPC监控更复杂
底层RPC耗时监控需要拆分为两部分，在分页调用时记为开始时间，在异步结果到达后，记为结束时间。如果调用异常或Get超时，需要标记本次调用失败。对于重试同样需要记录调用耗时，且正常调用与重试调用需分开记录。
除了需要监控RPC耗时外，还需要监控结果处理阶段Get等待时长，这个时间才是真正对应用性能有影响的时间。由于底层是分页调用，所以业务调用次数和底层RPC调用次数并不相同。
3）分页异步结果不能合并，否则无法获取异常Provider信息
底层异步调用结果，必须通过包装类原样返回给上层，除了上边提到的需要单分页重试外，另一个原因是必须保留异步结果，在分页超时后才能输出超时的Provider信息。这是由于Provider信息依赖JSF框架的JSFCompletableFuture，如果在底层合并结果，会导致信息丢失。
4）每页超时时间需单独控制
分页调用过程如上图所示，在结果处理时，每页Get超时时间需要单独控制，因为获取结果是顺序进行，获取后边的分页时，前边分页等待的时间也应计算在内，以保证整个获取结果的时间不超过单个分页的最大超时时间。计算公式如下：
超时=RPC超时时间 > (当前时间-异步调用开始时间) ? RPC超时时间 – (当前时间-异步调用开始时间) : 0
5）分页均衡
求分享
求点赞
求在看