相比普通格式图片,纹理压缩可以节省大量显存和 CPU 解码时间,且对 GPU 友好。目前,NextRPC 已经在淘宝的部分交易场景上线,经历几次大促,业务模式稳定。
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的要求;
服务质量的冲突:引入个性化推荐,会使得交易链路的下游系统变得更加复杂,对系统的稳定性带来新的挑战;同时,导购链路的「个性化推荐业务」容忍部分不确定性(如请求超时/失败),而「核心交易链路」则对稳定性和确定性要求极高,每一次的失败可能都会错失交易;
机器资源的冲突:交易、导购 的多地部署结构不一样,机器容量和分布存在差异化。
上述的这些问题,引出了新的技术挑战:如何在一次请求中同时支持对「用户体验」、「服务质量」、「资源」要求不一样的多个业务支撑系统。
技术选型
▐ RPC模式分享
以下针对五种常见的RPC模型展开对比分析:
▐ 请求处理模型分析
请求处理模型主要分析 串行处理、并行处理两种模型。
串行处理:数据的依赖深度决定了整体可优化的最小rt;
并行处理:通过并行化(并发度n),来将对应层次上的rt降低为原来的 max(RTn)。
▐ NextRPC的多段返回模式
NextRPC结合了 单请求异步推送数据流 的RPC模式和 并行处理 的请求处理模型,解决了新的业务场景带来的挑战:
单请求异步推送数据流:
可以将 核心业务逻辑 和 非核心业务逻辑 解耦,保证核心数据同步响应,非核心数据异步响应,解决服务质量问题;
交易链路、导购链路逻辑解耦,内部跨应用调用,解决机器资源问题;
并行处理:
业务逻辑可并行化处理,节省串行等待时间,解决交易链路用户体验问题
NextRPC架构
▐ 客户端架构
技术架构
网络层,抹平Mtop/Accs通道,对业务透明;
数据整流层,控制 单个请求多个返回的时序(其中异步副返回包含了异步的业务数据流);
数据编排层,控制 多请求间 异步数据的合并。
数据流和多实力
一个页面支持多个 NextRPC 实例,多页面可创建多个 NextRPC 实例;
一个 NextRPC 实例可进行多个不同请求,接收不同的副响应推送。
▐ 服务端架构
技术架构
请求过程详解
客户端发起主请求;
服务端接收到客户端主请求,执行业务逻辑的同时,通过消息中间件发送副请求信息(注:AttachedRequestEmitter 通过消息中间件,将非核心依赖解耦出去),所有业务逻辑执行完成后,副请求也都发送完成;
返回客户端主响应,主响应包含副请求元信息;
副请求接收端通过消息中间件消费副请求消息,并调用业务处理器AttachedRequestProcessor,业务处理完成后,返回nextrpc-sdk副请求处理结果;
副响应通过消息推送通道下发给客户端
客户端监听指定的消息推送通道,收到副响应数据后,渲染上屏。
异常情况处理
副请求编排,一个主请求多个副响应的场景下,客户端如何知道总共有多少个副请求?
由于服务端业务调用 NextRPC SDK 发送副请求,SDK 是知道自己被调用了多少次的,所以这个信息由 SDK 来统计并存储,SDK 内部维护一个副请求元信息,包括总数、副请求业务信息,业务每调用一次 SDK 发送副请求,SDK 累加累加总数,主响应结束时,同时下发副请求总个数。
副请求处理,不同业务吞吐量不一样,多个业务之间如何隔离确保互不影响?
业务之间通过消息中间件的不同 Topic 或者 不同的 Tag 进行隔离,每个 Topic 或 Tag 使用单独线程池消费。
消息过期、重复如何处理?
副请求通过消息中间件发送,当副请求接收端收到消息时,消息存在过期、重复的情况,SDK 提供消息的元信息(包括时间戳、唯一标识)
消息过期:SDK 内部可
消息重复:需要由业务代码根据请求的唯一标识来实现幂等。
▐ 技术指标
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
✿ 拓展阅读
作者|蓄昂
编辑|橙子君
出品|阿里巴巴新零售淘系技术