Rhino是字节自研全链路容量评估产品,致力于构建完整的全链路容量评估解决方案(覆盖:容量预估->资源准备->数据准备->容量验证->监控->分析->决策->处理反馈);围绕容量在稳定性、成本、效率 三方面提供业务全方位基础支撑。Rhino 目前已经成为字节各业务容量评估主流解决方案,并且历年来在业务大型活动稳定性保障中(抖音春节项目、电商618/双11大促等)均扮演了关键角色。
Rhino 所解决的核心问题包括:
Rhino 是由之前全链路压测升级而来,自上线以来经历了3次大的产品变革,当前围绕容量评估进行容量保障生态体系建设。
Rhino 整个产品体系是围绕容量验证和容量预估两个基础能力构建,协同为业务提供完整容量评估解决方案:
其中,基于算法模型的容量预估自22年初开始开始在各头部业务和活动中实现规模化应用,容量模型基础能力建设是【Rhino】 、【电商服务架构】以及【基础架构各组件团队】深度合作完成的。
容量模型建设里程碑:
全链路容量评估自动化及多场景支持
超大流量、多场景施压引擎能力
安全、可靠、准确容量评估支持
定义容量评估标准,实现容量评估低成本、常态化
基础信息:双11 历来都是电商业务年度重要的节点,技术侧整体目标对系统架构也一向有很高的要求。
活动策略:
本次电商大促活动,Rhino 全链路容量保障方案从活动前、活动中、活动后三个活动时段,拆分 7 个阶段围绕:流量预估、压测、限流、资源、风险巡检等Topic 展开。
2023年双11 大促涉及链路覆盖上下游:上千个服务, 几十个子域场景 & 几百个核心接口全链路压测 & 入口千万级QPS发压。
复杂场景下资源预估多组件覆盖技术挑战
容量治理能力初次在电商活动中实践落地
变化:由于双十一活动业务目标的提升,业务在容量治理方面提出了更高的要求;过去常态容量保障基础上增加了:核心服务极限容量探测、强弱依赖集群拆分验证、线上性能防劣化等容量治理诉求。
容量治理基建能力 —— 线上切流巡检,在稳定性、安全性上需要深度契合电商业务场景,不能引起线上切流资损或事故;
对业务所有接口进行逐个分析,将流量预估方案细化到单接口的维度上;在此过程中,我们主要考虑接口流量来源、接口流量的影响因素以及接口之间的关联性。接口流量预估主要可以分为两部分:
大促基础流量:分为以下几种类型采用不同方式进行流量预估
高热直播间核心接口增量流量:这类接口容易受主播达人的口播内容、玩法策略影响产生尖刺流量,因此需要使用更精细的秒级数据进行建模。
电商上下游依赖上千服务,人工估算难以准确推算整体资源部署情况;Rhino 资源预估能力借助拓扑流量估算、排队论等算法,自动化估算全链路资源缺口。
业务目标明确: 在开始流量预估前,借助关注的往年及今年核心整体数据(例如 DAU、GMV、PCU),提供统一的参考基准;不同阶段会综合考虑多层面影响因素,例如:
入口服务流量估算:业务目标及转化关系明确后,完成入口服务流量预估。
资源预估入口导入: 流量预估完成后通过填写或导入的方式,开始活动资源预估
MySQL( RDS) | Redis | Abase | ByteKV | ByteGraph | ... | |
---|---|---|---|---|---|---|
系统架构 | Proxy - Server | Proxy - Server | Proxy - Server | Proxy - Server | Proxy - Cache - Server | ... |
数据存储方式 | 单机 + 分片存储 | 分片存储 | 分片存储 | 分片存储 | 分片存储 | ... |
部署方式 | 物理机 + 同规格容器 + 不同规格容器 | 同规格容器 | 同规格容器 | 同规格容器 | 同规格容器 + 不同规格容器 | ... |
容灾方式 | 主从容灾部署 | 主从 + 分机房容灾部署 | 主从 + 分机房容灾部署 | 分布式部署 | 分布式部署 | ... |
存储资源依赖 | 磁盘 | 磁盘 | 磁盘 | 磁盘 | 依赖 ByteKV 存储 | ... |
资源申报方式 | CPU + 存储分离申报 | 合并存储资源申报 | 按分片量申报 | 按分片量申报 | 按分片量申报 | ... |
Rhino 预估方案聚焦此架构特点,在流量预估阶段按照部署架构分离读写流量至对应实例。
存储资源预估:Rhino 预估方案从资源瓶颈和申报口径两个视角切入评估存储资源
注:业务完成资源预估后,即可根据预估数据进行资源填报和进行资源交付,从而完成资源准备工作。
目标:为了活动保障电商核心链路稳定性,业务会通过‘重保集群’拆分对链路进行隔离,达到容灾目的;拆分集群的性能有一致性要求,在这个过程中我们需要辅助业务对容灾链路进行性能摸底。
实现方案
任务&环境创建:自动化的构建泳道环境创建,支持集群间业务真实流量切流,低成本实现单pod性能压测。
服务接入完成后,业务需要确立服务性能摸底目标并调试任务运行,以保障泳道切流能够成功运行并达成业务目标,主要工作包含:
确立性能摸底目标后,即可开始泳道切流任务,通过服务端监控观测性能差异,从而判断性能基本状态。
背景
过往电商链路由于流量异常增长等情况未配置有效限流造成事故占比较高,所以电商业务针对全链路服务进行通用限流建设,限流覆盖率达到 80%+;
限流覆盖率增高,误限流导致的问题同样增多,影响场景如下:
限流前置治理目的
限流治理类型和方案
限流风险排查
整体来讲,电商业务全链路压测包括2个阶段:子域压测、C端全链路压测。
全链路压测之前需要各个业务模块提前进行子域压测,重要性如下:
流程效率:
压测仿真度:全链路压测无法保证100%仿真,流入到某些子域的流量可能不及预期,需要在子域压测中覆盖。
覆盖场景:
C端全链路压测定位是端到端容量评估和验收,因此在子域压测完成之后进行。
Rhino 经过多年来字节各大活动容量保障支持,沉淀打磨下完整稳定容量验证平台化能力,自2022年以来验证环节中具体步骤不再需要 Rhino 过多介入;故为了保证全链路容量验证预期目标,Rhino 与业务方分工:
容量验证方案
前置准备支持: 辅助服务改造、场景梳理、数据准备以及相关知识培训,为正式开展容量验证做准备
资源、上下游风险评估:保障容量验证流程、目标顺利完成,及上下游依赖方系统安全性:
平台基建保障: 提供平台稳定性保障,保证活动顺利进行。
全链路压测执行: 目前业界对全链路压测的实施成熟方案已经很多,并且在我们过去的技术文章中有过介绍(https://mp.weixin.qq.com/s/vofrpFGvnptj3MNAv1hQ-w),本文不再赘述。
电商系统庞大复杂,这么多指标,哪些才是重点?业务会构建自己的系统监控大盘。
只看重点还不够,如何看全、看细?子域监控大盘。
当前Rhino 提供的容量预估与巡检覆盖了主流在线计算相关组件,覆盖电商96%+核心链路服务,风险拦截准确率达到 90%以上。
整体来讲,活动结束后会进行:容量调整和缩容验证。
完成活动资源回收目标后,从电商链路稳定性角度考虑,需要进行一轮电商全链路压测进行验证,确保缩容后服务稳定性。
本次电商双11 活动中,基于调度的全链路自动化压测方案投入使用,主要优势如下:
自2022年初以来,Rhino 成功完成了从压测 到容量产品转型,围绕业务全流程容量保障构建了基础能力支撑体系;这个期间,非常感谢公司内所有合作团队,尤其是基础架构各兄弟团队、中台团队对Rhino 的支撑,没有他们的支撑,整个容量评估体系难以完成的。
多模态容量模型持续探索
持续探索基于模型容量评估解决方案(排队论、深度学习、LLM等),不断推进组件类型和业务场景低成本覆盖;
容量模型预测、分析准确率持续提升:
面向业务完整容量解决方案SOP 构建
常态化容量评估能力建设
Rhino 属于字节跳动架构体系下QE 团队,致力于建设字节跳动完整全链路容量评估生态体系和标准,提供覆盖容量预估、容量分析、容量验证、容量治理及容量运维等完整容量保障解决方案,以及低成本、安全、准确的容量评估支持,覆盖场景包括大型活动、技术升级验证、常态化容量评估等。
职位要求:
目前团队【后端开发工程师】和【算法工程师】紧缺,非常期待感兴趣的同学加入。