4.3 负载均衡部署拓扑
本节将介绍四种负载均衡部署拓扑，不同的部署拓扑决定了流量如何被分配、如何实现冗余和高可用性，进而影响系统的性能、可扩展性和容错能力。
4.3.1 中间代理型
第一种是中间代理型部署拓扑，如图 4-5 所示。这是最常见的负载均衡部署方式，负载均衡器位于客户端与后端服务器之间，负责将请求转发至多个后端服务器。
在这种拓扑中，负载均衡器可以分为以下三类：
- 硬件设备：由 Cisco、Juniper、F5 Networks 等公司提供的硬件负载均衡设备；
- 纯软件：如 Nginx、HAProxy、Envoy 和 Traefik 等开源软件负载均衡器；
- 云服务：包括阿里云的 SLB（Server Load Balancer）、AWS 的 ELB（Elastic Load Balancer）、Azure 的 Load Balancer 和 Google Cloud 的 Cloud Load Balancing 等云平台提供的负载均衡服务。
总结中间代理型优缺点：
- 优点：配置简便，用户只需通过 DNS 连接到负载均衡器，无需关心后端细节，使用体验简单直观；
- 缺点：存在单点故障的风险，负载均衡器一旦出现故障，会导致整个系统无法访问。
图 4-5 中间代理型
6.3.2 边缘代理型
边缘代理型实际上是中间代理型拓扑的一个变种。
一个典型的边缘代理示例是本书第二章 2.7 节中提到的动态请求‘加速’技术。Akamai 在全球多个数据中心部署边缘节点，这些节点具备代理功能，用户请求会被路由至最近的节点。收到请求后，边缘节点会执行安全检查（如 DDoS 防护），根据缓存策略决定是返回缓存内容（CDN 技术），或者将请求转发至源服务器（请求加速技术）。
总结边缘代理型优缺点：
- 优点：通过将负载均衡、缓存和安全策略集中在网络边缘，边缘代理显著降低延迟、提高响应速度，并增强安全性（如 DDoS 防护）；
- 缺点：虽然边缘代理减少了单点故障的风险，但若某个边缘节点发生故障，仍会影响到该节点服务的用户。
图 4-6 网络边缘型
4.3.3 客户端内嵌
为解决中间代理型拓扑的单点故障问题，出现了更复杂的解决方案，其中之一是将负载均衡器以 SDK 库形式嵌入客户端（如图 4-7 所示）。这些 SDK 库如 Finagle、Eureka、Ribbon 和 Hystrix 等，它们优缺点是：
- 优点：将负载均衡器功能“转移”至客户端，避免了单点故障问题；
- 缺点：需要为每种编程语言实现相应的 SDK，且在项目复杂时，处理版本依赖和兼容性问题变得棘手（微服务框架的相关问题将在本书第八章 8.2 节中详细讨论，读者可参考进一步了解）。
图 4-7 客户端内嵌型
4.3.4 边车代理型
边车代理型拓扑近年来在微服务架构中得到广泛应用，并发展成为一种被称为“服务网格”（Service Mesh）的架构模式。
边车代理的基本原理是在应用容器或服务旁边部署一个独立的代理容器，用于实现请求的负载均衡和流量管理。目前，像 Envoy 和 Linkerd 等网络型边车代理已被广泛应用。关于服务网格的技术原理，笔者将在第八章中进行详细阐述。
图 4-8 边车代理型
总体而言，中间代理型负载均衡器正逐步演变为功能更强大的“网关”，所有请求通过单一入口（即网关）进入集群。在这种架构下，负载均衡器作为网关，不仅负责基本的请求转发，还承担更高级的请求管理与安全控制，包括 TLS 卸载、请求限制、身份验证和复杂内容路由等。同时，针对东西向流量（即服务间通信），边车代理模式“透明”地接管了服务间的通信治理，正逐渐成为主流选择。