本文最初发布于 The Startup 博客，经原作者授权由 InfoQ 中文站翻译并分享。
云原生开发最常见的其中一个特性是弹性伸缩。许多公司告诉我们，他们认为弹性伸缩是他们的团队评估云平台的关键需求。然而，我们很少听到这些团队告诉我们，他们为什么需要弹性伸缩。
事实上，我们甚至可以说弹性伸缩是“在云上”的标志之一。所有云平台都提供某种弹性伸缩支持。不管是 Kubernetes 中的Horizontal Pod Autoscalers（根据观察到的 CPU 利用率自动扩展 Pods 的数量），还是像AWS Autoscaling（它会自动缩放 EC2 实例、Dynamo DB 表和许多其他资源类型）这样的供应商特性，通常，弹性伸缩都被视为最想要的云特性。
如果你是一家全新的初创公司，正在构建一个新的 B2C 应用程序，那么弹性伸缩可能至关重要，因为你无法预测你的业务何时会突然腾飞。但大型企业不是初创公司。它们有现有的客户群，而且它们的使用模式在很大程度上是已知的。相反，在大多数企业中，我们看到，公司是将所有不同的工作负载作为一个整体来运行，这些工作负载大致可以分为以下几类：
最大的一类是静态负载，它是可预测的、不变的负载；这可能占所有应用程序的 65%。
第二大类是计划内的伸缩（季节性、批量处理或计划内的活动）——可能占所有应用程序的 35%。
剩下的就是计划外的伸缩（不可预测的负载）；剩下的可能非常少——在许多企业，这样的应用程序可能只有 5%。
下图展示了这个划分（取自一个真实的客户，仅用于说明这种情况）：
各种伸缩情况的占比
问题是，许多团队在构建他们的应用程序时，都将其当成是这 5%的一部分，而实际上，只有很少的应用程序属于这 5%，这 5%总是受到计划外负载的影响。现在，这并不是一个新问题。在相对更传统的应用程序环境中，常见的方法是准备远超需要的基础设施，“以防万一”。显然，这是一种浪费，也是团队想要迁移到云的原因之一。然而，理想的云原生方法假定每个功能都部署成可无限扩展的。然而，对于我们与之合作的那类大型企业，更好的方法是设法识别这 5%的功能，将它们从庞大的单体中分离出来，并以云原生的方式构建它们（例如，它们可能是 Strangler 模式的早期候选对象）。
因此，假设所有的云原生程序都必须具有弹性和无限的可伸缩性，通常是一种误导——相反，对于 95%的企业应用程序来说，更重要的是弹性而不是弹性伸缩。反之，如果我们需要的是横向稳定性（这是实现横向伸缩的必要条件），那么，这些程序就是那 5%确实需要横向稳定性的。
因此，换句话说，如果一个节点或实例丢失、替换或重启，程序应该可以继续稳定地运行，而服务不会中断——与突然需要额外增加节点的扩展相比，这要常见得多。现在我们发现，关键的云原生要素（如松耦合、不使用共享数据库以及仅通过 HTTP 和消息传递系统等标准的、可伸缩的协议进行进程间通信）是实现这一目标的好方法。因此，以云原生方式编写应用程序仍然是正确的做法，但原因可能和你想的不同。
而且，对于许多企业来说，弹性伸缩都是一种反模式。例如，当我们与一家银行谈论弹性软件许可模型时，我们被告知，鉴于他们进行应用程序成本规划的方式，对于新项目的业务案例，他们实际上需要预先确定软件成本。遗憾的是，我们合作的很多企业都是如此。
一个我们会反复听说的可怕的故事（太经常了，我们都希望它是虚构的，但不幸的是我们见证了不只一个这样的例子）是，一个团队新部署了一个具备自动伸缩能力的云原生应用程序，第一个月因为自动伸缩而产生了一个巨额的云提供商账单，这不是因为客户使用率高，而是因为在测试中未遇到的意外错误导致在正常负载下 CPU 利用率反常升高。在成本模型和财务规划赶上技术发展的步伐之前，你最好以云原生的方式构建应用程序，但部署的时候要么固定资源数量，要么采用有资源限制的自动伸缩设置。
查看英文原文：
A Cloud-Native Coda: Why You (probably) Don’t Need Elastic Scaling
延伸阅读：
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论