Nginx API Gateway ve Mikroservis Yönetimi Rehberi

Nginx ile Gelişmiş API Gateway ve Mikroservis Yönetimi

Mikroservis mimarilerinin yaygınlaşmasıyla birlikte, API Gateway'lerin önemi artmıştır. Nginx, yüksek performanslı bir reverse proxy ve load balancer olarak mikroservis mimarilerinde kritik bir rol üstlenmektedir. Bu rehberde, Nginx ile gelişmiş API Gateway yapılandırmasını ve mikroservis yönetimi stratejilerini detaylı olarak ele alacağız.

API Gateway Nedir ve Neden Gereklidir?

API Gateway, istemciler ile arka uç mikroservisleri arasında tek bir giriş noktası sağlayan bir sunucu bileşenidir. Gartner'ın araştırmalarına göre, 2025 yılına kadar kurumsal uygulamaların %85'i mikroservis mimarilerine geçiş yapacak ve bu dönüşümde API Gateway'ler kritik bir rol oynayacaktır.

API Gateway'in temel işlevleri şunlardır:

• Tekil giriş noktası ile mikroservis karmaşıklığını gizleme
• Kimlik doğrulama ve yetkilendirme yönetimi
• Rate limiting ve throttling
• Request/response dönüşümü
• Load balancing ve service discovery
• Monitoring ve logging

Nginx Mikroservis Mimarisi için Yapılandırma

Nginx'i API Gateway olarak kullanmak için temel yapılandırma dosyası aşağıdaki şekilde oluşturulmalıdır. Bu konfigürasyon, Nginx reverse proxy yapılandırması temelinde mikroservis iletişimini yönetir.

events {
    worker_connections 1024;
}

http {
    upstream backend_services {
        least_conn;
        
        server service-user:8001 max_fails=3 fail_timeout=30s;
        server service-order:8002 max_fails=3 fail_timeout=30s;
        server service-product:8003 max_fails=3 fail_timeout=30s;
        server service-payment:8004 max_fails=3 fail_timeout=30s;
        
        keepalive 32;
    }

    # Rate limiting bölgesi
    limit_req_zone $binary_remote_addr zone=api_limit:10m rate=100r/s;
    
    # Connection limiting
    limit_conn_zone $binary_remote_addr zone=conn_limit:10m;

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

        # Rate limiting uygulama
        limit_req zone=api_limit burst=50 nodelay;
        limit_conn conn_limit 20;

        location /api/users/ {
            proxy_pass http://backend_services;
            proxy_http_version 1.1;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            
            # Circuit breaker benzeri davranış
            proxy_connect_timeout 5s;
            proxy_send_timeout 30s;
            proxy_read_timeout 30s;
        }

        location /api/orders/ {
            proxy_pass http://backend_services;
            proxy_http_version 1.1;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

        location /health {
            access_log off;
            return 200 "OK\n";
            add_header Content-Type text/plain;
        }
    }
}

Gelişmiş Rate Limiting ve Throttling

Mikroservis mimarilerinde her servise ayrı rate limiting kuralları uygulamak kritik önem taşımaktadır. Aşağıdaki yapılandırma, farklı endpoint'ler için farklı limitler belirler.

http {
    # Genel API limiti
    limit_req_zone $binary_remote_addr zone=general:10m rate=50r/s;
    
    # Premium kullanıcılar için limit
    limit_req_zone $http_x_api_key zone=premium:10m rate=500r/s;
    
    # Kritik endpoint'ler için
    limit_req_zone $binary_remote_addr zone=critical:10m rate=10r/s;

    server {
        location /api/public/ {
            limit_req zone=general burst=20 nodelay;
        }

        location /api/premium/ {
            limit_req zone=premium burst=100 nodelay;
        }

        location /api/payment/ {
            limit_req zone=critical burst=5 nodelay;
            
            # IP whitelist
            allow 10.0.0.0/8;
            allow 172.16.0.0/12;
            deny all;
        }
    }
}

Service Discovery ve Dinamik Yapılandırma

