API Gateway ve Service Discovery — İstek Doğru Kapıyı Nasıl Bulur
Önce şunu oku: Mikroservis Katmanları — İstek Nereden Geçiyor
30 saniyede özet
Gateway, bütün isteklerin geçtiği tek kapıdır: yönlendirir, kimliği kontrol eder, aşırı isteği durdurur. Arkadaki servislerin adresleri ise sürekli değişir; discovery onları çalışırken bulur ama hep biraz geriden gelir.
Fiyat servisinin üç kopyası vardı, dördüncüsü eklendi. Kısa süre sonra tuhaf şeyler olmaya başladı.
-
Bayt: Fiyat servisinin üç kopyası vardı, yük artınca dördüncüsünü ekledik.
-
Sen: Yük dağıldı mı?
-
Bayt: Tuhaf şeyler oldu! Kopyalardan biri çökünce de hatalar başladı.
-
Bayt: Kapıcı kargoyu dağıtırken dairelerin listesine nereden bakıyor?
Herkes aynı kapıdan girer
Bir API gatewayDışarıdan gelen her isteğin girdiği tek kapı. Auth, rate limit, TLS sonlandırma ve yönlendirme gibi her servisi ilgilendiren işleri tek yerde toplar.Gateway yönlendirir, birleştirmez. Sayfa için beş servis gerekiyorsa istemci yine beş kez gidip gelir — gecikmeyi çözen şey gateway değil, sunucu tarafında birleştirme yapan BFF'tir.Sözlükte gör →, dışarıdan gelen her isteğin girdiği yerdir. Her servisi ilgilendiren işleri tek yerde toplar: yönlendirme, kimlik doğrulama, TLS, rate limitingBir istemcinin belirli sürede yapabileceği istek sayısını sınırlamak. Aşan istek 429 Too Many Requests alır; birden çok gateway varsa sayaç paylaşılmalıdır.Sözlükte gör →.
Gateway’e iş kuralı ya da ekran başına veri birleştirme girmez. Girerse, bütün ekiplerin aynı anda değiştirmek zorunda kaldığı bir darboğaz olur.
Kafam karıştı, daha basit anlat
Gateway binanın tek giriş kapısıdır. Kimlik kontrolü ve yönlendirme her oda için ayrı ayrı değil, kapıda bir kez yapılır.
Mikroservislerde service discovery neden gerekir?
API Gateway'in sorumluluklarına en uygun liste hangisi?
Adresler sürekli değişir
Fiyat servisinin pod adresleri application.yml'a elle yazıldı. Bir pod çöküp yenisi başka bir IP'yle gelirse ne olur? Cevabı göster
Ölü adrese istek gitmeye devam eder, yeni pod hiç iş almaz. Liste, dosyayı biri elle güncelleyene kadar değişmez.
Adım adım oku
- Gateway, kapıcı gibi gelen her isteği uygun servis kopyasına yönlendirir.
- Adresler bir dosyaya elle yazılmışsa ölen kopyaya istek gitmeye devam eder, yeni kopya hiç iş almaz.
- Servis keşfinde her kopya açılınca kendini bir kayıt defterine yazdırır ve düzenli olarak yaşadığını bildirir.
- Ölen kopya listeden düşer, yeni kopya eklenir; trafik her zaman canlı listeye göre dağıtılır.
service discoveryBir servisin o an çalışan instance'larının adreslerini çalışma anında bulmak. Kayıt servisi (Eureka, Consul) ya da platform (Kubernetes Service) bu listeyi güncel tutar.Sözlükte gör →, çalışan instance’ları çalışma anında bulur. İki yaygın model var:
| Model | Listeyi kim tutar | Örnek |
|---|---|---|
| Kayıt servisi | Instance’lar kendini kaydeder, çağıran listeyi alır | Eureka, Consul |
| Platform | Altyapı hazır pod’lara yönlendirir | Kubernetes Service |
Kayıt servisiyle çalışırken seçimi çağıran yapar; buna client-side load balancingÇağıranın, bildiği instance listesinden hangisine gideceğini kendisinin seçmesi (ör. Spring Cloud LoadBalancer). Arada ayrı bir yük dengeleyici yoktur.Sözlükte gör → denir. Kubernetes’te çoğu zaman ayrı bir kayıt servisine gerek yoktur.
Kafam karıştı, daha basit anlat
Servisler sık sık taşınır, adresleri değişir. Service discovery, güncel adresleri tutan bir rehberdir: sen adı söylersin, o sana şu an nerede olduğunu verir.
Her aracı, listeyi kimin tuttuğuna göre ayır.
Pricing servisi ölçeklendi ama yeni pod'lar hiç trafik almıyor; biri çökünce de hatalar başlıyor. Sorun hangi satırlarda?
Kendin gör
Service discovery — ölen instance, yeni gelen instance
Tohum 710195| Periyot | Canlı | Çağıranın bildiği | İstekler |
|---|
Oynat ya da adımla.
Şu an ne oldu?
Sabit adres listesi, retry kapalı
Üç instance: A, B, C. 3. periyotta B çökecek, 6. periyotta yeni bir D gelecek.
Görevler0/3
Ölen bir instance'a sonsuza kadar istek gönderaçık
İpucu
Adres listesi hiç değişmezse?
Hiç hata görme — ama yeni instance'a da tek istek gitmesinaçık
İpucu
Retry hataları gizleyebilir; listenin güncel olup olmadığını söylemez.
Sıfır kullanıcı hatası ve yeni instance trafik alıyoraçık
İpucu
Listeyi güncel tutan bir discovery ve aradaki boşluk için retry.
Olay günlüğü (0)
Henüz olay yok. Oynat veya adımla.
- Varsayılanla oynat. Sabit liste: B çöktükten sonra her üç istekten biri boşluğa gidiyor, D hiç iş almıyor.
- Retry’ı aç. Hatalar kayboldu — ama D hâlâ boşta.
- Kayıt servisi seç, retry’ı kapat. Birkaç periyot hata, sonra toparlanma.
- Platform seç ve retry’ı aç. Hata yok, yeni instance trafik alıyor.
Adres listesi yapılandırmada sabit yazılı ve retry açık. Bir instance çöktü, yerine yenisi geldi. Kullanıcılar hata görmüyor. Sorun var mı?
Satır satır: bir gateway rotası
Yönlendir, sınırla, gerekirse bir kez daha dene
@BeanRouteLocator routes(RouteLocatorBuilder builder) { return builder.routes() .route("pricing", r -> r.path("/api/prices/**") .filters(f -> f .stripPrefix(1) .requestRateLimiter(c -> c.setRateLimiter(redisRateLimiter())) .retry(c -> c.setRetries(1).setMethods(HttpMethod.GET))) .uri("lb://pricing")) .build();}Debug
gateway /api/prices/... ile başlayan her istek bu rotaya düşer.
Sol/sağ ok tuşlarıyla da gezebilirsin.
Adresi değil, servisin adını yaz. Hangi instance’ın yaşadığını bilmek discovery’nin işi.
Şimdi aynı fikri bir bankanın kapısında görelim. Bakiye sorgusu ve para transferi aynı kapıdan girer, ama her biri kendi kuralıyla geçer.
Derinleş · Bankanın kapısı: bakiye, transfer ve canlı adres listesi 4 dosya · ~79 satır · ilk okumada atlayabilirsin
Kafam karıştı, daha basit anlat
Rotaya adres yazma, servisin adını yaz. Adresin güncel olup olmadığını rehber zaten takip ediyor.
Gateway'de 'başka instance'ta bir kez dene' retry'ı açıldı. Hangi isteklerde bu tehlikelidir?
Rate limit aşıldığında istemciye ne dönmelisin?
Tuzaklar
Gateway’de iş kuralı. Sipariş toplamını hesaplayan gateway, her ekibin kuyruğuna girer.
Pod başına rate limit. Üç gateway pod’u kendi sayacını tutarsa gerçek sınır üç katıdır.
POST’u yeniden denemek. Timeout isteğin işlenmediği anlamına gelmez.
Retry ile gizlenen liste. Hata görünmüyor diye liste güncel değil; kapasite sessizce düşer.
Kendini sına
API gateway, dışarıdan gelen isteklerin girdiği ortak kapıdır.
Gateway üç pod'la çalışıyor ve her pod kendi bellek içi sayacıyla dakikada 100 istek sınırı uyguluyor. Gerçek sınır nedir?
Aklında kalacak üç şey
- 1 Gateway yönlendirme, kimlik kontrolü ve istek sınırı gibi ortak işleri toplar. İş kuralı ve ekran birleştirmesi içermez.
- 2 Adresleri elle yazmak sistemin hiç değişmeyeceğini varsaymaktır. Discovery güncel listeyi bulur, ama bir sunucunun öldüğünü her zaman biraz geç öğrenir.
- 3 Tekrar deneme, discovery'nin geriden geldiği kısa boşluğu kapatır; yalnızca tekrarlanması zararsız isteklerde güvenlidir.
5 kart sonraki derste seni bekliyor
Bu dersin üstüne kurulanlar
Bunlar bu dersi temel alıyor; hazır olduğunda devam edebilirsin.
- Mikroservisler & Design PatternsStrangler Fig ve API Sürümleme — Monoliti Kimseyi Kırmadan TaşımakMonoliti bir gecede yeniden yazmadan, müşteriler hiçbir şey fark etmeden parça parça taşıyabilir misin?Derse git
- Mikroservisler & Design PatternsServisler Arası Kimlik — İç Ağdan Gelen Her İstek Güvenilir mi?Muhasebe defterine bir borç kaydı düştü. İstek iç ağdan gelmişti ve doğru anahtarı taşıyordu. Ama gönderen havale servisi değildi.Derse git