![]()
作者：吴欣蔚(蓄昂)
NextRPC 是对 RPC 请求模式的创新和探索，它可以像多级火箭一样，返回 Payload 多段数据，从不同的网络通道请求/应答多段返回，最终完成业务场景交付。里面的“Next”有双关的意思：
- 核心的区别于传统 RPC，请求的特点是让请求响应以流式多段返回给客户端，在流式的语义里面数据不停地通过 Next -> Next -> Next 的模式来响应；
- Next 有下一代的意思，NextRPC 是传统单响应的下一代 RPC 模式。
目前，NextRPC 已经在手淘的部分交易场景上线，如：下单换购业务在2021年4月初上线，经历9.9、11.11两次大促，业务模式已经稳定。在2021年的双十一大促中，通过 NextRPC 链路给业务整体带来超过5%的 uv 转化提升，在多商品中选择一个最优商品透出的场景下，uv 转化提升达25%以上。
业务背景
在一些交易核心链路如 购物车、订单 等场景，期望引入导购链路的推荐算法，基于店铺维度针对单品、多品SKU、跨店场景进行个性化推荐，推出如“顺手买一件”的个性化推荐产品 或 其他优惠信息的透出，提升uv转化率。
![]()
![]()
问题与挑战
当 核心交易场景 遇上 个性化推荐 ，交易 和 导购 的场景碰撞，会产生以下新的问题：
- 用户体验的冲突：个性化推荐算法服务RT高，不满足核心交易链路对RT的要求；
- 服务质量的冲突：引入个性化推荐，会使得交易链路的下游系统变得更加复杂，对系统的稳定性带来新的挑战；同时，导购链路的「个性化推荐业务」容忍部分不确定性（如请求超时/失败），而「核心交易链路」则对稳定性和确定性要求极高，每一次的失败可能都会错失交易；
- 机器资源的冲突：交易、导购 的多地部署结构不一样，机器容量和分布存在差异化。
上述的这些问题，引出了新的技术挑战：如何在一次请求中同时支持对「用户体验」、「服务质量」、「资源」要求不一样的多个业务支撑系统。
技术选型
1、RPC模式分析
以下针对五种常见的RPC模型展开对比分析：
![]()
2、请求处理模型分析
请求处理模型主要分析 串行处理、并行处理两种模型。
- 串行处理：数据的依赖深度决定了整体可优化的最小rt；
- 并行处理：通过并行化（并发度n），来将对应层次上的rt降低为原来的 max(RTn)。
![]()
3、NextRPC的多段返回模式
NextRPC结合了 单请求异步推送数据流 的RPC模式和 并行处理 的请求处理模型，解决了新的业务场景带来的挑战：
-可以将 核心业务逻辑 和 非核心业务逻辑 解耦，保证核心数据同步响应，非核心数据异步响应，解决服务质量问题；
-交易链路、导购链路逻辑解耦，内部跨应用调用，解决机器资源问题；
-业务逻辑可并行化处理，节省串行等待时间，解决交易链路用户体验问题。
![]()
NextRPC架构
1、客户端架构
技术架构
- 网络层，抹平Mtop/Accs通道，对业务透明；
- 数据整流层，控制 单个请求多个返回的时序（其中异步副返回包含了异步的业务数据流）；
- 数据编排层，控制 多请求间 异步数据的合并。
![]()
数据流和多实例
- 一个页面支持多个 NextRPC 实例，多页面可创建多个 NextRPC 实例；
- 一个 NextRPC 实例可进行多个不同请求，接收不同的副响应推送。
![]()
2、服务端架构
技术架构
![]()
请求过程详解
- 客户端发起主请求；
- 服务端接收到客户端主请求，执行业务逻辑的同时，通过消息中间件发送副请求信息（注：AttachedRequestEmitter 通过消息中间件，将非核心依赖解耦出去），所有业务逻辑执行完成后，副请求也都发送完成；
- 返回客户端主响应，主响应包含副请求元信息；
- 副请求接收端通过消息中间件消费副请求消息，并调用业务处理器AttachedRequestProcessor，业务处理完成后，返回nextrpc-sdk副请求处理结果；
- 副响应通过消息推送通道下发给客户端
- 客户端监听指定的消息推送通道，收到副响应数据后，渲染上屏。
异常情况处理
- 副请求编排，一个主请求多个副响应的场景下，客户端如何知道总共有多少个副请求？
由于服务端业务调用 NextRPC SDK 发送副请求，SDK 是知道自己被调用了多少次的，所以这个信息由 SDK 来统计并存储，SDK 内部维护一个副请求元信息，包括总数、副请求业务信息，业务每调用一次 SDK 发送副请求，SDK 累加累加总数，主响应结束时，同时下发副请求总个数。
- 副请求处理，不同业务吞吐量不一样，多个业务之间如何隔离确保互不影响？
业务之间通过消息中间件的不同 Topic 或者 不同的 Tag 进行隔离，每个 Topic 或 Tag 使用单独线程池消费。
- 消息过期、重复如何处理？
副请求通过消息中间件发送，当副请求接收端收到消息时，消息存在过期、重复的情况，SDK 提供消息的元信息（包括时间戳、唯一标识）
消息过期：SDK 内部可
消息重复：需要由业务代码根据请求的唯一标识来实现幂等。
3、技术指标
NextRPC作为一种单请求多响应的RPC模式，按请求阶段划分，衡量服务质量的技术指标可以分为 3 种：
- 主请求成功率：主请求被成功处理的比例。主请求的成功与否，决定着后续的流程能否继续进行，也是衡量NextRPC服务质量的最基本指标；
- 副请求成功率：副请求从发起到被处理成功的比例，用于衡量副请求的服务质量；
- 副响应到达率：在主请求成功的基础之上，从副请求的发起、接收、处理，再到端上设备成功接收到副响应，是NextRPC多响应服务质量的核心衡量指标。配合上请求的超时配置，还可以进一步衡量 1s、3s、5s 到达率。
不同的请求阶段会有不同的技术指标，可以用于客户端、服务端服务质量分析，各个阶段产出的指标如下图所示：
![]()
总结与展望
双11是阿里巴巴的超级工程，2021年是双11的第十三个年头，立足过去12年的技术与商业创新，是一个新轮回的开始。
我们从追求更高到追求更好，技术也在探索这个过程，围绕消费体验不降级这个目标，我们在核心交易链路上做出大胆的技术尝试，追求交易确定性和体验的同时，提供更好、更有质量的服务满足消费者，并且可以赋能商家提升运营能力。
后续，我们也将继续尝试落地更多业务场景，借助NextRPC为业务的创新助力！
我们招聘啦！
欢迎加入淘宝移动技术中台，团队成员大牛云集，有阿里移动中间件的创始人员、鹰眼全链路追踪平台核心成员、更有一群热爱技术，期望用技术推动业务的小伙伴。
淘宝移动技术中台，推进淘系（淘宝、天猫等）架构升级，致力于为淘系、整个集团提供基础核心能力、产品与解决方案：
- 业务高可用的解决方案与核心能力（应用高可用：为业务提供自适应限流、隔离与熔断的柔性高可用解决方案，站点高可用：故障自愈、多机房与异地容灾与快速切流恢复）；
- 新一代的业务研发模式FaaS（一站式函数研发Gaia平台）；
- 下一代网络协议QUIC实现与落地；
- 移动中间件（API网关MTop、域名调度AMDC、消息/推送、文件上传AUS、移动配置推送Orange 等等）。
期待一起参与加入淘系基础平台的建设~
简历投至方式 ：zebin.xuzb@alibaba-inc.com
关注【阿里巴巴移动技术】微信公众号，每周 3 篇移动技术实践&干货给你思考！
