Ana içeriğe atla

Routing Kavramı

Routing, bir API Proxy’de iki temel bileşenden oluşur:

Routing Akışı

Aşağıdaki diyagram, istek ve yanıt akışının Gateway üzerinden Routing ve Upstream mekanizması ile nasıl gerçekleştiğini gösterir:

1. İstemci İsteği

İstemci API Proxy’ye istek gönderir

2. Client Route

İsteklerin API Proxy’ye girdiği nokta
Path, Method, Protocol ve Port tanımları

3. Routing Logic

Load Balancing, Failover ve yönlendirme mantığı uygulanır

4. Upstream Target

İsteklerin yönlendirildiği backend API
Backend adresi, protokol ve yapılandırma

5. Backend API

İşlenmiş istek backend API’ye gönderilir

Upstream Target

Upstream Target (Yukarı Akış Hedefi), API Proxy’de istemcilerden gelen isteklerin yönlendirildiği backend API’nin adresidir. Upstream Target, API Proxy’nin backend ile iletişim kurduğu noktadır.

Upstream Target Genel Bakış

Upstream ve target kavramları, API Proxy’lerde backend servislere yönlendirme yapılırken kullanılan temel kavramlardır. Upstream Target, backend API’nin fiziksel veya mantıksal adresini temsil eder. API Proxy, Client Route’dan gelen istekleri bu hedefe yönlendirir.

Backend Adresi

Backend API’nin URL’i veya IP adresi

Protokol

HTTP, HTTPS, gRPC, WebSocket protokolleri

Yük Dengeleme

Birden fazla backend instance’ı arasında yük dengeleme

Failover

Hata durumunda alternatif backend’e geçiş

Upstream ve Target

Upstream: API Proxy’nin istekleri yönlendirdiği backend servislerin tanımlandığı yapılandırmadır. Bir upstream birden fazla target içerebilir. Target: Upstream içinde tanımlanan backend servis adresleridir. Her target bir URL ve gerekli yapılandırma bilgilerini içerir.

Upstream Target Yapısı

Bir Upstream Target şu bilgileri içerir:
http://backend-service:8080/api/products
│     │                │    │
│     │                │    └─ Backend Path
│     │                └─ Port
│     └─ Host/Service Name
└─ Protocol

Örnek Upstream Target’lar

HTTP Target

http://product-service:8080

HTTPS Target

https://api.backend.com/v1

gRPC Target

grpc://backend-service:50051

WebSocket Target

ws://websocket-service:8080

Upstream Target Yapılandırması

Bir Upstream Target oluştururken şu bilgiler tanımlanır:
  • URL: Backend API’nin adresi
  • Protocol: HTTP, HTTPS, gRPC, WebSocket
  • Host: Backend sunucu adı veya IP
  • Port: Backend port numarası
  • Path: Backend path’i (opsiyonel)
  • Path Rewrite: Backend path’ini değiştirme (opsiyonel)
Upstream Target’da path rewrite yapılabilir:
Client Route: /api/v1/products

   ▼ (Path Rewrite)
Upstream Target: /products


Backend API: http://backend:8080/products
Path Rewrite Örnekleri:
  • /api/v1/products/products (prefix removal)
  • /api/v1/products/v2/products (version change)
  • /api/products/{id}/products/{id} (path simplification)
  • Connection Timeout: Bağlantı zaman aşımı
  • Read Timeout: Okuma zaman aşımı
  • Write Timeout: Yazma zaman aşımı

Upstream Target Türleri

Single Target

Tek bir backend instance:
http://backend:8080

Multiple Targets

Birden fazla backend instance (Load Balanced):
http://backend1:8080
http://backend2:8080
http://backend3:8080

Dynamic Target

Dinamik olarak belirlenen backend:
Variable-based target selection

Routing Türleri

Apinizer platformu farklı protokoller için routing desteği sağlar:

HTTP Routing

HTTP Routing, HTTP/HTTPS protokolü kullanan REST API’ler için routing desteğidir.

HTTP Routing Özellikleri

Protokol Desteği

  • HTTP/1.1
  • HTTP/2
  • HTTPS (TLS/SSL)

Method Desteği

  • GET, POST, PUT, DELETE
  • PATCH, HEAD, OPTIONS
  • Custom methods

Content-Type

  • application/json
  • application/xml
  • application/x-www-form-urlencoded
  • multipart/form-data

Özellikler

  • Path matching (exact, prefix, regex)
  • Query parameter handling
  • Header manipulation
  • Body transformation
  • Host bazlı routing
  • Method bazlı routing

