分布式常见概念

_李白_

已于 2025-06-03 15:45:17 修改

阅读量1.1k

点赞数 9

CC 4.0 BY-SA版权

分类专栏：分布式文章标签：分布式

于 2025-05-27 15:22:12 首次发布

本文链接：https://blog.csdn.net/weixin_40179091/article/details/148254499

分布式专栏收录该内容

5 篇文章

订阅专栏

分布式常见概念

反向代理
API网关
负载均衡（Load Balancing）

反向代理

“反向代理”（Reverse Proxy）之所以叫“反向”，是相对于“正向代理”（Forward Proxy）而言的。我们先理解“正向代理”，然后对比就能明白“反向代理”名字的来源。

正向代理 vs 反向代理（对比理解名称）

代理类型	客户端视角	服务端视角	功能方向（代理谁）	示例用途
正向代理	代理客户端	服务端不知道真实客户端	代理客户端向服务器发请求	科学上网、访问被屏蔽网站
反向代理	客户端不知道真实服务器	代理服务器接收请求	代理服务器代理真实服务器	负载均衡、隐藏源站、加速网站

正向代理示意（“我去帮你拿数据”）

用户（客户端）配置一个代理服务器。
用户的请求先发给代理服务器，由代理代替用户向目标网站发起请求。
代理收到响应后，再返回给用户。

📌 特点：客户端知道自己用的是代理，服务器不知道谁是原始请求者。

反向代理示意（“你找我，我替你联系内部服务器”）

用户访问网站，请求发给一个代理服务器。
代理服务器决定将请求转发给哪个后端服务器（真实源站）。
用户不直接接触后端服务器，只与代理打交道。

📌 特点：客户端不知道后端服务器的存在，感觉就像访问的是反向代理本身。

为什么叫“反向”？

在正向代理中，客户端知道代理存在并主动使用它，代理代表“客户端”去访问外部世界。
在反向代理中，客户端无感知，代理是服务器部署的“防线”，代表“服务器”处理外部请求。

所以，“反向代理”这个名字强调的是方向变了：

正向代理是 客户端→代理→服务器，
反向代理是 客户端→代理（看似服务器）→真实服务器。

如果你还想知道反向代理和负载均衡、防火墙等功能模块的细节关系，我可以进一步展开。是否需要？

API网关

API 网关（API Gateway）是一个位于客户端与一组后端服务之间的服务器，作为所有客户端请求的唯一入口点。它的主要作用是接收客户端的 API 请求，路由到合适的后端服务，聚合结果，并返回给客户端。

一、为什么需要 API 网关？

在现代微服务架构中，一个系统通常由多个小的服务组成。如果客户端直接访问每个服务，会带来以下问题：

客户端需要维护多个服务的地址和通信逻辑；
每个服务可能有不同的认证、限流、安全要求；
请求可能需要访问多个服务来聚合数据，客户端需要承担复杂逻辑；
服务迁移或重构时客户端容易受到影响。

API 网关解决了这些问题。

二、API 网关的核心功能

功能	描述
路由请求	根据 URL 或请求内容，把请求转发给相应的后端服务
请求聚合	聚合多个服务的响应，形成一个统一的返回结果
身份验证与授权	在统一入口进行用户身份认证（如 OAuth、JWT）、权限检查等
日志与监控	记录访问日志、请求耗时、错误信息，便于监控和调试
限流与熔断	控制请求频率，防止系统过载，提升系统稳定性
协议转换	如 HTTP 转 gRPC，或 SOAP 转 REST
缓存	对一些频繁访问的数据进行缓存，提升响应速度
CORS处理	统一处理跨域资源共享（Cross-Origin Resource Sharing）问题

三、工作流程示意图（简化）：

客户端
   |
   v
[ API 网关 ]
   |    \
   |     ---> 微服务 A
   |     ---> 微服务 B
   |     ---> 微服务 C
   v
  返回聚合结果

四、常见的 API 网关实现

