Gateway und Reverse Proxy

Kernfrage

Wie leitet man in einer hochparallelen Internetarchitektur Traffic sicher und effizient an die richtigen Dienste weiter? Reverse Proxy loest das Problem der "Traffic-Verteilung", API-Gateway das Problem der "Anfrageverarbeitung". Dieser Artikel verwendet reale Beispiele (Empfang, Sicherheitsysteme, intelligentes Routing), um die Designphilosophie und Engineering-Praxis von Gateways zu erklaeren.

1. Warum braucht man ein "Gateway"?

1.1 Ein reales Beispiel: Die Architektur-Evolution eines E-Commerce-Unternehmens

Ein E-Commerce-Unternehmen stiess bei schnellem Geschaeftswachstum auf ernsthafte Architekturprobleme:

Szenario-Rekonstruktion:

Phase 1: Dienste direkt exposen
Client -> direkte Aufrufe an Nutzer-Service, Bestell-Service, Zahlungs-Service...
         |
Problem 1: Service-IPs exponiert, Sicherheitsrisiko
Problem 2: Keine einheitliche Authentifizierung, kein Rate-Limiting
Problem 3: Neuer Service erfordert Aenderung der Client-Konfiguration

⚠️ Fatale Probleme bei direkter Exposition

Sicherheitsrisiko: Alle Service-IPs sind oeffentlich sichtbar und leicht angreifbar
Duplizierte Funktionalitaet: Jeder Service muss Authentifizierung, Rate-Limiting und Logging selbst implementieren
Schwierige Erweiterung: Neuer Service erfordert Aenderungen bei allen Clients
Protokoll-Chaos: Einige nutzen HTTP, andere gRPC - der Client muss sich anpassen

Verbesserte Architektur (mit Gateway):

Client -> API-Gateway (Nginx/Kong) -> Interne Dienste
         |
      Einheitliche Authentifizierung, Rate-Limiting, Routing
         |
      Client kennt nur die Gateway-Adresse

✨ Verbesserte Ergebnisse

Sicherheit: Echte Service-IPs verborgen, nur das Gateway ist extern sichtbar
Funktionskonsolidierung: Authentifizierung, Rate-Limiting und Logging zentral im Gateway
Einfache Erweiterung: Neuer Service erfordert nur eine neue Route im Gateway
Einheitliches Protokoll: Extern HTTP, intern kann gRPC verwendet werden

1.2 Alltags-Analogie fuer Gateways

Der Empfang

Stell dir vor, du besuchst ein grosses Unternehmen:

Ohne Empfang: Besucher gehen direkt zu den Abteilungen, wissen nicht wohin, das Unternehmen ist im Chaos
Mit Empfang: Besucher kommen zunaechst zum Empfang, der Empfraegt nach dem Anliegen und leitet sie an die richtige Abteilung weiter

Das API-Gateway ist der "Empfang" des Systems:

Reverse Proxy: Der Empfang, der Besucher zur richtigen Abteilung leitet
API-Gateway: Ein intelligenter Empfang, der auch die Identitaet der Besucher prueft (Authentifizierung) und die Besucherzahl begrenzt (Rate-Limiting)

👤

用户 (浏览器)

→

访问域名

🛡️

反向代理 (Nginx)

代理服务器

→

负载均衡

⚙️

后端服务器集群

Web1 | Web2 | Web3

🛡️ 反向代理特点

客户端无感知，只需要访问域名
隐藏真实服务器架构，统一对外接口
提供负载均衡、安全防护、SSL卸载等功能
典型代表：Nginx、HAProxy、AWS ELB

💡 典型使用场景

网站需要承载高并发流量（负载均衡）
统一HTTPS证书管理（SSL卸载）
防护DDoS攻击和SQL注入
灰度发布、A/B测试、蓝绿部署

🧠 记忆口诀

"反向代理 = 代理服务器" —— 客户端不知道真实服务器，只知道域名

2. Was ist ein Reverse Proxy?

2.1 Forward Proxy vs. Reverse Proxy

Begriffserklaerung

