Gateway y Proxy Inverso

🎯 Pregunta Central

En una arquitectura de internet de alta concurrencia, ¿cómo enrutar el tráfico de forma segura y eficiente al servicio correcto? El proxy inverso resuelve "cómo distribuir el tráfico", y el API Gateway resuelve "cómo procesar las solicitudes". Este artículo utiliza casos reales (recepcionista, sistema de seguridad, enrutamiento inteligente) para comprender a fondo la filosofía de diseño y la práctica de ingeniería de los gateways.

1. ¿Por qué necesitamos un "Gateway"?

1.1 Un caso real: la evolución de la arquitectura de un e-commerce

Una plataforma de e-commerce encontró graves problemas de arquitectura durante su rápido crecimiento:

Escenario:

Fase 1: Exposición directa de servicios
Cliente → Llama directamente al servicio de usuarios, servicio de pedidos, servicio de pagos...
         ↓
Problema 1: Las IPs de los servicios quedan expuestas, riesgo de seguridad
Problema 2: No se puede unificar autenticación ni limitación de tasa
Problema 3: Añadir nuevos servicios requiere modificar la configuración del cliente

⚠️ Problemas fatales de la exposición directa

Riesgo de seguridad: Todas las IPs de los servicios expuestas, vulnerables a ataques
Funcionalidad duplicada: Cada servicio debe implementar autenticación, limitación de tasa y logs
Difícil de escalar: Añadir un nuevo servicio requiere modificar todos los clientes
Protocolos inconsistentes: Algunos usan HTTP, otros gRPC, los clientes deben adaptarse a todos

Arquitectura mejorada (con Gateway):

Cliente → API Gateway (Nginx/Kong) → Servicios internos
         ↓
      Autenticación, limitación de tasa y enrutamiento unificados
         ↓
      El cliente solo conoce la dirección del gateway

✨ Beneficios tras la mejora

Seguridad: Las IPs reales de los servicios quedan ocultas, solo el gateway está expuesto
Funcionalidad consolidada: Autenticación, limitación de tasa y logs se manejan de forma unificada en el gateway
Fácil de escalar: Añadir un nuevo servicio solo requiere configurar el enrutamiento en el gateway
Protocolo unificado: HTTP hacia el exterior, gRPC posible en el interior

1.2 Analogía cotidiana del Gateway

Recepcionista

Imagina que visitas una gran empresa:

Sin recepcionista: Los visitantes buscan directamente cada departamento, no saben dónde ir, la empresa es un caos
Con recepcionista: Los visitantes pasan primero por recepción, el recepcionista pregunta el motivo y los guía al departamento correspondiente

El API Gateway es el "recepcionista" del sistema:

Proxy inverso: Recepcionista, guía a los visitantes al departamento correcto
API Gateway: Recepcionista inteligente, también verifica la identidad del visitante (autenticación) y limita el número de visitantes (limitación de tasa)

👤

用户 (浏览器)

→

访问域名

🛡️

反向代理 (Nginx)

代理服务器

→

负载均衡

⚙️

后端服务器集群

Web1 | Web2 | Web3

🛡️ 反向代理特点

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

💡 典型使用场景

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

🧠 记忆口诀

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

2. ¿Qué es un Proxy Inverso?

2.1 Proxy Directo vs Proxy Inverso

🤔 Explicación de términos

Proxy Directo (Forward Proxy):

Desplegado en el lado del cliente
Accede a recursos externos en nombre del cliente
Aplicaciones típicas: VPN, herramientas para saltar el firewall
Ejemplo: En la red de la empresa, accedes a internet a través de un proxy

Proxy Inverso (Reverse Proxy):

Desplegado en el lado del servidor
Recibe solicitudes de los clientes y las reenvía a los servicios internos
El cliente solo conoce el proxy, no los servidores reales
Ejemplos: Nginx, HAProxy

Tabla comparativa:

Dimensión	Proxy Directo	Proxy Inverso
Ubicación	Lado del cliente	Lado del servidor
A quién sirve	Al cliente	Al servidor
Aplicación típica	VPN, saltar restricciones	Balanceo de carga, Gateway
Transparencia	El servidor ve la IP del proxy	El cliente ve la IP del proxy
Propósito	Ocultar el cliente real, acelerar acceso	Ocultar el servidor real, balanceo de carga

