运维123 - 负载均衡
type: channel
link: https://www.sddts.cn/index.php/tag/%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1/
items: 使用 NGINX 作为 AI 代理实现指南
items: Octopus LLM API 聚合服务技术分析
items: 从零构建 eBPF/XDP 二层直连返回负载均衡器技术教程
items: Bonding 双活模式：Balance-tlb 与 Balance-alb 技术分析
items: gpt-load 企业级多渠道大模型 API 管理平台技术分析
items: Nginx + LVS + Keepalived 百万并发架构实战技术分析

使用 NGINX 作为 AI 代理实现指南
type: item
date: 2026-02-03T14:16:13+00:00
description: 使用 NGINX 作为 AI 代理实现指南一、概述1. 背景A. AI 时代的新挑战人工智能（AI）技术的快速发展创造了一个复杂的生态环境。组织开始将多个大型语言模型（LLM）提供商结合起来，并管理具有不同 API 规范的多个模型端点，以构建 AI 驱动的应用程序。这种多模型并存的环境催生了 AI Gateway 和 AI Proxy 的兴起。B. AI Proxy 的定义AI Proxy 是 AI Gateway 的简化实现，是位于应用程序与 AI 模型之间的专用基础设施组件，用于编排和保护 AI 请求的流向。2. 核心功能A. 流量控制流量控制是 AI Proxy 的核心功能，它实现了身份验证与授权机制以及速率限制，有助于防止模型滥用，并确保资源的公平分配。B. 模型转换模型转换通过提供对不同 AI 模型的统一 API 入口来实现跨 AI 模型和提供商的无缝集成，从而将复杂性从客户端应用抽象掉。C. 宕机切换宕机切换系统提供高可用性，确保请求的可靠性，能够优雅地处理模型不可用或速率受限的情况。D. 流量可观测性提供全面的监控和日志记录，以维持 AI 流程中的运营可见性。对请求与响应负载进行流量审计，对于合规性验证、故障排查与模型性能分析至关重要。二、技术方案1. 系统架构使用 NGINX 结合 NJS（NGINX JavaScript）脚本实现 AI Proxy，可以提供完整的 AI 流量治理能力。graph TB Client[客户端应用] -->|OpenAI API 格式| NGINX[NGINX AI Proxy] NGINX -->|NJS 转换| Anthropic[Anthropic API] NGINX -->|直接透传| OpenAI[OpenAI API] subgraph NGINX Router[NJS 路由脚本] Transform[模型转换] RBAC[访问控制] Failover[宕机切换] Logger[Token 日志] Router --> Transform Router --> RBAC Router --> Failover Router --> Logger end style NGINX fill:#e1f5fe style Client fill:#f3e5f5 style OpenAI fill:#c8e6c9 style Anthropic fill:#fff9c42. 工作原理A. 请求流程客户端发送统一格式的 API 请求到 NGINXNJS 脚本验证用户身份和访问权限根据请求的模型类型进行路由决策如果目标模型是 Anthropic，将请求转换为 Anthropic 格式如果目标模型是 OpenAI，直接透传请求发起子请求到后端模型提供商接收响应并进行必要格式转换记录 Token 使用情况返回统一格式的响应给客户端sequenceDiagram participant C as 客户端 participant N as NGINX participant JS as NJS 脚本 participant A as Anthropic API participant O as OpenAI API C->>N: POST /v1/chat/completions N->>JS: 路由处理 JS->>JS: 验证用户权限 JS->>JS: 检查模型类型 alt Anthropic 模型 JS->>JS: 转换请求格式 JS->>A: 子请求 A-->>JS: 响应 JS->>JS: 转换响应格式 else OpenAI 模型 JS->>O: 直接透传 O-->>JS: 响应 end JS->>JS: 记录 Token 使用 JS-->>C: 返回响应三、核心实现1. 模型路由与转换A. 请求格式转换OpenAI Chat Completions API 和 Anthropic Messages API 使用不同的请求格式。需要实现转换函数：function transformAnthropicRequest(requestBody) { let maxTokens = requestBody.max_completion_tokens || requestBody.max_tokens || 512; const anthropicRequest = { model: requestBody.model, max_tokens: maxTokens, stream: requestBody.stream || false, temperature: requestBody.temperature || 1.0, top_p: requestBody.top_p }; if…

