构建可扩展系统的 8 个必知策略

科技   2024-12-11 23:19   北京  

价值 5000 亿美元的电子商务平台、全球叫车服务和全球最受欢迎的流媒体服务有什么共同点?

它是构建可扩展系统的核心能力。

这种扩展能力可确保您的系统能够处理增加的负载,而不会牺牲性能或用户体验。当然,并非每个系统都需要亚马逊、Uber 或 Netflix 的规模。但扩展策略仍然有帮助。

以下是构建可扩展系统的八个必须了解的策略:

1 -无状态服务

无状态服务是指在请求之间不保留客户端会话信息的服务。每个请求都包含服务器处理该请求所需的所有信息。

无状态架构使扩展变得更加容易,因为它允许服务器互换并降低了管理状态的复杂性。

为什么重要:

  • 易于扩展:无状态服务可以轻松地在多台服务器上复制。

  • 容错:如果服务器出现故障,请求可以被重定向到另一台服务器而不会丢失会话数据。


实施提示:

使用 JSON Web Tokens (JWT) 之类的令牌将会话数据存储在客户端而不是服务器。

对于需要状态的操作(例如购物车会话),考虑将状态管理外部化到数据库或缓存层,如 Redis。

2 -水平扩展

水平扩展或“横向扩展”涉及添加更多服务器以分担负载。与涉及升级硬件的垂直扩展不同,水平扩展更具成本效益,并提供更好的容错能力。

为什么重要:

  • 冗余:多台服务器减少单点故障的影响。

  • 可扩展性:只需添加更多服务器即可处理更大的工作负载。


实施提示:

确保您的系统支持分布式工作负载。Kubernetes 等工具可以帮助管理跨多个节点的容器化应用程序。

使用无状态服务来简化水平扩展,因为每个服务器都可以独立处理请求。

3 -负载均衡

载平衡涉及在多台服务器上均匀分配传入请求。负载平衡器充当中间人,确保没有任何一台服务器不堪重负。

为什么重要:

  • 性能:通过均匀分散流量来防止过载。

  • 高可用性:发生故障时自动将流量重定向到健康的服务器。


实施提示:

使用硬件或软件负载均衡器,如 NGINX、HAProxy 或 AWS Elastic Load Balancer。

实施健康检查以确保负载均衡器只向正常运行的服务器发送请求。

谨慎配置粘性会话,因为它们可能会引入状态并降低灵活性。

4 -自动缩放

自动扩展可根据实时流量动态调整服务器或资源的数量。它可确保您不会在非高峰时段配置过多,也不会在流量高峰时段配置不足。

为什么重要:

  • 成本效益:当需求减少时自动缩减资源,节省成本。

  • 流量管理:无需人工干预即可处理意外的流量激增。


实施提示:

使用提供内置自动扩展工具的 AWS、Azure 或 Google Cloud 等云提供商。

根据 CPU 使用率、内存或请求延迟设置明确的扩大和缩小阈值。

5 -缓存

缓存是指将经常访问的数据存放在离用户更近的地方或内存系统中,以减少数据库的负载。适当的缓存可以显著提高系统性能和可扩展性。

为什么重要:

  • 减少数据库负载:通过从缓存提供重复查询,您可以减少数据库的负载。

  • 提高速度:检索缓存数据的速度比从数据库获取数据的速度快得多。


实施提示:

使用 Redis、Memcached 或 Varnish 等缓存工具。

实现不同的缓存层:

数据库缓存:缓存查询结果以避免重新计算它们。

应用程序缓存:将数据存储在内存中以便快速访问。

内容分发网络 (CDN) :缓存靠近用户的静态资产,如图像和脚本。

设置适当的过期时间以确保缓存的数据保持最新。

6 -数据库复制

数据库复制涉及在不同节点上创建数据库的多个副本。这些副本可以处理读取请求,从而提高性能和冗余度。

为什么重要

  • 可扩展读取:多个副本可以处理读取繁重的工作负载,而不会影响主数据库。

  • 容错:在主数据库发生故障时提供备份节点。


实施提示:

使用支持复制的数据库系统,例如 PostgreSQL、MySQL 或 MongoDB。

使用异步复制可以获得更好的性能,但要注意最终的一致性问题。

设计您的应用程序以区分读取和写入查询,将读取发送到副本并将写入发送到主节点。

7 -数据库分片

分片是将数据库划分为更小、更易于管理的部分(称为分片)的过程。每个分片包含一部分数据并独立运行。

为什么重要:

  • 可扩展写入:通过分发数据,您可以减少争用并提高写入性能。

  • 高可用性:分片可以分布在不同的区域,以实现更好的容错能力。


实施提示:

使用一致性哈希或基于范围的分片来有效地分配数据。

仔细规划您的分片策略,因为以后重新分片数据可能会很有挑战性。

监控分片性能并确保均衡分布以避免热点。

8 -异步处理

异步处理将资源密集型任务(例如发送电子邮件或生成报告)移至后台工作程序。这使系统无需等待这些任务完成即可处理新请求。

为什么重要:

  • 提高响应能力:用户不必等待任务完成后才收到响应。

  • 可扩展性:后台工作者可以独立扩展来处理任务队列。


实施提示:

使用 RabbitMQ、Kafka 或 AWS SQS 等消息队列来管理任务队列。

实施重试机制来处理后台任务中的失败。

优先考虑任务的幂等性,以确保它们可以安全地重试而不会重复。

那么——您还会将哪些其他策略添加到以上列表中?

作者:聆听音乐的鱼

相关阅读:

21CTO
21CTO(21CTO.com),开发者的学习与服务平台。提供高品质文章、课程与训练营、招聘等产品。
 最新文章