NextRPC : RPC多段返回的创新和探索

相比普通格式图片，纹理压缩可以节省大量显存和 CPU 解码时间，且对 GPU 友好。目前，NextRPC 已经在淘宝的部分交易场景上线，经历几次大促，业务模式稳定。

NextRPC 是对 RPC 请求模式的创新和探索，它可以像多级火箭一样，返回 Payload 多段数据，从不同的网络通道请求/应答多段返回，最终完成业务场景交付。里面的“Next”有双关的意思：

1. 核心的区别于传统 RPC，请求的特点是让请求响应以流式多段返回给客户端，在流式的语义里面数据不停地通过 Next -> Next -> Next 的模式来响应；

2. Next 有下一代的意思，NextRPC 是传统单响应的下一代 RPC 模式。

目前，NextRPC 已经在淘宝的部分交易场景上线，如：下单换购业务在2021年4月初上线，经历9.9、11.11两次大促，业务模式已经稳定。在2021年的双十一大促中，通过 NextRPC 链路给业务整体带来超过5%的 uv 转化提升，在多商品中选择一个最优商品透出的场景下，uv 转化提升达25%以上。

业务背景

在一些交易核心链路如 购物车、订单 等场景，期望引入导购链路的推荐算法，基于店铺维度针对单品、多品SKU、跨店场景进行个性化推荐，推出如“顺手买一件”的个性化推荐产品或其他优惠信息的透出，提升uv转化率。 

 

问题与挑战

当 核心交易场景 遇上 个性化推荐 ，交易 和 导购 的场景碰撞，会产生以下新的问题：

1. 用户体验的冲突：个性化推荐算法服务RT高，不满足核心交易链路对RT的要求；

2. 服务质量的冲突：引入个性化推荐，会使得交易链路的下游系统变得更加复杂，对系统的稳定性带来新的挑战；同时，导购链路的「个性化推荐业务」容忍部分不确定性（如请求超时/失败），而「核心交易链路」则对稳定性和确定性要求极高，每一次的失败可能都会错失交易；

3. 机器资源的冲突：交易、导购 的多地部署结构不一样，机器容量和分布存在差异化。

上述的这些问题，引出了新的技术挑战：如何在一次请求中同时支持对「用户体验」、「服务质量」、「资源」要求不一样的多个业务支撑系统。

技术选型

▐  RPC模式分享

以下针对五种常见的RPC模型展开对比分析：

▐  请求处理模型分析

请求处理模型主要分析 串行处理、并行处理两种模型。

1. 串行处理：数据的依赖深度决定了整体可优化的最小rt；

2. 并行处理：通过并行化（并发度n），来将对应层次上的rt降低为原来的 max(RTn)。

▐  NextRPC的多段返回模式

NextRPC结合了 单请求异步推送数据流 的RPC模式和 并行处理 的请求处理模型，解决了新的业务场景带来的挑战：

• 单请求异步推送数据流：

  • 可以将 核心业务逻辑 和 非核心业务逻辑 解耦，保证核心数据同步响应，非核心数据异步响应，解决服务质量问题；

  • 交易链路、导购链路逻辑解耦，内部跨应用调用，解决机器资源问题；

• 并行处理：

  • 业务逻辑可并行化处理，节省串行等待时间，解决交易链路用户体验问题

NextRPC架构

▐  客户端架构

• 技术架构

1. 网络层，抹平Mtop/Accs通道，对业务透明；

2. 数据整流层，控制 单个请求多个返回的时序（其中异步副返回包含了异步的业务数据流）；

3. 数据编排层，控制 多请求间 异步数据的合并。

• 数据流和多实力

1. 一个页面支持多个 NextRPC 实例，多页面可创建多个 NextRPC 实例；

2. 一个 NextRPC 实例可进行多个不同请求，接收不同的副响应推送。

▐  服务端架构

• 技术架构

• 请求过程详解

1. 客户端发起主请求；