Mikroservis ortamlarında servislerin dinamik olarak eklenip kaldırılması gerektiğinden, Nginx'in service discovery mekanizmalarını kullanmak önemlidir. DNS tabanlı service discovery veya Consul gibi araçlarla entegrasyon sağlanabilir.

http {
    resolver 127.0.0.11 valid=10s ipv6=off;
    resolver_timeout 5s;

    upstream backend {
        # DNS-based service discovery
        server service-1.service-discovery.local:8001 resolve;
        server service-2.service-discovery.local:8002 resolve;
        
        # Backup sunucular
        server backup-1.example.com:8001 backup;
    }

    # Dynamic upstream modülü ile runtime'da ekleme/çıkarma
    # OpenResty veya Nginx Plus kullanılabilir
}

Güvenlik Yapılandırması ve Header Yönetimi

API Gateway üzerinde güvenlik header'larının doğru yapılandırılması, mikroservislerin güvenliğini sağlamak için kritiktir. Güvenlik header'ları rehberimizde detaylı bilgi bulunmaktadır.

server {
    # Güvenlik header'ları
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    add_header Content-Security-Policy "default-src 'self'" always;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    # CORS yapılandırması
    location /api/ {
        if ($request_method = 'OPTIONS') {
            add_header Access-Control-Allow-Origin "https://app.example.com";
            add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS";
            add_header Access-Control-Allow-Headers "Authorization, Content-Type, X-Requested-With";
            add_header Access-Control-Max-Age 3600;
            add_header Content-Length 0;
            add_header Content-Type text/plain;
            return 204;
        }
        
        add_header Access-Control-Allow-Origin "https://app.example.com" always;
        add_header Access-Control-Allow-Credentials "true" always;
    }
}

Load Balancing Stratejileri

Nginx, mikroservisler arasında etkili yük dengeleme için çeşitli algoritmalar sunmaktadır. Aşağıdaki tablo, yaygın kullanılan algoritmaları karşılaştırmaktadır:

Algoritma	Kullanım Senaryosu	Avantajlar
Round Robin	Eşit kaynaklara sahip sunucular	Basit, dengeli dağılım
Least Connections	Değişken istek süreleri	Daha az bağlantıyla sunucu tercih edilir
IP Hash	Session persistence gerekli	Aynı istemci aynı sunucuya yönlendirilir
Weighted	Farklı kapasitelerde sunucular	Kaynak bazlı dağılım
Least Time	Gecikme hassasiyeti yüksek	En hızlı yanıt veren sunucu tercih edilir

upstream backend_services {
    least_conn;
    
    # Ağırlıklı yük dengeleme
    server service-1:8001 weight=3;
    server service-2:8001 weight=2;
    server service-3:8001 weight=1;
    
    # Sağlık kontrolü
    server service-backup:8001 backup;
    
    # Keep-alive bağlantıları
    keepalive 32;
    keepalive_requests 1000;
    keepalive_timeout 60s;
}

Circuit Breaker Pattern Uygulaması

Mikroservis mimarilerinde bir servisin çökmesi, tüm sistemi etkileyebilir. Nginx'in yeteneklerini kullanarak circuit breaker benzeri davranışlar uygulanabilir. Bu konuda Docker Swarm ve Kubernetes karşılaştırmamız da incelenebilir.

upstream backend {
    server service-problematic:8001 max_fails=3 fail_timeout=10s;
    server service-problematic-2:8001 max_fails=3 fail_timeout=10s;
}

# Proxy timeouts ile circuit breaker davranışı
location /api/ {
    proxy_pass http://backend;
    
    # Bağlantı zaman aşımı
    proxy_connect_timeout 3s;
    proxy_send_timeout 10s;
    proxy_read_timeout 10s;
    
    # Hata durumlarında özel sayfalar
    proxy_intercept_errors on;
    error_page 502 503 504 /errors/service-unavailable.html;
    
    # Retry mekanizması
    proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
    proxy_next_upstream_tries 3;
    proxy_next_upstream_timeout 10s;
}

SSL/TLS Termination ve Mutual Authentication