HTTP Routing Yapılandırması

client_route:
  path: /api/v1/*
  method: GET, POST, PUT, DELETE
  protocol: https
  port: 443

upstream_target:
  url: http://backend-service:8080
  protocol: http

HTTP Routing Kullanım Senaryoları

  • REST API Gateway: REST API’lerin yönetimi
  • API Versioning: API versiyonlama
  • Legacy System Integration: Eski sistemlerle entegrasyon
  • Public API Exposure: Dış dünyaya API açma
Detaylı bilgi için HTTP Yönlendirme sayfasına bakın.

gRPC Routing

gRPC Routing, gRPC protokolü kullanan microservice’ler için routing desteğidir.

gRPC Routing Özellikleri

Protokol Desteği

  • gRPC (HTTP/2 üzerinde)
  • gRPC-Web
  • TLS/SSL desteği

Service Definition

  • Protocol Buffers (Protobuf)
  • Service definition
  • Method routing

Özellikler

  • Unary calls
  • Server streaming
  • Client streaming
  • Bidirectional streaming

Load Balancing

  • gRPC-aware load balancing
  • Failover

gRPC Routing Yapılandırması

client_route:
  path: /com.example.ProductService/*
  protocol: grpc
  port: 50051

upstream_target:
  url: grpc://backend-service:50051
  protocol: grpc
  service: com.example.ProductService

gRPC Routing Kullanım Senaryoları

  • Microservice Communication: Microservice’ler arası iletişim
  • High Performance APIs: Yüksek performans gereksinimleri
  • Streaming APIs: Gerçek zamanlı veri akışı
  • Internal APIs: İç sistem API’leri
Detaylı bilgi için gRPC Yönlendirme sayfasına bakın.

WebSocket Routing

WebSocket Routing, WebSocket protokolü kullanan gerçek zamanlı uygulamalar için routing desteğidir.

WebSocket Routing Özellikleri

Protokol Desteği

  • WebSocket (ws://)
  • Secure WebSocket (wss://)
  • HTTP Upgrade

Bağlantı Yönetimi

  • Connection establishment
  • Connection persistence
  • Connection pooling

Mesaj İşleme

  • Text messages
  • Binary messages
  • Message routing

Özellikler

  • Subprotocol support
  • Ping/Pong frames
  • Connection timeout

WebSocket Routing Yapılandırması

client_route:
  path: /ws/*
  protocol: wss
  port: 443

upstream_target:
  url: ws://backend-service:8080
  protocol: ws
  subprotocol: chat

WebSocket Routing Kullanım Senaryoları

  • Real-time Chat: Gerçek zamanlı sohbet uygulamaları
  • Live Updates: Canlı güncellemeler
  • Gaming: Oyun uygulamaları
  • IoT: IoT cihazları ile iletişim
Detaylı bilgi için WebSocket Yönlendirme sayfasına bakın.

Protokol Karşılaştırması

ÖzellikHTTPgRPCWebSocket
ProtokolHTTP/1.1, HTTP/2HTTP/2WebSocket
Veri FormatıJSON, XMLProtobufText, Binary
İletişimRequest-ResponseRequest-Response, StreamingBidirectional
PerformansOrtaYüksekYüksek (persistent)
KullanımREST API’lerMicroservicesReal-time apps
Browser Desteği⚠️ (gRPC-Web)

Protokol Seçim Kılavuzu

  • REST API’ler için
  • Browser tabanlı uygulamalar için
  • Geniş uyumluluk gereksinimleri için
  • JSON/XML veri formatları için
  • Microservice mimarileri için
  • Yüksek performans gereksinimleri için
  • Streaming gereksinimleri için
  • İç sistem API’leri için
  • Gerçek zamanlı iletişim için
  • Canlı güncellemeler için
  • Bidirectional iletişim için
  • Düşük latency gereksinimleri için

Load Balancing Strategies

Backend’de birden fazla instance varsa, yük dengeleme stratejileri kullanılır. Yük dengeleme, trafiğin eşit dağıtılmasını, yüksek erişilebilirliği ve performans artışını sağlar.

Load Balancing Stratejileri

Round Robin

İstekler sırayla tüm backend instance’larına dağıtılır. Basit ve anlaşılır bir stratejidir, tüm backend’lerin benzer kapasitede olduğu durumlar için uygundur.

Least Connections

En az bağlantıya sahip backend’e istek gönderilir. Yükü daha iyi dağıtır ve uzun süren istekler için uygundur.

Weighted Round Robin

Backend’lere ağırlık atanır ve buna göre istek dağıtılır. Farklı kapasiteli backend’ler için uygundur.

Strateji Karşılaştırması

StratejiYük DağılımıKarmaşıklıkKullanım
Round RobinEşitDüşükGenel kullanım
Least ConnectionsİyiOrtaDeğişken süreler
Weighted Round RobinAğırlıklıOrtaFarklı kapasiteler

Best Practices

  • Backend kapasitelerine göre strateji seçin
  • Trafik desenlerini analiz edin
  • İstek sürelerini değerlendirin
  • Backend yük dağılımını izleyin
  • Performans metriklerini takip edin
  • Backend durumlarını düzenli kontrol edin

Routing Yapılandırması

Client Route Yapılandırması

Client Route, istemcilerden gelen isteklerin karşılandığı endpoint’i tanımlar:

Path

/api/v1/products

Method

GET, POST, PUT, DELETE, vb.

Protocol

HTTP, HTTPS

Port

443, 80, vb.

Upstream Target Yapılandırması

Upstream Target, backend API’nin adresini tanımlar:

URL

http://backend-service:8080

Protocol

HTTP, HTTPS, gRPC, WebSocket

Timeout

İstek zaman aşımı

Routing Özellikleri

Dinamik Yönlendirme

Apinizer’ın Client Route özelliği sayesinde dinamik yönlendirme yapılabilir:

Host Bazlı Routing

Host header değerine göre farklı proxy’lere yönlendirme:
Host: api.example.com → Proxy A
Host: test.example.com → Proxy B

Header Bazlı Routing

HTTP header değerlerine göre yönlendirme:
X-Environment: production → Proxy A
X-Environment: test → Proxy B

Method Bazlı Routing

HTTP method’a göre yönlendirme:
GET /api/products → Proxy A
POST /api/products → Proxy B

Kombinasyon Bazlı Routing

Host, header ve method kombinasyonlarına göre yönlendirme

Yönlendirme Öncelik Sırası

Gateway, gelen istekleri aşağıdaki öncelik sırasına göre değerlendirir:

1. Relative Path

En yüksek öncelik

2. Hosts

Host header kontrolü

3. Headers

Header kontrolü

4. Methods

En düşük öncelik
Eşleştirme Mantığı:
  • Hosts: Birden fazla host tanımlandığında OR mantığı ile çalışır (herhangi biri eşleşirse yeterli)
  • Headers: Birden fazla header tanımlandığında AND mantığı ile çalışır (tümü eşleşmeli)
  • Exact match: Tam eşleşme
  • Prefix match: Önek eşleşmesi (daha spesifik path’ler önceliklidir)
  • Regex match: Düzenli ifade eşleşmesi
Path Önceliği:
/api/v1/products/{id} → Daha spesifik (öncelikli)
/api/v1/products      → Daha genel
  • HTTP method kontrolü (GET, POST, PUT, DELETE)
  • Method bazlı routing
  • Method override desteği
  • Method tanımlanmazsa tüm method’lar kabul edilir
  • Header bazlı routing
  • Content-Type bazlı routing
  • Custom header bazlı routing
  • AND mantığı: Tüm header’lar eşleşmeli
  • Host header bazlı routing
  • Wildcard hostname desteği (.example.com, example.)
  • OR mantığı: Herhangi bir host eşleşirse yeterli
  • Query parametresi bazlı routing
  • Parametre değeri bazlı routing

Failover ve Retry

Failover

Backend instance’larından biri hata verdiğinde:

Automatic Failover

Otomatik olarak başka bir instance’a geçiş

Circuit Breaker

Hata durumunda geçici olarak devre dışı bırakma

Retry

Geçici hatalar için retry mekanizması:

Retry Count

Tekrar deneme sayısı

Retry Delay

Tekrar deneme aralığı

Retry Conditions

Hangi hatalar için retry yapılacağı

Kullanım Senaryoları

Load Balancing

Birden fazla target tanımlanarak yük dengeleme yapılabilir

Farklı Upstream'ler

Farklı upstream’ler farklı backend servislere yönlendirme yapmak için kullanılabilir

Path Rewrite

Path rewrite ile API versiyonlama ve path dönüşümleri yapılabilir

Failover

Failover mekanizmaları ile yüksek erişilebilirlik sağlanabilir

Sonraki Adımlar