Load Balancing und Gateway

Kernfrage

Wenn ein einzelner Server die Last nicht mehr tragen kann, wie verteilt man Traffic "intelligent" auf mehrere Server-Instanzen? Load Balancing ist der "Verteiler" moderner verteilter Systeme. Dieser Artikel verwendet reale Beispiele (Milchtee-Kassen, Paketsortierung, Verkehrssteuerung), um die Designphilosophie und Engineering-Praxis von Load Balancing zu erklaeren.

1. Warum "Load Balancing"?

1.1 Ein reales Beispiel: Die Architektur-Evolution einer Website

Ein Startup hatte bei schnell wachsenden Nutzerzahlen ernsthafte Performance-Probleme:

Szenario-Rekonstruktion:

Phase 1: Einzelner Server
Nutzer -> Server (1 Kern, 2 GB)
         |
   1000 DAU -> 1000 gleichzeitige Besucher zu Spitzenzeiten
         |
Problem: CPU 100%, langsame Antwort, haeufige Abstuerze

⚠️ Fatale Probleme eines einzelnen Servers

Performance-Engpass: CPU 100%, Antwortzeit > 5 Sekunden
Single Point of Failure: Server faellt aus -> gesamte Website nicht erreichbar
Schwierige Skalierung: Nur vertikales Upgrade moeglich (CPU, Speicher hinzufuegen) - teuer und begrenzt

Verbesserte Architektur (mit Load Balancing):

Phase 2: Mehrere Server + Load Balancer
Nutzer -> Load Balancer (Nginx)
         |
       ├-> Server 1 (1 Kern, 2 GB)
       ├-> Server 2 (1 Kern, 2 GB)
       └-> Server 3 (1 Kern, 2 GB)

✨ Verbesserte Ergebnisse

Hoehere Performance: 3 Server verarbeiten parallel, Antwortzeit < 1 Sekunde
Hohe Verfuegbarkeit: Ein Server faellt aus, die anderen weiter im Dienst
Horizontale Skalierung: Mehr Performance? Einfach Server hinzufuegen

1.2 Alltags-Analogie fuer Load Balancing

Die Milchtee-Kassen

Stell dir vor, du betreibst einen trendigen Milchtee-Laden:

1 Kasse: Kunden warten, die hinteren werden ungeduldig - schlechte Bewertungen
3 Kassen: Mitarbeiter weisen Kunden verschiedenen Kassen zu - 3x effizienter

Load Balancer ist der "Kassenzuteiler":

Nutzer (Kunden) -> Service anfragen
Load Balancer (Zuteiler) -> Anfragen auf verschiedene Server verteilen
Server (Kassen) -> Anfragen verarbeiten

传统架构单点

🖥️

Web Server

负载: 95% 🔥

→

负载均衡架构分布式

⚖️L4 Load Balancer

🖥️

📦四层负载均衡 (L4)

工作原理

基于传输层信息（IP地址+端口）进行流量分发。不关心应用层内容，只做"快递分拣"，因此性能极高。

典型产品

LVS (Linux Virtual Server)HAProxy (TCP模式)AWS NLBAzure Load Balancer

适用场景

需要极高吞吐量的场景
TCP/UDP流量分发
不需要内容识别的场景
微服务间通信

性能对比一览

类型

处理层

性能

灵活性

成本

硬件负载均衡

L4/L7

$$$$$

四层负载均衡

L4 (传输层)

七层负载均衡

L7 (应用层)

$$$

软件负载均衡

L4/L7

2. Was ist Load Balancing?

2.1 Layer-4-Load-Balancing (L4): Nur die Hausnummer betrachten

Arbeitet auf der Transportschicht (TCP/UDP), wie ein Paketbote, der nur deine Hausnummer (IP-Adresse + Port) ansieht, sich nicht dafuer interessiert, was in deinem Haus passiert.

Eigenschaften:

Extrem schnell: Nur einfache Adress-Weiterleitung, keine Paketinhaltsanalyse
Anwendungsfaelle: Datenbankverbindungen, Redis-Cache, Long-Polling-Game-Server
Repraesentative Produkte: LVS (Linux Virtual Server), AWS NLB, Azure Load Balancer

2.2 Layer-7-Load-Balancing (L7): Den Paketinhalt pruefen

