前言

Rhino 简介

Rhino是字节自研全链路容量评估产品，致力于构建完整的全链路容量评估解决方案（覆盖：容量预估->资源准备->数据准备->容量验证->监控->分析->决策->处理反馈）；围绕容量在稳定性、成本、效率 三方面提供业务全方位基础支撑。Rhino 目前已经成为字节各业务容量评估主流解决方案，并且历年来在业务大型活动稳定性保障中（抖音春节项目、电商618/双11大促等）均扮演了关键角色。

Rhino 所解决的核心问题包括：

• 如何降低字节各业务容量风险，内部变更、外部流量、活动、容灾、应急等场景容量风险？
• 如何控制业务资源成本管控同时不拖累业务发展，尤其是例行抖音春节项目和电商业务大促活动？
• 如何在资源有限情况下，保障业务持续运行，兼顾稳定性与成本？

容量评估产品体系

Rhino 发展历程

Rhino 是由之前全链路压测升级而来，自上线以来经历了3次大的产品变革，当前围绕容量评估进行容量保障生态体系建设。

Rhino 产品架构

Rhino 整个产品体系是围绕容量验证和容量预估两个基础能力构建，协同为业务提供完整容量评估解决方案：

• 以分布式压测为核心的容量验证，能够为业务提供高置信度评估支持；但随着各业务压测进入深水区，仿真度和安全性保障趋于完善，业务成本方面关注度更高；
• 基于算法模型的容量预估，对于业务而言能够大幅降低容量评估成本，但缺点是置信度不如压测，这个也是我们要持续提升算法模型准确性的原因，没有置信度即使成本 0也没有价值。

其中，基于算法模型的容量预估自22年初开始开始在各头部业务和活动中实现规模化应用，容量模型基础能力建设是【Rhino】 、【电商服务架构】以及【基础架构各组件团队】深度合作完成的。

容量模型建设里程碑：

Rhino 核心能力

• 全链路容量评估自动化及多场景支持

• 构建面向业务提供容量预估、资源准备、数据准备、容量验证、监控、分析、决策、处理、反馈完整容量评估流程；
• 容量评估流程各环节交互高度自动化；
• 提供多种场景容量评估支持，如大型活动、新服务上线、线上性能探测等 。

• 超大流量、多场景施压引擎能力

• 提供不同协议、多地区、数据类型、过亿 QPS 级别施压引擎支持 ；
• 针对业务复杂场景，提供开放性支持，如灵活任务编排、流量调度、Plugin、云 IDE 支持等 。

• 安全、可靠、准确容量评估支持

• 提供多种协议的流量染色标记和不同泳道流量数据监控、追踪能力 ；
• 构建完整的安全合规配套管控方案；
• 多评估模型支持能力。

• 定义容量评估标准，实现容量评估低成本、常态化

• 容量评估配套基础能力横向打通，提供丰富数据构造、基础组件改造、容灾等基础能力支持 ；
• 研发流程相结合，提供容量评估管控能力支持，实现容量评估同时覆盖左移、右移；
• 容量评估标准化、流程化，如基础组件改造统一、数据构造标准化、业务评估模板定制化。

业务背景

活动背景及目标

基础信息：双11 历来都是电商业务年度重要的节点，技术侧整体目标对系统架构也一向有很高的要求。

活动策略：

核心挑战

业务容量保障流程长

本次电商大促活动，Rhino 全链路容量保障方案从活动前、活动中、活动后三个活动时段，拆分 7 个阶段围绕：流量预估、压测、限流、资源、风险巡检等Topic 展开。

链路复杂、业务规模大

2023年双11 大促涉及链路覆盖上下游：上千个服务， 几十个子域场景 & 几百个核心接口全链路压测 & 入口千万级QPS发压。

• 复杂场景下资源预估多组件覆盖技术挑战

• 单一模型无法适用所有组件类型和业务场景，针对不用业务场景和组件需要构建不同模型；
• 预估效果影响因素众多：除受算法模型影响之外，还跟不同类型组件设计架构、业务工程策略等因素有关。

• 容量治理能力初次在电商活动中实践落地

• 变化：由于双十一活动业务目标的提升，业务在容量治理方面提出了更高的要求；过去常态容量保障基础上增加了：核心服务极限容量探测、强弱依赖集群拆分验证、线上性能防劣化等容量治理诉求。

• 挑战：

• 容量治理基建能力 —— 线上切流巡检，在稳定性、安全性上需要深度契合电商业务场景，不能引起线上切流资损或事故；

• 容量治理在问题召回及问题分析方面，数据标准化缺失，需平衡对齐多方标准提升业务认可度。

容量保障方案介绍

活动前流量预估