Forward Proxy (Vorwaerts-Proxy):

Auf der Client-Seite bereitgestellt
Vertritt den Client beim Zugriff auf externe Ressourcen
Typische Anwendungen: VPN, Proxy-Tools
Beispiel: Unternehmensnetzwerk - du greifst ueber einen Proxy auf externe Ressourcen zu

Reverse Proxy (Reverse Proxy):

Auf der Server-Seite bereitgestellt
Empfängt Client-Anfragen und leitet sie an interne Dienste weiter
Der Client kennt nur den Proxy, nicht die echten Server
Beispiele: Nginx, HAProxy

Vergleichstabelle:

Dimension	Forward Proxy	Reverse Proxy
Bereitstellungsposition	Client-Seite	Server-Seite
Dient	Dem Client	Dem Server
Typische Anwendungen	VPN, Proxy	Load Balancing, Gateway
Transparenz	Server sieht die Proxy-IP	Client sieht die Proxy-IP
Zweck	Echten Client verbergen, Zugriff beschleunigen	Echten Server verbergen, Load Balancing

2.2 Kernwert von Reverse Proxy

Wert 1: Load Balancing

Verteilt Traffic auf mehrere Backend-Server und verhindert Ueberlastung einzelner Server.

Client
  |
Nginx (Reverse Proxy)
  |
┌─────────┬─────────┬─────────┐
│ Server 1 │ Server 2 │ Server 3 │
└─────────┴─────────┴─────────┘

Wert 2: Sicherheitsabschirmung

Verbirgt die echten Server-IPs und verhindert direkte Angriffe. Einheitliche Sicherheitsmassnahmen auf Proxy-Ebene.

Client -> sieht nur die Nginx-IP
Echte Server -> Nur im internen Netzwerk, von aussen nicht direkt erreichbar

Wert 3: SSL-Terminierung

HTTPS-Verschluesselung/Entschluesselung auf Proxy-Ebene. Backend-Dienste nutzen HTTP, was die Backend-Rechenlast reduziert.

HTTPS-Client -> Nginx (Verschluesselung/Entschluesselung) -> HTTP-Backend-Dienst
                   |
              SSL-Terminierungspunkt

3. Nginx: Warum kann es Millionen parallele Verbindungen bewaeltigen?

3.1 Master-Worker-Prozessmodell

Nginx verwendet eine Multi-Prozess-Architektur statt Multi-Threading:

Master-Prozess (Verwalter):

Liest und validiert Konfigurationsdateien
Verwaltet Worker-Prozesse (Start, Stopp, Neuladen)
Verarbeitet keine konkreten Anfragen

Worker-Prozesse (Arbeiter):

Verarbeiten tatsaechlich HTTP-Anfragen
Jeder Worker ist ein unabhaengiger Prozess, voneinander isoliert
Die Anzahl wird ueblicherweise auf die Anzahl der CPU-Kerne gesetzt, um Kontextwechsel-Overhead zu vermeiden

Vorteile

Gute Isolierung: Ein Worker-Absturz betrifft nicht die anderen Worker
Volle Mehrkern-Ausnutzung: Jeder Worker laeuft unabhaengig
Keine Multi-Threading-Komplexitaet: Keine Notwendigkeit fuer Locks, Race Conditions etc.

3.2 Event-Driven + Asynchron Nicht-Blockierend

Das ist das Kerngeheimnis von Nginx's hoeher Performance:

Traditionelles Apache (Multi-Prozess/Thread-Modell):

Eine Verbindung = ein Prozess/Thread
Paralleilitaet durch System-Prozess/Thread-Anzahl begrenzt
Bei vielen Verbindungen enormer Prozesswechsel-Overhead

Nginx (Event-Driven-Modell):

Verwendet epoll (Linux)/kqueue (macOS) fuer effizientes I/O-Multiplexing
Ein Worker-Prozess kann gleichzeitig Zehntausende Verbindungen verarbeiten | Verbindungen ohne Daten belegen keine CPU, bei neuen Daten erfolgt eine Event-Benachrichtigung

