Load Balancer 详解：它如何在流量高峰期间让您的应用保持在线

为什么网站会在流量激增时崩溃

回想一下您上次遇到网站崩溃是什么时候。也许您当时正准备购买演唱会门票，或者正在限时促销中结账。网站突然卡住，或者直接报错。

这种崩溃很可能是因为太多人同时访问网站。所有请求一下子都冲向同一台服务器。服务器无法承受，最终直接宕掉。

Load Balancer 可以解决这个问题。它会接收进入的流量，并将其分散到多台服务器上。一台服务器无法承载 10,000 人？没关系，那就把这些用户分摊到 10 台服务器上。

这并不是新技术。大型企业从 1990 年代起就一直在使用 Load Balancer。但 Cloud computing 让它们变得更便宜、也更容易部署。如今，即使是小型初创公司也能负担得起专业的负载均衡。

Load Balancer 的作用及其存在的原因

想象一家周五晚上座无虚席的餐厅。门口有一位接待员，5 个用餐区域同时开放。接待员会查看每个区域，找出哪些地方还有空桌，然后把每一组客人安排到不同区域。这样没人会等太久，也不会有某一个区域被过多客流压垮。

Load Balancer 的工作方式就像这位接待员。用户输入您的网站地址后，Load Balancer 会检查哪些后端服务器运行正常，并为每位访客选择其中一台。

用户通常不会知道这件事正在发生。他们只会看到页面顺利加载，或者 API 调用正常工作。在背后，他们的请求可能被发送到 Server 4，下一位用户的请求则被发送到 Server 2。

如果您的服务器崩溃，Load Balancer 会在几秒内发现。它会立即停止向该服务器分发流量。由于其他服务器会接手工作，您的网站仍能持续运行。

无需手动修复。无需更新 DNS。无需停机。系统会自行恢复。

Health Checks 和自动故障切换详解

大多数 Load Balancer 每隔几秒就会检查一次服务器健康状态。当某台服务器停止响应时，Load Balancer 会将其从资源池中移除。流量会被发送到其余服务器，直到故障服务器重新上线或被替换。

这一切都是自动完成的。您无需登录并修复路由规则，也不需要更新 DNS 记录。Load Balancer 会处理这一切。

有些 Load Balancer 还会管理 TLS 证书。您无需在每一台后端服务器上分别配置 SSL，只需要在 Load Balancer 上配置一次即可。这样可以降低应用服务器的 CPU 负载，并让证书管理更加简单。

Layer 4 与 Layer 7 Load Balancer：您需要哪一种

Load Balancer 运行在不同的 Network 层级。请根据您的构建需求选择合适的类型。

Layer 4 Load Balancer只会查看 IP address 和端口号。它们速度极快，因为不会检查实际内容本身。只需确认流量要去哪里，然后将其转发。

这种速度对某些特定场景非常关键。游戏服务器需要零延迟，视频流媒体需要最大 Bandwidth，语音通话需要即时响应。Layer 4 在这些场景中都表现出色。

Layer 7 Load Balancer则会实际读取 URL、Header、Cookie，以及请求中的内容。这意味着它们可以更智能地决定流量该发送到哪里。

可以将 API 调用发送到一组服务器，把图片请求发送到另一组服务器。可以为移动端用户和桌面端用户设置不同路由。还可以通过将 10% 的用户发送到实验版本来运行 A/B 测试。

Layer 7 会增加几毫秒的延迟。不过现代产品已经经过高度优化。对于典型的网站和应用来说，这一点点延迟完全值得，以换取更高的灵活性。

您真正需要 Load Balancer 的时候

只要您运行的不止一台服务器，就需要负载均衡。即使只有 2 台虚拟机，也能从 Load Balancer 带来的自动故障切换中获益。一台宕机？流量仍会继续通过另一台。

如果您的流量会在一天中发生波动，您也需要它。在线商店在晚上会迎来大量访问，商业应用在工作时间使用量更高。Load Balancer 让您可以随时增加或减少服务器，而无需改变用户看到的任何内容。

有些团队还会使用 Load Balancer 来实现无停机更新。让旧版本继续运行在一半服务器上，再把新版本部署到另一半服务器上。Load Balancer 会将流量同时发送到两边。一切运行正常？那就逐步把所有用户切换到新版本。

会破坏扩展能力的常见 Load Balancer 错误

很多团队以为 Load Balancer 能神奇地解决所有扩展问题，但事实并非如此。Load Balancer 只是分散流量；如果您的数据库已经不堪重负，那么增加更多 Web 服务器也完全没有帮助。

