证明水平扩展的合理性

Question

什么时候是水平扩展可以解决您的扩展问题吗？

假设您有一个 api 节点（无数据库），期望目标是 5 分钟内 10k RPS，其中 p95 < x 毫秒。请求进来，您开始看到 p95 超过您的 x 目标。如果您没有看到任何明确的指标表明应用程序性能不佳（> 75% CPU，> 75% RAM 等），是否可以安全地假设水平扩展可能是解决方案？

一开始我以为答案是“是”，但后来我看到本文。将节点应用程序从大型 AWS 实例垂直扩展到超大型 AWS 实例，使其从 10k RPS 增加到 25K RPS。这怎么可能？10k 测试的 CPU 利用率约为 10%（不是那么高）。可能是内存问题，但似乎不太可能。我是不是漏掉了什么？或者水平扩展比垂直扩展更便宜，而且具有弹性的额外优势？

Answer 1

一般来说，扩展是解决负载增加问题的安全选择。即使是最糟糕的单线程应用程序通常也会受益于更快的 CPU，任何磁盘受限的应用程序几乎总是会受益于更多更快的存储，即使更多的 RAM 不会立即使应用程序受益，将 IO 卸载到内存通常也会有所帮助。

一般来说，您需要非常深入地了解应用程序的运行方式（在负载下），才能提前知道在应用水平扩展时它是否会正常运行，更不用说这样做是否能真正解决让您考虑扩展的任何瓶颈。

对于两者而言，拥有适当的性能指标并运行负载和压力测试确实很有帮助。这是找到真正瓶颈的唯一方法，可以查看调优和配置调整是否有助于产生影响，以及/或者更多和/或更好的硬件是否可能实现最具成本效益的升级。

在我看来，经常指出应用程序遇到瓶颈的地方并坚持要求开发人员修复他们发布到生产中的任何垃圾是一个比扩大和/或缩小规模更好、更有弹性的解决方案。