基础设施扩展：水平与垂直、负载平衡和自动扩展

Netflix 通过根据实时需求动态扩展数千个实例，为 190 个国家/地区的 2.6 亿用户提供服务。 虽然大多数企业运营规模不及 Netflix，但扩展原则是相同的：自动将基础设施容量与流量需求相匹配，无需人工干预，也无需为闲置资源付费。您在水平和垂直扩展、L4 和 L7 负载均衡器以及反应性和预测性自动扩展之间做出的选择决定了您的平台是平稳增长还是碰壁。

要点

• 为了简单起见，启动垂直（更大的机器），然后在需要高可用性或超出单机限制时切换到水平（更多机器）
• L7 负载均衡器提供现代应用程序所必需的基于内容的路由，而 L4 负载均衡器则为简单的 TCP 分发提供原始吞吐量
• 自动扩展策略应将基于指标的触发器（CPU、内存）与已知流量模式的预测扩展相结合
• 数据库扩展遵循与应用程序扩展不同的规则——针对读重负载的只读副本，针对写重负载的分区

---

水平缩放与垂直缩放

基本的扩展决策是使现有机器更大（垂直）还是添加更多机器（水平）。每种方法都有不同的权衡。

何时垂直缩放

出于多种原因，垂直缩放是正确的首选。它不需要应用程序更改，不需要负载均衡器配置，也不需要分布式状态管理。特别是对于数据库来说，垂直扩展可以避免分片、复制延迟和分布式事务的复杂性。

在以下情况下垂直缩放：

• 您的应用程序还不是无状态的（会话存储在内存中，文件系统写入）
• 您正在运行单个数据库并且未达到连接或 CPU 限制
• 下一个实例规模的扩大比水平化的工程时间更便宜
• 您需要立即扩展而不需要更改架构

在以下情况下停止垂直缩放：

• 您需要高可用性（单实例=单点故障）
• 最大的可用实例还不够
• 您正在为 90% 时间处于闲置状态的峰值容量付费
• 您需要延迟的地理分布

何时水平扩展

水平扩展要求您的应用程序是无状态的——任何请求都可以由任何实例处理。这意味着：

• 会话存储在Redis或数据库中，而不是内存中
• 文件上传存储在对象存储（S3）中，而不是本地磁盘中
• 没有特定于实例的配置或没有复制的本地缓存
• 优雅地处理实例终止（健康检查、连接耗尽）

在以下情况下水平缩放：

• 高可用性是一项要求（您的企业不能容忍几分钟的停机时间）
• 流量是可变的，自动缩放可以通过在安静时段缩小规模来节省成本
• 您需要在不停机的情况下进行部署（跨实例滚动部署）
• 性能要求超出单机容量

---

负载均衡深入探讨

负载均衡器在多个后端服务器之间分配传入流量。负载均衡器的类型决定了可能的路由决策。

L4（传输层）负载平衡

L4 负载均衡器在 TCP/UDP 级别运行。它们根据 IP 地址和端口路由连接，而不检查数据包内容。它们快速、简单，并且可以处理任何基于 TCP 的协议。

最适合： 原始 TCP 分发、数据库连接代理 (PgBouncer)、非 HTTP 协议、极高的吞吐量要求

限制： 无法根据 URL 路径、标头或 cookie 做出路由决策。无法终止 SSL（必须在后端完成）。

L7（应用层）负载均衡

L7 负载均衡器在 HTTP 级别运行。它们检查请求标头、URL、cookie，甚至请求主体来做出路由决策。它们处理 SSL 终止、压缩，并可以修改请求和响应。

最适合： Web 应用程序、API 网关、基于内容的路由、SSL 终止、A/B 测试、金丝雀部署

负载均衡算法

健康检查和优雅降级

健康检查确定后端服务器是否应该接收流量。仔细配置它们：

• 浅度运行状况检查 -- 专用端点上的简单 TCP 连接检查或 HTTP 200。捕获服务器崩溃，但不捕获应用程序级故障。
• 深度健康检查 -- 验证数据库连接、Redis 可用性和外部服务可访问性。捕获更多问题，但如果非关键依赖项关闭，则存在误报风险。
• 宽限期 -- 新实例需要时间预热（JIT 编译、缓存填充）。在负载均衡器发送完整流量之前设置启动宽限期。
• 耗尽 -- 删除实例时，停止发送新请求，但允许完成现有请求（连接耗尽）。通常为 30-60 秒。

---

自动扩展策略

自动扩展可根据需求调整实例数量，将容量与流量相匹配，无需人工干预。

基于指标的扩展

最常见的方法是在指标超过阈值时触发扩展操作。

预测缩放

如果您的流量遵循可预测的模式（每日峰值、每周周期、季节性事件），则预测性扩展会在流量到达之前提供容量。 AWS Auto Scaling 支持预测性扩展，可以从历史模式中学习并主动扩展。

结合预测性和反应性： 对已知模式（早上流量增加、黑色星期五预配置）使用预测性扩展，对意外激增使用反应性扩展。

扩展最佳实践

