可扩展的Web应用架构：实用设计指南
构建一个在首批百万用户面前崩溃的Web应用，是一种代价高昂且常见的工程失败。核心挑战不仅仅是处理流量，而是设计一个能够随着数据、用户和功能复杂性的增长而优雅演进的系统。本指南提供了一个实用、有据可依的框架，用于如何设计可扩展的Web应用架构，从基本原则到具体实施策略。
你将学到什么
要设计可扩展的架构，优先考虑应用层的无状态性和数据层的分片。最关键的决定是数据库分区策略，因为它最难在后期更改；从单体数据库开始，但要从第一天起就计划采用分片或多语言持久化模型。
1. 不可妥协的基础：无状态与冗余
可扩展架构的首要原则是应用服务器必须是无状态的。如果任何服务器可以随时处理来自任何用户的任何请求，你就可以通过增加更多实例来水平扩展。这是如何设计可扩展的Web应用架构的基石。
正如官方Kubernetes文档所述：“无状态应用是指不跨请求持久化客户端数据的应用。”这种简单性允许简单、可靠的扩展。实现无状态意味着将所有会话数据（如用户认证令牌和购物车内容）从本地服务器内存移出，放入集中式快速数据存储，如Redis或Memcached。
- 行动： 实现中央会话存储。
- 行动： 确保负载均衡器使用轮询或最少连接算法，而不是粘性会话（会话亲和性），后者会重新引入状态。
2. 数据库架构：最难解决的问题
数据库几乎总是成长型应用中的第一个瓶颈。你在此做出的设计选择最为关键，也最难撤销。数据库策略是如何设计可扩展的Web应用架构中最重要的因素。
2.1 数据可扩展性的三大支柱
根据关于大规模系统的同行评审文献（例如来自IEEE Xplore），扩展数据存储的三种主要策略是：
| 策略 | 描述 | 何时使用 | 复杂度 |
|---|---|---|---|
| 复制 | 将数据复制到多个服务器（例如主从）。 | 读密集型工作负载；提高可用性。 | 中等 |
| 分片（分区） | 基于某个键（例如用户ID）将数据拆分到多个数据库。 | 写密集型工作负载；海量数据集。 | 高 |
| 多语言持久化 | 对不同数据类型使用不同数据库（例如PostgreSQL用于用户，Elasticsearch用于搜索）。 | 复杂、多样化的数据需求，单一数据库非最优。 | 非常高 |
⚠️ 关键警告： 分片会引入显著的应用复杂性。 你的应用逻辑必须知道要查询哪个数据库实例。对于选择不当的分片键，没有“撤销”按钮。选择一个不可变的键（例如永远不会改变的
user_id），并且能均匀分布数据和负载。
2.2 实用数据库建议
- 从简单开始，但为分片做计划： 从一个强大的关系型数据库（例如PostgreSQL）开始。抵制过度工程的冲动。正如著名软件架构师Martin Fowler所说：“除非绝对必要，否则不应实施分片。”然而，设计你的数据模型和访问模式，使分片成为未来可行的步骤。
- 积极实施缓存： 在分片之前，实施缓存层（例如Redis）以卸载读取流量。配置良好的缓存可以将数据库负载减少高达90%。
- 考虑“命令查询职责分离”（CQRS）： 对于复杂应用，考虑将读取和写入的数据模型分离。这允许你独立优化两者，但会引入显著复杂性。
基于[复制]和[CQRS]，一个合理的结论是混合策略通常最佳：一个用于写入的单一事实来源和一组只读副本，结合一个针对搜索优化的数据存储用于复杂查询。
3. API层：为解耦而设计
你的API是应用的接口。设计不良的API会强制产生不必要的依赖关系，并使扩展复杂化。目标是松散耦合，使内部更改不影响外部客户端。
- 拥抱RESTful原则或GraphQL： REST强调资源和HTTP动词，创建可预测的端点。GraphQL虽然更复杂，但允许客户端精确请求所需数据，减少过度获取。选择取决于前端复杂性。
- 对API进行版本控制： 从第一天起就对API进行版本控制（例如
/api/v1/users）。这允许你在不影响现有客户端的情况下进行破坏性更改。在任何关于如何设计可扩展的Web应用架构的成熟指南中，版本控制都是不可协商的实践。 - 实施速率限制： 速率限制保护你的应用免受拒绝服务（DoS）攻击和个别行为不当的客户端的影响。Nginx和API网关提供了强大的速率限制模块。
4. 消息传递与异步处理
并非每个请求都需要立即响应。对于耗时或资源密集型任务，使用消息队列（例如RabbitMQ、Apache Kafka）。这是从请求/响应模型到事件驱动模型的根本转变。
- 解耦服务： Web请求只需将任务（例如“send_welcome_email”）发布到队列并返回“202 Accepted”状态。单独的工作者服务消费任务并处理它。
- 提高弹性和可扩展性： 工作者可以独立于Web服务器进行扩展，如果它失败，任务会保留在队列中。
- 用例： 图像处理、发送电子邮件、生成报告、数据同步。
5. 可观测性：监控、日志和追踪
你无法扩展你无法测量的东西。可观测性是从系统外部输出理解其内部状态的实践。
- 指标： 收集关键性能指标（KPI），如请求延迟、错误率、吞吐量和资源利用率（CPU、内存）。Prometheus和Grafana等工具是行业标准。
- 结构化日志： 以机器可读格式（如JSON）记录日志。这允许集中化和强大的查询。避免在没有严格控制的情况下记录个人身份信息（PII）。
- 分布式追踪： 对于微服务，单个请求可能穿越多个服务。分布式追踪系统（如Jaeger）让你看到端到端路径并定位瓶颈。
基于[指标]和[分布式追踪]，一个合理的结论是，从一开始就投资于强大的可观测性栈（而不是事后改造）可以在事件期间节省一个数量级的时间。
6. 分步指南：可扩展的演进路线图
如何设计可扩展的Web应用架构不是一个单一状态，而是一个旅程。以下是分阶段方法：
- 阶段1：单体（0-1000用户）。 保持简单。使用单个Web服务器和单个数据库。优化代码和查询。
- 阶段2：垂直和水平扩展（1000 - 100,000用户）。 迁移到更强大的服务器（垂直）。然后，实施负载均衡器和多个无状态Web服务器（水平）。为数据库添加缓存层。
- 阶段3：数据分离（100,000 - 1,000,000用户）。 为数据库实施只读副本以卸载读取查询。考虑将文件存储迁移到CDN。
- 阶段4：微服务和分片（1,000,000+用户）。 开始将单体应用分解为有界上下文（微服务）。此时考虑数据库分片和多语言持久化。
这种分阶段方法是回答如何设计可扩展的Web应用架构而不过早过度工程的实用答案。
常见问题解答
“可扩展性”与“性能”有何不同？
性能是关于单个请求的速度（例如200ms响应时间）。可扩展性是系统在负载增加时保持该性能的能力（例如以每个200ms的速度服务100万用户）。系统可以快速但不可扩展，反之亦然。
“无服务器”架构总是最可扩展的选择吗？
无服务器平台自动扩展，这是一个主要优势。然而，它们可能引入延迟（冷启动），并且在非常高、持续的吞吐量下，由于按请求计费模型，可能会变得出奇地昂贵。它非常适合事件驱动和零星工作负载。
工程师在扩展时犯的最大错误是什么？
最大的错误是过早优化（试图为初创公司构建Google规模的系统），以及相反地，将关键架构决策推迟到几乎无法更改的时候。具体来说，数据分片是一个当系统上线时无法快速做出的架构决策。
如何为数据库选择分片键？
一个好的分片键是不可变的（永不改变）、具有高基数（大量潜在值）并且能在服务器之间均匀分布数据。一个常见的例子是user_id。选择导致“热点”的键（例如地理位置）会造成性能瓶颈。
每个可扩展系统都需要微服务架构吗？
不。一个结构良好的模块化单体对于许多大型应用来说可能已经足够，而且开发、部署和调试要简单得多。微服务会引入显著的操作开销。只有当管理单一代码库的团队复杂性超过管理分布式系统的复杂性时，才采用微服务。
— Editorial Team
暂无评论。