另一个常见错误，是在没有充分理由的情况下使用 Session affinity。Session affinity 会把每个用户固定到某一台特定服务器上。听起来似乎有利于保留会话数据，但它会严重削弱负载均衡效果。如果那台服务器宕机，用户还是会丢失会话。更好的做法是什么？把 Session 存储在 Redis 或数据库中，这样所有服务器都可以访问。

有些用户认为 Layer 7 Load Balancer 因为要检查内容，所以一定很慢。其实现代产品已经进行了极致优化。延迟通常只有几毫秒。您当然可以自己测量，但通常它带来的收益远远超过这点微小的速度成本。

您应始终监控的 Load Balancer 指标

Load Balancer 会输出大量有价值的数据。请重点关注以下这些数字。

健康后端数量应当保持稳定。突然下降意味着服务器正在崩溃，或者 Health Checks 配置有误。无论是哪种情况，都应立即排查。因为您的承载能力已经缩小了。

请求延迟需要看百分位分析，而不是平均值。平均延迟可能是 50ms，但如果有 5% 的请求耗时达到 10 秒，用户体验依然会非常糟糕。请检查 p95 和 p99 延迟。这些数字能揭示平均值掩盖的问题。

错误率能告诉您到底哪里出了问题。500 级错误激增意味着后端服务器正在失败。400 级错误激增则意味着客户端发出了错误请求。请长期跟踪这两类数据，以便快速发现异常。

活动连接数对于 Layer 4 部署以及 WebSockets 这类长连接场景非常重要。连接数不断上升却不下降？这可能意味着您存在连接泄漏，或者需要调整 keepalive 设置。

请求分布应当在各个后端之间大致均衡。如果某一台服务器获得的流量是其他服务器的 3 倍？那说明您的负载均衡算法有问题，或者某台服务器被标记为拥有比实际更高的容量。

Tenbyte 的托管式 Load Balancer 如何工作

Tenbyte 提供托管式 Load Balancer，客户可以自行配置后端目标、端口和安全规则。它可直接连接到您的虚拟机，并与您的 VPC、Firewall 和 DDoS protection 协同工作。

您将获得一个静态公网 IP。将您的 Domain 指向它即可。Load Balancer 本身会将流量分发到您的后端服务器。这些服务器可以位于同一个 availability zone，也可以分布在多个 availability zones 中，以获得更高韧性。

Bandwidth 为无限量。通过 Load Balancer 传输的流量不会按每 GB 额外收费。流量激增时不会出现意外账单，也无需进行复杂的价格计算。

该 Load Balancer 可与 Tenbyte Cloud Firewall 集成。您可以控制哪些 IP addresses 能访问您的应用，并在请求到达后端服务器之前，于 Network 层过滤流量。

部署只需几分钟。创建 Load Balancer，指定后端服务器，并分配 IP。流量会立即开始传输。您可以随时增加或移除服务器，Load Balancer 会自动适应。

用户最常问的 Load Balancer 问题

服务器崩溃时会发生什么？

Health checks 会在几秒内发现问题。Load Balancer 会立刻停止向该服务器发送流量。其他服务器会接手工作。修复完成后，一旦通过 health checks，它就会自动重新加入。

只有一台服务器时值得用吗？

您可以获得稳定的 IP 和一些安全能力，但无法享受自动故障切换。至少 2 台服务器才真正有意义。

Health checks 是如何工作的？

Load Balancer 每隔几秒就会 ping 每台服务器。能正常回应的服务器保持活跃。失败或超时的服务器会被标记为不可用，并从轮转中移除。

它能处理多少流量？

现代 Cloud Load Balancer 每秒可以处理数百万个请求。通常在 Load Balancer 到达极限之前，您的服务器就会先撑不住。

用正确的负载均衡终结停机并应对流量高峰

流量高峰不应该在凌晨 3 点把您吵醒。服务器崩溃不应该拖垮您的业务。更新也不应该像拿可用性去掷骰子。

Tenbyte 的托管式 Network Load Balancer 能处理这些繁琐的技术问题，让您专注于打造产品。无限 Bandwidth。可配合 Firewall 和 DDoS protection 使用。几分钟即可完成部署，而不是花上几天时间与配置反复周旋。

联系 Tenbyte 让我们为您设计一个真正契合需求的负载均衡方案。我们会为您讲清各种选项，解答您的疑问，并帮助您构建一个真正稳定可用的系统。