横向扩展与纵向扩展的区别是什么？哪种扩展方法最适合 API？

横向扩展（也称为“扩容”）是部署额外的虚拟机 (VM) 以增加 API 容量来处理更多负载的过程。（缩减容量称为“缩容”。）随着所需容量的增加，系统管理员可以向集群中添加更多虚拟机。但是，需要使用专门的资源管理软件来管理 API 调用的负载，将它们路由到集群中正确的虚拟机实例并保持平衡。

纵向扩展是向单个节点中添加资源的过程。它与用于增加节点的横向扩展形成鲜明对比。纵向扩展（也称为纵向扩容或缩容）意味着向服务器中增加中央处理单元 (CPU) 容量、内存或存储等资源。对于 API，纵向扩展通常是指增加托管该 API 的虚拟机的计算能力。

例如，如果某个 API 托管在分配有一个 CPU 核心和 512 MB 随机存取存储器 (RAM) 的虚拟机上，则对 API 进行纵向扩展可能意味着将核心数量和 RAM 增加一倍。该 API 将拥有两个专用 CPU 处理器内核和 1,024 MB 的 RAM。通过采用这种新配置，该 API 应该能够处理大约两倍的负载，但网络带宽、存储速度和其他因素的限制可能会削弱纵向扩展的效果。纵向扩展也存在资源管理方面的挑战，但专用软件通常可以处理此问题。

API 通常设计为无状态，这意味着它们不会在会话之间存储请求数据或保留信息。在考虑扩展方法时，这种无状态性质至关重要。无状态 API 不需要跨实例复制数据，因而使横向扩展更高效且更易于实施。系统管理员可以根据需要添加或移除虚拟机，同时不会影响 API 运行，因为 API 客户端的运行不依赖于特定的服务器实例。

有状态本身并无不妥。实际上，它对于应用程序的预期运行可能至关重要。但是，对有状态应用程序执行横向扩展要复杂得多。进行横向扩展需要将所存储的数据从应用程序的原始版本复制到新的实例中。

相比之下，无状态应用程序或 API 不会存储请求数据。它不会在内存中保留会话数据。每次会话开始时，就好像是该应用程序第一次与客户端见面。该会话结束后就是“再见”，而不会保留任何关于该会话的记忆。

可以对无状态应用程序进行横向扩展，因为由哪个虚拟机对 API 调用作出响应并不重要。API 客户端可以调用无限数量的托管该 API 的虚拟机，这完全不是问题。系统管理员可以根据自己的需要添加或移除任意数量的虚拟机，同时不会影响 API 的运行。

由于 API 是无状态的，因此横向扩展成为扩展 API 的正确方式。对于无状态 API，通过添加更多虚拟机来增加容量非常有效。管理员可以创建随着 API 需求增长而扩展的虚拟机集群。

此外，虽然纵向扩展 API 是可行的，但横向扩展更可取，因为纵向扩展中的资源分配问题导致其相对难以实现。相比之下，可以轻松对 API 进行横向自动扩展。当系统管理工具检测到 API 流量激增时，它们可自动添加虚拟机以在集群中托管更多的 API 实例。在纵向扩展情况下，这要困难得多，因为自动扩展在纵向扩展中效果不佳。

随着时间的推移，对 API 的需求将不可避免地发生变化。增加或缩减 API 容量必不可少。对于 API，横向扩展和纵向扩展都是可用选项。但是，API 具有无状态性质，再加上横向自动扩展相对更加容易，这使得横向扩展成为扩展 API 的正确方法。

在分布式系统中，API 是微服务架构的一部分，横向扩展尤为有利。每项微服务都可以根据其特定负载和要求进行独立扩展。此模块化方法可以更高效地利用资源并具备更出色的容错能力，因为一项微服务发生故障不会影响其他微服务。

此外，在微服务架构中，横向扩展符合分布式系统的原则，在这些系统中不同的服务部署在多个节点上。这可以确保系统能够处理不同的负载，并且即使在高峰时段也能保持最佳性能。

在扩展 API 时，停机是一个关键问题，因为任何服务中断都会导致收入损失和客户不满。横向扩展使系统管理员能够在不影响 API 可用性的情况下添加或移除服务器，从而最大限度地减少停机时间。相比之下，纵向扩展可能需要重启服务器或暂时使服务器脱机，这可能会中断服务。

API 提供商可利用横向扩展来确保持续运行，尤其是在计划维护或意外流量高峰期间。通过将负载分配到多个服务器上，横向扩展可确保 API 快速响应并持续可用，即使有个别服务器需要离线进行升级或维修也是如此。