Alltags-Analogie

Apache: Im Restaurant bekommt jeder Kunde einen eigenen Kellner (Prozess), viele Kunden erfordern viele Kellner
Nginx: Ein Super-Kellner, der alle Kunden gleichzeitig bedient, dorthin geht, wer Service braucht, anstatt bei einem Kunden zu stehen

Nginx 进程架构图

👑

Master 进程

管理所有 Worker，负责配置加载、平滑升级

4 个 Worker

⚙️

Worker 1

处理 0 请求

⚙️

Worker 2

处理 0 请求

⚙️

Worker 3

处理 0 请求

⚙️

Worker 4

处理 0 请求

📡 epoll (Linux) / kqueue (macOS)

事件驱动：一个 Worker 同时处理数万个连接

传统 Apache

一个连接 = 一个进程/线程

❌ C10K 问题

Nginx

事件驱动 + 异步非阻塞

✅ 百万并发

🎮 模拟请求处理

💡 生产环境建议

Worker 数量 = CPU 核心数（通常设置为 auto，让 Nginx 自动检测）
太多了上下文切换开销大，太少了无法利用多核性能。

4. Was ist ein API-Gateway?

4.1 Warum braucht man ein API-Gateway?

Stell dir ein System ohne Gateway vor:

Der Client muss die Adressen mehrerer Dienste kennen (Nutzer-Service, Bestell-Service, Zahlungs-Service...)
Jeder Service muss selbst Authentifizierung, Rate-Limiting und Logging implementieren
Protokolle sind nicht einheitlich, einige nutzen HTTP, andere gRPC
Bei Service-Upgrades muss auch der Client geaendert werden

Mit einem API-Gateway:

Der Client kennt nur die Gateway-Adresse, das Gateway leitet an den richtigen Service weiter
Querschnittsthemen wie Authentifizierung, Rate-Limiting und Logging werden zentral im Gateway behandelt
Das Gateway kann Protokollkonvertierung durchfuehren und nach aussen einheitlich HTTP exposen | Backend-Service-Upgrades erfordern nur Aenderungen in der Gateway-Konfiguration - der Client merkt nichts davon

客户端 (来访者)

📱 App

💻 Web

🔧 第三方

⬇️ 统一入口

🚪 API 网关 (前台)

🔐身份认证

⚡限流熔断

🧭路由转发

🔄协议转换

⬇️ 分发请求

⚙️ 后端服务 (各个部门)

👤

用户服务

/api/users

📦

订单服务

/api/orders

💳

支付服务

/api/pay

🔐身份认证

统一校验用户身份，无需每个后端服务都写登录逻辑。支持 JWT、OAuth2、API Key 等多种认证方式。

💡 实际场景

用户请求携带 JWT Token，网关校验签名和过期时间，通过后把用户ID添加到请求头转发给后端服务。

🤔 没有网关 vs 有网关的区别

功能需求	没有网关 (直接访问)	有 API 网关
身份认证	每个服务都要写一遍登录校验	✅ 统一在网关层校验 JWT
限流保护	每个服务自己实现限流	✅ 网关统一限流，保护后端
协议转换	HTTP、gRPC、WebSocket各自处理	✅ 网关统一对外暴露 HTTP
灰度发布	需要改负载均衡器配置	✅ 网关层按 Header 路由

4.2 Kernfunktionen eines API-Gateways

Funktion	Beschreibung	Typische Szenarien
Routing	Anfragen basierend auf URL, Headern etc. an verschiedene Dienste weiterleiten	`/api/users` -> Nutzer-Service, `/api/orders` -> Bestell-Service
Load Balancing	Bei mehreren Instanzen desselben Service: Traffic verteilen	Nutzer-Service hat 3 Instanzen, Round-Robin-Verteilung
Authentifizierung	Einheitliche JWT- und OAuth-Token-Validierung	Nicht eingeloggte Nutzer koennen `/api/admin` nicht aufrufen
Rate-Limiting und Circuit-Breaking	Traffic-Obergrenzen steuern, Ueberlastung verhindern	Max. 1000 Anfragen pro Sekunde, darueber 429 zurueckgeben
Protokollkonvertierung	Extern HTTP, intern kann gRPC verwendet werden	Client nutzt HTTP, Gateway konvertiert zu gRPC fuer interne Dienste
Canary Release	Nach Headern oder Proportionen Teile des Traffic an die neue Version leiten	5% der Nutzer sehen die neue Version, 95% die alte
Logging und Monitoring	Einheitliche Anfrage-Protokollierung fuer Analyse und Fehlerbehebung	Protokolliert Dauer, Statuscode und Antwortgroesse jeder Anfrage

