运维123 - 负载均衡
type: channel
link: https://www.sddts.cn/index.php/category/%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1/
items: Nginx 反向代理配置错误导致磁盘空间耗尽故障复盘
items: eBPF/XDP 构建二层直接服务器返回负载均衡器教程
items: 使用 NGINX 作为 AI 代理实现指南
items: Octopus LLM API 聚合服务技术分析
items: Tangled 使用 Pandoc 构建静态文档网站技术分析
items: 从零构建 eBPF/XDP 二层直连返回负载均衡器技术教程
items: Bonding 双活模式：Balance-tlb 与 Balance-alb 技术分析
items: Frontail Web日志实时流式工具技术分析
items: gpt-load 企业级多渠道大模型 API 管理平台技术分析

Nginx 反向代理配置错误导致磁盘空间耗尽故障复盘
type: item
date: 2026-04-17T03:00:46+00:00
description: Nginx 反向代理配置错误导致磁盘空间耗尽故障复盘一、事件概述1. 事件背景2026 年 3 月 31 日晚，作者在 Hetzner 小型服务器上部署了数字产品下载服务。服务器配置为 4GB RAM 和 40GB 磁盘空间，提供包括一个 2.2GB 大文件在内的多个文件下载功能。系统架构采用 Haskell 程序处理静态文件服务（包含授权验证），前端使用 nginx 反向代理。2. 影响范围A. 影响用户数数百名付费用户B. 影响时长20:40 - 23:00，持续约 2 小时C. 影响功能所有文件下载功能完全中断（前 2 小时）大文件（2.2GB）下载失败（后续）3. 严重程度P1 级故障（核心业务受损，付费用户无法访问已购买产品）二、事件时间线1. 故障发生（20:40）A. 现象描述产品发布后几分钟内，数百名用户同时访问服务器，系统立即出现磁盘空间不足错误。B. 监控告警日志中出现重复错误信息：user error (Unexpected reply to: MAIL "<...> at kanjideck.com", Expected reply code: 250, Got this instead: 452 "4.3.1 Insufficient system storage")Grafana 显示磁盘使用率 100%（40GB/40GB），df -h 显示 /dev/sda 100% 使用。2. 应急响应（20:40-21:00）A. 初步排查使用 du -sh 分析磁盘占用，发现：/var/lib 下的 Plausible Analytics（ClickHouse 数据库）：8.5GB/nix/store（NixOS 系统配置和可执行文件）：15GB剩余约 20GB 空间来源不明，未进一步分析。B. 处理措施尝试清理 Nix store：nix-collect-garbage -d因磁盘空间不足而失败。清理日志释放空间：journalctl --vacuum-time=1s尝试清理 ClickHouse 日志表：clickhouse-client -q "TRUNCATE TABLE system.query_log"因磁盘空间不足失败。C. 效果评估临时释放少量空间，但系统仍持续消耗磁盘空间，根因未定位。3. 扩容方案（21:00-23:00）A. 实施措施Hetzner 无更大规格实例可用，采用方案 B：购买独立 Volume 挂载 /nix/store。按照 NixOS Wiki 指南迁移 store：fileSystems."/nix" = { device = "/dev/disk/by-label/nix"; fsType = "ext4"; neededForBoot = true; options = [ "noatime" ]; };B. 效果评估服务器重启后，磁盘使用率降至 50%，服务恢复。但大文件下载问题未解决。4. 根本解决（次日）A. 问题定位用户反馈大文件下载中途失败。通过调整 proxy_max_temp_file_size 从默认的 1024m 提升到 5000m，大文件可下载。使用 lsof +L1 发现 14.5GB 已删除但仍被 nginx 占用的临时文件：lsof +L1 | grep nginx # 显示大量 /tmp/nginx_proxy/ 目录下的 deleted 文件B. 根本原因nginx 默认启用响应缓冲，将后端服务器返回的大文件内容缓存到临时文件。proxy_max_temp_file_size 默认值 1024m 限制单个临时文件大小，但多用户并发时产生大量临时文件。C. 解决方案在 nginx 配置中禁用缓冲：extraConfig = '' proxy_buffering off; proxy_max_temp_file_size 0; '';D. 验证结果磁盘使用率降至 20%，不再出现波动。sequenceDiagram participant U as 用户 participant N as Nginx participant T as 临时文件 participant H as Haskell 应用 participant D as 磁盘 U->>N: 下载 2.2GB 文件 N->>H: 代理请求 H-->>N: 返回文件流 N->>T: 写入临时文件（缓冲） T->>D: 占用 1GB 空间 Note over D: 并发 20 用户 = 20GB D-->>N: 磁盘满 N-->>U: 下载失败三、问题分析1. 直接原因nginx 的 proxy_max_temp_file_size 配置不当。默认值 1024m 允许单个请求缓冲最…

