SRE weekly 所有文章

Cloud DevOps/负载均衡基本概念笔记.md

@@ -0,0 +1,573 @@
+## 什么是负载均衡？
+
+负载均衡是一种计算技术，用于在多个计算资源（如服务器、网络链接、处理器等）之间分配工作负载，使得：
+
+- 实现最优资源利用率
+- 最大化系统吞吐量
+- 最小化响应时间
+- 避免任何单一资源过载
+
+简单理解：就是把用户请求"分散"到多个服务器上，让每个服务器承担部分工作，而不是让一个服务器承担所有工作。
+
+---
+
+## 核心思想
+
+### 三个关键原则
+
+#### 1. 分散请求
+
+- 将客户端请求均匀分配到多个后端服务器
+- 充分利用每个服务器的计算能力
+- 避免某个服务器成为性能瓶颈
+
+#### 2. 避免单点瓶颈
+
+- 防止某个服务器承载过多流量而崩溃
+- 在高并发场景下保证系统稳定性
+- 提高整体系统容量
+
+#### 3. 提高可用性
+
+- 当某台服务器故障时，其他服务器可继续处理请求
+- 用户不会因为单个服务器故障而无法访问服务
+- 实现近似"零停机"的服务体验
+
+### 工作流程
+
+```
+客户端请求 → 负载均衡器 → 选择服务器 → 转发请求 → 后端服务器处理
+                                ↓
+                           根据算法决定
+                           分配给哪个服务器
+```
+
+---
+
+## 主要作用
+
+### 1. 性能提升
+
+- **增加吞吐量**：多个服务器并行处理请求，整体处理能力提升
+- **降低单机压力**：每台服务器承载的请求数减少，响应速度更快
+- **更好的资源利用**：CPU、内存、网络带宽都能得到充分利用
+
+### 2. 高可用性
+
+- **故障转移**：某台服务器故障，请求自动转向其他正常服务器
+- **服务连续性**：单点故障不影响整体服务可用性
+- **自动检测**：能自动检测故障服务器并隔离它
+
+### 3. 可扩展性
+
+- **水平扩展**：需要处理更多请求时，直接添加更多服务器即可
+- **弹性伸缩**：根据实时负载动态增加或减少服务器数量
+- **成本优化**：比起升级单个高性能服务器，增加普通服务器成本更低
+
+### 4. 故障转移
+
+- **自动检测不健康的服务器**：定期检查服务器是否正常
+- **自动隔离故障服务器**：停止向故障服务器发送请求
+- **自动恢复**：当服务器恢复正常后，自动重新加入服务
+
+### 5. 会话保持
+
+- **某些算法支持会话保持**：确保同一用户的多次请求由同一服务器处理
+- **减少状态同步开销**：无需在多个服务器间同步用户会话状态
+- **提升用户体验**：用户可能不会感到"跳跃"
+
+---
+
+## 负载均衡的分类
+
+### 按实现层级分类
+
+#### 第4层（传输层）负载均衡
+
+**基于TCP/UDP协议**
+
+- 工作在传输层
+- 根据IP地址、端口号进行分配
+- 只关心数据包的转发，不理解应用层内容
+- 优点：性能最高，效率最快，CPU消耗低
+- 缺点：功能相对简单，无法做到很精细的分配
+- 常见工具：LVS、HAProxy、Nginx
+- 适用：对性能要求高、应用相对简单的场景
+
+**例子**：
+
+- 某个TCP连接建立后，所有该连接的数据包都发往同一个后端服务器
+- 基于源IP和目的IP的五元组进行映射
+
+#### 第7层（应用层）负载均衡
+
+**基于HTTP/HTTPS协议或应用内容**
+
+- 工作在应用层
+- 可以理解应用层协议（HTTP、FTP等）和内容
+- 可以根据URL、hostname、HTTP头等进行分配
+- 优点：功能强大，可以做到细粒度控制，功能灵活
+- 缺点：性能相对较低，需要解析和理解应用协议
+- 常见工具：Nginx、Apache、HAProxy
+- 适用：需要精细控制、复杂业务逻辑的场景
+
+**例子**：
+
+- 根据请求的URL路径分配到不同的后端服务器
+- 根据HTTP请求头信息（如User-Agent）进行分配
+- 某个API调用可能被分配到不同的服务器
+
+### 按部署位置分类
+
+#### 服务器端负载均衡
+
+- 部署在数据中心内
+- 对内部服务器之间的流量进行分配
+- 控制范围明确
+- 常见：Nginx、HAProxy
+
+#### 客户端负载均衡
+
+- 逻辑内置在客户端应用中
+- 客户端自己选择要调用的服务器
+- 减少中间层
+- 常见：服务发现框架
+
+#### 浏览器端负载均衡
+
+- 域名解析返回多个IP地址
+- 浏览器随机选择其中一个
+- 最简单的分散方式
+
+---
+
+## 实现层级和性能对比
+
+|对比维度|第4层|第7层|
+|---|---|---|
+|**性能**|极高|中等|
+|**CPU消耗**|低|高|
+|**功能**|简单|复杂|
+|**控制粒度**|粗|细|
+|**应用理解**|无|有|
+|**配置复杂度**|低|高|
+|**适用场景**|高并发简单服务|复杂业务逻辑|
+
+---
+
+## 常见的负载均衡产品
+
+### 硬件负载均衡器
+
+这些是专门的硬件设备，通常很贵但性能很好。
+
+**F5 Big-IP**
+
+- 业界最知名的硬件负载均衡器
+- 功能最全面，性能最强劲
+- 价格最贵，通常用于大型企业
+
+**Citrix NetScaler**
+
+- 功能全面的企业级产品
+- 提供应用交付服务
+- 成本较高
+
+**A10 Networks**
+
+- 专注于应用交付和负载均衡
+- 性能和功能的平衡
+
+### 开源软件负载均衡
+
+**Nginx**
+
+- 轻量级、高性能
+- 支持第7层负载均衡
+- 配置简单灵活
+- 生态最活跃，使用最广泛
+- 适合：Web应用、API网关、反向代理
+
+**HAProxy**
+
+- 专业的负载均衡软件
+- 支持第4层和第7层
+- 配置能力强大
+- 适合：复杂的负载均衡需求
+
+**Apache HTTP Server**
+
+- 可通过模块支持负载均衡
+- 功能相对简单
+- 通常用于传统Web服务
+
+**LVS (Linux Virtual Server)**
+
+- Linux内核级的负载均衡
+- 性能最好
+- 配置相对复杂
+- 适合：超高并发场景
+
+### 云厂商的负载均衡服务
+
+**AWS (Amazon Web Services)**
+
+- ELB (Elastic Load Balancer)
+- ALB (Application Load Balancer) - 第7层
+- NLB (Network Load Balancer) - 第4层
+- 自动扩展和高可用
+
+**阿里云**
+
+- SLB (Server Load Balancer)
+- 支持多种负载均衡算法
+- 与其他阿里云服务深度集成
+
+**腾讯云**
+
+- CLB (Cloud Load Balancer)
+- 支持多种协议
+- 与腾讯云生态集成
+
+**Microsoft Azure**
+
+- Azure Load Balancer
+- 支持第4层和第7层
+- 与Azure服务集成
+
+---
+
+## 负载均衡的应用场景
+
+### 1. Web应用的多服务器部署
+
+最常见的使用场景。
+
+**典型架构**：
+
+- 用户访问域名 → 负载均衡器 → 分发到多个Web服务器
+- 每个Web服务器运行相同的应用代码
+- 通常结合会话保持技术
+
+**优势**：
+
+- 单个服务器故障不影响用户访问
+- 可以轻松扩展服务器数量应对流量增长
+- 升级部署时无需停止服务
+
+### 2. 数据库读写分离
+
+在数据库层面使用负载均衡。
+
+**架构**：
+
+- 主数据库（写操作）
+- 多个从数据库（读操作）
+- 负载均衡器分配读请求到不同从库
+
+**优势**：
+
+- 提高数据库读取性能
+- 减少主库压力
+- 实现高可用的数据库架构
+
+### 3. API网关
+
+微服务架构中的流量入口。
+
+**功能**：
+
+- 统一的API入口
+- 根据API路径分配到不同的后端服务
+- 提供认证、限流、转发等功能
+
+**优势**：
+
+- 屏蔽后端服务复杂性
+- 便于API版本管理
+- 统一的流量控制
+
+### 4. 微服务架构
+
+每个微服务可能有多个实例。
+
+**场景**：
+
+- 用户服务：多个实例
+- 订单服务：多个实例
+- 支付服务：多个实例
+
+**优势**：
+
+- 服务之间独立扩展
+- 故障隔离
+- 灵活的部署策略
+
+### 5. CDN和内容分发
+
+地理位置分散的服务器。
+
+**工作方式**：
+
+- 用户访问就近的CDN节点
+- CDN节点内部进行负载均衡
+- 加速内容分发
+
+**优势**：
+
+- 减少网络延迟
+- 加快内容加载速度
+- 减少源站压力
+
+### 6. DNS级负载均衡
+
+最上层的负载均衡。
+
+**方式**：
+
+- DNS服务器返回多个IP地址
+- 客户端自动选择其中一个
+- 实现地理级别的流量分散
+
+**优势**：
+
+- 简单易用
+- 跨地域分散流量
+- 成本最低
+
+### 7. 消息队列负载均衡
+
+处理异步消息的场景。
+
+**场景**：
+
+- 多个消费者从队列消费消息
+- 负载均衡器分配消息到不同消费者
+- 提高消息处理能力
+
+---
+
+## 负载均衡的关键特性
+
+### 1. 健康检查
+
+定期检测后端服务器是否正常运作。
+
+**检查方式**：
+
+- TCP连接检查：尝试建立TCP连接
+- HTTP探针：发送HTTP请求检查响应
+- 自定义脚本：运行自定义检查逻辑
+
+**作用**：
+
+- 自动隔离故障服务器
+- 恢复后自动加入
+- 保证只向健康服务器分配请求
+
+### 2. 会话保持（粘性会话）
+
+确保用户请求始终路由到同一服务器。
+
+**实现方式**：
+
+- IP哈希：根据客户端IP路由
+- Cookie：在HTTP Cookie中标记服务器ID
+- 会话表：中央维护会话映射表
+
+**应用场景**：
+
+- 有状态应用（传统Web应用）
+- 需要本地缓存的服务
+- 某些特殊的业务需求
+
+### 3. 连接复用
+
+连接可以被多个请求重复使用。
+
+**好处**：
+
+- 减少连接建立开销
+- 提高性能
+- 减少资源消耗
+
+**实现**：
+
+- HTTP Keep-Alive
+- TCP连接池
+- 长连接管理
+
+### 4. 请求排队
+
+当后端服务器繁忙时，对请求进行排队。
+
+**作用**：
+
+- 保护后端服务器
+- 提高系统稳定性
+- 避免雪崩效应
+
+### 5. 速率限制（限流）
+
+控制通过的请求速率。
+
+**实现**：
+
+- 按IP地址限流
+- 按用户账号限流
+- 全局限流
+
+**作用**：
+
+- 保护系统不过载
+- 公平对待用户
+- 防止被滥用
+
+### 6. 连接超时
+
+设置请求的最大等待时间。
+
+**参数**：
+
+- 连接超时：建立连接的最大时间
+- 读超时：接收响应的最大时间
+- 写超时：发送请求的最大时间
+
+---
+
+## 负载均衡的优势和局限
+
+### 主要优势
+
+|优势|说明|
+|---|---|
+|**高可用性**|单点故障不导致服务中断|
+|**高性能**|分散负载，提高吞吐量|
+|**可扩展性**|轻松增加服务器应对增长|
+|**灵活性**|支持多种分配策略|
+|**容错能力**|自动故障转移和恢复|
+|**部署灵活**|可以独立升级和部署服务器|
+
+### 主要局限
+
+|局限|说明|
+|---|---|
+|**成本增加**|需要额外的负载均衡设备或软件|
+|**复杂度提升**|系统架构变复杂，运维难度增加|
+|**单点故障**|如果负载均衡器本身故障，整体服务可能中断|
+|**会话管理**|多服务器环境下会话管理变复杂|
+|**调试困难**|分布式系统排查问题更难|
+|**延迟增加**|额外的转发层可能增加少量延迟|
+
+### 如何应对局限
+
+**负载均衡器单点故障**：
+
+- 部署多个负载均衡器
+- 使用VIP（虚拟IP）和故障转移技术
+- 云厂商通常内置冗余
+
+**会话管理**：
+
+- 使用分布式会话存储（如Redis）
+- 会话粘性（粘性会话）
+- 无状态设计
+
+**调试和监测**：
+
+- 完善的日志和监测系统
+- 分布式追踪（Distributed Tracing）
+- 完整的告警机制
+
+---
+
+## 负载均衡部署模式
+
+### 单负载均衡器
+
+最简单的部署方式。
+
+- 一个负载均衡器
+- 多个后端服务器
+- 局限：负载均衡器成为单点
+
+### 主备部署
+
+负载均衡器本身也做高可用。
+
+- 一个主负载均衡器
+- 一个备负载均衡器
+- 使用VIP进行故障转移
+- 主故障时自动切到备
+
+### 多活部署
+
+多个负载均衡器同时工作。
+
+- 多个负载均衡器并行工作
+- 通过DNS返回多个IP
+- 提高可用性和性能
+- 配置和管理复杂
+
+### 分层部署
+
+在多个层级部署负载均衡。
+
+- 第一层：DNS级负载均衡（地理位置）
+- 第二层：网络级负载均衡（区域）
+- 第三层：应用级负载均衡（服务器）
+
+---
+
+## 选择负载均衡方案的考虑因素
+
+### 1. 并发规模
+
+- **小规模**（<1000 QPS）：Nginx足够
+- **中规模**（1000-10000 QPS）：Nginx或HAProxy
+- **大规模**（>10000 QPS）：硬件或LVS
+- **超大规模**：云厂商或自建专业方案
+
+### 2. 功能需求
+
+- **简单转发**：LVS、Nginx基础功能
+- **复杂逻辑**：Nginx高级功能、HAProxy、硬件
+- **应用层控制**：必须第7层负载均衡
+
+### 3. 部署环境
+
+- **物理机**：LVS、HAProxy、硬件负载均衡器
+- **虚拟机**：Nginx、HAProxy
+- **云环境**：使用云厂商的负载均衡服务
+
+### 4. 运维能力
+
+- **专业团队**：可选择复杂的开源方案
+- **普通团队**：优先选择云厂商或商业产品
+- **小团队**：选择简单易用的方案
+
+### 5. 成本预算
+
+- **硬件**：最贵，但功能最全
+- **开源软件**：最便宜，需要自己部署运维
+- **云服务**：中等成本，省去运维
+
+### 6. 数据安全性
+
+- **敏感数据**：考虑自建方案
+- **一般数据**：可使用云厂商方案
+- **加密需求**：考虑支持TLS/SSL的方案
+
+---
+
+## 总结
+
+负载均衡是现代互联网应用必不可少的技术：
+
+1. **核心价值**：通过分散请求提高系统的可靠性和性能
+2. **关键作用**：高可用、高性能、可扩展性
+3. **多种实现**：从简单到复杂，从硬件到软件
+4. **广泛应用**：Web、数据库、微服务、CDN等各个领域
+5. **需要权衡**：性能、功能、成本、复杂度之间的平衡
+
+选择合适的负载均衡方案需要综合考虑系统规模、业务需求、运维能力和成本预算。