流量预估架构

详细说明

对业务所有接口进行逐个分析，将流量预估方案细化到单接口的维度上；在此过程中，我们主要考虑接口流量来源、接口流量的影响因素以及接口之间的关联性。接口流量预估主要可以分为两部分：

• 大促基础流量：分为以下几种类型采用不同方式进行流量预估

• 背景流量：流量不随大促活动变化，仅作为背景流量补充，因此可以直接取近期线上最高流量水位；
• 模型预估接口：流量随电商直播间PCU、直播间进房量等业务指标变化而变化，而大促期间这2组指标数据量波动较大，这类接口受大促影响较大。我们对这类接口进行流量数据建模并沉淀出日常流量模型、大促流量模型作为后续流量预估基准；
• 重保接口：业务方往往有强诉求，其流量目标比通用模型估出来的结果要高，对标历史大促的最高峰值流量，比如交易提下单、购物车、福袋抽奖等模块。

• 高热直播间核心接口增量流量：这类接口容易受主播达人的口播内容、玩法策略影响产生尖刺流量，因此需要使用更精细的秒级数据进行建模。

流量预估模型

活动前资源预估

目标

电商上下游依赖上千服务，人工估算难以准确推算整体资源部署情况；Rhino 资源预估能力借助拓扑流量估算、排队论等算法，自动化估算全链路资源缺口。

资源准备流程

• 业务目标明确： 在开始流量预估前，借助关注的往年及今年核心整体数据（例如 DAU、GMV、PCU），提供统一的参考基准；不同阶段会综合考虑多层面影响因素，例如：

• 大促活动目标交易额预估：往届、本届大促成交量目标 GMV 及头部主播实时在线人数 PCU 变化等；
• 子域链路目标流量预估：拆分至营销、直播间等子域链路目标流量；
• 具体到接口流量的预估：业务逻辑、调用关系、流量增幅等。

• 入口服务流量估算：业务目标及转化关系明确后，完成入口服务流量预估。

• 资源预估入口导入： 流量预估完成后通过填写或导入的方式，开始活动资源预估

• 参考历史时段：选择参考线上的 QPS、CPU 等指标日期，以及链路拓扑时间区间；
• 预期 CPU 利用率：选择大促活动各组件目标资源水位；

资源预估方案

• 业务冗余度注入：基础组件资源预估往往需要考虑更高维度指标（磁盘 IO、链接池、主从同步等）；从业务评估灵活度考虑，流量冗余度参考计算的方式，能够弥补业务其他角度补充预估考虑。
• 模型细分构建：综合各组件架构、部署特性、工程策略等因素进行容量模型建模，为各类基础组件提供资源预估数据，例如下面典型组件核心影响因素差异。

• 读写流量分离：基础组件主从实例流量与读写流量存在特殊分布关系，例如 Redis 主从实例流量架构：

Rhino 预估方案聚焦此架构特点，在流量预估阶段按照部署架构分离读写流量至对应实例。

• 存储资源预估：Rhino 预估方案从资源瓶颈和申报口径两个视角切入评估存储资源

• 存储资源增长趋势预测：预测存储资源剩余使用天数，辅助业务评估存储瓶颈；
• 资源申报汇总：结合计算资源、存储资源，汇总资源申报建议数据。

注：业务完成资源预估后，即可根据预估数据进行资源填报和进行资源交付，从而完成资源准备工作。

活动前容量治理

容灾链路性能摸底

• 目标：为了活动保障电商核心链路稳定性，业务会通过‘重保集群’拆分对链路进行隔离，达到容灾目的；拆分集群的性能有一致性要求，在这个过程中我们需要辅助业务对容灾链路进行性能摸底。

• 实现方案

• 任务&环境创建：自动化的构建泳道环境创建，支持集群间业务真实流量切流，低成本实现单pod性能压测。

• 服务接入完成后，业务需要确立服务性能摸底目标并调试任务运行，以保障泳道切流能够成功运行并达成业务目标，主要工作包含：

• 切流负载目标：评估服务性能摸底 CPU 负载目标；
• 持续时间：泳道切流运行持续时间，及步长；
• 熔断配置：保障线上流量安全性，进行错误率、时延等任务熔断配置。

• 确立性能摸底目标后，即可开始泳道切流任务，通过服务端监控观测性能差异，从而判断性能基本状态。

限流治理

• 背景

• 电商大促活动中，流量增长往往超出限流配置预期，易出现限流误命中造成流量损失；
• 电商大促容量验证期间，限流误命中会导致容量验证目标无法达成，影响验证效率。

• 过往电商链路由于流量异常增长等情况未配置有效限流造成事故占比较高，所以电商业务针对全链路服务进行通用限流建设，限流覆盖率达到 80%+；