API Gateway üzerinde SSL/TLS termination uygulamak, mikroservislerin yükünü hafifletir ve merkezi güvenlik sağlar. Mutual TLS (mTLS) yapılandırması ile servisler arası kimlik doğrulama sağlanabilir.

server {
    listen 443 ssl http2;
    server_name api.example.com;

    # SSL sertifikaları
    ssl_certificate /etc/nginx/ssl/api.example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/api.example.com.key;
    
    # Modern TLS yapılandırması
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
    ssl_prefer_server_ciphers off;
    
    # OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 valid=300s;

    # Mutual TLS (mTLS) için client sertifikası doğrulama
    ssl_client_certificate /etc/nginx/ssl/ca.crt;
    ssl_verify_client optional;
    
    location /api/ {
        # Client sertifikası bilgisini mikroservislere ilet
        proxy_set_header X-Client-Cert $ssl_client_cert;
        proxy_set_header X-Client-Verify $ssl_client_verify;
        proxy_set_header X-Client-Verify_Success $ssl_client_verify_success;
        
        proxy_pass http://backend_services;
    }
}

Monitoring ve Logging Stratejileri

Mikroservis mimarilerinde kapsamlı monitoring ve logging, sistem sağlığını korumak için elzemdir. Nginx access ve error log'ları, Prometheus ve Grafana gibi araçlarla entegre edilmelidir.

# JSON formatında structured logging
log_format main_json escape=json
    '{'
    '"time_local":"$time_local",'
    '"remote_addr":"$remote_addr",'
    '"remote_user":"$remote_user",'
    '"request":"$request",'
    '"status": "$status",'
    '"body_bytes_sent":"$body_bytes_sent",'
    '"request_time":$request_time,'
    '"http_referer":"$http_referer",'
    '"http_user_agent":"$http_user_agent",'
    '"request_id":"$request_id",'
    '"upstream_addr":"$upstream_addr",'
    '"upstream_status":"$upstream_status",'
    '"upstream_response_time":"$upstream_response_time"'
    '}';

access_log /var/log/nginx/access.log main_json;
error_log /var/log/nginx/error.log warn;

# Request ID oluşturma
map $http_x_request_id $request_id {
    default $http_x_request_id;
    "" $request_id;
}

server {
    location /api/ {
        # Request ID header ekleme
        proxy_set_header X-Request-ID $request_id;
        
        # Upstream zamanlama bilgisi
        proxy_set_header X-Request-Start "t=$msec";
    }
}

API Versioning ve URL Yönetimi

Mikroservis API'lerinde versiyonlama stratejisi belirlemek, backward compatibility için kritiktir. Nginx, farklı versiyonlara yönlendirme yapabilir.

server {
    location /api/v1/ {
        proxy_pass http://backend-v1;
        
        # V1'e özgü yapılandırmalar
        proxy_set_header X-API-Version "v1";
    }

    location /api/v2/ {
        # Beta özellikler için rate limiting
        limit_req zone=general burst=10 nodelay;
        
        proxy_pass http://backend-v2;
        proxy_set_header X-API-Version "v2";
        
        # Feature flags
        proxy_set_header X-Feature-NewPayment "enabled";
    }

    # Varsayılan olarak en son versiyona yönlendirme
    location /api/ {
        return 301 /api/v2$request_uri;
    }
}

Request/Response Dönüşümü ve Filtreleme

Nginx, istek ve yanıtları mikroservis ihtiyaçlarına göre dönüştürmek için kullanılabilir. OpenResty (Lua entegrasyonu) ile gelişmiş manipülasyon mümkündür.

# Request header ekleme
location /api/ {
    proxy_pass http://backend_services;
    
    # İstemci bilgilerini ekleme
    proxy_set_header X-Original-URI $request_uri;
    proxy_set_header X-Request-ID $request_id;
    proxy_set_header X-Forwarded-User $remote_user;
    
    # Caching header'larını manipüle etme
    proxy_hide_header X-Powered-By;
    proxy_hide_header X-AspNet-Version;
}

# Response dönüşümü