API Gateway

Request Routing

Kierowanie żądań do właściwych serwisów po URL, metodzie, nagłówkach i parametrach

Path-based, header-based, weighted routing

Authentication

Centralna weryfikacja JWT, OAuth2, API Keys — serwisy downstream nie implementują auth

Kong JWT/OAuth2, AWS Cognito, Traefik ForwardAuth

Rate Limiting

Ochrona serwisów przed nadmiernym ruchem — limity per user/IP/API key/endpoint

Token bucket, sliding window, Redis distributed

SSL Termination

Decryptuje TLS raz na Gateway — serwisy komunikują się HTTP lub mTLS wewnątrz

cert-manager, Let's Encrypt, AWS ACM

Circuit Breaking

Automatyczne odcinanie awaryjnych serwisów i izolacja błędów (bulkhead pattern)

Kong circuit-breaker, Envoy outlier detection

Observability

Centralne logowanie, metryki, trace ID propagation — jeden punkt zbierania danych

OpenTelemetry, Prometheus, Datadog, Jaeger

Co to jest API Gateway i jakie funkcje pełni w architekturze mikroserwisów?

API Gateway to pojedynczy punkt wejścia (single entry point) dla wszystkich klientów do systemu mikroserwisów. Zamiast klient łączy się bezpośrednio z każdym serwisem — łączy się z Gateway który kieruje żądania do odpowiednich serwisów. Kluczowe funkcje API Gateway: Request routing — przekierowuje żądania do właściwych mikroserwisów na podstawie URL, metody HTTP, nagłówków. Authentication i Authorization — weryfikacja JWT/OAuth2 tokens zanim żądanie dotrze do serwisu. Brak duplikacji logiki auth w każdym serwisie. Rate Limiting i Throttling — ograniczanie liczby żądań per użytkownik/API key/IP. Broni serwisy przed nadmiernym ruchem. Load Balancing — rozkładanie ruchu między instancjami serwisów. SSL Termination — decryptuje SSL/TLS raz na Gateway, serwisy komunikują się HTTP wewnątrz (lub mTLS). Response Transformation — modyfikacja odpowiedzi (add/remove fields, format transformation). Request Aggregation (BFF pattern) — łączenie wyników z wielu serwisów w jedno żądanie. Caching — cache responses na poziomie Gateway. Circuit Breaking — odcinanie awaryjnych serwisów. Observability — centralne logowanie requestów, metryki, traces. Wzorce: API Gateway vs. BFF (Backend for Frontend) — BFF to specjalizowana Gateway per typ klienta (mobile, web, TV). Reverse Proxy — najprostsza forma Gateway (Nginx, Traefik).

Kong, AWS API Gateway, Apigee — jak wybrać właściwe narzędzie?

Kong Gateway: open-source (Kong CE) lub enterprise (Kong EE). Plugin ekosystem — 100+ pluginów (auth, rate limit, logging, transforms, AI). Declarative config (deck CLI) lub Admin API. Kubernetes Ingress Controller (Kong Ingress Controller). Kong Konnect — cloud control plane dla self-hosted data planes. Idealny dla: hybrid/multi-cloud, high customization, on-prem. AWS API Gateway: w pełni managed, serverless. REST API, HTTP API (tańszy), WebSocket API. Direct integracje z Lambda, DynamoDB, S3 (bez pośrednika). Usage Plans i API Keys — monetyzacja API. Idealny dla: AWS native, serverless, Lambda backends. Apigee (Google): enterprise-grade API management. Full lifecycle management (design, secure, publish, analyze, monetize). Apigee X — GCP native. Idealny dla: enterprise, API monetization, developer portal. Traefik: open-source, Kubernetes-native (automatic config z CRDs/annotations). Bardzo popularne jako Ingress Controller. NGINX / NGINX Plus: reverse proxy i load balancer. Używany jako lightweight Gateway w prostszych scenariuszach. AWS ALB + Listener Rules: wbudowany routing bez dedykowanego Gateway. Cloudflare API Shield: WAF + rate limiting + bot protection na poziomie Cloudflare (zero deploy). Wybór: open-source + Kubernetes to Kong lub Traefik. Serverless AWS to AWS API Gateway. Enterprise + multi-cloud to Apigee lub Kong EE.

Rate Limiting i throttling — jak chronić API przed nadużyciami?

