写点什么

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

  • 2022 年 3 月 14 日
  • 本文字数:2690 字

    阅读完需:约 9 分钟

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


作者:吴欣蔚(蓄昂)


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 转化率。



问题与挑战

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


  • 用户体验的冲突:个性化推荐算法服务 RT 高,不满足核心交易链路对 RT 的要求;

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

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


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

技术选型

1、RPC 模式分析

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


2、请求处理模型分析

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


  • 串行处理:数据的依赖深度决定了整体可优化的最小 rt;

  • 并行处理:通过并行化(并发度 n),来将对应层次上的 rt 降低为原来的 max(RTn)。


3、NextRPC 的多段返回模式

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


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


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


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


  • 并行处理:


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


NextRPC 架构

1、客户端架构

技术架构

  • 网络层,抹平 Mtop/Accs 通道,对业务透明;

  • 数据整流层,控制 单个请求多个返回的时序(其中异步副返回包含了异步的业务数据流);

  • 数据编排层,控制 多请求间 异步数据的合并。


数据流和多实例

  • 一个页面支持多个 NextRPC 实例,多页面可创建多个 NextRPC 实例;

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


2、服务端架构

技术架构

请求过程详解

  1. 客户端发起主请求;

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

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

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

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

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

异常情况处理

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


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


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


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


  1. 消息过期、重复如何处理?


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


消息过期:SDK 内部可


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

3、技术指标

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


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

  • 副请求成功率:副请求从发起到被处理成功的比例,用于衡量副请求的服务质量;

  • 副响应到达率:在主请求成功的基础之上,从副请求的发起、接收、处理,再到端上设备成功接收到副响应,是 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


关注【阿里巴巴移动技术】微信公众号,每周 3 篇移动技术实践 &干货给你思考!

发布于: 刚刚阅读数: 2
用户头像

还未添加个人签名 2018.07.07 加入

阿里巴巴移动&终端技术官方账号。

评论

发布
暂无评论
NextRPC : RPC多段返回的创新和探索_RPC_阿里巴巴移动技术_InfoQ写作平台