Octopus LLM API 聚合服务技术分析
type: item
date: 2026-01-26T10:16:32+00:00
description: Octopus LLM API 聚合服务技术分析一、概述1. 项目简介Octopus 是一个面向个人的 LLM API 聚合与负载均衡服务，旨在为用户提供统一接入多个大语言模型提供商的能力。项目采用 Go 语言后端结合 Next.js 前端的架构设计，提供简洁优雅的 Web 管理界面。2. 核心价值A. 统一接入通过单一服务接入 OpenAI、Anthropic、Gemini 等多个 LLM 提供商，简化多模型调用流程。B. 成本优化支持多 API Key 轮询使用，智能选择最低延迟的端点，帮助用户优化使用成本和响应速度。C. 协议兼容实现 OpenAI Chat、OpenAI Responses、Anthropic API 等多种协议的无缝转换，降低客户端集成复杂度。二、系统架构1. 技术栈graph TB Client[客户端] --> API[Octopus API] API --> LB[负载均衡层] LB --> Channel1[OpenAI 通道] LB --> Channel2[Anthropic 通道] LB --> Channel3[Gemini 通道] Channel1 --> Provider1[提供商1] Channel1 --> Provider2[提供商2] Channel2 --> Provider3[提供商3] Channel3 --> Provider4[提供商4] API --> DB[(数据库)] API --> Cache[内存缓存] Cache --> DB Web[Web管理面板] --> API2. 组件说明A. 后端服务（Go）提供统一的 API 接口实现负载均衡和协议转换处理通道管理和请求路由统计数据收集与存储B. 前端管理界面（Next.js）通道配置与管理模型分组与负载均衡策略设置价格管理与统计数据展示系统配置与监控C. 数据存储支持 SQLite、MySQL、PostgreSQL存储通道配置、模型信息、统计数据自动创建表结构三、核心功能1. 通道管理通道是连接 LLM 提供商的基本配置单元。A. 多通道聚合支持同时配置多个 LLM 提供商的通道，每个通道包含：基础 URL多个 API Key多个端点地址B. 智能端点选择每个通道支持配置多个端点，系统自动选择延迟最短的端点进行请求。C. 协议类型支持协议类型自动追加路径应用场景OpenAI Chat/chat/completions对话补全OpenAI Responses/responses结构化响应Anthropic/messagesClaude 模型Gemini/models/:model:generateContentGemini 模型★ Insight ─────────────────────────────────────自动路径拼接设计：用户只需提供基础 URL，系统根据通道类型自动追加 API 路径，这种设计降低了配置复杂度，减少了用户错误。多端点智能选择：通过实时监测各端点延迟，自动选择最优路径，这种动态优化机制能有效提升用户体验。─────────────────────────────────────────────────2. 分组管理与负载均衡分组将多个通道聚合为一个统一的外部模型名称。A. 负载均衡模式graph LR Request[请求] --> Router{负载均衡器} Router -->|轮询| CH1[通道1] Router -->|随机| CH2[通道2] Router -->|故障转移| CH3[通道3] Router -->|加权| CH4[通道4] CH1 --> Provider1[提供商1] CH2 --> Provider2[提供商2] CH3 --> Provider3[提供商3] CH4 --> Provider4[提供商4]B. 模式详解模式描述适用场景轮询按顺序依次使用各通道通道能力相近，需要均匀分配请求随机随机选择可用通道通道能力相近，不需要严格顺序故障转移优先使用高优先级通道，失败时切换有主备通道之分，需要高可用性加权按配置权重分配请求通道能力不同，需要按比例分配★ Insight ─────────────────────────────────────故障转移机制：高优先级通道优先使用，失败时自动降级到低优先级通道，这种设计确保了服务的高可用性，避免了单点故障。加权负载均衡：通过权重配置实现按能力分配请求，这种方式既充分利用了高能力通道，又避免了过载风险。─────────────────────────────────────────────────3. 协议转换系统支持在不同 API 协议之间进行无缝转换。A. 转换流程sequenceDiagr…

