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 累加累加总数，主响应结束时，同时下发副请求总个数。

2 . 副请求处理，不同业务吞吐量不一样，多个业务之间如何隔离确保互不影响？ 业务之间通过消息中间件的不同 Topic 或者 不同的 Tag 进行隔离，每个 Topic 或 Tag 使用单独线程池消费。

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

消息过期：SDK 内部可

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

▐ 技术指标

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

1. 主请求成功率：主请求被成功处理的比例。主请求的成功与否，决定着后续的流程能否继续进行，也是衡量NextRPC服务质量的最基本指标；
2. 副请求成功率：副请求从发起到被处理成功的比例，用于衡量副请求的服务质量；
3. 副响应到达率：在主请求成功的基础之上，从副请求的发起、接收、处理，再到端上设备成功接收到副响应，是NextRPC多响应服务质量的核心衡量指标。配合上请求的超时配置，还可以进一步衡量 1s、3s、5s 到达率。

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

总结与展望

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

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

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