eBPF/XDP 构建二层直接服务器返回负载均衡器教程
type: item
date: 2026-02-06T07:33:24+00:00
description: eBPF/XDP 构建二层直接服务器返回负载均衡器教程一、概述1. 简介A. 是什么本教程讲解如何使用 eBPF/XDP 技术从零开始构建一个二层 Direct Server Return（DSR）负载均衡器。DSR 是一种高级负载均衡模式，允许后端服务器直接响应客户端请求，无需通过负载均衡器回传响应流量。B. 为什么学解决 NAT 模式负载均衡器的性能瓶颈问题掌握 eBPF/XDP 在网络编程中的实际应用理解 DSR 架构在云原生环境中的价值C. 学完能做什么使用 eBPF/XDP 实现二层 DSR 负载均衡理解虚拟 IP（VIP）的工作原理和配置方法掌握 MAC 地址重写技术在数据平面加速中的应用2. 前置知识A. 必备技能Linux 网络基础（IP、MAC、ARP 协议）基本的 C/Go 编程能力了解 eBPF/XDP 基本概念B. 推荐知识完成前序教程：NAT 模式 XDP 负载均衡器了解网络协议栈的分层模型二、背景知识1. NAT 模式的局限性在之前的教程中，我们构建了基于 NAT 的 XDP 负载均衡器。虽然该方案可以正常工作，但存在以下问题：A. 资源消耗负载均衡器需要处理双向流量（请求和响应），这会导致：更高的 CPU 和内存占用可能成为系统瓶颈B. 流量不对称入站流量通常远小于出站流量：搜索查询或 AI 提示只有几字节搜索结果或 AI 响应可能有数千字节C. 客户端信息丢失由于 NAT 负载均衡器重写了数据包头，后端服务器：无法感知真实客户端 IP难以维护用户会话无法按源 IP 记录请求日志2. Direct Server Return 概念DSR 通过让后端服务器直接响应客户端来解决上述问题。有多种 DSR 实现方式：Layer 2 DSR（本教程重点）IP-in-IP 封装GRE 隧道基于 IP 或 TCP 头部字段的变体三、实验环境1. 网络拓扑实验环境包含 5 个节点，分布在两个网络中：节点网络IP 地址lb192.168.178.0/24192.168.178.10/24backend-01192.168.178.0/24192.168.178.11/24backend-02192.168.178.0/24192.168.178.12/24client10.0.0.0/1610.0.0.20/16gateway跨网络192.168.178.2/24 + 10.0.0.2/162. DSR 原理与传统 NAT 负载均衡不同，DSR 保留原始客户端 IP，并允许后端直接响应客户端，在回程路径上绕过负载均衡器。核心问题：后端如何看到客户端 IP（数据包经过了负载均衡器）？后端知道响应哪个客户端吗？如何确保客户端从同一 IP 收到响应？简而言之，二层 DSR 通过在负载均衡器上仅重写数据包的 MAC 地址（保持 IP 头不变），并依靠负载均衡器和后端服务器之间的虚拟 IP 来实现。四、核心概念1. 虚拟 IP（VIP）在任何网络设置中，当客户端向特定端点发送请求时，期望响应来自相同的 IP 地址。如果响应来自不同的 IP，客户端网络栈会认为出错并丢弃数据包。在 NAT 负载均衡中，这会造成问题，因为客户端请求总是通过负载均衡器，后者将其转发给具有不同 IP 的后端节点。A. VIP 解决方案为了解决这个问题，负载均衡器和后端节点需要共享相同的 IP，确保客户端始终认为响应来自其最初联系的地址。这个共享 IP 就是虚拟 IP（VIP）。B. VIP 特性与物理 IP 不同，VIP 不绑定到特定接口或节点。相反，它是由多个节点使用的共享地址，用于处理同一服务的流量。2. VIP 配置A. 负载均衡器配置在负载均衡器的主接口（eth0）上配置 VIP：sudo ip addr add 192.168.178.15/32 dev eth0B. 后端服务器配置在两个后端服务器上，在环回接口（lo）上配置 VIP：sudo ip addr add 192.168.178.15/32 dev loC. ARP 隔离两个节点具有相同 IP 会引起混乱。因此，我们将 VIP 分配给后端节点的 lo 接口。我们不希望后端通过 ARP 广告虚拟 IP。网络中没有人应该知道后端上存在 VIP，否则客户端可能绕过负载均衡器直接连接。为防止后端节点响应 lo 接口上 VIP 地址的 ARP 请求（即广告），在每个后端节点上运行以下命令：# 仅当目标 IP 分配给接收请求的接口时才响应 ARP 请求 # （防止在 eth0 上广告 VIP） sudo sysctl -w net.ipv4.conf.eth0.arp_ignore=1 # 发送 ARP 请求时，仅使用分配给出站接口的地址 # （防止节点在 ARP 中泄露 VIP 作为源 …