从零构建 eBPF/XDP 二层直连返回负载均衡器技术教程
type: item
date: 2026-01-21T21:59:38+00:00
description: 从零构建 eBPF/XDP 二层直连返回负载均衡器技术教程一、概述1. 简介A. 是什么本教程介绍如何使用 eBPF 和 XDP（eXpress Data Path）从零开始构建一个二层（Layer 2）Direct Server Return（DSR）负载均衡器。DSR 是一种高性能负载均衡技术，允许后端服务器直接响应客户端请求，绕过负载均衡器的回程路径。B. 为什么学理解现代高性能负载均衡的核心原理掌握 eBPF/XDP 在网络编程中的应用学习 DSR 技术如何解决传统 NAT 负载均衡的性能瓶颈深入理解二层网络转发机制C. 学完能做什么使用 eBPF/XDP 编写二层负载均衡器配置虚拟 IP（VIP）实现 DSR 架构理解 MAC 地址重写与 IP 转发的区别部署高性能、低延迟的负载均衡解决方案2. 前置知识A. 必备技能Linux 网络基础（IP、MAC、ARP 协议）基本 C 语言编程能力网络命令行工具使用（ip、tcpdump、curl）B. 推荐知识eBPF 和 XDP 基础概念NAT 负载均衡原理二层网络与三层网络的区别二、背景知识1. NAT 负载均衡的局限性在之前的教程中，我们构建了基于 NAT 的 XDP 负载均衡器。虽然这种方案可以正常工作，但存在以下问题：A. 资源消耗负载均衡器需要处理双向流量（请求和响应）入站流量通常远小于出站流量例如：搜索查询或 AI 提示只有几字节，但响应可能有几 KB 甚至更多B. 性能瓶颈负载均衡器成为网络瓶颈高流量场景下资源消耗显著C. 客户端信息丢失后端服务器无法看到真实客户端 IPNAT 负载均衡器重写了数据包头后端无法基于源 IP 进行会话管理或日志记录2. DSR 解决方案Direct Server Return（DSR）概念被引入以克服上述限制。DSR 有多种实现方式：Layer 2 DSR（本教程重点）IP-in-IP 封装GRE（Generic Routing Encapsulation）封装基于 IP 或 TCP 头部字段的变体三、网络拓扑1. 实验环境本教程使用一个包含五个节点的网络拓扑，分布在两个不同的网络中：节点列表： - lb: 192.168.178.10/24（负载均衡器） - backend-01: 192.168.178.11/24（后端服务器 1） - backend-02: 192.168.178.12/24（后端服务器 2） - client: 10.0.0.20/16（客户端） - gateway: 192.168.178.2/24 和 10.0.0.2/16（网关）2. 架构图graph TB C[客户端 10.0.0.20/16] -->|请求| GW[网关 192.168.178.2 10.0.0.2] GW -->|转发| LB[负载均衡器 192.168.178.10 VIP: 192.168.178.15] LB -->|MAC重写| B1[后端服务器1 192.168.178.11 VIP on lo] LB -->|MAC重写| B2[后端服务器2 192.168.178.12 VIP on lo] B1 -->|直接响应| C B2 -.->|直接响应| C四、核心概念1. DSR L2 负载均衡原理与 NAT 负载均衡不同，DSR 保留原始客户端 IP，并允许后端服务器直接响应客户端，绕过负载均衡器的回程路径。为了理解这是如何实现的，我们需要回答三个核心问题：后端如何看到客户端 IP？数据包通过负载均衡器时，IP 头部保持不变只有 MAC 地址被重写后端知道响应哪个客户端吗？后端看到原始客户端 IP，可以正常响应如何确保客户端接收来自同一 IP 的响应？通过虚拟 IP（VIP）实现，负载均衡器和后端共享同一 IP2. 虚拟 IP（VIP）A. 什么是 VIP在任何网络设置中，当客户端向特定端点发送请求时，期望响应来自相同的 IP 地址。如果响应来自不同的 IP，客户端的网络栈会认为出错并丢弃数据包。虚拟 IP（Virtual IP，VIP）不是绑定到特定接口或节点的物理 IP，而是由多个节点共享的地址，用于处理同一服务的流量。B. VIP 配置在负载均衡器（lb 节点）上配置 VIP：sudo ip addr add 192.168.178.15/32 dev eth0在后端服务器（backend-01 和 backend-02）上配置 VIP：sudo ip addr add 192.168.178.15/32 dev loC. 为什么后端使用 lo 接口两个节点配置相同的 IP 不会混淆客户端或网关吗？这正是我们将 VIP 分配到后端节点的 lo 接口的原因。我们不希望后端广播虚拟 IP（通过 ARP）。换句…