2.2 Valor central del Proxy Inverso

Valor 1: Balanceo de carga

Distribuye el tráfico entre múltiples servidores backend para evitar la sobrecarga de un solo punto.

Cliente
  ↓
Nginx (Proxy Inverso)
  ↓
┌───────────┬───────────┬───────────┐
│ Servidor 1│ Servidor 2│ Servidor 3│
└───────────┴───────────┴───────────┘

Valor 2: Protección de seguridad

Oculta las IPs reales de los servidores, previniendo ataques directos. La protección de seguridad se unifica en la capa del proxy.

Cliente → Solo ve la IP de Nginx
Servidores reales → Solo en la red interna, inaccesibles desde el exterior

Valor 3: Terminación SSL

El cifrado/descifrado HTTPS se maneja en la capa del proxy, los servicios backend usan HTTP, reduciendo la sobrecarga de cómputo en el backend.

Cliente HTTPS → Nginx (cifrado/descifrado) → Servicio backend HTTP
                       ↑
              Punto de terminación SSL

3. Nginx: ¿Cómo maneja millones de conexiones concurrentes?

3.1 Modelo de procesos Master-Worker

Nginx utiliza una arquitectura multiproceso, no multihilo:

Proceso Master (Administrador):

Responsable de leer y validar archivos de configuración
Gestiona los procesos Worker (iniciar, detener, recargar)
No procesa solicitudes concretas

Procesos Worker (Trabajadores):

Procesan las solicitudes HTTP
Cada Worker es un proceso independiente, aislado de los demás
La cantidad suele configurarse igual al número de núcleos de CPU, para evitar sobrecarga por cambio de contexto

💡 Ventajas

Buen aislamiento: Si un Worker falla, no afecta a los demás
Aprovechamiento multinúcleo: Cada Worker se ejecuta de forma independiente
Evita la complejidad del multihilo: No hay que manejar bloqueos, condiciones de carrera, etc.

3.2 Event-driven + E/S asíncrona no bloqueante

Este es el secreto central del alto rendimiento de Nginx:

Apache tradicional (modelo multiproceso/multihilo):

Una conexión = Un proceso/hilo
La concurrencia está limitada por el número de procesos/hilos del sistema
Con muchas conexiones, la sobrecarga por cambio de contexto es enorme

Nginx (modelo event-driven):

Usa mecanismos eficientes de multiplexación de E/S como epoll (Linux) / kqueue (macOS)
Un proceso Worker puede manejar decenas de miles de conexiones simultáneamente
Cuando una conexión no tiene datos, no consume CPU; cuando hay datos nuevos, se despierta mediante notificación de eventos

Analogía cotidiana

Apache: Un restaurante donde cada cliente tiene un camarero dedicado (proceso); con muchos clientes se necesitan muchos camareros
Nginx: Un supercamarero que atiende a todos los clientes simultáneamente, va a quien necesita servicio en lugar de quedarse parado junto a un solo cliente

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. ¿Qué es un API Gateway?

4.1 ¿Por qué necesitamos un API Gateway?

Imagina un sistema sin gateway:

El cliente necesita conocer las direcciones de múltiples servicios (usuarios, pedidos, pagos...)
Cada servicio debe implementar su propia autenticación, limitación de tasa y logs
Los protocolos no están unificados, algunos usan HTTP, otros gRPC
Al actualizar un servicio, el cliente también debe modificarse

⚠️ Problemas sin un gateway

Cliente complejo: Necesita configurar múltiples direcciones de servicio
Funcionalidad duplicada: Cada servicio debe implementar autenticación y limitación de tasa
Protocolos inconsistentes: El cliente debe adaptarse a múltiples protocolos
Actualizaciones difíciles: Al actualizar un servicio, el cliente también debe cambiar

Con un API Gateway:

