神话
所有 API 从一开始就必须设计成高吞吐量的。
现实
大多数 API 的流量都不会达到很高的水平。为了应对实际并不需要的规模而进行扩展，只会浪费工程时间和金钱。应该从简单的架构开始，只有当指标证明值得投入时才进行扩展。过早优化是导致系统过度设计的最常见原因之一。
云基础设施API设计分布式系统缩放表现
高吞吐量服务系统与低流量 API
高吞吐量服务系统能够以毫秒级的延迟处理海量请求，为推荐引擎和广告平台提供强大支持。低流量 API 则服务于用户群体较小的场景，在这些场景中，简洁性、成本效益和易于维护比单纯的规模更为重要。
亮点
- 高吞吐量系统每秒处理数百万个请求，而低流量 API 每天处理数百到数千个请求。
- 延迟预期差异巨大，从 50 毫秒以下到 100 毫秒，再到几秒不等。
- 基础设施的复杂程度从全球分布式集群到单个小型服务器不等。
- 运营成本可能从每月数百万美元到低流量服务的不到五十美元不等。
高吞吐量服务系统是什么？
分布式基础设施，旨在以低延迟和高可靠性每秒处理数百万个请求。
- 像谷歌的 TensorFlow Serving 和 Meta 的 TAO 这样的系统每秒可以处理数十万到数百万个查询。
- 他们通常使用分片、复制和缓存层将负载分配到数千台机器上。
- 生产环境部署的延迟目标通常低于 50 毫秒（第 99 个百分位）。
- 常见的实现方式依赖于 gRPC、自定义 RPC 框架或优化的 HTTP/2 协议来实现快速通信。
- 它们为搜索排名、信息流个性化、欺诈检测和实时竞价等应用场景提供支持。
低流量 API是什么？
轻量级 API 服务，专为适中的请求量而构建，优先考虑简洁性和低运营开销。
- 大多数内部工具、管理仪表板和 B2B 集成都属于这一类，处理每分钟几个请求到每天几千个请求不等。
- 它们通常运行在单个服务器或小型容器集群上，无需复杂的分片。
- 由于 Flask、Express、FastAPI 或 Spring Boot 等框架简单易用且开发者熟悉，因此被广泛使用。
- 延迟要求通常比较宽松，可接受的响应时间范围从 100 毫秒到几秒不等。
- 成本优化比原始性能更重要，通常运行在无服务器平台或配置较低的云实例上。
比较表
| 功能 | 高吞吐量服务系统 | 低流量 API |
|---|---|---|
| 典型请求量 | 每秒数百万 | 每天成百上千人 |
| 延迟目标（p99） | 小于 50 毫秒 | 100毫秒到几秒 |
| 基础设施复杂性 | 高（分片、复制集群） | 低（单服务器或小型集群） |
| 通用协议 | gRPC、自定义 RPC、HTTP/2 | 基于 HTTP/1.1 的 REST、GraphQL |
| 缓存要求 | 必备（Redis、Memcached、内存缓存） | 可选或最低限度 |
| 运营成本 | 高（数千台服务器） | 低（单虚拟机或无服务器） |
| 典型应用案例 | 搜索、广告、推荐、排名 | 内部工具、管理面板、B2B集成 |
| 扩展方法 | 水平方向，具备自动伸缩和负载均衡功能 | 垂直缩放或手动水平缩放 |
| 容错性 | 多区域冗余，优雅降级 | 单点故障通常是可以接受的 |
详细对比
规模和绩效要求
高吞吐量服务系统旨在应对极高的规模，通常每秒可处理数百万个请求，这些请求分布在全球各地的集群上。低流量 API 则处于截然相反的极端，单个编写良好的服务即可轻松处理全部工作负载。两者之间的性能差距是以数量级来衡量的，而非百分比。
基础设施和架构
大规模服务系统依赖于复杂的架构，包括模型分片、特征存储和多层缓存，以保持较低的响应时间。低流量 API 通常运行在简单的单体或微服务架构上，无需专门的数据管道。两者所需的工程投入截然不同，高吞吐量系统通常需要专门的平台团队。
成本和资源效率
考虑到计算、内存和网络方面的要求，运行高吞吐量服务系统每月可能耗资数十万甚至数百万美元。而低流量 API 在基础云基础设施或无服务器平台上每月运行成本通常不到 50 美元。对于没有大规模需求的组织而言，投资高吞吐量基础设施既浪费又不划算。
开发和维护
构建高吞吐量服务系统需要分布式系统、性能优化和容量规划方面的专业知识。团队会花费大量时间进行负载测试、性能分析和调优。而低流量 API 则可以使用标准框架由单个开发人员构建和维护，这样可以将大部分精力投入到业务逻辑而非基础设施方面。
可靠性和故障处理
高吞吐量系统必须具备应对部分故障的能力，例如采用断路器、回退机制和多区域故障转移等措施，以防止级联故障。即使是短暂的性能下降也可能影响数百万用户，造成巨大的经济损失。低流量 API 则可以采用更简单的可靠性模型，因为停机影响的用户较少，对业务的影响通常也有限。
每种方法何时适用
选择哪种架构完全取决于流量模式和业务需求。当延迟、规模和可靠性直接影响大规模收入时，高吞吐量服务系统至关重要。而当服务于内部用户、小众群体或B2B客户时，低流量API才是更合适的选择，因为在这些情况下，简洁性和成本比性能更为重要。
优点与缺点
高吞吐量服务系统
优点
- + 处理大规模
- + 延迟低于 50 毫秒
- + 高可靠性
- + 支持全球用户
- + 优化缓存
继续
- − 运营成本高
- − 复杂建筑
- − 需要专门的人才
- − 更长的开发周期
低流量 API
优点
- + 运营成本低
- + 易于建造
- + 易于维护
- + 快速发展
- + 灵活的托管选项
继续
- − 可扩展性有限
- − 相对延迟较高
- − 单点故障
- − 不适合生长
常见误解
神话
低流量 API 不需要监控或可观测性。
现实
即使是低流量服务也能从基本的日志记录、错误跟踪和正常运行时间监控中获益。无论规模大小，一旦出现故障，都需要快速知晓。可观测性关乎可靠性，而不仅仅是性能。
神话
对于单个用户而言，高吞吐量系统总是更快。
现实
速度取决于架构、缓存和距离，而不仅仅是吞吐量。精心设计的低流量 API 对用户来说可能比调优不佳的高吞吐量系统更快。吞吐量衡量的是容量，而非用户体验。
神话
无服务器平台无法处理高吞吐量工作负载。
现实
诸如 Cloudflare Workers、AWS Lambda 和 Vercel Edge Functions 等现代无服务器和边缘计算平台可以处理数百万个请求。高吞吐量和低流量之间的区别越来越取决于架构选择，而非托管模式。
神话
以后可以轻松地将低流量 API 转换为高吞吐量系统。
现实
要使简单的 API 能够大规模扩展，通常需要重写核心组件、添加缓存层并重新设计数据访问模式。在数据建模和无状态设计中预留潜在增长空间固然有所帮助，但真正的规模化需要尽早做出架构决策。
常见问题解答
什么样的系统才算得上是高吞吐量服务系统？
高吞吐量服务系统通常每秒处理数万到数百万个请求，并且对延迟有严格的要求，通常第 99 个百分位延迟低于 100 毫秒。例如，谷歌、Meta 和亚马逊等公司的广告投放平台、搜索引擎和推荐系统都属于此类。
每天多少请求才算低流量？
虽然没有严格的定义，但通常来说，每天处理请求量低于 10 万次的 API 被认为是低流量的。许多内部工具和 B2B 集成远低于这个阈值，有时每天只有几百个请求。
低流量 API 能否扩展到高吞吐量？
是的，但这通常需要大量的重构。无状态设计、高效的数据库查询和合理的缓存机制使得扩展更容易。然而，要达到每秒数百万次的请求处理能力，通常需要分布式系统方面的专业知识和基础设施投入，而不仅仅是简单的代码修改。
哪些框架最适合低流量 API？
常用的框架包括 Python 的 Flask 和 FastAPI、Node.js 的 Express 和 NestJS、Java 的 Spring Boot 以及 Go 的 Gin 或 Echo。这些框架优先考虑开发者的效率和易用性，而非极致的性能，因此非常适合低流量的工作负载。
高吞吐量系统如何实现低延迟？
它们结合了多种技术：内存缓存、跨机器模型分片、预计算结果、优化的序列化（例如 Protocol Buffers）以及计算与数据共置。像 Google 和 Meta 这样的公司在定制硬件和网络方面投入巨资，以缩短响应时间，哪怕只有几毫秒。
无服务器架构是否适用于高吞吐量 API？
现代无服务器平台能够处理海量流量，尤其适用于边缘计算服务。然而，在极高规模下，冷启动、执行时间限制和按请求计费等问题可能会变得棘手。许多公司会选择无服务器平台来处理中等流量，而对于流量最大的服务则切换到专用基础设施。
高通量系统最大的成本驱动因素是什么？
计算资源、内存、网络带宽和存储是成本的主要组成部分。高吞吐量系统通常需要数千台机器全天候运行，再加上维护这些机器的工程师的薪资。一个大型服务器系统每月可能耗资数百万美元。
低流量API需要负载均衡吗？
通常情况下，基础部署不需要负载均衡。单台服务器就能轻松应对大多数低流量工作负载。只有当需要高可用性或单台机器的性能接近极限时，负载均衡才显得尤为重要，而这种情况在低流量服务中并不常见。
缓存分别在各种系统类型中扮演什么角色？
缓存对于高吞吐量系统至关重要，通常采用多层策略，并使用 Redis 或 Memcached 等内存缓存。对于低流量 API，缓存是可选的，通常仅限于简单的 HTTP 缓存头或在需要时进行基本的应用级缓存。
如何决定采用哪种架构？
首先要估算实际流量、延迟要求和预算。如果你的服务用户数以百万计，且对延迟要求非常严格，那么就应该投资高吞吐量的基础设施。如果你只是构建内部工具或服务于小规模的客户群，那么使用标准的 API 框架保持简单，仅在指标需要时才进行扩展。
裁决
当您需要以互联网规模运行，并为数百万用户提供始终低于 50 毫秒的稳定延迟，同时能够接受其运维复杂性和成本时，请选择高吞吐量服务系统。对于内部工具、小用户群或 B2B 集成等场景，如果简单易用、成本低廉和快速开发比单纯的性能更重要，则应选择低流量 API。
相关比较
AI编排系统与独立模型的使用
AI编排系统通过统一的框架协调多个模型、工具和数据管道，而独立模型的使用方式则是直接调用单个AI模型来完成每个任务。组织通常会根据复杂性、规模以及对多步骤自动化的需求来选择合适的方案。
AWS 与 Google Cloud 对比
该比较通过分析亚马逊云科技（Amazon Web Services）和谷歌云（Google Cloud）的服务产品、定价模式、全球基础设施、性能、开发者体验以及理想应用场景，帮助企业选择最符合其技术和业务需求的云平台。
Docker 与虚拟机
该对比通过分析 Docker 容器和虚拟机在架构、资源使用、性能、隔离性、可扩展性以及常见使用场景方面的差异，帮助团队决定哪种虚拟化方案最适合现代开发和基础设施需求。
Kafka 和 Flink 与内存处理对比
Kafka 和 Flink 构成了一个分布式流处理生态系统，用于实时数据管道，而内存处理则通过将数据完全保存在 RAM 中来加速分析——它们各自满足速度、规模和持久性方面不同的架构需求。
MLOps 流水线与传统软件 CI/CD 的比较
MLOps 流水线扩展了传统的 CI/CD 流程，增加了专为机器学习工作流程定制的模型训练、验证和监控阶段。传统的 CI/CD 侧重于代码部署，而 MLOps 则负责处理整个机器学习生命周期中的数据版本控制、实验跟踪和模型漂移检测。