@@ -307,13 +307,60 @@ $ ip addr add 1.1.1.1/32 dev lo
307
307
[ ^ 1 ] : Anycast VIP 是一种通过 Anycast 路由协议分配的虚拟 IP 地址,用于在多个位置部署相同的 IP 地址,并根据路由选择将流量引导到最靠近的或最优的服务器节点
308
308
309
309
310
+ ## 从七层负载均衡到网关
311
+ 早期的七层负载均衡器(如 Nginx)依赖静态配置,仅具备基本的请求代理功能。随着微服务架构兴起,负载均衡器开始承担更多职责,逐步从“流量工具”演变为“系统的边界控制层” —— 网关。
310
312
313
+ 业界较流行的网关系统(高级负载均衡器)
311
314
315
+ 业内网关系统代表
312
316
317
+ | 名称 | 简介 |
318
+ | -------------------- | ------------------------------------------------------------------------------------------------ |
319
+ | OpenResty | 基于 Nginx 的高性能 Web 平台,集成了大量模块,用来处理 HTTP 请求,被许多企业作为内部网关的基础框架。 |
320
+ | Kong | 构建在 OpenResty 上的网关平台,有丰富的插件体系,支持身份认证、限流、日志记录、监控等功能。 |
321
+ | Spring Cloud Gateway | Spring 框架下的 API 网关解决方案,与 Spring Cloud 生态(如 Eureka、Config Server)深度集成,广泛应用于 Java 技术栈的微服务项目。 |
322
+ | Traefik | 专为容器化系统设计,可与 Kubernetes、Docker 无缝集成。支持自动服务发现、动态配置路由、请求限流、身份验证、可观测等。 |
323
+ | Envoy | Envoy 是 Lyft 开发的一款面向服务网格的高性能网络代理,支持高级的路由控制、负载均衡策略、服务发现和健康检查等。Envoy 与 Istio 紧密结合,通常作为服务网格的数据平面出现。 |
313
324
325
+ 这些网关(高级负载均衡器)各有各的特点,实现的功能也非常强大-------,简单列举部分功能,以便读者对“强大”有个直观的感受。
326
+
327
+ - ** 协议支持** :负载均衡器对应用层协议了解的越多,就可以处理更复杂的事情,包括系统可观测、高级负载均衡和内容路由等。以 Envoy 为例,它支持 HTTP/1、HTTP/2、HTTP/3(QUIC)、gRPC、TCP、TLS、WebSocket、PostgreSQL、Redis、MongoDB、DynamoDB 等协议。
328
+
329
+ - ** 动态配置** :随着系统的动态性不断增强,需要在两个方面进行投入,一是动态控制,即实时调整系统行为;二是响应式控制,即根据环境变化做出快速反应。以 Istio 为例,它的架构分为控制平面和数据平面:
330
+
331
+ - 数据平面:专注于动态控制,负责执行微服务之间的请求转发、负载均衡、熔断、重试、超时等流量管理策略。
332
+ - 控制平面:专注于响应式控制,通过集中式配置和管理,为数据平面提供统一接口,用于定义和修改流量管理策略。
333
+ - ** 流量治理** :在分布式架构中,服务间通信治理(如超时、重试、限速、熔断、流量镜像、缓存等)是系统稳定性的重要保障。作为集群的入口,负载均衡器将服务间通信治理需求统一收敛,这极大降低了业务系统的运维难度。
334
+
335
+ - ** 可观测** :目前,指标监控、链路追踪和日志记录已成为高级七层负载均衡器的标配功能。如上面提到的 Envoy 和 Traefik,均支持与 Prometheus、Grafana、Jaeger 等监控系统集成。
336
+
337
+ - ** 可扩展** :网关系统通常是插件化的,开发者可以根据需求灵活加载特定插件。例如,在 OpenResty 上,通过编写 Lua 脚本或集成第三方插件,可实现数据缓存、身份认证、安全防护、日志监控等自定义功能。
338
+
339
+ - ** 高可用及无状态设计** :网关系统强调“无状态”(stateless)架构设计,即每个请求都被视为独立的,不依赖于任何先前的请求或存储在服务器上的会话信息。通过消除服务器状态依赖,系统能够轻松实现水平扩展!
340
+
341
+
342
+ ## 全局负载均衡设计
343
+ 近年来,负载均衡系统的发展趋势是将单个负载均衡器视为通用的标准化组件,由一个全局控制系统统一管理。
344
+
345
+ 全局负载均衡系统设计。
346
+
347
+ - 边车代理(Sidecar Proxy)和位于三个 Zone 的后端通信。
348
+ - 边车代理、后端定期向全局负载均衡器(Global Load Balancer)汇报请求延迟、自身的负载等状态,全局负载均衡器根据状态做出最合适的配置策略。
349
+ - 全局负载均衡器向边车代理下发转发策略,可以看到 90% 的流量到了 Zone C,Zone A 和 B 各只有 5%。
350
+ ![ [ global-load-balancer-DgFSK_xh.svg]]
351
+ 全局负载均衡器能够实现很多单个负载均衡器无法完成的功能,比如下面这些。
352
+
353
+ - 某个区域故障或负载过高时,全局负载均衡器自动将流量切换到其他可用区。
354
+ - 利用机器学习、神经网络技术检测并缓解流量异常问题。比如识别并治理 DDoS 攻击。
355
+ - 收拢边车代理配置,提供全局运维视角,帮助工程师直观理解、维护整个分布式系统。
356
+
357
+ 全局负载均衡器在服务网格领域表现的形式称为“控制平面”(Control Plane),控制平面与边车代理协作的关键在于配置动态化。这部分内容,笔者将在第八章 8.3 节详细阐述。
314
358
359
+ 负载均衡作为分布式系统的入口,直接影响整个系统的行为。因此,这一领域的竞争异常激烈,技术创新不断涌现。
315
360
361
+ 在四层负载均衡领域,传统的硬件负载均衡设备(如 F5)正逐步被基于通用服务器和专用软件(如 IPVS、DPDK、fd.io)的解决方案所取代。例如,基于 DPDK 的流量转发和数据包处理技术,即使普通的物理机,也能轻松实现每秒百万至数千万的每秒数据包处理能力。在七层负载均衡领域,随着微服务架构的快速发展,传统代理软件(如 NGINX、HAProxy)逐渐被更适应动态微服务环境的解决方案(如 Envoy、Traefik)所取代。
316
362
363
+ 总体而言,随着技术架构逐步向云厂商主导的 IaaS、CaaS 和 FaaS 模式演进,工程师未来将很少需要关注物理网络的工作原理,隐藏在 XaaS 模式之下的各类网络技术,正逐渐演变为“黑科技”。
317
364
318
365
319
366
0 commit comments