Scalable software architecture as an engineering decision tree

什么是可扩展的？

两句话定义：可扩展性是系统在增加工作负载的同时满足操作约束（延迟、吞吐量和成本）的能力，可以通过添加或重新分配资源而无需进行重大重新设计来实现。工程师设计可扩展性，以便系统可以在保持服务级别目标和运营商运行手册的同时增长（或缩小）。

关于可衡量结果的快速说明：在选择模式之前，选择直接映射到您的SLA的指标：吞吐量（req/s）、p99延迟或每次事务的成本（或每个租户的成本）。该选择决定了您是否偏好水平扩展、垂直扩展、分片或区域/域分区。

片段（40-55个字）：“可扩展系统通过添加资源或分区工作来维持服务级别目标，当负载增长时。工程师根据延迟、隔离和成本目标选择水平扩展、分片或区域/域架构；正确的指标（吞吐量、p99延迟、每租户成本）必须驱动决策。”

针对平台和后端团队的实用框架：将“可扩展”视为一个工程决策树，而不是一个单一的属性。从您必须保护的SLA指标开始。如果p99延迟在突发情况下是您的约束，则偏好共置服务、有界扇出和快速的水平自动扩缩，具有保守的并发限制。如果总吞吐量和成本驱动决策，则偏好分片或分区工作负载，以便您可以有效地批处理和多路复用资源。如果租户隔离和爆炸半径是主要的，则采用域/区域边界，将租户映射到单独的计算、存储和可观察性流中。

您可以在设计会议中使用的具体结果映射：

- 延迟敏感API（p99目标）：最小化跨AZ/网络跳数；偏好水平扩展，具有紧密的资源预留和电路断路器。- 高吞吐量摄取：通过密钥分片（分片），以便每个分片可以独立批处理、压缩或应用反压。- 成本优化的多租户服务：将软多租户与每租户节流和计费指标相结合；当成本/延迟需求分散时，将重租户移到专用区域。- 操作可观察性和可靠性：确保每个扩展模式保留跟踪、指标基数限制和混沌/规模测试的测试套件。

使用此定义和映射来驱动设计审查中的架构权衡表：列出SLA指标、首选扩展模式、预期操作任务（自动扩缩调优、分片重新平衡、租户迁移）以及在模式被执行时保证SLA的运行手册步骤。

可扩展性有什么用途？

可扩展系统的设计目的是在负载、租户、数据量或功能复杂性增长时保持关键的操作结果。实际上，团队使用可扩展性模式来保护四个以买家为中心的结果：延迟（用户体验）、吞吐量（容量）、成本（单位经济学）和隔离/合规（租户保证）。下面是常见的生产使用案例、映射到要保护的主要指标，以及可以立即应用的单一战术模式。

常见使用案例和结果

- 面向消费者的API，具有流量激增：主要指标——尾部延迟。模式——自动扩缩的无状态前端，后面是请求限制和电路断路器；与限速的客户端SDK和边缘的令牌桶配对。- 多租户SaaS，需要隔离和公平计费：主要指标——租户隔离和成本归属。模式——分区租赁：逻辑租赁（架构或行）用于密度；隔离租赁（每个租户计算或节点）在性能SLA或监管分离需要时使用，加上每个租户的成本计量表在遥测中。- 分析管道，具有可变的摄取：主要指标——吞吐量和处理延迟。模式——解耦摄取和处理，使用持久队列（例如Kafka、SQS）和自动扩缩的消费者组，扩缩基于延迟，而不仅仅是CPU。- LLM流媒体和实时推理：主要指标——尾部延迟和流媒体可观察性。模式——背压感知管道（异步流+连接池）和令牌级别的跟踪，因此可以将基础设施事件关联到模型延迟。

映射示例——真正的选择，立即的后果