1. 快速扩展，缓慢扩展 -- 积极添加实例（1-2 分钟冷却时间），但逐渐删除实例（10-15 分钟冷却时间）以避免抖动
2. 使用多个指标 -- 使用触发的第一个指标来扩展 CPU 或内存或请求计数
3. 设置最小和最大限制——防止缩放到零（不可用）或无限期缩放（成本爆炸）
4. 在负载测试期间测试扩展 -- 验证自动扩展是否正确触发以及新实例是否在预期时间范围内提供流量
5. 监控扩展事件 -- 对频繁扩展发出警报以检测配置问题或潜在性能问题

---

数据库扩展策略

数据库不像应用程序服务器那样水平扩展。写操作需要共识，强一致性限制了分发选项。

阅读副本

读取副本从主数据库复制数据并提供读取查询服务。它们线性地扩展读取吞吐量，但对写入吞吐量没有帮助。

实施注意事项：

• 复制滞后 -- 副本最终是一致的。写入后立即查询可能看不到变化。使用主数据库进行先写后读。
• 连接路由 -- 您的应用程序需要逻辑将读取路由到副本并将写入路由到主节点。 ORM 和连接代理（ProxySQL、PgBouncer）可以自动执行此操作。
• 故障转移 -- 如果主数据库发生故障，可以升级副本。自动故障转移（AWS RDS 多可用区、AWS Aurora）将停机时间缩短至几秒。

表分区

对于大型表上的写入密集型工作负载，分区将表划分为更小的物理块，同时维护单个逻辑接口。详细的分区策略，请参阅我们的数据库优化指南。

连接池

创建数据库连接的成本很高，而且数量有限。像 PgBouncer 这样的连接池将来自许多应用程序实例的连接池化为较少数量的数据库连接。

没有池化： 20 个应用程序实例 x 每个 20 个连接 = 400 个数据库连接（可能超出 PostgreSQL 限制）

使用 PgBouncer： 20 个应用程序实例连接到 PgBouncer，它维护与 PostgreSQL 的 50-100 个连接，有效地多路复用请求。

---

微服务分解

当单体变得太大而无法有效地开发和部署单个团队时，微服务分解允许不同组件的独立扩展。

何时分解

不要从微服务开始。从结构良好的整体开始，并在以下情况下分解：

• 不同的组件有截然不同的扩展要求（搜索需要 20 个实例，结账需要 5 个）
• 不同团队需要独立部署，无需协调发布时间表
• 特定组件需要不同的技术堆栈（Python 中的机器学习、Node.js 中的 API）
• 由于代码库大小，单体应用的部署时间超过 30 分钟

首先提取什么

---

常见问题

我如何知道何时需要扩展？

监控四个关键指标：CPU 利用率（始终高于 70%）、内存使用率（高于 80%）、响应时间 P95（高于 SLO）和错误率（高于 0.1%）。当任何指标持续突破其阈值时，您就需要进行扩展。通过警报进行主动监控，可以在用户注意到之前捕获这些趋势。请参阅我们的监控指南。

自动扩展或预配置是否更具成本效益？

对于不可预测的流量，自动扩展更具成本效益，因为您只需在需要时为容量付费。预配置更适合可预测的高峰（黑色星期五、每日高峰），因为自动扩展需要 3-10 分钟来增加容量。最具成本效益的方法将两者结合起来：针对预期峰值进行预先配置，针对意外激增进行自动扩展，并使用预留实例作为基准容量。请参阅我们的云成本优化指南。

我应该使用容器（Docker/Kubernetes）还是传统虚拟机？

容器启动速度更快（秒与分钟），更有效地使用资源（每台主机的密度更高），并在开发和生产过程中提供一致的环境。 Kubernetes 增加了编排（自动扩展、自我修复、滚动部署），但操作复杂性显着增加。在考虑 Kubernetes 之前，先从托管容器服务（AWS ECS、Google Cloud Run）开始。

如何处理数据库故障转移而不丢失数据？

使用同步复制实现零数据丢失故障转移——主数据库在副本确认写入之前不会确认写入。这会增加写入延迟（同一区域内通常为 1-5 毫秒），但可以保证故障转移期间不会丢失数据。 AWS RDS 多可用区和 Aurora 提供具有自动故障转移功能的托管同步复制。

---

下一步是什么

根据您的增长预测评估您当前的基础设施。如果您运行的是单个服务器，请确保您的应用程序是无状态的并准备好进行水平扩展。如果您已经运行多个实例，请优化负载均衡器配置并实施自动扩展策略。

有关完整的性能工程视角，请参阅我们关于扩展您的业务平台 的支柱指南。要在扩展时优化成本，请阅读我们的云成本优化 指南。

ECOSIRE 为 AWS 和多云环境上的业务平台设计和实施可扩展的基础设施。 联系我们的 DevOps 团队 进行基础设施扩展评估。

---

由 ECOSIRE 发布 — 通过 Odoo ERP、Shopify 电子商务 和 OpenClaw AI 等人工智能驱动的解决方案帮助企业扩展规模。