您的应用程序已经成长。之前还睡得很安稳的服务器，现在CPU利用率已经达到了100%。用户抱怨速度缓慢。 [数据库0崩溃。 欢迎来到规模问题。
扩展后端以支持数百万个请求并不是一项简单的任务。它需要从“使其工作”模式转变为“使其执行”模式。 以下是为后端做好准备的架构最佳实践。
1. 数据库：核心（和瓶颈）
[数据库 1 几乎总是第一个崩溃的。
- 索引：检查您的所有查询是否都使用索引。在拥有 100 万行的数据库中进行无索引的搜索（全表扫描）会导致一切停止。
- 缓存（Redis）：不再向银行索取一切。如果信息不是每秒都在变化（例如用户配置文件、类别列表），请将其保存在 Redis（RAM 内存）中。速度快了 100 倍。
- 连接池：打开和关闭与银行的连接的成本很高。使用“池”来保持连接打开和可重用。
2. 异步（不要让用户等待）
如果用户单击“生成 PDF 报告”，并且需要 10 秒，请不要让 HTTP 请求处于打开等待状态。
- 队列：使用 RabbitMQ、Kafka 或 SQS。
- 流程：用户请求报告 -> 后端响应“好的，已注意到”（202 已接受）并将其发送到队列 -> “工作人员”从队列中取出报告，对其进行处理并在准备就绪时通知用户（推送通知/电子邮件）。
3.无状态（无内存）
为了扩展，您需要多个服务器（实例）运行相同的代码。 如果您将用户的会话保存在服务器 A 的内存中，并且下一个请求到达服务器 B，则该用户将被注销。
- 练习：使用 JWT 令牌（状态保留在客户端）或将会话存储在 Redis（共享数据库）上。您的应用程序服务器必须是一次性的。
4.CDN（内容分发网络）
不要从主服务器提供图像、视频和 CSS。 使用 CDN（Cloudflare、AWS CloudFront）。 CDN 将文件的副本存储在遍布世界各地的服务器上。用户从他家附近的服务器下载照片，减轻了他的中央基础设施的负担并加快了加载速度。
5. 监控（可观察性）
你无法修复你看不到的东西。 安装 APM（应用程序性能监控）工具，例如 New Relic 或 Datadog。 确切地知道：
- 哪个端点最慢？
- 哪家银行查询花费的时间最长？
- 错误率是多少（500）？
结论
扩展就是消除瓶颈。这是一款侦探游戏。您找到瓶颈（例如银行），解决它（缓存），然后瓶颈改变位置（例如网络）。保持架构简单、解耦和可观察，你就能在增长中生存下来。
另请阅读
- [应用后端：架构、技术和最佳实践2
- [应用程序后端 - 初创公司的良好实践3
- [GraphQL 应用程序：实施指南4
- [应用中的微服务：移动分布式架构5
- [现代 GraphQL API：架构设计、性能和有效模式6
- [应用程序API - 逐步扩展7