Bonding 双活模式：Balance-tlb 与 Balance-alb 技术分析
type: item
date: 2026-01-18T00:11:25+00:00
description: Bonding 双活模式：Balance-tlb 与 Balance-alb 技术分析一、概述1. 背景在上一篇文章中讨论了 active-backup 模式，能够在一张网卡出现故障时快速切换，配置简单。但这种方式存在明显缺点——虽然有两张网卡，但同一时间只能使用一张，只有当主网卡挂了才会使用备网卡。2. 核心问题在高可用设计中，双活优于主备，主备意味着浪费。用户希望实现两张网卡都在工作，当其中一张网卡挂了时，退回到单网卡模式。3. 解决方案Linux Bonding 驱动提供了两种双活模式：Balance-tlb（Adaptive transmit load balancing，模式 5）：发送负载均衡Balance-alb（Adaptive load balancing，模式 6）：收发双向负载均衡二、Balance-tlb 模式1. 工作原理A. 发送方向假设两张网卡都要发送数据，需要解决 MAC flapping 问题——如果同一个 MAC 地址一会从端口 1 发出，一会从端口 2 发出，交换机通过收到的包学习 MAC 地址会感到困惑。因此，两个 interface 必须使用不同的 MAC 地址。对于发送流量，可以使用两个 interface 来发送，交换机看起来就像是两个不同的主机。B. 接收方向对于接收流量，只能用一个 interface 来接收。实现方式是：在回应 ARP 请求时，总是使用其中一个 interface 的 MAC 地址来回复。graph LR subgraph 服务器 B0[bond0 IP: 192.168.1.10 主MAC: 1a:50:9c:11:58:a3] E0[eth0 MAC: 1a:50:9c:11:58:a3 主接口: 收+发] E1[eth1 MAC: 9e:fa:f1:b5:0c:28 备接口: 仅发] B0 --> E0 B0 --> E1 end C1[客户端1] -->|目标MAC: 1a:50| SW[交换机] C2[客户端2] -->|目标MAC: 1a:50| SW SW --> E0 SW --> E1 E0 -->|源MAC: 1a:50| SW E1 -->|源MAC: 9e:fa| SW SW --> C1 SW --> C22. 流量特征对于发送流量：使用两个 interface 发送数据通过 hash 机制保证同一个 TCP 流总是走同一个 interface，避免 reorder 问题实际上会根据两张卡的负载动态调整使用哪张卡对于接收流量：由于其他客户端只知道 IP 对应一个网卡的 MAC 地址，入流量总是走到其中一个 interface 上从交换机视角看，有一个主机的 MAC 地址只会发出去包，但从来没有其他人发给这个 MAC3. 适用场景虽然只是发送流量可以使用两张卡，但对于面向客户的服务器来说：进入服务器的流量较少（请求一般比较小）从服务器出去的流量较多（响应一般很大）对于短视频服务器、流媒体、HTTP 服务器等，这种方案可以有效解决性能问题。三、Balance-tlb 故障切换流程1. 角色定义主接口：接收流量的 interface备接口：不接受流量、只发送的 interface2. 故障场景A. 备接口故障接收端不受影响发送端切换到只用主接口发送B. 主接口故障发送端切换到只使用备接口发送接收端流量也要切换到备接口3. 快速切换机制接收端流量的切换需要让发送流量的地方来切换。直观思路是切换 ARP，但 ARP 太慢，在 ARP 更新到发送者之前，流量会因发送到挂掉的 MAC 地址而被丢弃。更好的解决办法是让交换机来切换：发送者的流量发送给交换机，交换机再发送给服务器客户端的目标 MAC 地址不能变，但交换机转发的端口改变这与 active-backup 中讨论的 Gratuitous ARP 类似4. MAC 地址交换机制Balance-tlb 模式需要硬件支持改写 MAC 地址。切换过程需要保持主 MAC 地址总是可用，以不影响 ARP 缓存，实现快速切换：sequenceDiagram participant C as 客户端 participant SW as 交换机 participant E0 as eth0 (主: 1a:50) participant E1 as eth1 (备: 9e:fa) Note over C,E1: 正常状态 C->>SW: 发送至 MAC: 1a:50 SW->>E0: 从端口1转发 E0->>SW: 发送 (源MAC: 1a:50) E1->>SW: 发送 (源MAC: 9e:fa) Note over C,E1: 主接口故障 E0--xE0: 故障 E1->>E1: MAC交换 eth1: 1…