Arbeitet auf der Anwendungsschicht (HTTP/HTTPS), wie ein Paketbote, der nicht nur die Hausnummer prueft, sondern auch das Paket oeffnet und den Inhalt untersucht, um basierend auf dem Inhalt zu entscheiden, wie es zugestellt wird.

Eigenschaften:

Intelligentes Routing: Kann basierend auf URL-Pfaden, HTTP-Headern, Cookies usw. praezise routen
Erweiterte Funktionen: SSL-Offloading, Inhalts-Caching, Komprimierung, WAF-Sicherheit
Anwendungsfaelle: Web-Anwendungen, API-Gateways, Microservice-Architektur
Repraesentative Produkte: Nginx, HAProxy, AWS ALB, Envoy

2.3 L4 vs L7 im Vergleich

Dimension	Layer-4 (L4)	Layer-7 (L7)
Schicht	Transportschicht (TCP/UDP)	Anwendungsschicht (HTTP/HTTPS)
Entscheidungsgrundlage	IP-Adresse + Port	URL, Header, Cookie, Body
Verarbeitungsgeschwindigkeit	Extrem schnell (Kernel-Mode)	Schnell (User-Mode-Analyse)
Funktionsumfang	Grundlegende Weiterleitung	SSL-Offloading, Caching, Komprimierung, WAF
Typische Szenarien	Datenbank, Gaming, Long-Polling	Web-Anwendungen, API-Gateway, Microservices
Repraesentative Produkte	LVS, AWS NLB	Nginx, HAProxy, AWS ALB

3. Kernproblem 1: Wie verhindert man, dass "kaputte" Server weiter Anfragen bekommen?

3.1 Health Checks: "Kranke" Server nicht das System belasten lassen

Stell dir vor, eine deiner Kassen ist ploetzlich defekt, aber der Zuteiler weiss es nicht und schickt weiterhin Kunden dorthin. Die Schlange wird immer laenger, die Kunden sind unzufrieden.

Health Checks (Gesundheitspruefungen) sind der "Wachposten", der dieses Problem verhindert. Sie fuehren regelmaessig "Gesundheitsuntersuchungen" bei jedem Server durch, entdecken "kranke" sofort und entfernen sie aus der Rotation. Wenn sie "genesen" sind, werden sie wieder aufgenommen.

3.2 Aktive vs. Passive Health Checks

Aktive Health Checks: Der Load Balancer klopft aktiv an und fragt "Bist du noch da?"

Regelmassig Pruef-Anfragen senden (z. B. HTTP /health, TCP ping) | Bei Zeitueberschreitung oder Fehler-Response als ungesund eingestuft
Vorteil: Genaue und zuverlaessige Ergebnisse
Nachteil: Erzeugt zusaetzlichen Probe-Traffic

Passive Health Checks: Der Load Balancer "beobachtet" die Antworten des echten Business-Traffics

| Antwortzeit und Fehlerrate tatsaechlicher Anfragen statistisch erfassen

Bei mehrfachen aufeinanderfolgenden Fehlern als ungesund eingestuft
Vorteil: Kein zusaetzlicher Traffic
Nachteil: Benoetigt ausreichend Traffic-Samples fuer eine zuverlaessige Bewertung

Haeufige Falle: Zu "empfindliche" Schwellenwerte

Ein Team hat den Schwellenwert fuer die Antwortzeit beim Health Check auf 100 ms gesetzt, waehrend die durchschnittliche Antwortzeit der Anwendung zwischen 80-120 ms schwankte. Das Ergebnis: Server wurden haeufig als "ungesund" markiert, was dazu fuehrte, dass der Traffic zwischen "gesund" und "ungesund" hin und her sprang - die Gesamtverfuegbarkeit des Systems sank tatsaechlich.

Richtige Vorgehensweise: Der Schwellenwert sollte auf das 2-3fache der P99-Antwortzeit gesetzt werden, um genuegend Puffer fuer normale Schwankungen zu lassen.

4. Kernproblem 2: Wie gewaehrleistet man, dass "Stammkunden" immer denselben "Kassierer" finden?

4.1 Session-Persistenz: "Stammkunden" immer denselben "Kassierer" bedienen lassen