El cliente solo necesita conocer la dirección del gateway; el gateway enruta al servicio correcto
Las lógicas transversales como autenticación, limitación de tasa y logs se manejan de forma unificada en el gateway
El gateway puede hacer conversión de protocolos, exponiendo HTTP uniformemente hacia el exterior
Al actualizar un servicio backend, solo se cambia la configuración del gateway, el cliente no lo percibe

客户端 (来访者)

📱 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 Funciones principales del API Gateway

Función	Descripción	Escenario típico
Enrutamiento	Reenvía solicitudes a diferentes servicios según reglas de URL, Header	`/api/users` → Servicio de usuarios, `/api/orders` → Pedidos
Balanceo de carga	Distribuye el tráfico cuando un servicio tiene múltiples instancias	Servicio de usuarios con 3 instancias, round-robin
Autenticación	Verifica JWT, OAuth Token de forma unificada	Usuarios no autenticados no pueden acceder a `/api/admin`
Limitación y fusible	Controla el límite de tráfico para evitar colapsar servicios	Máximo 1000 solicitudes/segundo, exceso devuelve 429
Conversión de protocolo	HTTP hacia el exterior, gRPC posible en el interior	El cliente usa HTTP, el gateway convierte a gRPC internamente
Canary release	Desvía parte del tráfico a la nueva versión según Header o porcentaje	5% de usuarios prueba la nueva versión, 95% usa la anterior
Logs y monitoreo	Registra logs de solicitudes de forma unificada para análisis	Registra duración, código de estado y tamaño de cada solicitud

5. Gateway en la práctica: ¿Cómo construir una arquitectura de gateway completa?

5.1 Diagrama de arquitectura completo

┌───────────────────────────────────────────────────────────────────────┐
│                           Cliente (Navegador/APP)                         │
└───────────────────────────┬─────────────────────────────────────────┘
                                │ HTTPS
                                ▼
┌───────────────────────────────────────────────────────────────────────┐
│                        Capa externa: CDN + WAF                            │
│  ┌─────────────────────────────────────────────────────────────┐  │
│  │  CDN (Content Delivery Network)                              │  │
│  │  - Caché de recursos estáticos (imágenes, CSS, JS)           │  │
│  │  - Acceso cercano, reduce latencia                           │  │
│  └───────────────────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  WAF (Web Application Firewall)                               │  │
│  │  - Protección contra inyección SQL, ataques XSS               │  │
│  │  - Bloqueo de bots maliciosos y crawlers                      │  │
│  │  - Protección contra ataques CC                                │  │
│  └───────────────────────────────────────────────────────────────┘  │
└───────────────────────────────────────────────────────────────────────┘
                                │
                                ▼
┌───────────────────────────────────────────────────────────────────────┐
│                     Capa intermedia: API Gateway (Nginx/Kong)             │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  Nivel 1: Terminación SSL + Protección de seguridad           │  │
│  │  - HTTPS / TLS 1.3                                            │  │
│  │  - HSTS, cabeceras de seguridad                               │  │
│  └───────────────────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  Nivel 2: Autenticación y autorización                        │  │
│  │  - Verificación de JWT Token                                  │  │
│  │  - Integración OAuth 2.0 / SSO                                │  │
│  │  - Gestión de API Key                                         │  │
│  │  - Verificación de permisos (RBAC)                            │  │
│  └───────────────────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  Nivel 3: Control de tráfico                                  │  │
│  │  - Limitación de tasa - Algoritmos Token Bucket/Leaky Bucket  │  │
│  │  - Circuit Breaker - Previene propagación de fallos           │  │
│  │  - Degradación - Plan de respaldo cuando el servicio falla     │  │
│  │  - Canary Release - Distribución de tráfico por porcentaje     │  │
│  └───────────────────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  Nivel 4: Enrutamiento y balanceo de carga                    │  │
│  │  - Path-based Routing                                         │  │
│  │  - Host-based Routing                                         │  │
│  │  - Header-based Routing                                       │  │
│  │  - Algoritmos de balanceo - Round-robin/Ponderado/Least Conn/IP Hash │
│  │  - Integración con Service Discovery                          │  │
│  └───────────────────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  Nivel 5: Conversión de protocolos y procesamiento de datos   │  │
│  │  - Terminación SSL - HTTPS ↔ HTTP                             │  │
│  │  - Conversión de protocolo - HTTP ↔ gRPC / WebSocket          │  │
│  │  - Transformación de solicitud/respuesta - JSON ↔ XML         │  │
│  │  - Compresión de datos - Gzip / Brotli                        │  │
│  │  - Caché - Recursos estáticos y respuestas API                 │  │
│  └───────────────────────────────────────────────────────────────┘  │
└───────────────────────────────────────────────────────────────────────┘
                                │
                                ▼