2. 服务端接收到客户端主请求，执行业务逻辑的同时，通过消息中间件发送副请求信息（注：AttachedRequestEmitter 通过消息中间件，将非核心依赖解耦出去），所有业务逻辑执行完成后，副请求也都发送完成；

3. 返回客户端主响应，主响应包含副请求元信息；

4. 副请求接收端通过消息中间件消费副请求消息，并调用业务处理器AttachedRequestProcessor，业务处理完成后，返回nextrpc-sdk副请求处理结果；

副响应通过消息推送通道下发给客户端

客户端监听指定的消息推送通道，收到副响应数据后，渲染上屏。

• 异常情况处理

1. 副请求编排，一个主请求多个副响应的场景下，客户端如何知道总共有多少个副请求？

由于服务端业务调用 NextRPC SDK 发送副请求，SDK 是知道自己被调用了多少次的，所以这个信息由 SDK 来统计并存储，SDK 内部维护一个副请求元信息，包括总数、副请求业务信息，业务每调用一次 SDK 发送副请求，SDK 累加累加总数，主响应结束时，同时下发副请求总个数。

副请求处理，不同业务吞吐量不一样，多个业务之间如何隔离确保互不影响？

业务之间通过消息中间件的不同 Topic 或者 不同的 Tag 进行隔离，每个 Topic 或 Tag 使用单独线程池消费。

消息过期、重复如何处理？

副请求通过消息中间件发送，当副请求接收端收到消息时，消息存在过期、重复的情况，SDK 提供消息的元信息（包括时间戳、唯一标识）

消息过期：SDK 内部可

消息重复：需要由业务代码根据请求的唯一标识来实现幂等。

▐  技术指标

NextRPC作为一种单请求多响应的RPC模式，按请求阶段划分，衡量服务质量的技术指标可以分为 3 种：

1. 主请求成功率：主请求被成功处理的比例。主请求的成功与否，决定着后续的流程能否继续进行，也是衡量NextRPC服务质量的最基本指标；

2. 副请求成功率：副请求从发起到被处理成功的比例，用于衡量副请求的服务质量；

3. 副响应到达率：在主请求成功的基础之上，从副请求的发起、接收、处理，再到端上设备成功接收到副响应，是NextRPC多响应服务质量的核心衡量指标。配合上请求的超时配置，还可以进一步衡量 1s、3s、5s 到达率。

不同的请求阶段会有不同的技术指标，可以用于客户端、服务端服务质量分析，各个阶段产出的指标如下图所示：

总结与展望

双11是阿里巴巴的超级工程，2021年是双11的第十三个年头，立足过去12年的技术与商业创新，是一个新轮回的开始。 

我们从追求更高到追求更好，技术也在探索这个过程，围绕消费体验不降级这个目标，我们在核心交易链路上做出大胆的技术尝试，追求交易确定性和体验的同时，提供更好、更有质量的服务满足消费者，并且可以赋能商家提升运营能力。

后续，我们也将继续尝试落地更多业务场景，借助NextRPC为业务的创新助力！

团队介绍

欢迎加入淘宝移动技术中台，团队成员大牛云集，有阿里移动中间件的创始人员、鹰眼全链路追踪平台核心成员、更有一群热爱技术，期望用技术推动业务的小伙伴。

淘宝移动技术中台，推进淘系（淘宝、天猫等）架构升级，致力于为淘系、整个集团提供基础核心能力、产品与解决方案：

1. 业务高可用的解决方案与核心能力（应用高可用：为业务提供自适应限流、隔离与熔断的柔性高可用解决方案，站点高可用：故障自愈、多机房与异地容灾与快速切流恢复）；

2. 新一代的业务研发模式FaaS（一站式函数研发Gaia平台）；

3. 下一代网络协议QUIC实现与落地；

4. 移动中间件（API网关MTop、域名调度AMDC、消息/推送、文件上传AUS、移动配置推送Orange 等等）。

期待一起参与加入淘系基础平台的建设~简历投至方式 ：zebin.xuzb@alibaba-inc.com

✿  拓展阅读

作者|蓄昂

编辑|橙子君

出品|阿里巴巴新零售淘系技术