• 限流覆盖率增高，误限流导致的问题同样增多，影响场景如下：

• 限流前置治理目的

• 通过前置限流治理，提前暴露风险，并提高整体容量评估效率；
• 为保护系统热点状态稳定性，针对业务核心接口进行限流全覆盖及L0&L1 核心链路覆盖；
• 为保护基础组件稳定性，针对热点直播间、热点商品进行独立限流，并通过子域压测检验可用性。

• 限流治理类型和方案

• 限流风险排查

• 结合Rhino 限流瓶颈预估组件，定期全链路扫描潜在限流风险；
• 组织业务侧限流风险review，检验限流设置合理性，并在活动保障中取得正向价值；
• 同时，针对异常报警数据建立了自动化追踪机制，持续协助业务侧高效排查风险案例。

活动前全链路压测

业务全链路压测实施要点

整体来讲，电商业务全链路压测包括2个阶段：子域压测、C端全链路压测。

• 子域压测意义

全链路压测之前需要各个业务模块提前进行子域压测，重要性如下：

• 流程效率：

• 大促机器资源到位时间较晚，等全部资源到位之后再开始压测时间会来不及，因此可以在部分机器资源到位之后就开始做子域压测，先把子域容量压到预期；
• 全链路压测的定位是整体容量验收，原则上需要各个子域确保自己没有容量问题了才能参加。避免全链路压测的时候因为某个子模块容量问题而反复回归与验证。

• 压测仿真度：全链路压测无法保证100%仿真，流入到某些子域的流量可能不及预期，需要在子域压测中覆盖。

• 覆盖场景：

• B端场景覆盖：B端目前没有全链路压测，只能依靠子域压测来覆盖；
• 极端场景覆盖：某些极端场景（比如秒杀场景、热点直播间场景等）在子域压测中覆盖，全链路压测更多的起到端到端容量评估和验收的作用；
• 横向玩法场景覆盖：某些横向玩法和C端核心接口的链路耦合性不强，适合通过子域压测单独覆盖。

• C 端全链路压测

C端全链路压测定位是端到端容量评估和验收，因此在子域压测完成之后进行。

全链路压测技术支撑

• Rhino 经过多年来字节各大活动容量保障支持，沉淀打磨下完整稳定容量验证平台化能力，自2022年以来验证环节中具体步骤不再需要 Rhino 过多介入；故为了保证全链路容量验证预期目标，Rhino 与业务方分工：

• 业务侧：主导容量验证各环节，包含：链路梳理、数据构造、任务创建、调试、执行等；
• Rhino：架构师角色参与关键方案评审，主要评估、协调验证环节风险点。

• 容量验证方案

• 前置准备支持： 辅助服务改造、场景梳理、数据准备以及相关知识培训，为正式开展容量验证做准备

• 服务改造：包括存储改造、登录鉴权改造、时间穿梭改造；
• 场景梳理：梳理接口逻辑、调用下游情况、不同参数不同链路情况；
• 数据模型构造：包括那些参数需要替换、替换方式确定、铺底数据如何构造。

• 资源、上下游风险评估：保障容量验证流程、目标顺利完成，及上下游依赖方系统安全性：

• 业务验证规模报备：峰值 QPS、使用场景、预期发压引擎资源、Mock 量级、改写数据量级等；
• 发压引擎资源预估、部署（优化中）：通过发压引擎模型，预估预期使用资源量；
• 上下游风险评估：评估录制、改写、Mock、压测服务账号等上下游风险点，并同步依赖方。

• 平台基建保障： 提供平台稳定性保障，保证活动顺利进行。

