4.3 负载均衡拓扑类型
前面介绍了负载均衡高层概览、四层负载均衡与七层负载均衡的区别，接下来介绍它们的分布式部署拓扑，建立对负载均衡的全局性认识。
注意
下面介绍的每种拓扑都适用于四层和七层负载均衡器。
第一种类型为中间代理型拓扑，如图 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 中间代理型负载均衡拓扑
第二种边缘代理型拓扑实际上是中间代理型拓扑变种。
一个典型的边缘代理示例是本书第二章 2.7 节中提到的动态请求“加速”技术。Akamai 在全球多个数据中心部署了多个具有代理功能的边缘节点，用户的请求被路由至距离最近的边缘节点。边缘节点收到请求后，执行安全检查（如 DDoS 防护），根据缓存策略决定是否返回缓存内容（CDN 技术），或将请求继续转发至源服务器（请求加速技术）。
总结边缘代理型拓扑的优缺点：
- 优点是，将负载均衡逻辑（还有缓存、安全策略等）集中在网络边缘，能够显著减少延迟，提高网站的响应速度，增强安全性（预防 DDos）；
- 缺点是，虽然边缘代理可以减少单点故障，但如果某个边缘节点出现问题，仍会影响到该节点所服务的用户。
图 4-6 网络边缘型负载均衡拓扑
为解决中间代理型拓扑模式的单点问题，出现了一些更复杂的解决方案。如将负载均衡器以 SDK 库的形式嵌入客户端内部（图 4-7 所示）。SDK 库就是大家熟知的 Finagle、Eureka、Ribbon 和 Hystrix 等微服务治理方案。
虽然这些库功能各异，但还是能总结出它们的共同优缺点：
- 优点是，将负载均衡器的功能完全下沉至客户端，避免了单点故障问题；
- 缺点是，每一种编程语言都要实现相应的 SDK 。且当项目非常复杂时，处理版本依赖等兼容问题将非常棘手（本书第八章 8.2 节详细阐述了微服务框架的痛点，可阅读本节进一步了解）。
图 4-7 客户端内嵌库实现负载均衡
客户端内嵌库的一个变种是边车代理（sidecar）型拓扑。
近年来边车型代理拓扑非常流行，被称为“服务网格”（service mesh）。边车代理拓扑的核心思路是：将流量导到另一个进程，牺牲一点（延迟）性能，实现客户端内嵌库模式的所有好处，而无任何语言绑定。当下，最流行的网络型边车代理有 Envoy、Linkerd 等，笔者将第八章详细阐述服务网格的技术原理。
图 4-8 Sidecar 代理实现负载均衡
总体上讲，中间代理型的负载均衡器正在演变成功能更为强大的“网关”，所有请求通过唯一的入口（即网关）进入集群。这种架构中，负载均衡器不仅负责基本的流量分发功能，还需提供额外的“API 网关”功能，如 TLS 卸载、流量限制、身份验证，以及复杂的内容路由等。另一方面，在处理东西向流量（服务间通信）的场景中，边车代理模式将代理部署在服务实例旁边，透明接管服务间通信治理，正逐渐取代其他所有的拓扑类型。