名称	特点
Nginx	可作为轻量级 API 网关，需手动编写配置
Kong	基于 Nginx，功能强大，支持插件机制
Apigee	Google 提供的企业级网关，集成分析、认证等
AWS API Gateway	云原生服务，与 AWS 服务集成紧密
Spring Cloud Gateway	Java生态，适用于 Spring 微服务架构
Zuul	Netflix 开源的旧网关，已逐步被替代

五、举例说明

假设你有三个微服务：

用户服务 /user/info
商品服务 /product/list
订单服务 /order/create

如果没有网关，客户端需要分别请求这三个服务。使用 API 网关后，只需请求统一入口，如：

GET /api/user/info   --> 转发到用户服务
GET /api/product/list --> 转发到商品服务
POST /api/order/create --> 转发到订单服务

负载均衡（Load Balancing）

负载均衡是指将来自客户端的请求合理分发到多个后端服务器（或节点）上，以提升系统的可用性、吞吐能力和响应速度，避免单点故障或过载。

一、负载均衡的作用

提升系统吞吐量：多个服务器并发处理请求，提升整体性能
提高系统可用性：某台服务器宕机，其它服务器接管请求，保障连续性
增强可扩展性：可随需扩容或缩容服务器节点
加快响应速度：流量分配至负载较轻或地理更近的服务器，提升体验

二、负载均衡的分类

按照实现方式和网络层级，常见的负载均衡可分为三类：

分类	层级	实现位置
DNS 负载均衡	L3/L4	DNS 服务器
硬件负载均衡	L4/L7	网络硬件设备（如 F5）
软件负载均衡	L4/L7	普通服务器或容器中运行的软件

三、DNS 负载均衡（基于域名系统）

DNS 服务器为一个域名配置多个 IP 地址（A 记录），客户端每次解析域名时会得到不同 IP，实现“伪轮询”。

example.com → [192.168.1.1, 192.168.1.2, 192.168.1.3]

✅ 优点：

成本低、实现简单
全球 CDN 常用，可结合 GeoDNS 实现地域调度

❌ 缺点：

缓存延迟高（TTL 问题）
无法判断服务器健康状态
不支持权重、会话保持等策略

四、硬件负载均衡（如 F5、Citrix、H3C）

使用专用硬件设备，将外部流量按特定策略转发到后端服务器，通常支持：

L4：基于 IP+端口的 TCP/UDP 分发
L7：基于 HTTP 的 URI、Host、Header、Cookie 等转发

✅ 优点：

高性能、高吞吐、超低延迟
支持高级安全功能、DDoS 防护、SSL 卸载等
适合大型企业、金融系统等核心业务

❌ 缺点：

成本昂贵，维护复杂
扩展性差，不易集成到云原生架构中

五、软件负载均衡（运行在普通服务器或容器中）

通过通用软件（如 Nginx、HAProxy、Envoy、Traefik）处理和转发流量，可作为独立组件运行或嵌入微服务体系。

🔥 常见软件对比：

软件	特点
Nginx	高性能反向代理，支持 TCP/UDP，配置简单，静态场景优先
HAProxy	专业级负载均衡器，稳定性强，支持丰富策略和健康检查
Envoy	云原生友好，支持 gRPC、服务发现、熔断、链路追踪等
Traefik	动态配置，适用于 K8s 和 Docker 等容器编排环境

✅ 优点：

支持动态服务发现，配置灵活
适配微服务与云环境，自动路由、自动注册
支持复杂的 L4/L7 策略（如权重、Header 路由等）

❌ 缺点：

高并发下需调优
依赖宿主资源，性能略逊硬件方案

Nginx 是一个高性能的 Web 服务器，同时也广泛用于反向代理和负载均衡。作为负载均衡器，Nginx 支持多种策略，用于将请求分发到后端服务器。以下是 Nginx 负载均衡策略的详细介绍：

Nginx负载均衡策略

基本配置结构

http {
    upstream backend {
        # 在这里配置负载均衡策略和后端服务器
    }

    server {
        location / {
            proxy_pass http://backend;
        }
    }
}

负载均衡策略类型

1. 轮询（Round Robin）【默认策略】

默认策略，不需要额外指定。
请求按顺序轮流分配到后端服务器。

upstream backend {
    server 192.168.0.101;
    server 192.168.0.102;
}

