负载测试和业务模型：如何在扩展之前评估容量

增长是一个好问题，直到它成为拖垮公司的问题。

在产品的生命周期中，有一个时刻，决策不再是技术性的，而是财务性的：现在值得扩展吗？这要花多少钱？该系统是否支持商业团队承诺的增长？无论是谁快速回答这些问题，都会付出高昂的代价，无论是一方面还是另一方面：要么他们过度扩张基础设施并烧钱，要么他们缩小规模并在高峰期倒下。

负载测试是将工程与业务决策联系起来的工具。它不仅说明了系统是否可以处理它，还说明了它可以以什么成本来处理它，以及升级的成本从哪里开始受到损害。对于那些接近押注增长的人来说，这改变了决策的质量。

容量是进入账户的数字

数字商业模式有一个前提：为每一个额外用户提供服务的成本很低。在某种程度上，这是真的。这个点是你系统的实际容量，它是有代价的。

负载测试揭示了曲线。当前架构能够支持多少并发用户且质量可以接受？响应时间降低到什么程度？您需要添加多少基础设施才能使容量翻倍，成本是线性增长还是爆炸式增长？

最后一个问题是最被低估的。许多系统可以廉价地扩展到上限，之后，每次容量增加的成本都会不成比例地增加，因为某些结构性瓶颈（通常是银行）占据主导地位。如果没有负载测试，您会在发票中而不是在计划中发现这个拐点。

当目标是扩展时，负载测试的性质就会发生变化。仅仅验证今天的需求是不够的；我们需要预测明天的情况。

我提倡的做法：以业务增长、用户、交易、收入为目标，并将其转化为技术负载。如果目标是在一年内将基数增加两倍，则测试需要模拟当前流量的三倍，而不是当前的流量。问题不是“我们能应对今天吗？”，而是“我们能应对成功的自己吗？”。

该测试预测了瓶颈。也许应用程序可以很好地扩展，但银行却不能。也许与第三方[支付网关]的集成有一个请求限制，这成为业务的真正上限。提前发现这一点可以让您规划、重写零件、与供应商协商限制、更改架构，而不是救火。

充电方式会影响负载曲线，这会产生直接后果。

全天使用分布的 B2B SaaS 具有相对平滑的负载曲线。最大的风险通常是每个客户的数据增长，而不是同时达到峰值。 [市场1] 或电子商务依赖于事件：销售、季节性日期、活动。该曲线有尖锐的峰值，测试需要针对这些峰值，而不是平均值。

具有公共组件的模型具有最糟糕的特征：需求集中且缺乏弹性。注册、申报或服务调度系统几乎在几个窗口中接收其全部年度负载。没有办法解决这个问题，要么系统坚持到窗口，要么公开失败。对于这些情况，峰值负载测试不是可选的，而是一种操作条件。

这是简单的业务决策：容量需要花钱，而闲置容量则需要闲置资金。

扩展最大峰值意味着全年为仅使用几天的容量付费。根据平均水平确定规模意味着要冒在峰值时下跌的风险。负载测试并不能消除这种权衡，但它使其变得可见且可量化。

这也是架构决策合理性的原因。弹性，即随需求自动增长和收缩的容量，解决了这一困境的很大一部分，但只有当你通过测试知道谷值和峰值之间的范围时，投资它才有意义。在不知道这个范围的情况下决定弹性就像购买一个您尚未测量的问题的解决方案。

第一个错误是将负载测试与扩展保证混淆。测试显示电流限制和退化行为。它并没有解决瓶颈；它只是揭示了它。扩展之后仍然需要进行架构工作。

第二是用不切实际的数据进行测试。拥有一千条记录的银行与拥有数百万条记录的银行的行为有所不同。由于扩展意味着数据增长，因此测试需要以预计的量运行，而不是当前的量。系统处理用户负载并因数据量而死机是很常见的，信息量少时速度快的查询在信息量多时会变慢。

三是把结果当作永远的真理。每次发布都可以移动曲线。对于成长型企业来说，负载测试是一种反复出现的实践，是发布过程的一部分，而不是发布前的一次性里程碑。

扩展是最昂贵的产品决策之一。它在两个方向上都是错误的：为时已晚，失去了市场；太早且规模较小，现金会被烧毁。

负载测试不会为您做出决定，但它可以消除猜测。它将“我认为我们可以处理”变成“我们以 Y 成本支持 X 用户，瓶颈出现在 Z”。有了这些数字，技术、产品和财务之间的对话就不再是意见，而是规划。

成长型组织的成熟度部分是这样衡量的：它了解自己产品的容量曲线，并通过观察它来决定成长。任何在没有这些知识的情况下进行扩张的人都是在赌博，而增长的成本太高，不适合赌博。

如果您的公司即将押注于增长，但没有人给出系统容量的数字，那么值得先进行数学计算。我在博客上还有其他关于可扩展性、基础设施成本和技术策略的文章，可以帮助制定这一决策。