Octopus LLM API 聚合服务技术分析
type: item
date: 2026-01-16T06:59:47+00:00
description: Octopus LLM API 聚合服务技术分析一、新闻概述1. 标题Octopus：为个人打造的 LLM API 聚合与负载均衡服务2. 发布时间2025 年 1 月 16 日3. 来源GitHub 开源项目二、核心内容1. 事件摘要A. 主要内容Octopus 是一个面向个人用户的 LLM API 聚合服务项目，旨在通过统一入口管理多个 LLM 提供商的 API，实现智能负载均衡和成本优化。B. 核心亮点多渠道聚合：统一管理多个 LLM 提供商通道智能负载均衡：支持轮询、随机、故障转移、加权等多种模式协议转换：无缝转换 OpenAI Chat、OpenAI Responses、Anthropic API 格式自动同步：模型列表和价格信息自动更新优雅 UI：简洁美观的 Web 管理面板2. 关键信息A. 技术栈后端：Go 1.24.4前端：Next.js + pnpm数据库：SQLite、MySQL、PostgreSQLB. 部署方式Docker 容器化部署二进制文件直接运行源码编译C. 默认配置服务端口：8080默认账号：admin/admin数据存储：/app/data3. 背景介绍A. 项目起源随着 LLM 服务提供商日益增多，个人用户面临管理多个 API Key、分散调用、成本统计困难等问题。Octopus 应运而生，提供统一的 API 聚合解决方案。B. 相关上下文项目借鉴了 axonhub 的 LLM API 适配模块设计，并整合了 models.dev 的 AI 模型数据库用于价格信息同步。三、详细报道1. 主要内容A. 功能特性渠道管理：支持单通道多 API Key 配置每个通道支持多个端点，智能选择延迟最短的端点自动根据通道类型追加 API 路径分组管理：将多个通道聚合为统一的对外模型名称调用时设置 model 参数为分组名称即可访问所有通道支持多种负载均衡模式负载均衡模式：轮询模式：按顺序依次分配请求到各通道随机模式：随机选择可用通道故障转移：优先使用高优先级通道，失败时切换到低优先级通道加权模式：根据配置的通道权重分配请求B. 技术改进协议转换：OpenAI Chat 格式OpenAI Responses 格式Anthropic Messages 格式Gemini Generate Content 格式自动同步：定期从 models.dev 同步模型定价数据创建通道时自动同步可用模型列表自动创建未知模型的定价信息C. 统计分析综合请求统计Token 消耗统计成本跟踪定期批量写入数据库（性能优化策略）2. 技术细节A. 系统架构graph TB Client[客户端应用] --> Octopus[Octopus API 网关] Octopus --> LoadBalancer[负载均衡器] LoadBalancer --> Channel1[通道 1] LoadBalancer --> Channel2[通道 2] LoadBalancer --> Channel3[通道 3] Channel1 --> Provider1[提供商 1] Channel2 --> Provider2[提供商 2] Channel3 --> Provider3[提供商 3] Octopus --> Database[(数据库)] Octopus --> PriceSync[价格同步] PriceSync --> ModelsDev[models.dev]B. 数据流程sequenceDiagram participant C as 客户端 participant O as Octopus participant LB as 负载均衡 participant P as LLM 提供商 participant D as 数据库 C->>O: API 请求（model=分组名） O->>LB: 负载均衡选择 LB->>O: 返回选定通道 O->>P: 转发请求（协议转换） P-->>O: 返回响应 O-->>C: 返回结果 O->>D: 异步记录统计C. 配置架构graph LR Config[配置文件] --> Server[服务器配置] Config --> Database[数据库配置] Config --> Log[日志配置] Database --> SQLite[SQLite] Database --> MySQL[MySQL] Database --> PostgreSQL[PostgreSQL]3. 数据与事实A. 支持的 LLM 提供商OpenAI（Chat Completions、Responses）Anthropic（Claude）Google（Gemini）其他兼容 OpenAI 格式的提供商B. 数据库支…

