02 容量：从业务视角看容量到底是什么？
你好，我是白园。从今天开始我们学习可靠性保障领域的第二个方面——容量。
2013年10月，百度举办了一场盛大的科技大会，会上宣布了一个重大消息：百度网盘的用户存储容量将从5GB大幅提升到2TB。这一时期，互联网行业迎来了“百盘大战”，各类网盘服务陆续出现，竞争非常激烈。在这个变革的浪潮中，百度网盘的流量激增20倍。面对这么大的流量压力，百度网盘没有出现任何故障。
这背后的关键因素就是 容量保障。所以这节课我就带你详细了解容量保障体系，并教你如何有效地开展容量相关的工作。
容量的本质
首先，让我们以第一性原理来探讨这个问题，容量本质上是资源消耗与资源补充之间取得一个平衡。目标是 在确保系统可靠性的同时，尽可能地减少资源的投入。你可以结合我给出的示意图来理解。
容量为什么这么重要？
容量管理对于系统稳定性的重要性，就像身体素质对人体健康的重要性一样，在生病的时候身体素质比较好的人往往恢复得更快，而身体素质比较差的人恢复缓慢，甚至可能引发其他基础疾病。
同样，如果服务的容量管理不善，就可能导致一系列问题，比如流量波动、热点事件以及变更操作都会引发资源冲突，从而导致故障。相反，如果容量管理得当，很多类似的问题都不会出现。所以一个好的容量管理是提升系统可靠性的基础。
容量管理到底在解决什么问题呢？
一谈到容量管理，我们不可避免地会遇到一系列专业术语，比如压测、流量预测、水位、混部、限流策略和弹性扩容等。这些术语之间存在着怎样的联系和区别？我们又需要采用哪种方法来解决容量问题呢？我们一个一个看。
在我的理解中，容量管理的核心在于解决四个关键问题：一是明确容量的定义；二是实现对容量的观测；三是确保对资源需求的准确评估；四是对容量问题的快速处理。
这里我整理了一张图片，你可以结合我给出的示意图来理解。
容量水位定义
如果去定义容量水位，就不得不提到两个概念：业务容量水位和资源容量水位。
- 业务容量水位 = 业务负载 / 业务容量 \* 100% = 当前承载的请求量（事务量）/ 能承载的最大请求量（事务量） * 100%
- 资源容量水位 = 资源用量 / 资源容量 \* 100% = 当前消耗的资源量 / 总体可用的资源量 * 100%
这两种水位定义有什么区别，在什么时候去使用，各有什么优缺点呢？
业务容量水位侧重于衡量整个服务链路的流量，从用户接入到业务服务再到后端的数据库等。优势在于能够提供一个 宏观的视角，可以贯穿整个链路。然而，它可能无法捕捉到那些不太明显或弱依赖的流程，这可能导致在压测不足的情况下出现盲点。此外，由于不可能对每个服务进行详尽的压测，这种方法可能没办法全面覆盖所有服务的细节。
资源容量水位关注具体的资源使用情况，比如CPU、内存、I/O和磁盘等。这种方法的优势在于能够全面地 识别资源瓶颈，但它可能没办法全面反映下游服务的状态。例如，单纯通过资源使用情况可能难以发现数据库的性能瓶颈。
在这里我推荐结合这两种方法，在不同的层面上实施容量管理。这里我整理了一张图片，你可以结合我给出的示意图来理解。
在入口层，我们可以针对核心接口采用 业务容量水位，以确保用户交互的关键点得到充分的压测和感知；在服务层，我们可以采用 资源容量水位，这样可以更精细和全面地监控各个服务的资源使用情况。
为什么采用这种衡量方式呢？其中一个考量就是兼顾 评估压测成本和服务覆盖率，如果对每个服务进行详尽的压测会带来很高的成本，同时也是不现实的。这里把这两种方式结合起来，我们既可以从业务视角出发贯穿整个链路做评估，保障核心链路的容量；同时又可以兼顾所有服务的资源不足问题，使其能够及时被发现。
容量观测
容量观测要求我们不仅要密切关注系统的实时水位状态进行监控，还要对长期性能趋势进行预测，以便及时发现并处理像性能退化或者流量上升等问题。
为了全面地进行容量观测，这里我推荐两种关键工具，实时的容量监控大盘和定期进行的容量巡检，还有两个平台，容量平台和压测平台。
容量监控大盘 就是一个实时的数据展示平台，集中显示系统的容量状态和关键性能指标，比如流量情况、上面定义水位情况，峰值情况等等。
另外与容量监控大盘相辅相成的是 容量巡检，就是要定期进行的系统评估。通过每天对系统水位和服务性能的检查和分析，我们可以发现那些不易察觉的潜在问题。
为了全面观测和记录系统的性能，我们依赖于 容量管理平台 和 压测平台 这两个关键技术支持平台。容量管理平台负责数据的累积和管理，搜集和分析系统资源的使用情况，支持容量规划和优化。而压测平台专注于模拟高负载情况下的系统行为，通过施加压力和流量回放，验证系统的稳定性和可靠性。
在一些公司内，这两个平台的功能可能会合并到一个统一的系统中，这样做不仅可以提升操作的效率，还能更加高效地进行容量管理和性能优化。你可以结合我给出的示意图来理解。
容量分析
容量分析是一项关键的工作，主要解决了三个核心问题。
- 评估当前资源是否满足需求：我们需要评估现有资源能不能满足当前以及高峰期间的业务需求。这不仅涉及到对现有资源的审视，还包括对业务高峰期资源需求的准确预测。
- 制定资源补充策略：如果发现资源不足以应对需求，我们需要确定补充资源的具体数量。这要求我们进行细致地资源规划，包括资源的采购、配置和部署等各个环节。
- 确定资源补充的时间节点：确定时间表和启动点，保证在业务需求增长之前，及时完成资源的扩充和优化。
尽管这三个问题看起来很直观，但解决它们需要复杂的数学模型和算法支持。比如我们需要运用 动态规划 等关键算法，来评估现有资源的充足程度。在资源充足的情况下，我们还需要利用 最优化理论， 来考虑如何更高效地分配资源。我们需要深入分析服务特性，构建服务画像，并根据这些内容来确定各服务在不同QPS下的资源需求量，从而制定出精确的资源补充计划。
容量处置
针对不同的业务需求和系统状态，我们通常采取四种基本的应对策略：增加资源、内部调度、限流丢弃、功能降级、缓存优化。你可以结合我给出的示意图来理解。
我们先来看增加资源这个策略，它的目的是通过增加资源来应对业务增长。它分为两个步骤：首先，将资源从现有库存或其他地点补充到我们的资源buffer，比如通过云上资源快速补充来到这个目标也就是我们说的混合云模式；其次，把这些资源部署到线上服务中去，也就是我们常说的快速扩容和弹性扩容。
第二个策略是内部调度，通过在系统内部进行资源的重新分配和优化，把资源从低优先级任务转移到高优先级的服务上。这种做法的一个典型例子是 混部技术，也就是把离线服务和在线服务部署在同一台机器上，当资源不足时快速腾退离线资源来保证在线服务的资源。
第三个策略就是限流丢弃，在系统面临超出它处理能力的流量时，就采取限流措施，确保系统只处理能力范围内的请求，而超出部分的请求会被丢弃。这种做法能够保护系统不受过载的影响，维持其在能力范围内的系统稳定。
最后一个策略是功能降级和缓存优化，在资源紧张的情况下，可以通过降级非核心功能来减少资源消耗，保证核心功能的正常运行。同时，通过缓存热点请求到高性能介质，比如内存或者SSD等进行缓存。
容量在网盘的实践
刚刚我们已经全面了解了容量管理相关的理论知识。接下来，我会结合具体的网盘业务场景，详细阐述怎么把这些理论应用到实际的业务保障中，并通过实践案例来展示落地实施的具体方法。
我先介绍一下网盘业务架构，它由三个部分组成，接入、计算、存储。接入层（网络层）接入用户流量和网络调度；计算层（服务层）负责管理用户元信息和用户文件元信息；存储层负责用户文件的实际存储。
我们再来具体看一下网盘的容量保障体系图，我从上往下给你一一解读一下。
首先是网盘的容量水位定义，分为业务容量水位和资源容量水位。业务容量包括下载、上传、列表、分享功能，当前QPS/极限QPS。因为网盘是计算、存储并列业务，所以资源容量水位同时兼具计算容量、存储容量两个类型。
容量大盘
为了实时监控和分析流量动态，我建议你采用三线趋势图来展示关键指标，比如实时流量曲线、当前水位状态、日与周的同比变化、流量峰值情况，以及风险评估。这些数据可以帮助我们评估系统是否需要进行扩容来应对潜在的流量增长。
容量巡检
为了高效监测和分析流量，我建议你利用表格形式的巡检图来清晰展示实时数据和峰值流量。通过对比峰值流量与当前实时流量，我们可以评估系统扩容的需求，并确定所需的资源规模，从而做出更加精准的扩容决策。
定期压测
网盘一般是采用周级别的压测来摸底容量极限。你可以根据自己业务的情况选择周、双周或者月去进行压测。
容量分析
给出扩容的时间和节奏，这里我们根据当前的流量和最近一次流量峰值，来预测是否需要扩容，如果需要的话，就应当给出扩容建议和需要的资源预估。其中涉及的预测方法和计算算法，我会在后续AIOps容量部分为你详细讲解。
容量的常态处置
扩容：我们采取的是弹性扩容。弹性扩容有两种触发机制，利用率触发和时间触发。利用率触发是在当CPU利用率超过50%的时候分布扩容，时间触发预测到下一次峰值到来之前进行扩容。
混部：我们采用了在线计算与在线存储服务的混部模式。之前由于资源冲突，计算资源和存储资源是分开部署的。然而随着云计算技术不断成熟，我们现在能够在存储服务的硬件上直接部署计算服务，从而实现了资源的高效整合。
限流和降级：网盘在各层之间都有限流，包括接入层、计算层、存储层都有对应的限流方案。降级的重点是在转码等计算层面，一旦出现计算资源不足会进行部分离线功能降级。
小结
容量管理的精髓在于精准平衡资源的消耗与补充，目的是在提升系统可靠性的同时，有效降低资源的总体投入。为了实现这个目标，我们需要重点解决四个关键问题：首先，明确容量水位的具体定义；其次，实现对容量状态的可视化监控；还有确保对容量的准确评估；最后，能够迅速响应并妥善处理任何容量相关问题。
值得注意的是，脱离业务实际的容量讨论是不具现实意义的。因此，容量管理策略必须紧密结合具体业务需求，确保所采用的容量定义和方法与业务目标高度一致。
思考题
在进行压测的时候，如果观察到流量达到某一阈值后，系统开始出现大量失败和延迟现象，但这个时候系统的CPU利用率却非常低，请你分析一下可能的原因。欢迎你把你思考后的结果分享到评论区，也欢迎你把这节课的内容分享给其他朋友，我们下节课再见！