使用 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…

Tangled 使用 Pandoc 构建静态文档网站技术分析
type: item
date: 2026-01-23T21:47:35+00:00
description: Tangled 使用 Pandoc 构建静态文档网站技术分析一、概述1. 背景Tangled 团队最近重新组织了文档，并将其发布到 https://docs.tangled.org，仅使用 Pandoc 工具实现。对于小型项目，使用 Pandoc 自建静态网站完全足够。2. 核心诉求A. 代码库集成文档必须存在于 monorepo 中B. 无 JavaScript 依赖纯文本页面不需要 JavaScript 即可浏览C. 可搜索性自带的搜索引擎效果较差，倾向于使用 Ctrl+F 或真实搜索引擎D. 低复杂度构建、测试、部署应当简单E. 易于样式化能够灵活定制外观二、生态系统评估1. 评估对象作者对多个文档引擎进行了评估：A. Mintlify特点：商业文档平台问题：官网显示正在进行 AI 转型，存在方向不明确的风险B. Docusaurus特点：生成精美的文档网站问题：将页面作为完整 React SPA 提供的价值存疑C. MkDocs优点：禁用 JS 后工作良好问题：需要通过 mkdocs.yml 维护目录结构，较为繁琐D. MdBook问题：需要 SUMMARY.md 文件控制目录2. 评估结论MkDocs 和 MdBook 仍在考虑范围内，以备将来需要更多功能时使用。三、Pandoc 方案1. Pandoc 介绍Pandoc 是一个高度可定制的标记转换工具，提供了 chunkedhtml 输出格式，非常适合生成文档网站。A. 默认特性基于文档布局自动生成目录（TOC）每个章节转换为独立页面2. 定制过程A. 合并文档将所有独立的 Markdown 文件合并为一个大的 DOCS.md 文件B. 模板修改修改默认模板，使 TOC 出现在每个页面上，形成侧边栏样式C. 样式统一插入 Tailwind prose 类，确保 Markdown 内容在 tangled.org 和 docs.tangled.org 之间渲染一致3. 生成命令pandoc docs/DOCS.md \ -o out/ \ -t chunkedhtml \ --variable toc \ --toc-depth=2 \ --css=docs/stylesheet.css \ --chunk-template="%i.html" \ --highlight-style=docs/highlight.theme \ --template=docs/template.html★ Insight ─────────────────────────────────────Pandoc 的 chunkedhtml 格式自动将单一大文档拆分为多个 HTML 页面，同时保持导航结构完整通过模板定制实现侧边栏 TOC，避免了复杂 JavaScript 代码的依赖─────────────────────────────────────────────────四、避免使用 JavaScript1. 移动端侧边栏侧边栏式目录需要在移动设备上折叠。大多数评估的文档引擎需要 JavaScript 来折叠和展开侧边栏，只有 MkDocs 使用 checkbox 的 :checked 伪类技巧来避免 JavaScript。2. 实现方案对比A. details/summary 方案优点：可实现折叠功能缺点：点击外部无法折叠，是明显的 hack 方案说明：Ctrl+F 或页面内查找仍然有效B. Popover API 方案（最终采用）优点：非常适合侧边栏组件实现：使用 HTML 原生 popover API触发按钮： Table of Contents 固定定位容器： Quick Start ... ... ... C. 方案特点TOC 可独立滚动点击侧边栏外部任何位置即可折叠页面内查找无法显示 popover 中的内容仅在小视口上可折叠，大视口上始终显示★ Insight ─────────────────────────────────────Popover API 是现代 HTML 原生功能，无需 JavaScript 即可实现复杂的交互效果通过 CSS 媒体查询实现响应式设计，小屏幕自动切换为折叠式侧边栏─────────────────────────────────────────────────五、搜索功能1. 搜索策略网站目前没有原生搜索功能。参考 htmx.org 的搜索栏，搜索栏直接重定向到 Google： ... 2. 单页版本考虑到 Ctrl+F 通常比 Docusaurus 提供的搜索引擎更好用，相同文档也导出为单页格式：pandoc docs/DOCS.md \ -o out/ \ --variable toc \ --toc-depth=2 \ --cs…