• 全链路压测执行： 目前业界对全链路压测的实施成熟方案已经很多，并且在我们过去的技术文章中有过介绍(https://mp.weixin.qq.com/s/vofrpFGvnptj3MNAv1hQ-w)，本文不再赘述。

活动中容量巡检

业务自建链路巡检

• 电商系统庞大复杂，这么多指标，哪些才是重点？业务会构建自己的系统监控大盘。

• 呈现核心业务指标、核心链路及关键系统指标、机房网络、基础组件监控；
• 其中核心业务指标以L0链路为主体，汇总SRE及各域稳定性同学共同决策出电商及各域结果指标，作为大促时最关注的指标之一；
• 同时监控与告警联动，当有指标异常时，会出现红色提示标识，并出现告警信息弹窗，以快速发现问题。

• 只看重点还不够，如何看全、看细？子域监控大盘。

• 提供子域监控能力，用于构建子域业务及系统链路，双十一前完成各个子域大屏接入；
• 类似，子域大屏与告警打通，如有异常会进行染色及标注提示，辅助业务快速发现子域内的问题；
• 同时与业务之前自建的Grafana等大盘结合互补，从电商整体的角度，看全看细。

基于模型多组件容量巡检

• 电商大促活动依赖的下游上千个，根据核心链路的强弱梳理，电商强依赖组件有十几种类型、几百个部署集群，且容量评估维度较多，依赖人工评估+巡检耗时巨大，容易遗漏。那么如何进行容量保障？引入自动化巡检提升效率和精准度。
• 由以下几个步骤来分阶段实现自动化：

当前Rhino 提供的容量预估与巡检覆盖了主流在线计算相关组件，覆盖电商96%+核心链路服务，风险拦截准确率达到 90%以上。

活动后缩容

整体来讲，活动结束后会进行：容量调整和缩容验证。

容量调整

• 容量建议：容量调整的输入，是基于活动前预估数据进行操作，通常无需重新计算；
• 容量调整：需要进行计算资源和相关配置等项的恢复。

缩容验证

• 目的

完成活动资源回收目标后，从电商链路稳定性角度考虑，需要进行一轮电商全链路压测进行验证，确保缩容后服务稳定性。

• 基于调度的自动化验证方案

本次电商双11 活动中，基于调度的全链路自动化压测方案投入使用，主要优势如下：

• 通过生产流量的调度，使得流量仿真度及下游服务触达率可以得到更有效保障，最终取得效果：压测仿真度100%；
• 切流操作步骤和压测执行过程中监控、分析等核心环节实现了高度自动化，异常检测分析和止损效率有可靠保障，最大限度的降低了整个压测活动的实施成本。

总结与展望

自2022年初以来，Rhino 成功完成了从压测 到容量产品转型，围绕业务全流程容量保障构建了基础能力支撑体系；这个期间，非常感谢公司内所有合作团队，尤其是基础架构各兄弟团队、中台团队对Rhino 的支撑，没有他们的支撑，整个容量评估体系难以完成的。

未来计划

• 多模态容量模型持续探索

• 继续围绕业务场景，构建基于：成本 - 流量 - 容量 模型分析能力，以及结合容量验证客观数据反馈，不断提升数据质量；
• 同时推进模型精细化训练，例如：集群、接口、时间、单指标等维度模型训练粒度。

• 持续探索基于模型容量评估解决方案（排队论、深度学习、LLM等），不断推进组件类型和业务场景低成本覆盖；

• 容量模型预测、分析准确率持续提升：

• 面向业务完整容量解决方案SOP 构建

• 继续提高全链路容量评估流程完整度，实现：容量评估、决策、处理、反馈闭环能力建设，面向业务构建全流程容量保障SOP；
• 细分业务场景SOP建设，例如容量基础能力在业务容量成本优化过程中提供系统解决方案。

• 常态化容量评估能力建设

• 常态运维能力建设：极致弹性运维、应急/自愈等核心能力强化；
• 全链路容量评估常态化运行，实现服务形态全新升级。

招聘广告

Rhino 属于字节跳动架构体系下QE 团队，致力于建设字节跳动完整全链路容量评估生态体系和标准，提供覆盖容量预估、容量分析、容量验证、容量治理及容量运维等完整容量保障解决方案，以及低成本、安全、准确的容量评估支持，覆盖场景包括大型活动、技术升级验证、常态化容量评估等。

1. 打造字节跳动全链路容量评估体系，负责平台架构设计和研发工作，持续保证系统高可用，为亿级DAU产品提供技术支撑；
2. 持续优化容量模型，优化全链路容量评估活动实施成本，为业务方降本增效赋能；
3. 研究软件工程学术前沿，并结合业务场景进行探索落地，引领公司和业界技术潮流。

职位要求：

1. 本科及以上学历，计算机、软件工程及相关专业；
2. 热爱计算机科学和互联网技术，精通 Go/Python/Java/C++ 等至少一门编程语言，有良好的编码能力和风格；
3. 熟悉Linux，对容器化、云原生架构、网络协议、文件系统等相关领域有一定了解；
4. 良好的后端架构设计能力，具备分布式、高并发开发经验；
5. 对问题有清晰分析和全局思维，能提出具有创造性的解决思路和方案；责任心强，有良好的对外沟通和团队协作能力；
6. 具有全链路压测、机器学习、存储组件研发经验者优先。

目前团队【后端开发工程师】和【算法工程师】紧缺，非常期待感兴趣的同学加入。

• 微信联系：duguxiaolong11；
• 简历投递邮箱：[email protected]（邮件标题：姓名 - 工作年限 - Rhino ）。
• 帮转【前端工程师】招聘：https://zjsms.com/i8jXQcAM/