gpt-load 企业级多渠道大模型 API 管理平台技术分析
type: item
date: 2026-01-16T01:48:52+00:00
description: gpt-load 企业级多渠道大模型 API 管理平台技术分析一、平台概述1. 简介gpt-load 是一款基于 Go 语言开发的企业级多渠道大模型 API 管理平台，专为需要集成多种 AI 服务的企业和开发者设计。它作为透明代理服务，完整保留了各 AI 服务商的原生 API 格式，支持智能密钥管理、负载均衡、故障切换和水平扩展，内置 Web 管理界面，提供高效、稳定的多 AI 服务集成管理方案。2. 核心定位企业级 AI 服务聚合中间件，解决多 AI 服务商接入、密钥管理、负载均衡等痛点问题。3. 设计目标简化 AI 服务集成复杂度，提供统一接入层，降低企业使用多种大模型的技术门槛和运维成本。二、核心功能特性1. 透明代理完全保留 OpenAI、Google Gemini 和 Anthropic Claude 等原生 API 格式，无需修改客户端代码即可无缝迁移。支持官方 OpenAI API、Azure OpenAI 以及其他 OpenAI 兼容服务。支持 Gemini Pro、Gemini Pro Vision 等模型的原生 API。支持 Claude 系列模型，支持高质量的对话和文本生成。2. 智能密钥管理支持密钥分组管理、自动轮换和故障恢复，提升密钥可用性与安全性。提供高性能密钥池，确保在高并发场景下密钥的稳定使用。3. 负载均衡支持多上游端点加权负载均衡，优化请求分发，提高服务整体可用性。自动管理密钥黑名单及恢复机制，减少因密钥失效导致的请求失败。4. 动态配置与热重载系统设置和分组配置支持热重载，修改后无需重启即可生效，提升运维效率。分组配置优先级高于系统设置，满足不同场景下的定制化需求。5. 企业级架构支持分布式主从部署和水平扩展，满足高并发场景下的性能需求。提供全面的监控功能，包括实时统计、健康检查和详细请求日志，便于问题排查与系统优化。6. 现代化管理与安全基于 Vue 3 的 Web 管理界面，直观易用，提升管理效率。管理端与代理端认证分离，支持全局和分组级别代理密钥，强化权限管控。提供优雅关闭、错误恢复和完善的安全机制，确保服务稳定运行。三、系统架构1. 架构设计graph TB subgraph 客户端层 A1[OpenAI 客户端] A2[Gemini 客户端] A3[Claude 客户端] end subgraph gpt-load 代理层 B1[API 网关] B2[认证模块] B3[负载均衡器] B4[密钥管理器] B5[健康检查] B6[配置中心] B7[Web 管理界面] end subgraph 上游服务层 C1[OpenAI API] C2[Azure OpenAI] C3[Gemini API] C4[Claude API] C5[其他兼容服务] end subgraph 数据存储层 D1[(MySQL/PostgreSQL)] D2[(SQLite)] D3[Redis 可选] end A1 --> B1 A2 --> B1 A3 --> B1 B1 --> B2 B2 --> B3 B3 --> B4 B4 --> C1 B4 --> C2 B4 --> C3 B4 --> C4 B4 --> C5 B3 --> B5 B5 --> B4 B7 --> B6 B6 --> B4 B6 --> D1 B6 --> D2 B6 --> D32. 请求处理流程sequenceDiagram participant C as 客户端 participant G as gpt-load 网关 participant A as 认证模块 participant L as 负载均衡器 participant K as 密钥管理器 participant P as 上游 AI 服务 C->>G: 发起 API 请求 G->>A: 验证代理密钥 A-->>G: 认证通过 G->>L: 获取可用端点 L->>K: 请求密钥 K-->>L: 返回健康密钥 L->>P: 转发请求 P-->>L: 返回响应 L-->>G: 转发响应 G-->>C: 返回结果3. 密钥管理机制graph LR subgraph 密钥池 A[密钥组 1] B[密钥组 2] C[密钥组 3] end subgraph 密钥状态 D[活跃密钥] E[冷却密钥] F[黑名单密钥] end subgraph 密钥操作 G[自动轮换] H[故障恢复] I[健康检查] end A --> D B --> D C --> D D --> E E --> D D --> F F --> H H --> D I --> D G --> D四、部署与安装1. 环境准备确保服务器已安装 Docker 和 Docker Compose。准备数据库（…