从零构建 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…

Frontail Web日志实时流式工具技术分析
type: item
date: 2026-01-17T15:57:01+00:00
description: Frontail Web日志实时流式工具技术分析一、概述1. 简介A. 是什么Frontail 是一个基于 Node.js 开发的日志实时流式传输工具，将传统的 tail -F 命令功能带入了 Web 浏览器。它通过 WebSocket 技术实现日志文件的实时推送，让开发者可以在浏览器界面中实时查看服务器日志，无需通过终端访问。B. 为什么学解决远程日志查看问题，无需 SSH 登录即可监控日志提供友好的 Web UI 界面，支持搜索和高亮显示支持多文件同时监控，适合微服务架构可以集成到现有 Web 基础设施中，与 Nginx 等反向代理配合使用C. 学完能做什么快速搭建日志监控 Web 服务配置基于 Basic Auth 的日志访问控制集成 HTTPS 加密传输自定义日志高亮规则通过 Nginx 反向代理嵌入现有系统2. 前置知识A. 必备技能基本的 Linux 命令行操作了解 tail -F 命令的基本用法Node.js 环境配置B. 推荐知识WebSocket 通信原理Nginx 反向代理配置HTTP 基本认证机制二、环境准备1. 系统要求Node.js 12.x 或更高版本npm 或 yarn 包管理器Linux/Unix/macOS/Windows 操作系统2. 安装步骤全局安装：npm install frontail -g本地安装：npm install frontail --save-dev3. 验证安装frontail --version三、核心概念1. 基本术语WebSocket：全双工通信协议，用于服务器主动推送日志tail -F：持续跟踪文件增长，即使文件被轮转也能继续监控Basic Auth：HTTP 基本认证，用于保护日志访问Daemon：后台进程模式，将 frontail 作为守护进程运行2. 工作原理graph LR A[日志文件] -->|tail -F| B[Frontail 服务] B -->|WebSocket| C[浏览器] C -->|搜索/过滤| B D[配置文件] -->|高亮规则| B E[Nginx] -->|反向代理| B三、核心架构1. 系统组成graph TB subgraph 前端层 A[Web UI] B[WebSocket 客户端] C[搜索过滤] end subgraph 服务层 D[Node.js 服务] E[文件监控模块] F[WebSocket 服务] G[认证模块] end subgraph 数据层 H[日志文件] I[配置文件] end A --> B B --> F F --> E E --> H G --> I四、快速上手1. Hello World 示例# 监控单个日志文件 frontail /var/log/nginx/access.log # 访问 http://localhost:90012. 核心功能演示# 监控多个文件 frontail /var/log/app/*.log # 指定端口和主机 frontail -h 0.0.0.0 -p 8080 /var/log/syslog # 启用高亮 frontail --ui-highlight /var/log/app.log3. 代码讲解Frontail 内部使用 Node.js 的 fs.watch() API 监控文件变化，通过 WebSocket 将新增的日志行实时推送到浏览器。前端使用纯 JavaScript 渲染日志流，支持自动滚动和搜索功能。五、功能详解1. 命令行参数A. 基础参数参数说明默认值-h, --host监听地址0.0.0.0-p, --port监听端口9001-n, --number启动时显示的行数10-l, --lines浏览器中存储的行数2000B. 安全参数参数说明-U, --userBasic Auth 用户名-P, --passwordBasic Auth 密码-k, --keyHTTPS 私钥文件-c, --certificateHTTPS 证书文件C. UI 参数参数说明-t, --theme主题（default、dark）--ui-hide-topbar隐藏顶部栏--ui-no-indent取消缩进--ui-highlight启用高亮--ui-highlight-preset自定义高亮规则文件D. 运行模式参数说明-d, --daemonize后台运行--pid-pathPID 文件路径--log-path日志文件路径--url-pathURL 路径前缀2. 高亮配置默认高亮规则（preset/default.json）：{ "words": { "err": "color: red;", "warn": "color: orange;" }, "…

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。准备数据库（…