高可用性和负载均衡对于构建即使在故障或高需求期间也能保持在线并高效处理流量的系统至关重要。高可用性通过消除单点故障和使用冗余来确保正常运行时间，而负载均衡则将流量分散到各个服务器以防止服务器过载。
关键要点：
- 高可用性：确保系统在故障时继续运行。正常运行时间以"个九"来衡量（例如，99.99% = 每年约52.6分钟的停机时间）。
- 负载均衡：将流量分散到各个服务器，以保持性能并避免瓶颈。
- 高可用性技术：
- 冗余：多个服务器或组件准备好在一个故障时接管。
- 健康检查：主动监控服务器健康状况以避免中断。
- 故障转移：在出现问题时自动切换到备份系统。
- 负载均衡算法：
- 轮询：依次循环遍历服务器。
- 最少连接：将流量发送到最不繁忙的服务器。
- IP哈希：将来自同一用户的请求路由到同一服务器。
- 一致性哈希：在添加/删除服务器时限制流量重新分配。
- 第4层与第7层负载均衡：
- 第4层：快速，在传输层运行（基于IP/端口的路由）。
- 第7层：更智能，在应用层工作（基于URL、标头等进行路由）。
通过结合这些策略，系统可以高效扩展，最小化停机时间，并在各种条件下提供可靠的服务。
系统设计中的高可用性是什么？
定义高可用性
高可用性（HA）确保系统即使在系统的某些部分故障时也能保持运行和可访问。这完全是关于提供不间断的服务，无论发生什么中断。
"高可用性（HA）是系统的一个特征，旨在确保在更长的时间内达成一致的运营性能水平，通常是正常运行时间。" – Robert Sheldon，技术贡献者，TechTarget [6]
可用性通常以"个九"表示，代表正常运行时间百分比。例如：
- 99.9%（三个九）：每年约8.77小时的停机时间
- 99.99%（四个九）：每年约52.6分钟的停机时间
- 99.999%（五个九）：每年仅约5.26分钟的停机时间
这些数字不仅仅是理论上的——它们有真实的财务后果。早在1996年，一份1998年的IBM报告估计停机时间使美国企业损失了45.4亿美元。显然，正常运行时间的风险很高。
如何实现高可用性
实现高可用性需要仔细规划和策略来保持系统的弹性。以下是一些关键方法：
-
消除单点故障（SPOF）：单个故障组件不应导致整个系统瘫痪。例如，Stripe通过使用区域感知数据库分片为其支付API实现99.99%的可用性。每个数据分片在一个可用区中有一个主节点，在另外两个区中有同步副本。这种设置允许亚秒级故障转移，同时保持低延迟——这对其运营至关重要[7]。
-
冗余：复制关键组件可确保备份准备好在出现故障时接管。Netflix在2021年12月AWS US-East-1中断期间展示了这一点。他们的多区域主动-主动架构自动将流量重定向到健康的区域。他们还使用"Chaos Monkey"等工具来模拟故障，确保其恢复流程按预期工作[7]。
-
深度健康检查：这些检查超越基本检查以确保完整功能。例如，与其仅确认数据库正在运行，健康检查可能验证数据库是否可以执行查询。这种主动方法允许在用户受到影响之前进行自动故障转移[7]。
接下来，我们将探讨负载均衡如何在支持高可用性中发挥关键作用。
负载均衡如何支持高可用性
负载均衡器如何工作
负载均衡通过高效地指导流量和维持系统正常运行时间在确保高可用性中发挥关键作用。将负载均衡器视为熟练的交通管制员，战略性地部署在用户和服务器之间，将每个请求引导到最佳目的地。
"负载均衡器从根本上说是一个交通警察，站在客户端和服务器之间的交叉口，根据一套规则、策略和关于服务器池的健康状况和容量的实时观察，将每个请求指导到最合适的目的地。" – Matt Klein，Envoy Proxy创建者[5]
这些系统不断监控后端服务器的健康状况。如果服务器停止响应，负载均衡器会迅速将流量重定向到功能正常的服务器，确保不间断的服务。
负载均衡器部署在系统架构中的各个点：用户和Web服务器之间、Web和应用服务器之间，甚至应用服务器和数据库之间[4]。这种分层方法确保整个系统的流量稳定流动。
为什么负载均衡改进高可用性
负载均衡的突出优势是其防止瓶颈和消除单点故障的能力。通过将请求分散到多个服务器，没有单个服务器会被压倒，这有助于维持连续服务[5]。
负载均衡还支持水平可扩展性，使得随着流量增加可以轻松添加更多服务器，而不会影响系统稳定性。例如，在2010年代，运行开源HAProxy的5000美元服务器处理的流量负载以前需要10万美元的硬件解决方案[5]。
这种方法还便于维护和升级而不会导致停机。它允许无缝的零停机部署，使团队可以灵活地进行更改而不会中断用户访问[8]。
但是，必须确保负载均衡器本身不会成为薄弱环节。在主动-被动或主动-主动设置中使用冗余负载均衡器可确保如果一个故障，另一个立即接管[2]。
接下来，我们将深入探讨使负载均衡如此有效的算法，作为您技术面试准备的一部分，以及如何为您的需求选择正确的算法。
负载均衡算法详解
主要负载均衡算法
选择正确的算法是有效分散流量的关键。轮询是一种直接的方法，依次循环遍历服务器，轮流向每个服务器发送请求。它非常适合服务器具有相同硬件且运行无状态应用程序的设置。有趣的是，这是NGINX的默认算法，在超过100,000个部署中使用[9][16]。
最少连接更进一步，通过监控活跃会话并将新请求指导到当前连接最少的服务器。这使其非常适合具有长期连接的场景，如WebSocket、流媒体平台或数据库，其中会话持续时间差异很大。HAProxy依赖这个作为其TCP负载均衡的默认值[10][16]。
对于需要会话持久性的应用程序，如购物车或聊天系统，IP哈希确保来自同一客户端IP的请求始终路由到同一服务器。但是，如果许多客户端共享单个IP（例如那些在NAT后面的客户端），这可能会导致流量分配不均[12][14]。
一致性哈希在扩展或缩减时特别有用，因为当添加或删除服务器时，它将重新映射的请求数限制在约1/n。这个特性对于分布式缓存（如Redis或Memcached）特别有价值，它们通常使用虚拟节点来确保均衡分配[11][12]。
加权版本的算法（如轮询和最少连接）允许根据服务器容量分配流量。例如，权重为10的服务器将处理权重为5的服务器流量的两倍。最少响应时间通过将流量指导到响应时间最快且连接最少的服务器来结合速度和负载，而基于资源的方法根据实时CPU和内存使用情况动态分配流量[9][10][13]。
选择正确的算法
您选择的算法取决于服务器功能、连接类型和会话要求等因素。
"一个很好的经验法则是从简单开始，根据需要发展。" – Maurice McMullin，首席产品营销经理，Progress Kemp[9]
如果您的服务器相同且处理快速的无状态请求，轮询是一个可靠的起点。但是，如果您的服务器池在容量上有所不同，加权算法可以帮助更均匀地分散流量，而不会使较弱的机器过载[9][10]。
对于混合工作负载，例如处理简短API调用和冗长上传的应用程序，最少连接是一个不错的选择。另一方面，严重依赖本地缓存的系统受益于一致性哈希，它通过维持一致的路由来改进缓存命中率[11][16]。
"选择错误的算法会浪费容量——请求堆积在空闲服务器上，而其他服务器则溢出。" – Sanjeev Sharma，全栈工程师，E-mopro[11]
有状态应用程序，如需要会话粘性的应用程序，通常依赖IP哈希或基于cookie的亲和性，尽管这些方法可能会降低负载分配的效率[15]。为了获得灵活性，HAProxy提供了超过13种不同的算法来适应多样化的基础设施设置[13]。
最后，强大的健康检查对于识别和从池中删除故障服务器至关重要。从轮询开始进行基本连接性测试是一种实用的方法，但根据实际性能数据发展您的策略将产生最佳结果[11][15]。
负载均衡器终极指南（系统设计基础）
构建高可用负载均衡器
让我们深入探讨创建弹性、高可用负载均衡器的策略，以此为基础建立在高可用性和负载均衡的概念之上。
多层负载均衡器设计
依赖单个负载均衡器是任何大规模系统都承受不起的风险。为了解决这个问题，许多架构实现了多层方法。在顶层，**基于DNS的全局服务器负载均衡（GSLB）**在地理区域之间指导流量。在此之下，区域第4层（L4）和第7层（L7）负载均衡器处理各个数据中心内的流量分配。同时，服务网格管理微服务之间的内部通信。
"L4和L7之间的选择不是非此即彼的。最具弹性的架构将它们分层，在边缘使用L4进行原始分配和容错，在更靠近服务的地方使用L7进行应用感知路由。" - Matt Klein，Envoy Proxy创建者[5]
这种分层设计确保没有单个组件成为瓶颈。例如，AWS弹性负载均衡自动在多个可用区部署冗余节点以增强可靠性。为了使DNS故障转移有效，在基础设施更改前将您的生存时间（TTL）设置为60秒或更少。更高的TTL值可能导致客户端在故障转移后继续访问故障服务器[17]。
下一步？集成健康检查和故障转移机制以维持这种分层弹性。
健康检查和故障转移
健康监控是保持负载均衡器平稳运行的核心。有两种主要方法：
- 主动检查：负载均衡器启动探针，如TCP握手或HTTP请求，期望获得200 OK响应。
- 被动检查：它观察实时流量以寻找警告信号，如5xx错误或超时。
为了微调此过程，设置阈值，在两次故障后将服务器标记为不健康，并在将其重新上线前需要三到五次成功检查[18]。
连接耗尽和缓慢启动机制等其他技术进一步增强了可靠性。连接耗尽确保活跃请求在删除服务器前完成，而缓慢启动将流量逐步增加到新恢复的实例，避免突然峰值。对于有状态应用程序，在活跃和备用负载均衡器之间同步会话表以防止故障转移期间的用户中断[3]。
一旦健康检查就位，下一个重点是消除单点故障。
防止负载均衡器故障
冗余是避免负载均衡器故障的关键。两种常见的设置是主动-被动和主动-主动配置：
- 在主动-被动设置中，一个负载均衡器处理流量，而备用单元使用心跳信号监控它。如果主负载均衡器故障，备用负载均衡器使用VRRP（使用keepalived等工具）接管共享虚拟IP（VIP）。
- 主动-主动设置更进一步，所有负载均衡器同时处理流量。这种配置依赖BGP和等成本多路径（ECMP）路由来均匀分配流量，随着添加更多负载均衡器而扩展容量。
| 特性 | 主动-被动 | 主动-主动 |
|---|---|---|
| 流量处理 | 一个负载均衡器处理流量 | 所有负载均衡器处理流量 |
| 复杂性 | 较低；大多数设置的标准 | 较高；需要高级网络 |
| 容量 | 限制为一个单元的容量 | 随活跃单元数量扩展 |
| 故障转移速度 | 通过VRRP/心跳近乎即时 | 连续；流量自动转移 |
要计算最大故障转移停机时间，请使用此公式：
持续时间 = DNS TTL +（健康检查间隔 × 不健康阈值）[17]。
例如，区域应用负载均衡器代理通常每秒处理多达600个HTTP或150个HTTPS新连接[17]。定期故障注入测试确保备用单元和VIP转换按预期工作，使您的系统为真实故障做好准备。
第4层与第7层负载均衡
第4层和第7层负载均衡之间的区别在于它们如何在网络堆栈中运行。每种都提供了速度和功能之间的独特平衡，取决于您的需求。
第4层和第7层详解
**第4层（传输层）**负载均衡器在TCP/UDP级别运行，仅基于IP地址和端口号路由流量。它们不检查或解密数据包内容，而是使用NAT（网络地址转换）或直接服务器返回（DSR）等方法转发流量。这种简单性允许快速数据包处理，而无需维持应用级状态[19]。
另一方面，**第7层（应用层）**负载均衡器在HTTP/HTTPS级别运行。它们终止客户端连接，检查应用数据，然后根据标头、cookie、URL或请求有效负载等因素路由流量。这种更深层的检查启用了更高级的决策制定，但需要与客户端和后端服务器建立单独的连接[19]。
"第4层的负载均衡就像按邮编分类邮件——快速高效。第7层就像阅读每封信件以决定哪个部门处理它——较慢但更聪明。" - Nawaz Dhandala，作者，OneUptime[19]
在性能方面，第4层拥有超低延迟，通常在50–100微秒左右，并使用最少的内存。同时，第7层由于请求缓冲和解析而引入略高的延迟，范围在1–5毫秒。第4层可以管理数百万个并发连接，而第7层通常适合处理每秒数十万个请求[19]。
比较第4层和第7层
第4层和第7层之间的正确选择取决于您的工作负载和目标。第4层非常适合最大化吞吐量、支持非HTTP协议（如PostgreSQL或Redis）或维持加密流量而不在负载均衡器处解密[19]。相比之下，第7层更适合需要路径基础路由（例如/api与/static）、SSL终止或高级安全工具（如Web应用防火墙（WAF））等功能的Web应用程序[19]。
| 特性 | 第4层（传输） | 第7层（应用） |
|---|---|---|
| 路由基础 | IP和端口 | URL、Cookie、标头、有效负载 |
| 延迟 | 超低（50–100 µs） | 低（1–5 ms） |
| 每个连接的内存 | ~1KB | 10–100KB |
| SSL终止 | 否（直通） | 是 |
| 协议支持 | 任何TCP/UDP（例如数据库、VoIP、游戏） | HTTP/HTTPS/gRPC（例如Web应用、API） |
| 安全功能 | DDoS缓解（例如SYN洪泛） | WAF、速率限制、内容检查 |
| AWS定价（每LCU） | ~$0.006 | ~$0.008 |
在健康检查方面，第4层依赖基本的端口可用性测试，确保服务器可达。但是，第7层可以通过针对特定端点（例如GET /health）执行更详细的检查来验证应用逻辑是否按预期工作[19]。
结论
高可用性和负载均衡不仅仅是技术考虑——它们是现代系统设计的支柱。这些概念对于维持用户信任、推动收入和确保运营连续性至关重要。通过消除单点故障和有效分散流量，它们确保系统即使在服务器中断或意外流量峰值期间也能平稳运行。
从昂贵的硬件到基于软件的解决方案的演变使企业级可靠性更容易获得。AWS ELB和Google Cloud负载均衡等服务现在提供令人印象深刻的正常运行时间保证（99.99%），相当于每年仅52分钟的停机时间[1]。
负载均衡器的作用不仅仅是流量分配器——它们是无缝部署、DDoS保护、SSL终止和水平扩展的大脑。它们使系统能够适应需求，无论是处理假日购物的电子商务平台还是管理病毒式内容的社交网络。
要实现真正的可靠性，冗余是关键。在每一层都纳入故障保险，通过使用Redis等工具进行会话管理来设计无状态系统，并进行评估应用性能而不仅仅是服务器可用性的健康检查。Willy Tarreau的见解强调了定制您的方法的重要性：
"理想的负载均衡算法在抽象中不存在——它相对于您的工作负载而存在"[5]。
无论您是在为系统设计面试做准备还是构建生产基础设施，掌握这些原则都是一个改变游戏规则的因素。高可用性和负载均衡携手创建高效扩展和优雅恢复的系统——因为即使几分钟的停机时间也可能对您的底线产生严重影响[3]。
常见问题
我如何为我的系统选择正确的正常运行时间目标（99.9与99.99与99.999）？
设置正常运行时间目标时，请考虑系统的关键程度。对于不太关键的系统，99.9%正常运行时间（每年约8.76小时的停机时间）通常就足够了。但是，对于关键任务服务——如医疗保健或金融领域的服务——您需要更高的目标，例如99.99%（每年约52.6分钟的停机时间）甚至99.999%（每年仅约5.26分钟）。请记住，实现更高的正常运行时间水平需要更大的投资，因此必须权衡您的可靠性需求与相关成本。
除了简单的ping之外，"深度"健康检查应该包括什么？
执行健康检查时，重要的是超越简单的ping。彻底的健康检查应评估所有关键依赖项，如数据库和消息队列。这种方法提供了系统整体健康状况的更清晰图景，并有助于最小化级联故障的风险。
我何时应该在生产中使用第4层与第7层负载均衡？
对于第4层负载均衡，路由决策基于IP地址和端口进行。这种方法非常适合高性能应用程序，因为它最小化了开销并提供了快速的基于协议的路由。
另一方面，第7层负载均衡专注于应用感知路由。它使用URL、标头或cookie等内容进行决策，使其非常适合更复杂的场景。但是，请注意这种方法涉及比第4层更高的延迟和更多的资源使用。