- 公共API，具有不可预测的流量→自动扩缩的无状态服务+限制。后果：降低尾部延迟，但提高成本变异性；执行限制以限制成本并保护下游系统。- 多租户分析→分区存储+每个租户保留+成本归属。后果：减少跨租户IO干扰，并支持每个租户的合规性；增加碎片管理工作。- 流媒体LLM响应→背压+实时可观察性。后果：保护尾部延迟需要端到端的流控制和令牌级别的跟踪；没有它们，隐藏的队列将破坏SLO，尽管有良好的聚合指标。

检查清单结果——保护此指标，应用此模式

- 延迟（用户面向API）：自动扩缩+边缘限制+电路断路器。- 吞吐量（摄取/分析）：持久队列和基于延迟扩缩的消费者。- 成本（单位经济学）：每个租户的计量表和分层隔离（共享→专用）。- 合规性/数据保留：根据保留策略对存储进行分区，并使用审计日志自动化保留安全删除。

可行的下一步：选择产品中的一个高优先级的使用案例，确定上述单一的主要指标，并在具有合成激增测试和SLO驱动的运行手册（阈值、警报、升级路径）的暂存环境中实现匹配的模式。

可扩展性是如何工作的？

可扩展性是通过一组工程模式来实现的，这些模式改变了您添加容量的位置、如何分割数据和工作，以及哪些平台组件协调该容量。以下是您需要将每个选择映射到具体的操作结果的机制、权衡和平台组件：成本、延迟、可观察性、测试可靠性和租户隔离。

机制和权衡：水平扩展与垂直扩展

水平扩展（添加实例）可以提高并发性和故障隔离；垂直扩展（更大的实例）可以减少单线程瓶颈的延迟。

- 预配时间：水平自动扩展通常需要实例启动和预热（取决于图像/JIT的秒数至分钟数）；垂直更改通常需要实例替换或计划的调整窗口，并且对于弹性来说速度较慢。- 故障爆炸半径：许多小节点可以减少爆炸半径；少量的大节点会集中风险并使滚动升级复杂化。- 自动扩展粒度和成本：水平扩展可以让您以更细的步骤（Pod）进行扩展，并使用实例；垂直扩展通常会浪费头部空间并产生更粗的计费步骤。

分区策略：分片与多区域/区域分割

分区可以隔离负载和状态。选择您关心的操作结果：

- 根据租户/用户/键进行分片：隔离噪音租户并启用每个分片的模式迁移；权衡包括复杂的跨分片事务和操作重新分片工作，这些工作必须被脚本化、测试并由运行手册覆盖。- 多区域或区域分割：减少延迟并提供区域故障容忍。主动-主动复制增加成本并需要冲突解决和区域故障转移运行手册。

所需的平台组件

- 编排：Kubernetes或托管的自动扩展组用于水平弹性；节点池用于混合实例大小；Pod中断预算用于安全升级。- 服务发现和速率限制：保持端点可路由并在突发期间保护下游系统。- 分布式缓存和消息队列：缓存减少数据库负载；队列平滑突发并在运行手册中启用重试/退避逻辑。- 可观察性：跟踪、P99关注的指标、日志和流式遥测。将租户标签记录到跟踪中，以便运行手册可以将事件映射到租户隔离操作。

微型计算清单：为P99延迟目标建模节点

- 1）测量稳态请求成本：在代表性负载下捕获每个请求的CPU毫秒、内存和I/O（在P50和P99下）。- 2）定义流量配置文件：预期的每秒请求数、突发因子（例如，2x峰值）和可接受的队列延迟。- 3）选择实例大小并估计系统开销后每个节点的可用CPU毫秒/秒。- 4）计算所需的节点数=ceil（（每秒请求数*每个请求的CPU毫秒*突发因子）/每个节点的CPU毫秒）。使用P99 CPU毫秒来捕获尾部工作；为自动扩展滞后和噪音邻居添加安全边际（25-50%）。- 5）使用针对P95/P99的负载测试进行验证：渐进式坡道、缓存失效练习和确认自动扩展行为在扩大和缩小时。