┌───────────────────────────────────────────────────────────────────────┐
│                    Capa interna: Clúster de microservicios                │
│  ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐      │
│  │  Usuarios   │ │   Pedidos   │ │  Productos  │ │    Pagos    │      │
│  │  User Svc   │ │  Order Svc  │ │ Product Svc │ │ Payment Svc │      │
│  │             │ │             │ │             │ │             │      │
│  └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘      │
│         │                │                │                │               │
│         └────────────────┴────────────────┴────────────────┘               │
│                                       │                              │
│              Centro de descubrimiento y configuración (etcd)            │
│                    - Registro y descubrimiento de servicios              │
│                    - Health checks                                      │
│                    - Almacenamiento de configuración KV                  │
└───────────────────────────────────────────────────────────────────────┘

5.2 Enrutamiento y balanceo de carga

Una de las responsabilidades centrales del gateway es enviar la solicitud al lugar correcto. Esto implica dos capacidades clave: enrutamiento (a qué servidor) y balanceo de carga (cómo distribuir el tráfico).

Reglas de enrutamiento: De la URL al servicio

Imagina un sistema de e-commerce, diferentes URLs corresponden a diferentes servicios:

/api/users/* → Servicio de usuarios
/api/orders/* → Servicio de pedidos
/api/products/* → Servicio de productos
/api/pay/* → Servicio de pagos

Ejemplo de configuración de Nginx:

nginx

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

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

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

    # Servicio de productos
    location /api/products/ {
        proxy_pass http://product-service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # Servicio de pagos (requiere mayor nivel de seguridad)
    location /api/pay/ {
        # Restringir acceso por IP
        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;
    }
}

Balanceo de carga: Comparación de cuatro estrategias

Cuando un mismo servicio tiene múltiples instancias, ¿cómo elegir?

Estrategia	Principio	Escenario	Ventajas	Desventajas
Round-Robin	Asigna secuencialmente a cada servidor	Servidores de rendimiento similar	Simple y justo	No considera la carga actual
Round-Robin Ponderado	Asigna por peso, más peso = más tráfico	Servidores de rendimiento desigual	Aprovecha servidores potentes	Requiere configurar pesos adecuadamente
Least Connections	Asigna al servidor con menos conexiones activas	Conexiones largas, streaming	Se adapta dinámicamente	Requiere estadísticas en tiempo real
IP Hash	Hash de la IP del cliente, misma IP siempre al mismo servidor	Necesidad de sesión persistente	Garantiza consistencia de sesión	Una IP con mucho tráfico causa presión

Ejemplo de configuración de Nginx:

nginx

# Round-Robin ponderado
upstream backend_weighted {
    server 10.0.1.10:8080 weight=3;  # Mayor rendimiento, más tráfico
    server 10.0.1.11:8080 weight=2;
    server 10.0.1.12:8080 weight=1;  # Menor rendimiento, menos tráfico
}

# Least Connections
upstream backend_least_conn {
    least_conn;
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080;
}

# IP Hash (persistencia de sesión)
upstream backend_ip_hash {
    ip_hash;
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080;
}

选择负载均衡策略

🎮 负载均衡模拟器

💡

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

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

🏢 后端服务器集群

服务器数量:4 台

🖥️

Server-A

18%

请求数:0

权重:4

最近请求:

🖥️

Server-B

18%

请求数:0

权重:4

最近请求:

🖥️

Server-C

39%

请求数:0

权重:3

最近请求:

🖥️

Server-D

39%

请求数:0

权重:3

最近请求:

📨 请求队列

总请求: 0待处理: 0

📊 负载分布统计

29%

平均负载

39%

最高负载

10.5

负载标准差

Server-C

最忙服务器

6. Seguridad del Gateway: ¿Cómo proteger la puerta del sistema?

6.1 Autenticación y autorización

Enfoque tradicional (cada servicio se autentica por separado):

Servicio de usuarios, pedidos, pagos... cada uno debe verificar JWT
Código duplicado, difícil de mantener
Secrets distribuidos en cada servicio, alto riesgo de filtración

Autenticación unificada en el gateway:

El cliente accede al gateway con un Token
El gateway verifica la validez del Token (firma, tiempo de expiración)
Tras la verificación, añade la información del usuario (como user_id) a las cabeceras y reenvía al servicio backend
El servicio backend no necesita verificar, obtiene la información del usuario directamente del Header

💡 Idea central

Autenticación en el gateway, autorización en el servicio:

Autenticación: ¿Quién eres? (Verificar Token, obtener identidad del usuario)
Autorización: ¿Qué puedes hacer? (Determinar permisos según el rol del usuario)

Como el recepcionista de una empresa: autentica tu identidad (DNI), pero los permisos específicos los determina cada departamento.

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 y terminación SSL

¿Por qué necesitamos HTTPS?

Seguridad: Evita que los datos sean interceptados durante la transmisión
Cumplimiento: Los navegadores modernos muestran advertencias de "No seguro" en sitios HTTP
SEO: Los motores de búsqueda priorizan los sitios HTTPS

Solución de terminación SSL:

Solo se configura HTTPS y certificados en la capa del gateway
El gateway maneja el handshake TLS y el cifrado/descifrado
Entre el gateway y los servicios backend se usa HTTP en texto plano (la red interna es confiable)
Los servicios backend se centran en la lógica de negocio, sin necesidad de manejar TLS

💡 Ventajas de la terminación SSL

Gestión simplificada: Los certificados solo se configuran en el gateway, no en el backend
Menor sobrecarga: Los servicios backend no necesitan procesar el handshake TLS
Actualización unificada: La renovación de certificados solo se hace en el gateway

🔐 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. Limitación de tasa y Circuit Breaker: ¿Cómo evitar que el sistema colapse por una "inundación de tráfico"?

7.1 Comparación de algoritmos de limitación de tasa

Algoritmo	Idea central	Tráfico en ráfaga	Escenario	Complejidad
Token Bucket	Cubo con tokens, se necesita un token para pasar	Permite ciertas ráfagas	Limitación de API, control de ancho de banda	Media
Leaky Bucket	Las solicitudes entran al cubo, salen a velocidad fija	Forzado a suavizar, ráfagas se encolan o rechazan	Escenarios que requieren procesamiento estrictamente uniforme	Media
Sliding Window	Cuenta solicitudes dentro de la ventana de tiempo	Conteo estricto por ventana, exceso rechazado	Estadísticas precisas (ej. "máx. 100 por minuto")	Alta

7.2 Configuración práctica de limitación de tasa en Nginx

nginx

# Definir zonas de limitación (en el bloque http)

# 1. Limitación por IP (algoritmo Leaky Bucket)
# zone=mylimit:10m - Nombre de zona y tamaño de memoria (10MB ≈ 160K IPs)
# rate=10r/s - 10 solicitudes por segundo
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

# 2. Límite de conexiones por IP (evita que una sola IP abra demasiadas conexiones)
limit_conn_zone $binary_remote_addr zone=addr:10m;

# 3. Limitación por endpoint de servidor (sin distinguir IP, protege el backend globalmente)
limit_req_zone $server_name zone=server_limit:10m rate=100r/s;

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

    # Servicio de usuarios - Limitación normal
    location /api/users/ {
        # Aplicar limitación
        # burst=20 - Capacidad del cubo, permite 20 solicitudes en ráfaga
        # nodelay - Sin retraso en ráfagas (procesar o rechazar inmediatamente)
        limit_req zone=mylimit burst=20 nodelay;

        # Limitar conexiones por IP
        limit_conn addr 10;

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

    # Servicio de pedidos - Limitación más estricta
    location /api/orders/ {
        # Limitación más estricta: 5 solicitudes por segundo
        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;
    }

    # Manejo tras limitación
    # Cuando se rechaza una solicitud, devolver 429 Too Many Requests
    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;
    }
}

💡 Recomendaciones de estrategia de limitación

APIs normales: 10 solicitudes/segundo, permitir ráfagas de 20
APIs críticas (pagos, pedidos): 5 solicitudes/segundo, permitir ráfagas de 10
Protección global: Total de solicitudes no superior a 100 por segundo

选择限流算法

🪙 令牌桶算法可视化

令牌桶

🪙

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 Breaker: Prevenir la propagación de fallos

Cómo funciona el Circuit Breaker:

Estado cerrado: Reenvía solicitudes normalmente, registrando la tasa de errores
Estado abierto: Cuando la tasa de errores supera el umbral, el circuito se abre, devuelve error directamente sin reenviar
Estado semiabierto: Tras un tiempo, permite unas pocas solicitudes de prueba; si tienen éxito, cierra el circuito

💡 Idea central

El Circuit Breaker es como un fusible eléctrico: Cuando la corriente es excesiva, el fusible se funde automáticamente, protegiendo todo el circuito.

De forma similar, cuando un servicio backend tiene muchos errores, el Circuit Breaker "salta", fallando rápido y evitando que el fallo se propague a todo el sistema.

8. Resumen: Pensamiento central del diseño de gateways

8.1 Repaso de principios fundamentales

Principio	Significado	Puntos prácticos
Enrutamiento	Enviar la solicitud al lugar correcto	Path-based, Host-based, Header-based routing
Balanceo de carga	Distribuir tráfico entre múltiples servidores	Round-robin, ponderado, least connections, IP hash
Seguridad	Proteger la puerta del sistema	Autenticación, HTTPS, WAF
Limitación de tasa	Evitar colapso por tráfico	Token Bucket, Leaky Bucket, Sliding Window
Circuit Breaker	Prevenir propagación de fallos	Fallo rápido, plan de degradación
Observabilidad	Monitoreo y diagnóstico	Logs, métricas, trazabilidad distribuida

8.2 Recomendaciones de selección tecnológica

💡 Árbol de decisión

Elegir gateway:
│
├─ ¿Solo necesitas proxy inverso y balanceo de carga?
│  ├─ Sí → Nginx (primera opción)
│  └─ No → Continuar
│
├─ ¿Necesitas un ecosistema rico de plugins?
│  ├─ Sí → Kong (basado en Nginx)
│  └─ No → Continuar
│
├─ ¿Usas el ecosistema Spring Cloud?
│  ├─ Sí → Spring Cloud Gateway
│  └─ No → Nginx

9. Glosario rápido

Término	Inglés	Explicación
Proxy Inverso	Reverse Proxy	Servicio proxy desplegado en el lado del servidor que recibe solicitudes de clientes y las reenvía a servicios internos. El cliente solo conoce el proxy inverso, no la dirección real del servidor.
Proxy Directo	Forward Proxy	Servicio proxy desplegado en el lado del cliente que accede a recursos externos en su nombre. El servidor ve la IP del proxy, no la del cliente real. Aplicaciones típicas: VPN, herramientas para saltar restricciones.
API Gateway	API Gateway	Capa intermedia entre el cliente y los servicios backend que proporciona enrutamiento, autenticación, limitación de tasa, logs, etc. Es la "puerta unificada" de la arquitectura de microservicios.
Balanceo de carga	Load Balancing	Distribuye las solicitudes entre múltiples servidores para evitar la sobrecarga de un solo servidor, mejorando la disponibilidad y el rendimiento del sistema.
Terminación SSL	SSL Termination	Maneja el cifrado/descifrado HTTPS en la capa del gateway; los servicios backend usan HTTP, reduciendo la sobrecarga de cómputo y simplificando la gestión de certificados.
Limitación de tasa	Rate Limiting	Limita el número de solicitudes por unidad de tiempo para evitar que el sistema colapse por tráfico repentino. Algoritmos comunes: Token Bucket, Leaky Bucket, Sliding Window.
Circuit Breaker	Circuit Breaking	Cuando un servicio dependiente falla, corta automáticamente las llamadas para evitar la propagación del fallo y proporciona un plan de degradación.
Persistencia de sesión	Session Persistence	Asegura que las solicitudes del mismo cliente siempre se enruten al mismo servidor backend, necesario para escenarios que requieren mantener estado de sesión.
Health Check	Health Check	Verifica periódicamente el estado de salud de los servicios backend, eliminando automáticamente los nodos fallidos para garantizar que el tráfico solo llegue a instancias sanas.
Canary Release	Canary Release	Dirige una pequeña porción de tráfico a la nueva versión; tras validar la estabilidad, se aumenta gradualmente el porcentaje, reduciendo el riesgo de despliegue.
WAF	Web Application Firewall	Firewall de aplicaciones web que protege contra inyección SQL, XSS, ataques CC y otras amenazas de seguridad web.
CDN	Content Delivery Network	Red de distribución de contenido que despliega nodos edge globalmente para acelerar el acceso a recursos estáticos.

Gateway y Proxy Inverso ​

1. ¿Por qué necesitamos un "Gateway"? ​

1.1 Un caso real: la evolución de la arquitectura de un e-commerce ​

1.2 Analogía cotidiana del Gateway ​

2. ¿Qué es un Proxy Inverso? ​

2.1 Proxy Directo vs Proxy Inverso ​

2.2 Valor central del Proxy Inverso ​

3. Nginx: ¿Cómo maneja millones de conexiones concurrentes? ​

3.1 Modelo de procesos Master-Worker ​

3.2 Event-driven + E/S asíncrona no bloqueante ​

4. ¿Qué es un API Gateway? ​

4.1 ¿Por qué necesitamos un API Gateway? ​

4.2 Funciones principales del API Gateway ​

5. Gateway en la práctica: ¿Cómo construir una arquitectura de gateway completa? ​

5.1 Diagrama de arquitectura completo ​

5.2 Enrutamiento y balanceo de carga ​

6. Seguridad del Gateway: ¿Cómo proteger la puerta del sistema? ​

6.1 Autenticación y autorización ​

6.2 HTTPS y terminación SSL ​

7. Limitación de tasa y Circuit Breaker: ¿Cómo evitar que el sistema colapse por una "inundación de tráfico"? ​

7.1 Comparación de algoritmos de limitación de tasa ​

7.2 Configuración práctica de limitación de tasa en Nginx ​

7.3 Circuit Breaker: Prevenir la propagación de fallos ​

8. Resumen: Pensamiento central del diseño de gateways ​

8.1 Repaso de principios fundamentales ​

8.2 Recomendaciones de selección tecnológica ​

9. Glosario rápido ​

Gateway y Proxy Inverso

1. ¿Por qué necesitamos un "Gateway"?

1.1 Un caso real: la evolución de la arquitectura de un e-commerce

1.2 Analogía cotidiana del Gateway

2. ¿Qué es un Proxy Inverso?

2.1 Proxy Directo vs Proxy Inverso

2.2 Valor central del Proxy Inverso

3. Nginx: ¿Cómo maneja millones de conexiones concurrentes?

3.1 Modelo de procesos Master-Worker

3.2 Event-driven + E/S asíncrona no bloqueante

4. ¿Qué es un API Gateway?

4.1 ¿Por qué necesitamos un API Gateway?

4.2 Funciones principales del API Gateway

5. Gateway en la práctica: ¿Cómo construir una arquitectura de gateway completa?

5.1 Diagrama de arquitectura completo

5.2 Enrutamiento y balanceo de carga

6. Seguridad del Gateway: ¿Cómo proteger la puerta del sistema?

6.1 Autenticación y autorización

6.2 HTTPS y terminación SSL

7. Limitación de tasa y Circuit Breaker: ¿Cómo evitar que el sistema colapse por una "inundación de tráfico"?

7.1 Comparación de algoritmos de limitación de tasa

7.2 Configuración práctica de limitación de tasa en Nginx

7.3 Circuit Breaker: Prevenir la propagación de fallos

8. Resumen: Pensamiento central del diseño de gateways

8.1 Repaso de principios fundamentales

8.2 Recomendaciones de selección tecnológica

9. Glosario rápido