优点： 简单有效，适用于后端性能接近的场景。

2. 权重轮询（Weighted Round Robin）

为服务器设置不同的权重，权重越高，被分配到的请求越多。

upstream backend {
    server 192.168.0.101 weight=3;
    server 192.168.0.102 weight=1;
}

应用场景： 后端服务器性能差异明显。

3. IP 哈希（ip_hash）

根据客户端 IP 进行哈希，固定客户端访问同一个后端服务器（会话粘性）。

upstream backend {
    ip_hash;
    server 192.168.0.101;
    server 192.168.0.102;
}

优点： 保持会话一致性，适用于不使用 session 共享的应用。

缺点： 某台服务器宕机会导致部分用户服务不可用。

4. 最少连接数（least_conn）

将请求分发到当前连接数最少的服务器。

upstream backend {
    least_conn;
    server 192.168.0.101;
    server 192.168.0.102;
}

适合场景： 后端处理请求时间不一，如 WebSocket、长连接。

5. 最少时间（least_time）【Nginx Plus 专有】

按响应时间加权，将请求分发给平均响应时间最短的服务器。

upstream backend {
    least_time header;
    server 192.168.0.101;
    server 192.168.0.102;
}

注意： 仅在 Nginx Plus 中可用。

高级功能（附加配置）

1. 健康检查（需要 Nginx Plus 或第三方模块）

upstream backend {
    server 192.168.0.101;
    server 192.168.0.102;
    health_check interval=5 fails=3 passes=2;
}

OpenResty、Tengine、Nginx Plus 都支持健康检查。

2. fail_timeout & max_fails

upstream backend {
    server 192.168.0.101 max_fails=3 fail_timeout=30s;
    server 192.168.0.102;
}

max_fails：在 fail_timeout 指定的时间窗口内，最多允许的失败次数。。
fail_timeout：如果在该时间段内失败次数达到 max_fails，就暂时将该服务器标记为“不可用”，不再转发请求给它。

3. backup（备用服务器）

upstream backend {
    server 192.168.0.101;
    server 192.168.0.102 backup;
}

只有主服务器全部不可用时才使用 backup 服务器。

4. keepalive 连接复用

upstream backend {
    server 192.168.0.101;
    server 192.168.0.102;
    keepalive 32;
}

减少 TCP 握手开销，提高性能。

会话保持的替代方式（适用于无 ip_hash）

使用 Cookie 记录路由信息（Sticky session）
- 第三方模块：nginx-sticky-module 或使用 Tengine/OpenResty。
使用共享 Session（Redis/Memcached）
使用 JWT 或 Token 实现无状态认证

总结

策略	特点	适用场景
轮询	简单、默认	性能相近的服务器
权重轮询	可按性能分配请求	后端性能不一致
ip_hash	客户端 IP 映射固定后端，粘性强	保持会话一致性
least_conn	动态选择连接数少的服务器	长连接/请求耗时不一致
least_time	按响应快慢分发（Nginx Plus）	高级调度场景

六、对比总结表

类型	网络层级	成本	灵活性	健康检查	缓存延迟	适用场景
DNS 负载均衡	L3/L4	低	低	❌ 无	高	简单服务分发、CDN 地域分流
硬件负载均衡	L4/L7	高	中	✅ 支持	低	金融、政企、大型数据中心入口流量管控
软件负载均衡	L4/L7	低 ~ 中	高	✅ 支持	低	微服务架构、云原生环境、Kubernetes 集群

七、常见负载均衡工具和平台

工具/平台	类型	说明
Nginx	软件	轻量级，支持静态资源代理、反向代理等
HAProxy	软件	高可靠、性能优异，适用于金融、电商、高并发系统
Envoy	软件	服务网格核心组件，支持动态发现、gRPC、指标采集等
Traefik	软件	云原生场景中首选，自动配置、支持热更新
F5 BIG-IP	硬件	企业级设备，支持 SSL 卸载、会话保持等高级特性
LVS（Linux Virtual Server）	内核模块	高性能，内核态转发，适合高吞吐部署
Kubernetes Ingress	云原生组件	集群服务访问入口，支持基于域名/路径的转发规则