将每个选择映射到运行手册操作：水平缩放事件→验证自动扩展触发、排水/封锁、验证滚动替换；分片重新平衡→检查点、迁移键、验证一致性；区域故障转移→转移DNS/边缘路由、验证仲裁。这些结果——成本、延迟、可观察性、测试可靠性和租户隔离——应该是选择生产系统缩放模式的主要轴。

何时选择可扩展架构？

当生产信号和业务约束映射到可衡量的运营结果（成本、延迟、隔离、可观察性、测试可靠性）时，选择可扩展的架构。如果您可以回答“负载增长速度如何？”，“p99 SLA 有多严格？”，以及“存在哪些租户隔离或合规需求？”，则选择最小化这些结果的运营麻烦的模式。

决策标准和生产信号

-增长概况：稳定的增长有利于容量规划和垂直右侧调整；不可预测的峰值有利于水平扩展、自动缩放和限制。- SLA 严格性：严格的 p99 延迟推动分区、相关数据的同位置和预热实例；宽松的延迟允许批处理、排队或最终一致性以节省成本。-租户模型：单租户系统可以优化每个客户的堆栈；多租户平台必须根据合规性和爆炸半径需求权衡逻辑隔离与物理隔离。-成本敏感度：如果单位成本至关重要，首选高效的打包和垂直缩放以处理可预测的负载；如果停机成本高于基础设施成本，首选冗余和水平扩展。-事务模式：重大的跨实体事务表明要么同位置相关分区，要么重新设计工作流以减少分布式事务。

具体决策树（实际映射到结果）

-严格的 p99 +不可预测的峰值 → 水平扩展 + 自动缩放 + 电路断路器。结果：保留延迟 SLO，以更大的编排和预热管理为代价。-多租户系统具有合规性/审计需求 → 逻辑或物理租户隔离 + 每个租户的保留和审计跟踪。结果：降低审计风险和爆炸半径；增加运营和许可成本。-重大的跨实体事务 → 相关分区的同位置或根据亲和力进行分片。结果：降低分布式事务延迟和故障模式；使重新平衡更加复杂。-可预测、缓慢增长的负载 + 严格的成本目标 → 垂直扩展和实例右侧调整。结果：降低成本，但单节点风险更高；需要强大的容量测试。

采用模式之前的运营准备清单

-自动化的 CI/CD，具有基础设施即代码和测试回滚。-金丝雀和渐进式部署，以验证生产流量上的扩展行为。-定义的 SLO/SLA（包括 p50/p95/p99）和与发布门控相关的错误预算政策。-用于扩展事件的运行手册：如何添加容量、卸载和恢复一致性，附带剧本所有者。-模拟现实峰值形状、租户混合和故障模式的容量测试；包括可观察性 KPI（请求队列长度、GC 暂停时间、尾延迟）。

决策是权衡练习：将每个选项映射到您关心的运营结果，然后在全面的推出之前使用容量测试和金丝雀窗口进行验证。

它与类似术语有什么不同?

可扩展性经常与弹性、可用性和性能混淆。实际差异：

- 可扩展性：系统如何通过架构选择（分片、水平扩展）来容忍随时间增长的工作负载。 - 弹性：容量可以如何快速改变以适应短期负载（自动扩展器、快速实例启动）。 - 可用性：服务可达到的概率（冗余、故障转移）。 - 性能：在给定负载下延迟或吞吐量。

将这些视为单独的工程问题，以将它们映射到不同的控制、运行手册任务和SLA结果。

可扩展性与弹性

可扩展性是一种设计属性，允许您在不进行重大重新设计的情况下添加容量。弹性是在可扩展设计之上实现的运行时行为。如果系统是可扩展的但不弹性，它可以处理长期增长，但会难以应对突然的峰值；如果弹性但不具有架构可扩展性，自动扩展将变得昂贵和脆弱，因为状态和负载模式的增长。