Nginx + LVS + Keepalived 百万并发架构实战技术分析
type: item
date: 2026-01-15T12:13:25+00:00
description: Nginx + LVS + Keepalived 百万并发架构实战技术分析一、新闻概述1. 标题百万并发架构实战：Nginx + LVS + Keepalived 架构2. 发布时间2025 年 1 月 15 日（资料整理）3. 来源架构师陈哥（微信公众号）二、核心内容1. 事件摘要A. 主要内容本文详细介绍了 Nginx + LVS + Keepalived 三层负载均衡架构，该架构是支撑百万级并发访问的主流解决方案。B. 核心亮点三层架构设计：LVS（四层）+ Nginx（七层）+ 业务集群高性能：LVS 运行在内核态，可支撑百万级并发连接高可用：Keepalived 提供主备切换和健康检查灵活性：Nginx 提供丰富的七层路由功能2. 关键信息A. 涉及技术LVS（Linux Virtual Server）NginxKeepalivedVRRP 协议DR 模式（Direct Routing）B. 性能指标LVS 可支撑数十万甚至上百万并发连接适用于互联网业务快速发展的场景3. 背景介绍A. 技术需求在互联网业务快速发展的大背景下，支撑百万并发访问成为大型网站和分布式应用设计的关键目标。B. 解决方案Nginx + LVS + Keepalived 架构以其高性能、可扩展性和高可用性，成为常见的解决方案。三、详细报道1. 架构概述A. 整体架构graph TD Client[客户端] -->|请求| LVS[LVS 四层负载均衡] LVS -->|转发| Nginx1[Nginx 七层代理 1] LVS -->|转发| Nginx2[Nginx 七层代理 2] Nginx1 -->|HTTP路由| App1[业务服务器1] Nginx1 -->|HTTP路由| App2[业务服务器2] Nginx2 -->|HTTP路由| App3[业务服务器3] Nginx2 -->|HTTP路由| App4[业务服务器4]B. 架构分层客户端 ↓ LVS（四层负载，抗并发） ↓ Nginx（七层负载，协议处理） ↓ 业务集群2. LVS 负载入口A. 技术特点LVS（Linux Virtual Server）是四层负载均衡解决方案，运行在内核态。核心优势：性能极高：运行在内核态，零拷贝技术抗并发能力强：轻松支撑数十万甚至上百万并发连接只负责转发：不解析 HTTP 协议内容，仅处理 TCP/UDP 数据包B. 工作模式LVS 支持多种工作模式，本文主要介绍 DR 模式（Direct Routing）：DR 模式特点：请求经过 LVS，响应不经过 LVS真实服务器直接响应客户端性能最优，要求 LVS 和服务器在同一物理网络C. LVS Director 架构graph TB subgraph "LVS Director 集群" LVSMaster[LVS Master 主节点] LVSSlave[LVS Slave 备节点] end subgraph "Keepalived 管理" VRRP[VRRP 协议 VIP 管理] Health[健康检查] end subgraph "ipvsadm 规则" Rules[DR 模式 负载均衡规则] end LVSMaster --> VRRP LVSSlave --> VRRP VRRP --> Rules Health --> LVSMaster Health --> LVSSlave3. Keepalived 高可用保障A. 核心功能Keepalived 是 LVS 集群的高可用保障组件。主要功能：VIP（Virtual IP）管理：通过 VRRP 协议实现虚拟 IP 漂移主备切换：当主节点故障时，备节点自动接管 VIP健康检查：自动检测后端节点状态，剔除异常节点B. VRRP 协议VRRP（Virtual Router Redundancy Protocol）是虚拟路由器冗余协议。工作原理：主节点定期发送 VRRP 广播备节点监听广播主节点故障时，备节点根据优先级接管 VIP客户端始终通过 VIP 访问服务C. 故障切换流程sequenceDiagram participant C as 客户端 participant VIP as 虚拟IP (VIP) participant M as LVS Master participant S as LVS Slave C->>VIP: 正常访问 VIP->>M: 转发请求 M->>C: 返回响应 Note over M: 主节点故障 S->>VIP: 检测到主节点故障 S->>VIP: 接管 VIP VIP->>S: VIP 绑定到备节点 C->>VIP: 继续访问 VIP->>S: 转发请求 S->>C: 返回响应4. Nginx 七层反向代理…