Stell dir vor, du bist Stammkunde in einem Milchtee-Laden und wirst jedes Mal von derselben Bedienung bedient. Sie kennt deine Vorlieben (halber Zucker, kein Eis), der Service ist schnell und persoenlich. Aber wenn du jedes Mal jemand Neues bekommst, musst du deine Wuensche immer wieder wiederholen - ineffizient.

Session-Persistenz (Session Persistence / Sticky Session) loest genau dieses Problem: Es stellt sicher, dass Anfragen desselben Benutzers immer an denselben Backend-Server geroutet werden.

应用场景：

👤

用户A

👥

用户B

👨‍💼

用户C

请求

↓

⚖️负载均衡器

🍪

Cookie 插入

通过HTTP Cookie保持会话

会话映射表

sess_abc123→Server 1

sess_def456→Server 2

sess_ghi789→Server 1

↓

🖥️

Server 1

10.0.1.10

✓

选中

🖥️

Server 2

10.0.1.11

✓

🖥️

Server 3

10.0.1.12

✗

↑

三种会话保持机制对比

🍪Cookie 插入

✓不受客户端IP变化影响

✓首次请求即可保持会话

✗客户端需支持Cookie

✗存在Cookie被禁用的风险

#️⃣IP Hash

✓无需客户端支持任何机制

✓无状态，LB重启不影响会话

✗客户端IP变化会丢失会话

✗难以做到真正的负载均衡

📝粘性会话

✓结合Cookie和IP两种方式优势

✓支持会话复制和故障转移

✗实现复杂，需要应用支持

✗会话复制带来性能开销

4.2 Drei Mechanismen der Session-Persistenz im Vergleich

Mechanismus	Implementierung	Vorteile	Nachteile	Anwendungsfall
Cookie-Einfuegung	LB fuegt Cookie in Response ein, nachfolgende Anfragen tragen dieses Cookie	Unabhaengig von IP-Aenderungen, ab der ersten Anfrage persistent	Client muss Cookies unterstuetzen, koennten deaktiviert sein	Einkaufswagen, Login-Status
IP-Hash	Hash-Berechnung der Client-IP, Zuordnung zu einem bestimmten Server	Keine Client-Unterstuetzung erforderlich, zustandslos	Bei IP-Aenderung geht die Session verloren, schwer gleichmaessig zu verteilen	Ohne Cookies, WebSocket
Sticky-Session-Tabelle	LB verwaltet eine Zuordnungstabelle Session -> Server	Unterstuetzt Session-Replikation und Failover	Verbraucht LB-Speicher, erfordert zusaetzliche Synchronisation	Hochverfuegbarkeits-Anforderungen

5. Kernproblem 3: Wie realisiert man Zero-Downtime-Deployments?

5.1 Blue-Green Deployment: Zero-Downtime-Release durch "Umschalten per Knopfdruck"

Kerngedanke: Gleichzeitig zwei identische Produktionsumgebungen unterhalten (Blaue und Gruene Umgebung), aber nur eine Umgebung ist nach aussen hin aktiv.

🔵

蓝环境

v1.0.0

100% 流量

🟢

绿环境

v1.1.0

0% 流量

用户流量

👤

↓

⚖️

负载均衡器

当前指向: 🔵 蓝环境

↓

🔵蓝环境v1.0.0

🖥️B1●

🖥️B2●

🖥️B3●

🟢绿环境v1.1.0

🖥️G1●

🖥️G2●

🖥️G3●

蓝绿部署流程

绿环境部署

在绿环境部署新版本，进行冒烟测试

→

切换流量

将负载均衡器指向绿环境，流量瞬间切换

→

监控观察

观察绿环境运行状态，确认无异常

→

蓝环境升级

在蓝环境部署新版本，为下次切换做准备

蓝绿部署优缺点

✅优点

零停机时间：流量切换在毫秒级完成，用户无感知
快速回滚：发现问题可立即切回原环境，风险可控
完整的预发布测试：新环境可完整测试后再接管流量
数据一致性：无需处理新旧版本同时运行时的兼容问题

❌缺点

资源成本高：需要同时维护两套完整环境，服务器成本翻倍
数据库兼容性挑战：如果涉及数据库Schema变更，需要特别处理兼容性
预热问题：新环境启动后可能需要时间预热缓存、连接池等
不适合有状态服务：对于长连接、会话保持要求高的场景处理复杂