5. Gateway-Praxis: Eine vollstaendige Gateway-Architektur aufbauen

5.1 Routing und Load Balancing

Routing-Regeln: Von der URL zum Service

Nginx-Konfigurationsbeispiel:

nginx

server {
    listen 80;
    server_name api.example.com;

    # Nutzer-Service
    location /api/users/ {
        proxy_pass http://user-service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # Bestell-Service
    location /api/orders/ {
        proxy_pass http://order-service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # Zahlungs-Service (hoehere Sicherheitsanforderungen)
    location /api/pay/ {
        allow 10.0.0.0/8;
        deny all;

        proxy_pass http://payment-service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Load Balancing: Vier Strategien im Vergleich

Strategie	Prinzip	Anwendungsfall	Vorteile	Nachteile
Round-Robin	Sequentielle Zuteilung an jeden Server	Aehnliche Serverleistung	Einfach und fair	Beruecksichtigt nicht aktuelle Serverlast
Weighted Round-Robin	Zuteilung nach Gewichtung, leistungsstaerkere Server bekommen mehr	Unterschiedliche Serverleistung	Hochleistungs-Server besser genutzt	Gewichtung muss sinnvoll konfiguriert werden
Least Connections	Zuteilung an den Server mit den wenigsten Verbindungen	Long-Polling, Video-Streaming	Dynamische Anpassung an Lastaenderungen	Erfordert Echtzeit-Verbindungsstatistik
IP-Hash	Hash basierend auf Client-IP, dieselbe IP immer zum selben Server	Session-Persistenz erforderlich	Garantiert Session-Konsistenz	Einzelne IP mit viel Traffic erzeugt Hotspot

选择负载均衡策略

🎮 负载均衡模拟器

💡

轮询 - 挨个分发，雨露均沾

按照服务器列表的顺序，依次将请求分配给每台服务器。就像银行叫号，1号窗口完事了到2号，2号完事了到3号，轮着来。

🏢 后端服务器集群

服务器数量:4 台

🖥️

Server-A

10%

请求数:0

权重:1

最近请求:

🖥️

Server-B

48%

请求数:0

权重:4

最近请求:

🖥️

Server-C

26%

请求数:0

权重:3

最近请求:

🖥️

Server-D

36%

请求数:0

权重:2

最近请求:

📨 请求队列

总请求: 0待处理: 0

📊 负载分布统计

30%

平均负载

48%

最高负载

13.9

负载标准差

Server-B

最忙服务器

6. Gateway-Sicherheit: Wie bewacht man das System-Tor?

6.1 Authentifizierung und Autorisierung

Kernidee

Authentifizierung im Gateway, Autorisierung im Service:

Authentifizierung: Wer bist du? (Token validieren, Benutzeridentitaet abrufen)
Autorisierung: Was darfst du tun? (Basierend auf Benutzerrolle Berechtigungen pruefen)

Wie im Unternehmen: Der Empfang authentifiziert deine Identitaet (Ausweis), aber die konkreten Berechtigungen werden von den Abteilungen geprueft.

JWT (JSON Web Token) 认证流程

用户

输入用户名密码，点击登录

↓

网关/Nginx

转发登录请求到认证服务

↓

认证服务

验证密码，生成 JWT Token（包含 Header、Payload、Signature）

↓

用户/客户端

保存 Token（LocalStorage 或 Cookie）

↓

后续请求

在 HTTP Header 中携带: Authorization: Bearer <Token>

↓

网关/Nginx

校验 Token 签名和过期时间，通过后转发请求

↓

后端服务

从 Token 中解析用户信息，处理业务逻辑

🔑 JWT Token 结构（Base64编码）

PAYLOAD

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ

{ "sub": "1234567890", "name": "John Doe", "iat": 1516239022 }

SIGNATURE

SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

HMACSHA256(base64Url(header) + "." + base64Url(payload), secret)

🛠️ 三种方案实现对比

对比维度	Session + Cookie	JWT	OAuth2.0
存储位置	服务端存储 Session，客户端存 Cookie	客户端存储 Token，服务端无状态	授权服务器存储，客户端存 Access Token
扩展性	❌ 需要共享 Session，扩展复杂	✅ 无状态，易于水平扩展	✅ 分布式架构，支持大规模系统
安全性	⚠️ Cookie 可能被窃取，需要 CSRF 防护	⚠️ Token 泄露风险，需 HTTPS + 短期有效	✅ 行业最佳实践，支持多种安全机制
实现复杂度	🟢 简单，开箱即用	🟡 中等，需要 Token 管理	🔴 复杂，需要授权服务器
适用场景	传统 Web 应用、后台管理系统	SPA、移动端 API、微服务	第三方登录、开放平台、SSO

🔒 网关层认证最佳实践

统一在网关层验证

不要在每个微服务里重复写认证逻辑，统一在网关层校验 JWT 或 Session

HTTPS 强制

网关层强制 HTTPS，防止 Token 在传输过程中被窃取（中间人攻击）

Token 过期策略

Access Token 短期有效（15分钟），配合 Refresh Token 实现无感知续期

黑名单机制

用户登出或 Token 泄露时，将 Token 加入黑名单（Redis 存储）

6.2 HTTPS und SSL-Terminierung

Warum HTTPS?

Sicherheit: Verhindert Datenabfang waehrend der Uebertragung
Compliance: Moderne Browser zeigen "Nicht sicher"-Warnung bei HTTP-Websites
SEO: Suchmaschinen bevorzugen HTTPS-Websites

SSL-Terminierung:

HTTPS und Zertifikate nur auf Gateway-Ebene konfigurieren
Das Gateway uebernimmt TLS-Handshake und Ver-/Entschluesselung | Zwischen Gateway und Backend-Diensten wird HTTP im Klartext verwendet (internes Netzwerk als vertrauenswuerdig)
Backend-Dienste konzentrieren sich auf Geschaeftslogik, muessen TLS nicht behandeln

🔐 HTTPS 流量解密流程

👤

客户端 (浏览器)

发起 HTTPS 请求

🔒TLS 加密连接

证书: *.example.com

算法: TLS 1.3

加密: AES-256-GCM

🚪

Nginx (SSL 终结)

📜 校验证书

🔓 解密流量

📝 添加 X-Forwarded-*

🔓HTTP 明文

X-Forwarded-For: 203.0.113.42

X-Forwarded-Proto: https

X-Real-IP: 203.0.113.42

⚙️

后端服务集群

专注于业务逻辑，无需处理 TLS

📜 SSL 证书管理

生成私钥

使用 OpenSSL 生成 RSA 私钥，这是证书的基础

openssl genrsa -out private.key 2048

创建 CSR

生成证书签名请求，包含域名和组织信息

openssl req -new -key private.key -out csr.pem

域名验证

CA 机构验证域名所有权（DNS 记录或 HTTP 文件）

# 添加 DNS TXT 记录或上传验证文件到 /.well-known/

签发证书

验证通过后，CA 签发证书文件

# 下载 certificate.crt 和 chain.crt

部署配置

将证书配置到 Nginx 并测试

nginx -t && systemctl reload nginx

✨ SSL 终结的核心优势

🚀

性能提升

TLS 握手和加密解密是 CPU 密集型操作，集中在 Nginx 处理，后端服务专注业务逻辑，整体吞吐量提升 2-5 倍

🔧

简化运维

证书统一管理，只需在 Nginx 配置一次，无需在每个后端服务重复配置，证书续期、更换一键完成

🛡️

集中安全

SSL/TLS 配置统一管控，强制使用最新协议版本和密码套件，统一添加安全响应头（HSTS、CSP 等）

📊

统一监控

所有 HTTPS 流量经过 Nginx，可以统一记录访问日志、分析 SSL 握手性能、监控证书有效期，便于审计和排障

7. Rate-Limiting und Circuit-Breaking: Wie verhindert man, dass das System von einer "Traffic-Flut" weggespuelt wird?

7.1 Vergleich von Rate-Limiting-Algorithmen

Algorithmus	Kernidee	Burst-Traffic	Anwendungsfall	Komplexitaet
Token Bucket	Tokens im Bucket, nur mit Token wird durchgelassen	Begrenzter Burst erlaubt	API-Rate-Limiting, Bandbreitenkontrolle	Mittel
Leaky Bucket	Anfragen fließen in den Bucket, werden gleichmaessig abgearbeitet	Erzwungene Glättung, Burst wird gepuffert oder abgelehnt	Szenarien mit streng gleichmaessiger Verarbeitung	Mittel
Sliding Window	Zaehlt Anfragen innerhalb eines Zeitfensters	Streng nach Fenster, Ueberschuss wird abgelehnt	Praezise Zaehlung (z. B. "max. 100 pro Minute")	Hoeher

7.2 Nginx Rate-Limiting-Konfiguration

nginx

# Rate-Limiting-Zone definieren (im http-Block)

# 1. IP-basiertes Rate-Limiting (Leaky-Bucket-Algorithmus)
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

# 2. IP-basierte Verbindungsbegrenzung
limit_conn_zone $binary_remote_addr zone=addr:10m;

server {
    listen 80;
    server_name api.example.com;

    # Nutzer-Service - normales Rate-Limiting
    location /api/users/ {
        limit_req zone=mylimit burst=20 nodelay;
        limit_conn addr 10;

        proxy_pass http://user-service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # Bestell-Service - strengeres Rate-Limiting
    location /api/orders/ {
        limit_req_zone $binary_remote_addr zone=order_limit:10m rate=5r/s;
        limit_req zone=order_limit burst=10 nodelay;

        proxy_pass http://order-service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # Behandlung bei Rate-Limiting
    error_page 429 /429.html;
    location = /429.html {
        internal;
        return 429 '{"error": "Too Many Requests", "message": "Rate limit exceeded. Please try again later."}';
        add_header Content-Type application/json;
    }
}

选择限流算法

🪙 令牌桶算法可视化

令牌桶

🪙

5 / 10 令牌

⏰ 令牌产生器 (2/秒)

🪙

📥 请求队列

📊 三种算法对比

维度	令牌桶 (Token Bucket)	漏桶 (Leaky Bucket)	滑动窗口 (Sliding Window)
核心思想	桶里装令牌，有令牌才能通过	请求进桶，匀速流出处理	统计时间窗口内的请求数
突发流量	✅ 允许一定程度的突发（桶里有令牌）	❌ 强制平滑，突发会被缓存或拒绝	❌ 严格按窗口计数，超出一律拒绝
适用场景	API 限流、带宽控制（允许突发）	需要严格匀速处理的场景（如消息队列）	精确统计（如"1分钟内最多100次"）
实现复杂度	中等	中等	较高（需要记录每个时间窗口的请求）
Nginx 配置	limit_req_zone (漏桶)	limit_req_zone (漏桶)	需第三方模块或 Lua

📝 Nginx 限流配置示例

# 定义限流区域
# $binary_remote_addr: 按 IP 限流
# zone=mylimit:10m: 区域名称和大小
# rate=10r/s: 每秒最多10个请求
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

server {
    listen 80;
    server_name api.example.com;

    location / {
        # 应用限流
        # burst=20: 桶容量，允许突发20个请求
        # nodelay: 不延迟处理突发请求
        limit_req zone=mylimit burst=20 nodelay;

        proxy_pass http://backend;
    }
}

💡 配置说明

limit_req_zone: 在 http 块中定义限流区域
$binary_remote_addr: 使用二进制 IP 地址作为限流键（省内存）
zone=mylimit:10m: 区域名称 mylimit，分配 10MB 内存
rate=10r/s: 每秒允许 10 个请求（漏桶算法）
burst=20: 桶的容量为 20，允许一定程度的突发流量
nodelay: 不延迟处理突发请求（立即处理或拒绝）

7.3 Circuit-Breaking: Fehlerausbreitung verhindern

Funktionsweise des Circuit-Breakers:

Geschlossen: Anfragen werden normal weitergeleitet, gleichzeitig wird die Fehlerrate erfasst
Geoeffnet: Wenn die Fehlerrate den Schwellenwert ueberschreitet, oeffnet sich der Breaker und gibt direkt einen Fehler zurueck, ohne Anfragen weiterzuleiten
Halb-geoeffnet: Nach einer gewissen Zeit werden wenige Anfragen zum Testen durchgelassen - bei Erfolg wird der Breaker geschlossen

Kernidee

Circuit-Breaking ist wie eine elektrische Sicherung: Bei Ueberstrom schmilzt die Sicherung automatisch und schuetzt den gesamten Stromkreis vor dem Durchbrennen.

Aehnlich: Wenn der Backend-Dienst viele Fehler produziert, "loest" der Breaker aus und schlaegt schnell fehl, um eine Fehlerausbreitung im gesamten System zu verhindern.

8. Zusammenfassung: Kerngedanken des Gateway-Designs

8.1 Zusammenfassung der Kernprinzipien

Prinzip	Bedeutung	Praktische Hinweise
Routing	Anfragen an den richtigen Ort leiten	Pfad-Routing, Domain-Routing, Header-Routing
Load Balancing	Traffic auf mehrere Server verteilen	Round-Robin, Gewichtet, Least Connections, IP-Hash
Sicherheit	Das System-Tor bewachen	Authentifizierung, HTTPS, WAF
Rate-Limiting	Vor Ueberflutung schuetzen	Token Bucket, Leaky Bucket, Sliding Window
Circuit-Breaking	Fehlerausbreitung verhindern	Schnelles Fehlschlagen, Degradierung
Observability	Monitoring und Fehlerbehebung	Logs, Metriken, Tracing

8.2 Technologieauswahl

Entscheidungsbaum

Gateway auswaehlen:
|
├─ Nur Reverse Proxy und Load Balancing noetig?
│  ├─ Ja -> Nginx (erste Wahl)
│  └─ Nein -> Weiter
│
├─ Reichhaltiges Plugin-Oekosystem noetig?
│  ├─ Ja -> Kong (basiert auf Nginx)
│  └─ Nein -> Weiter
│
├─ Spring Cloud Full-Stack?
│  ├─ Ja -> Spring Cloud Gateway
│  └─ Nein -> Nginx

9. Glossar

Begriff	Englisch	Erklaerung
Reverse Proxy	Reverse Proxy	Auf der Server-Seite bereitgestellter Proxy, der Client-Anfragen empfängt und an interne Dienste weiterleitet.
Forward Proxy	Forward Proxy	Auf der Client-Seite bereitgestellter Proxy, der den Client beim Zugriff auf externe Ressourcen vertritt.
API-Gateway	API Gateway	Zwischenschicht zwischen Client und Backend-Diensten, bietet Routing, Authentifizierung, Rate-Limiting und weitere Funktionen.
Load Balancing	Load Balancing	Verteilt Anfragen-Traffic auf mehrere Server, verhindert Ueberlastung einzelner Server.
SSL-Terminierung	SSL Termination	HTTPS-Verschluesselung/Entschluesselung auf Gateway-Ebene, Backend nutzt HTTP.
Rate-Limiting	Rate Limiting	Beschraenkt die Anzahl der Anfragen pro Zeiteinheit. Algorithmen: Token Bucket, Leaky Bucket, Sliding Window.
Circuit-Breaking	Circuit Breaking	Automatische Unterbrechung von Aufrufen bei Dienstausfaellen, verhindert Fehlerkaskaden.
Session-Persistenz	Session Persistence	Stellt sicher, dass Anfragen desselben Clients immer an denselben Backend-Server geroutet werden.
Health Check	Health Check	Regelmässige Pruefung der Gesundheit von Backend-Servern, automatisches Entfernen ausgefallener Knoten.
Canary Release	Canary Release	Leitet einen kleinen Teil des Traffic zur neuen Version, um die Stabilitaet schrittweise zu validieren.
WAF	Web Application Firewall	Web-Applikations-Firewall zum Schutz vor SQL-Injection, XSS, CC-Angriffen.
CDN	Content Delivery Network	Content Delivery Network mit weltweiten Edge-Knoten zur Beschleunigung statischer Ressourcen.

Gateway und Reverse Proxy ​

1. Warum braucht man ein "Gateway"? ​

1.1 Ein reales Beispiel: Die Architektur-Evolution eines E-Commerce-Unternehmens ​

1.2 Alltags-Analogie fuer Gateways ​

2. Was ist ein Reverse Proxy? ​

2.1 Forward Proxy vs. Reverse Proxy ​

2.2 Kernwert von Reverse Proxy ​

3. Nginx: Warum kann es Millionen parallele Verbindungen bewaeltigen? ​

3.1 Master-Worker-Prozessmodell ​

3.2 Event-Driven + Asynchron Nicht-Blockierend ​

4. Was ist ein API-Gateway? ​

4.1 Warum braucht man ein API-Gateway? ​

4.2 Kernfunktionen eines API-Gateways ​

5. Gateway-Praxis: Eine vollstaendige Gateway-Architektur aufbauen ​

5.1 Routing und Load Balancing ​

6. Gateway-Sicherheit: Wie bewacht man das System-Tor? ​

6.1 Authentifizierung und Autorisierung ​

6.2 HTTPS und SSL-Terminierung ​

7. Rate-Limiting und Circuit-Breaking: Wie verhindert man, dass das System von einer "Traffic-Flut" weggespuelt wird? ​

7.1 Vergleich von Rate-Limiting-Algorithmen ​

7.2 Nginx Rate-Limiting-Konfiguration ​

7.3 Circuit-Breaking: Fehlerausbreitung verhindern ​

8. Zusammenfassung: Kerngedanken des Gateway-Designs ​

8.1 Zusammenfassung der Kernprinzipien ​

8.2 Technologieauswahl ​

9. Glossar ​

Gateway und Reverse Proxy

1. Warum braucht man ein "Gateway"?

1.1 Ein reales Beispiel: Die Architektur-Evolution eines E-Commerce-Unternehmens

1.2 Alltags-Analogie fuer Gateways

2. Was ist ein Reverse Proxy?

2.1 Forward Proxy vs. Reverse Proxy

2.2 Kernwert von Reverse Proxy

3. Nginx: Warum kann es Millionen parallele Verbindungen bewaeltigen?

3.1 Master-Worker-Prozessmodell

3.2 Event-Driven + Asynchron Nicht-Blockierend

4. Was ist ein API-Gateway?

4.1 Warum braucht man ein API-Gateway?

4.2 Kernfunktionen eines API-Gateways

5. Gateway-Praxis: Eine vollstaendige Gateway-Architektur aufbauen

5.1 Routing und Load Balancing

6. Gateway-Sicherheit: Wie bewacht man das System-Tor?

6.1 Authentifizierung und Autorisierung

6.2 HTTPS und SSL-Terminierung

7. Rate-Limiting und Circuit-Breaking: Wie verhindert man, dass das System von einer "Traffic-Flut" weggespuelt wird?

7.1 Vergleich von Rate-Limiting-Algorithmen

7.2 Nginx Rate-Limiting-Konfiguration

7.3 Circuit-Breaking: Fehlerausbreitung verhindern

8. Zusammenfassung: Kerngedanken des Gateway-Designs

8.1 Zusammenfassung der Kernprinzipien

8.2 Technologieauswahl

9. Glossar