Routing ve Upstream
Routing Kavramı
Routing, bir API Proxy'de iki temel bileşenden oluşur:
İsteklerin API Proxy'ye girdiği nokta. İstemciler bu endpoint'e istek gönderir.
İsteklerin yönlendirildiği backend API. API Proxy bu adrese istek gönderir.
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:
sequenceDiagram
participant Client as 👤 İstemci
participant Gateway as 🚪 API Gateway
participant ClientRoute as 🔀 Client Route
participant RoutingLogic as ⚙️ Routing Logic
participant Upstream as 🎯 Upstream Target
participant Backend1 as 🖥️ Backend 1
participant Backend2 as 🖥️ Backend 2
Client->>Gateway: HTTP İsteği<br/>(Path, Method, Headers)
Note over Gateway: İstek Gateway'e Ulaştı
Gateway->>ClientRoute: İsteği Client Route'a Yönlendir
Note over ClientRoute: Client Route Değerlendirme<br/>Path, Host, Header, Method
ClientRoute->>RoutingLogic: Uygun API Proxy Bulundu<br/>Routing Logic'e İlet
Note over RoutingLogic: Routing İşlemleri
RoutingLogic->>RoutingLogic: Load Balancing<br/>Stratejisi Uygula<br/>(Round Robin, Least Connections, vb.)
RoutingLogic->>RoutingLogic: Path Rewrite<br/>(Gerekirse)
RoutingLogic->>Upstream: Upstream Target Seçildi
Note over Upstream: Backend Hedef Belirlendi
alt Başarılı Yönlendirme
Upstream->>Backend1: İstek Backend'e İletilir<br/>(Load Balanced)
Backend1->>Upstream: Yanıt Döner
Upstream->>RoutingLogic: İşlenmiş Yanıt
RoutingLogic->>Gateway: Routing Tamamlandı
Gateway->>Client: HTTP Yanıtı
else Failover Senaryosu
Upstream->>Backend1: İstek Backend 1'e İletilir
Backend1-->>Upstream: ❌ Hata (Timeout/Error)
Upstream->>Backend2: Failover: Backend 2'ye Geçiş
Backend2->>Upstream: ✅ Başarılı Yanıt
Upstream->>RoutingLogic: İşlenmiş Yanıt
RoutingLogic->>Gateway: Routing Tamamlandı
Gateway->>Client: HTTP Yanıtı
end
Note over Client,Gateway: İşlem Tamamlandı
İstemci API Proxy'ye istek gönderir
İsteklerin API Proxy'ye girdiği nokta
Path, Method, Protocol ve Port tanımları
Load Balancing, Failover ve yönlendirme mantığı uygulanır
İsteklerin yönlendirildiği backend API
Backend adresi, protokol ve yapılandırma
İş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 API'nin URL'i veya IP adresi
HTTP, HTTPS, gRPC, WebSocket protokolleri
Birden fazla backend instance'ı arasında yük dengeleme
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://product-service:8080
https://api.backend.com/v1
grpc://backend-service:50051
ws://websocket-service:8080
Upstream Target Yapılandırması
Bir Upstream Target oluştururken şu bilgiler tanımlanır:
Temel Yapılandırma
- 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)
Path Rewrite
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)
Timeout Ayarları
- Connection Timeout: Bağlantı zaman aşımı
- Read Timeout: Okuma zaman aşımı
- Write Timeout: Yazma zaman aşımı
Upstream Target Türleri
Tek bir backend instance:
http://backend:8080
Birden fazla backend instance (Load Balanced):
http://backend1:8080
http://backend2:8080
http://backend3:8080
Dinamik olarak belirlenen backend:
Variable-based target selection
Routing Türleri
Apinizer platformu farklı protokoller için routing desteği sağlar:
HTTP/HTTPS protokolü için routing. REST API'ler için kullanılır.
gRPC protokolü için routing. Microservice mimarileri için kullanılır.
WebSocket protokolü için routing. Gerçek zamanlı iletişim için kullanılır.
HTTP Routing
HTTP Routing, HTTP/HTTPS protokolü kullanan REST API'ler için routing desteğidir.
HTTP Routing Özellikleri
- HTTP/1.1
- HTTP/2
- HTTPS (TLS/SSL)
- GET, POST, PUT, DELETE
- PATCH, HEAD, OPTIONS
- Custom methods
- application/json
- application/xml
- application/x-www-form-urlencoded
- multipart/form-data
- 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
- gRPC (HTTP/2 üzerinde)
- gRPC-Web
- TLS/SSL desteği
- Protocol Buffers (Protobuf)
- Service definition
- Method routing
- Unary calls
- Server streaming
- Client streaming
- Bidirectional streaming
- 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
- WebSocket (ws://)
- Secure WebSocket (wss://)
- HTTP Upgrade
- Connection establishment
- Connection persistence
- Connection pooling
- Text messages
- Binary messages
- Message routing
- 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ı
| Özellik | HTTP | gRPC | WebSocket |
|---|---|---|---|
| Protokol | HTTP/1.1, HTTP/2 | HTTP/2 | WebSocket |
| Veri Formatı | JSON, XML | Protobuf | Text, Binary |
| İletişim | Request-Response | Request-Response, Streaming | Bidirectional |
| Performans | Orta | Yüksek | Yüksek (persistent) |
| Kullanım | REST API'ler | Microservices | Real-time apps |
| Browser Desteği | ✅ | ⚠️ (gRPC-Web) | ✅ |
Protokol Seçim Kılavuzu
Ne Zaman HTTP Kullanılmalı?
- REST API'ler için
- Browser tabanlı uygulamalar için
- Geniş uyumluluk gereksinimleri için
- JSON/XML veri formatları için
Ne Zaman gRPC Kullanılmalı?
- Microservice mimarileri için
- Yüksek performans gereksinimleri için
- Streaming gereksinimleri için
- İç sistem API'leri için
Ne Zaman WebSocket Kullanılmalı?
- 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
İ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.
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.
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ı
| Strateji | Yük Dağılımı | Karmaşıklık | Kullanım |
|---|---|---|---|
| Round Robin | Eşit | Düşük | Genel kullanım |
| Least Connections | İyi | Orta | Değişken süreler |
| Weighted Round Robin | Ağırlıklı | Orta | Farklı kapasiteler |
Best Practices
Strateji Seçimi
- Backend kapasitelerine göre strateji seçin
- Trafik desenlerini analiz edin
- İstek sürelerini değerlendirin
Monitoring
- 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:
/api/v1/products
GET, POST, PUT, DELETE, vb.
HTTP, HTTPS
443, 80, vb.
Upstream Target Yapılandırması
Upstream Target, backend API'nin adresini tanımlar:
http://backend-service:8080
HTTP, HTTPS, gRPC, WebSocket
İstek zaman aşımı
Routing Özellikleri
Dinamik Yönlendirme
Apinizer'ın Client Route özelliği sayesinde dinamik yönlendirme yapılabilir:
Host header değerine göre farklı proxy'lere yönlendirme:
Host: api.example.com → Proxy A
Host: test.example.com → Proxy B
HTTP header değerlerine göre yönlendirme:
X-Environment: production → Proxy A
X-Environment: test → Proxy B
HTTP method'a göre yönlendirme:
GET /api/products → Proxy A
POST /api/products → Proxy B
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:
En yüksek öncelik
Host header kontrolü
Header kontrolü
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)
Path Matching
- 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
Method Matching
- HTTP method kontrolü (GET, POST, PUT, DELETE)
- Method bazlı routing
- Method override desteği
- Method tanımlanmazsa tüm method'lar kabul edilir
Header Matching
- Header bazlı routing
- Content-Type bazlı routing
- Custom header bazlı routing
- AND mantığı: Tüm header'lar eşleşmeli
Host Matching
- Host header bazlı routing
- Wildcard hostname desteği (.example.com, example.)
- OR mantığı: Herhangi bir host eşleşirse yeterli
Query Parameter Matching
- Query parametresi bazlı routing
- Parametre değeri bazlı routing
Failover ve Retry
Failover
Backend instance'larından biri hata verdiğinde:
Otomatik olarak başka bir instance'a geçiş
Hata durumunda geçici olarak devre dışı bırakma
Retry
Geçici hatalar için retry mekanizması:
Tekrar deneme sayısı
Tekrar deneme aralığı
Hangi hatalar için retry yapılacağı
Kullanım Senaryoları
Birden fazla target tanımlanarak yük dengeleme yapılabilir
Farklı upstream'ler farklı backend servislere yönlendirme yapmak için kullanılabilir
Path rewrite ile API versiyonlama ve path dönüşümleri yapılabilir
Failover mekanizmaları ile yüksek erişilebilirlik sağlanabilir