Rate Limiting: ograniczenie liczby żądań w czasie. Algorytmy: Fixed Window — X requests per minute window. Problem: burst na granicy okna (59s + 60s = 119 requestów). Sliding Window — płynne okno — bardziej fair. Token Bucket — wiadro tokenów. Token dodawany co tick, każdy request zużywa token. Pozwala na burst do pojemności wiadra. Leaky Bucket — requests w kolejce, obsługiwane ze stałym tempem. Granularity rate limiting: per IP — podstawowa ochrona przed DoS. Per API Key — kontrola per klient/aplikacja. Per User ID — kontrola per uwierzytelniony użytkownik. Per endpoint — różne limity dla różnych ścieżek. Kombinowane — per user per endpoint. Distributed Rate Limiting: wiele instancji Gateway musi współdzielić countery. Redis jako distributed counter. Kong Rate Limiting: wtyczka z konfiguracją per consumer/route/service. Redis lub local (w klastrze — Redis wymagany). Response headers (RateLimit-Limit, RateLimit-Remaining, Retry-After). Circuit Breaker pattern: automatyczne odcinanie serwisu który zwraca błędy. Stany: Closed (normalne) → Open (serwis odcięty) → Half-Open (próbne żądania). Resilience4j (Java), Polly (.NET). Implementacja w Kong: circuit-breaker plugin lub przez upstream health checks. Bulkhead: izolacja zasobów — problemy w jednym serwisie nie wpływają na inne.

Authentication i Authorization w API Gateway — JWT, OAuth2, API Keys?

Authentication na poziomie Gateway: centralizuje weryfikację tożsamości — serwisy downstream nie muszą implementować auth. JWT (JSON Web Token): stateless — wszystkie informacje w tokenie. Weryfikacja podpisu (RSA/ECDSA/HMAC) na Gateway. Claims forwarding — Gateway wyciąga user ID i role z JWT, dodaje do nagłówków X-User-Id, X-User-Roles. Kong JWT plugin — konfiguracja public key verification. JWK (JSON Web Key Set) — dynamiczne pobieranie public keys z JWKS endpoint (np. z Keycloak). Refresh Token rotation — serwisy nie zarządzają sesjami. OAuth2 i OIDC: Authorization Code Flow — dla aplikacji webowych. Client Credentials — dla server-to-server (M2M). PKCE — dla SPA i mobile (bez client secret). Kong OAuth2 Introspection — weryfikacja tokenów przez Authorization Server. Keycloak/Auth0 jako IdP. API Keys: prostsze od JWT. Identyfikują aplikację/klienta, nie użytkownika. Podpinane do Usage Plans (rate limits, quotas). Kong Key Authentication plugin. Mutual TLS (mTLS): klient prezentuje certyfikat — weryfikowany przez Gateway. Silne uwierzytelnianie dla B2B API. Gateway jako policy enforcement point: Forward auth pattern — Gateway wywołuje zewnętrzny auth serwis przed routingiem. Open Policy Agent (OPA) sidecar lub plugin — decyzje autoryzacji jako kod. Scope-based authorization: OAuth2 scopes — Gateway weryfikuje czy token ma wymagany scope.

API Gateway w Kubernetes — Ingress, Gateway API i service mesh?

Kubernetes Ingress: standard API do wystawiania HTTP/HTTPS z klastra. Ingress Controller: implementacja Ingress (Nginx, Traefik, Kong, Istio). Annotations dla konfiguracji (rate limiting, auth, SSL). Ograniczenia: brak standaryzacji cross-controller. L7 routing tylko HTTP. Brak support dla TCP/UDP routing w standardzie. Kubernetes Gateway API (nowy standard, GA 2023): zastępuje Ingress — bogatsza semantyka. GatewayClass, Gateway, HTTPRoute, TCPRoute. Rozdzielenie ról: Platform admin (Gateway), Application dev (HTTPRoute). Ekspresywniejsze matching (headers, query params, methods). Wsparcie: Istio, Envoy, Kong, Traefik, HAProxy. Kong Ingress Controller (KIC): używa Kong jako data plane dla Kubernetes. CRDs dla Kong-specific konfiguracji (KongPlugin, KongConsumer). Service Mesh vs. API Gateway: API Gateway — north-south traffic (zewnętrzny ruch do klastra). Service Mesh — east-west traffic (między serwisami wewnątrz klastra). Istio jako Gateway + Service Mesh: Istio Gateway obsługuje north-south. VirtualService, DestinationRule — traffic management wewnątrz. mTLS automatyczny między serwisami. Multi-cluster routing: Gateway federacja między klastrami. ArgoCD + Gateway dla progressive delivery (canary przez Gateway weight routing).

Wyślij zapytanie