Mikroservis Katmanları — İstek Nereden Geçiyor
Önce şunu oku: Servisler Arası İletişim Desenleri
30 saniyede özet
Mimari çizimlerdeki her kutu ayrı bir soruya cevap verir: gateway ortak kapıdır, BFF bir ekranı tanır, servis kuralı tutar. Bir kutuyu atlarsan onun işi başka bir yere sızar.
Mikroservis mimarisi diyagramlarında kutular üst üste dizilir: gateway, BFF, servisler, veri. Sorun şu ki hiç kimse her kutunun hangi soruyu cevapladığını söylemez.
Adım adım oku
- Gateway danışma gibidir: isteği karşılar, kimliğe bakar ve doğru servise yönlendirir.
- BFF, tek bir ekran için gereken bilgileri toplayan hemşire gibidir.
- Servisler asıl uzmanlığın, yani iş kurallarının yaşadığı doktorlardır; altındaki veri katmanı laboratuvardır.
- Her kutu tek bir soruya cevap verir: kim ve nereye, bu ekran neye ihtiyaç duyar, iş kuralı ne, veri nerede saklanır.
-
Bayt: Mimari çizimimizde kat kat kutular var: gateway, BFF, servisler, veri...
-
Sen: Her biri ne işe yarıyor?
-
Bayt: Açıkçası bunu kimse bize hiç söylemedi.
-
Bayt: Hastanede danışma, hemşire ve doktor aynı işi yapmaz. Katmanlar da öyle.
Her katman bir soruya cevap verir
| Katman | Cevapladığı soru | Bilmediği şey |
|---|---|---|
| Gateway | Bu isteği kim yaptı ve nereye gidecek? | İşin ne olduğu |
| BFF | Bu ekran için hangi veriler, hangi şekilde? | Kuralların ne olduğu |
| Domain servisi | Bu iş kuralı nedir, geçerli mi? | İsteğin hangi ekrandan geldiği |
| Veri katmanı | Bu veri nerede duruyor ve nasıl okunur? | Neden okunduğu |
Sağdaki sütun soldakinden daha önemli. Bir katman bilmemesi gereken şeyi bilmeye başlayınca katman olmaktan çıkar: ekran adını bilen bir domain servisi artık o ekrana bağlıdır.
Kafam karıştı, daha basit anlat
Her katmanın bir işi var, ve bilmemesi gereken şeyler de var. Kapıdaki görevli indirim hesaplamaya başlarsa, artık kapı görevlisi değildir.
API gateway'in asıl varlık sebebi nedir?
Gateway ile BFF arasındaki fark nedir?
Gateway neyi çözer, neyi çözmez?
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 →’in varlık sebebi gecikme değil. Çözdüğü şey tekrar: auth, rate limit, TLS sonlandırma ve log korelasyonu gibi kesişen ilgiHer servisi ilgilendiren ama hiçbirinin iş kuralı olmayan işler: auth, rate limit, log korelasyonu, TLS sonlandırma.Bunlar her serviste tekrarlanırsa aynı kural N yerde tutulur ve biri geride kalır. Gateway'in asıl varlık sebebi gecikme değil, bu tekrarın tek yere toplanmasıdır.Sözlükte gör →ler her serviste ayrı ayrı yazılırsa aynı kural beş yerde tutulur ve er geç biri geride kalır.
Ama gateway yönlendirir, birleştirmez. Sayfa beş servisten veri istiyorsa istemci yine beş kez gidip gelir — üstüne bir hop daha eklenmiş olur.
Gateway koymak sayfanın açılma süresini düşürür mü? Cevabı göster
Hayır, biraz artırır. Çağrı sayısı aynı kaldı ve araya bir hop girdi. Süreyi düşüren şey sunucu tarafında birleştirme yapan BFF’tir.
Kafam karıştı, daha basit anlat
Gateway binanın tek giriş kapısıdır: kimlik kontrolü ve yönlendirme orada yapılır. Ama beş farklı odadan bilgi toplamaz, seni sadece doğru odaya yollar.
Beş servisten veri çeken bir sayfanın önüne gateway koydun. Açılma süresi ne olur?
Satır satır: bir ürün sayfası
Aynı sayfa, katman katman
GET /api/products/42GET /api/prices/42GET /api/stock/42GET /api/reviews?productId=42GET /api/recommendations?productId=42 # gateway sonrası: aynı beş çağrı, tek adresGET /gw/products/42 # BFF sonrası: tek çağrı, sayfaya biçilmiş yanıtGET /mobile/product-page/42Debug
doğrudan İstemci beş servisi de tanıyor. Her biri kendi yetkilendirmesini yapıyor — aynı kural beş yerde.
- istemci çağrısı
- = 5
- auth
- = 5 yerde
Sol/sağ ok tuşlarıyla da gezebilirsin.
Buradaki asıl fikir şu: over-fetchingİstemcinin ihtiyacından fazla veri indirmesi. Servis kendi modelini döndürdüğü, ekranın neye ihtiyacı olduğunu bilmediği için olur.Mobilde asıl maliyet baytların kendisi değil, o baytları taşıyan ek gidiş-dönüşlerdir. Under-fetching tersidir: tek çağrı yetmez, istemci ikinci bir çağrı yapmak zorunda kalır.Sözlükte gör →’in maliyeti baytlarda değil, o baytları taşıyan gidiş-dönüşlerde. Mobil bir ağda tek bir round trip, veri merkezi içindeki yirmi hop’tan pahalıdır.
Mobil istemcide over-fetching'in asıl maliyeti nedir?
Her sorumluluğu, ait olduğu katmana göre ayır.
Kendin gör
Aynı sayfa, dört topoloji
Tohum 5- Doğrudan çağrı
- Gateway
- BFF
- Katman yığını
İstemci beş servisi tek tek çağırıyor.
- İstemci
- 5 servis
- İstemci çağrısı
- 5
- Auth kaç yerde
- 5
- Sunucu içi hop
- 1
- Şekli değiştirmek için
- 5 ekip
| Topoloji | Sayfa süresi | Fazla veri |
|---|---|---|
| Doğrudan çağrı | 605 ms | 42 KB |
| Gateway | 610 ms | 42 KB |
| BFFen hızlı | 135 ms | 3 KB |
| Katman yığını | 145 ms | 3 KB |
Şu an ne oldu?
5 çağrı, 605 ms
Her servis kendi yetkilendirmesini yapıyor — 5 ayrı yerde aynı kural. İstemci 42 KB fazladan veri indiriyor çünkü servisler sayfayı değil kendi modellerini döndürüyor. Bu ağda BFF daha hızlı (135 ms).
Aklında kalsın: Katmansız topoloji en az hop demektir; bedeli, istemcinin servis sayısını ve her servisin güvenliği bilmesidir.
Görevler0/3
Yetkilendirmeyi beş yerden tek yere indiraçık
İpucu
"Gateway koy"a bas. İstemci hâlâ beş çağrı yapıyor, ama güvenlik artık tek kapıda.
Sayfayı tek bir istemci gidiş-dönüşüyle ve tek sahip ekiple çizaçık
İpucu
Gateway’den sonra "BFF ekle". Birleştirme istemciden sunucuya geçiyor.
Doğrudan çağrının en hızlı olduğu bir ağ koşulu bulaçık
İpucu
İstemci aynı veri merkezindeyse gidiş-dönüş ucuz, sunucu içi hop pahalı olabilir. Slider’ları iki uca çek.
Olay günlüğü (0)
Henüz olay yok. Oynat veya adımla.
Sırayla dene:
- Başlangıçta istemci beş servisi tek tek çağırıyor. “Gateway koy”a bas — auth beş yerden bire indi ama sayfa süresi arttı.
- “BFF ekle”ye bas: çağrı sayısı bire düştüğü için süre de düştü. Asıl kazanç burada.
- İstemci gidiş-dönüşünü 10 ms’ye, hop maliyetini 60 ms’ye çek. Şimdi doğrudan çağrı kazanıyor — istemci yakın ve sunucu içi pahalıysa her katman bir vergi.
- “Katman yığ”a bas: hiçbir ağda kazanmıyor. BFF’in verdiği her şeyi veriyor, üstüne iki hop ve iki ayrı auth noktası ekliyor.
- Görevleri tamamla. Sonuncusu, BFF’in her ağda kazanmadığını gösteriyor.
Tuzaklar
Gateway’i tek arıza noktası yapmak. Her istek oradan geçiyorsa düştüğünde her şey düşer. En az iki örnek, sağlık kontrolü ve gateway’in kendi bağımlılıklarını en aza indirmek şart.
Her istemci için BFF, ama sahipsiz. BFF’in değeri istemci ekibinin sahipliğinden gelir. Platform ekibinin baktığı bir BFF, adı değişmiş bir gateway’dir — ve her ekran değişikliği yine başka bir ekibin kuyruğunda bekler.
Paylaşılan BFF. Mobil ve web aynı BFF’i kullanmaya başladığında yanıt ikisine birden yetecek kadar büyür. O noktada elinde BFF değil, ikinci bir genel amaçlı API vardır.
Aşağıdaki örnek bir bankanın mobil uygulamasının hesap detay ekranı: her katman yalnızca kendi sorusuna cevap veriyor.
Derinleş · Hesap detay ekranı: gateway, BFF ve domain servisi 5 dosya · ~98 satır · ilk okumada atlayabilirsin
Kafam karıştı, daha basit anlat
Tek bir giriş kapısı kapanırsa bina kapanır. Kapıyı en az iki tane yap ve kapıya iş kuralı taşıma.
Kendini sına
Gateway, isteği doğru servise yönlendiren ortak kapıdır.
BFF beş servisi paralel çağırıyor. Yorum servisi hata döndürüyor — istemci ne görür?
Aklında kalacak üç şey
- 1 Gateway gecikmeyi çözmez, tekrarı çözer: kimlik kontrolü ve istek sınırı gibi ortak işleri tek bir yerde toplar.
- 2 Kullanıcının cihazı ile sunucu arasındaki gidiş dönüşleri azaltan katman BFF'tir. Pahalı olan ağ, sunucuların kendi arasındaki değil, kullanıcıya giden ağdır.
- 3 Her katman hangi soruyu cevapladığını söyleyebilmeli. Söyleyemeyen katman yalnızca fazladan bir durak ve bir koordinasyon yüküdür.
5 kart sonraki derste seni bekliyor
Bu dersin üstüne kurulanlar
Bunlar bu dersi temel alıyor; hazır olduğunda devam edebilirsin.