每一次点击背后：理解 Client–Server Architecture

Source: Dev.to

Introduction

客户端‑服务器架构是现代应用开发中最基础的模型之一。

• Client – 发起请求的用户或应用程序
• Server – 处理请求并返回响应的机器

当用户想要访问服务器时，最简单的方法是 ping 服务器的 IP 地址。然而，IP 地址难以记忆，使得直接访问不切实际。为了解决这个问题，我们使用 域名系统（DNS）。

硬件受限的服务器（例如，2 CPU 和 4 GB RAM）只能处理一定数量的请求。当流量显著增加时，用户可能会遇到延迟，甚至服务器会变得无响应。

Scaling Strategies

Vertical Scaling (Scaling Up)

增加单台服务器的物理资源，例如升级到 16 CPU 和 128 GB RAM。

Pros

• 架构更简单（单服务器）

Cons

• 流量低时资源浪费
• 扩容期间需要停机，因为服务器必须重启
• 硬件限制——存在一个最大容量，超过后无法再升级

Horizontal Scaling (Scaling Out)

复制多个配置相同的小服务器（例如，多台 2‑CPU、4‑GB‑RAM 服务器）。

Pros

• 添加或移除服务器时无需停机
• 成本效率更高
• 高容错性
• 在高峰期能够高效管理流量

Consideration

• 每台克隆的服务器都会获得自己的 IP 地址，这就提出了一个问题：如果 DNS 只指向一个地址，如何处理多个服务器 IP？

Handling Multiple Server IPs

当存在多台服务器时，通常会在它们前面放置一个 负载均衡器。负载均衡器接收指向单一 DNS 名称的流量，然后根据选定的算法（例如，轮询、最少连接、加权分配）将请求分配到服务器 IP 池中。

Critical Design Considerations

• Load balancing decision logic – 负载均衡器如何决定将每个请求发送到哪台服务器？
• Session persistence – 如何在多台服务器之间保持用户会话（例如登录会话）？
• Auto‑scaling – 当流量突然增加时，自动伸缩组是如何工作的？
• Shared storage – 当服务器分布式部署时，应用程序如何存储共享文件？
• Health checking – 健康检查如何确保流量永远不会被发送到故障服务器？