Workflow:

Initialzustand: Blaue Umgebung laeuft mit v1.0 (Produktion), Gruene Umgebung steht bereit.
Neue Version bereitstellen: Auf der Gruenen Umgebung v1.1 deployen und internen Smoketest durchfuehren.
Traffic umschalten: Den Load Balancer auf die Gruene Umgebung umleiten - Traffic schaltet sofort auf v1.1 um.
Ueberwachen und beobachten: Die Gruene Umgebung beobachten und sicherstellen, dass keine Anomalien auftreten.
Alte Version behalten: Die Blaue Umgebung bleibt mit v1.0 fuer einige Zeit (z. B. 24 Stunden) als Versicherung fuer schnelles Rollback.

5.2 Canary Release: "Kleine Schritte" als schrittweise Rollout-Strategie

Der Name stammt von den historischen "Bergbau-Kanarienvoegeln" - Bergarbeiter nahmen einen Kanarienvogel mit in die Mine. Zeigte der Vogel Anomalien, bedeutete das Giftgas und die Bergarbeiter evakuierten sofort. Beim Software-Release bedeutet Canary Release: Zunaechst einen kleinen Teil der Nutzer die neue Version testen lassen und nach Beobachtung schrittweise den Anteil erhoehen.

流量分配比例拖动滑块调整新旧版本流量占比

稳定版 v1.0.090%

金丝雀 v1.1.010%

实时流量模拟总请求: 0 | 稳定版: 0 | 金丝雀: 0

用户请求

→

负载均衡器

⚖️

Canary:10%

→

后端服务

稳定版 v1.0.0

📦S1

📦S2

📦S3

金丝雀 v1.1.0

🧪C1

🧪C2

金丝雀发布最佳实践

📊渐进式放量

1% → 5% → 10% → 25% → 50% → 100%
每个阶段观察至少15-30分钟
关键指标：错误率、延迟、吞吐量

🎯精准用户选择

内部员工/测试用户先行
按地域：选择特定区域用户
按用户属性：VIP用户或普通用户
按设备类型：iOS/Android/Web

🛡️自动回滚机制

错误率超过阈值自动回滚
P99延迟异常触发告警
关键业务指标下降自动回滚
一键回滚：30秒内恢复旧版本

📈监控与指标

基础设施：CPU、内存、磁盘、网络
应用指标：QPS、错误率、延迟分布
业务指标：转化率、订单量、收入
用户体验：页面加载时间、交互延迟

Kerngedanke:

Kleiner Traffic zuerst: Zunaechst 1% des Traffic auf die neue Version leiten.
Metriken beobachten: Kontinuierlich Fehlerrate, Latenz und geschaeftliche Kennzahlen ueberwachen.
Schrittweise erhoehen: Wenn alles normal, den Anteil schrittweise auf 5%, 10%, 25%, 50%, 100% erhoehen.
Schnelles Rollback: Sobald Anomalien entdeckt werden, sofort den gesamten Traffic zurueck auf die alte Version schalten.

6. Kernproblem 4: Wie bringt man das System dazu, selbst zu "atmen"?

6.1 Auto-Scaling: Das System wie ein Restaurant "flexibel besetzen" lassen

Stell dir vor, du betreibst ein Restaurant:

Mittagsspitze: 10 Kellner benoetigt, aber um 15 Uhr braucht man nur 2
Wenn immer 10 Kellner da sind: Personalkosten explodieren
Wenn immer nur 2 da sind: Zur Spitze warten die Kunden zu lange und gehen

Auto-Scaling laesst das System wie ein Restaurant "flexibel besetzen" - bei viel Traffic automatisch Server hinzufuegen, bei wenig Traffic automatisch abbauen.

扩容指标：

实时监控实时

💻CPU使用率

45%

扩容阈值: 70%缩容阈值: 30%

🧠内存使用率

60%

扩容阈值: 75%缩容阈值: 40%

⚡QPS

650req/s

扩容阈值: 1000/s目标: 800/s

🖥️运行实例

3个实例

最小: 2最大: 10

扩缩容历史最近 5 次操作

📈

扩容: 2 → 3 实例

CPU使用率超过70%