可扩展性与可用性

可用性通过冗余、运行健康检查和故障转移来实现正常运行时间。可扩展性以容量增长为目标。即使具有高度可扩展性，如果缺乏冗余或具有单点故障协调组件，系统也可能不可用。为每个问题单独创建运行手册和测试。

可扩展性与性能

性能工程优化了当前负载下的延迟（配置文件、缓存、更快的I/O）。可扩展性衡量这些延迟如何随着负载的增长而变化。通过代码和缓存改进性能；通过分区、并行性和解耦来改进可扩展性。

实际映射：快速清单

- 需要平滑的成本增长和长期容量：优先考虑可扩展性——水平扩展、分片、无状态工作者。 - 需要用最小的运营来处理突然的峰值：添加弹性——快速自动扩展器、短启动时间、短暂池。 - 以正常运行时间为首要的SLA：投资于可用性——复制、运行健康检查、多区域故障转移、事件运行手册。 - 以延迟为首要的SLA：关注性能——配置文件、缓存、资源隔离和SLO驱动测试。

常见问题

如何在有状态 API 中选择水平和垂直缩放?

当单进程有状态工作负载受益于更多内存/CPU，并且需要简单的一致性时，选择垂直缩放（更大的实例）；预计会有更高的边际成本和更大的故障范围。选择水平缩放时，可以分区状态（分片或粘性会话）或使用无状态前端；这可以提高可用性和故障隔离，但需要路由、发现和跨实例协调。将选择与 SLA 绑定：如果 99th 百分位延迟由 GC 暂停主导，垂直缩放可以成为短期解决方案；对于可用性和运营韧性，首选水平缩放加上明确的分区规则。

当您分片数据时，哪些运营结果会发生变化?

分片减少了每个节点的负载，并且可以降低尾部延迟，但它增加了运营工作：重新平衡分片、路由逻辑、跨分片事务以及更大的测试矩阵。预计会有用于分割/合并迁移的运行手册条目、用于监测分片偏差的监控以及验证跨分片一致性的合成测试。分片可以在租户映射到分片时提高租户隔离，但仅当您在编排中包含每个分片的配额和断路器时才会发生这种情况。

分区（多区或多区域）如何影响可观察性和成本?

分区可以提高故障隔离并降低用户延迟，但它会增加可观察性表面：您需要带有分区标签的聚合跟踪和指标、每个分区的合成测试以及自动故障转移手册。成本会增加，因为区域资源被复制，且跨分区流量会增加；在 SLA 收益和运行成本以及数据驻留要求之间取得平衡。使用分区感知的警报阈值，以避免在计划分区故障转移期间发出噪音报警。

何时应该重构服务边界以实现可扩展性?

当服务的缩放配置文件与其同行（例如，读取密集型端点会膨胀计算或导致噪音邻居）发生偏差时，重构边界。将功能移动到单独的服务中，以减少耦合、实现独立部署并允许定制存储/缓存。每次重构都需要更新的 CI 测试、合同/版本控制策略以及 SLO 迁移计划，以在更改期间保持可靠性。

什么快速检查可以验证架构是否真正可扩展?

运行四项检查：（1）您可以在不更改代码的情况下添加容量吗？（2）故障模式是否隔离到小的故障范围？（3）遥测和合成测试是否在负载下显示线性或亚线性退化？（4）运营任务（部署、回滚、恢复）是否自动化并记录在运行手册中？如果任何答案为否，则设计需要更改 - 通常是在编排、可观察性或服务边界中 - 然后再宣布它为生产可扩展。

来源

- 维基百科：可扩展性 - 汽车IQ：域vs区域架构（新闻源） - EE Times：芯片架构（新闻源） - Designboom：八度（新闻源） - HackerNoon：人工智能和工程师（新闻源） - 沙漠太阳报：JPLoft（新闻源） - TNGlobal：FPT扩展（新闻源）