A lecke végére meg tudod különböztetni a reverse proxy, az API gateway és a BFF szerepét, és fel tudod sorolni a közös belépési pont előnyeit és költségeit.
Miért kell?
Több szolgáltatásnál a kliensnek valahogy el kell jutnia a megfelelő szolgáltatáshoz. Az Azure leírása szerint közvetlen hívásnál a kliens kódja összetett lesz (több végpontot kell követni és hibát kezelni), a kliens a backend felbontásához kötődik, több hálózati körút késleltet, minden publikus szolgáltatásnak külön kell kezelnie a hitelesítést és a korlátozást, és megnő a támadási felület.
Szerepek
A reverse proxy a szerverek előtt áll, és a beérkező kéréseket továbbítja. Elrejtheti a belső címeket, lezárhatja a TLS-kapcsolatot, és több célt kezelhet.
Az API gateway az API-k közös belépési pontja. Az Azure szerint reverse proxyként működik, a kéréseket a megfelelő szolgáltatáshoz irányítja, és keresztmetszeti feladatokat is elláthat: hitelesítés, TLS-lezárás, mutual TLS, korlátozás (rate limiting). A microservices.io megfogalmazásában ez a minta „az egyetlen belépési pont minden kliens számára”: vagy egy szolgáltatáshoz irányít, vagy több szolgáltatásra szétküld.
Az Azure három gateway-mintát különböztet meg:
Routing: réteg-7 útválasztás, egyetlen végpont a kliensnek;
Aggregation: több kérést egybe vonva csökkenti a kliens és a szolgáltatások közti fecsegést;
Offloading: a közös feladatok (TLS, hitelesítés, korlátozás, naplózás, gyorsítótár…) áthelyezése a szolgáltatásokból.
Egy termék több szerepet is betölthet, ezért az architektúrában a funkciót nevezzük meg, ne a terméket.
flowchart LR
C["Külső kliens"] --> G["Gateway: belépési szabályok"]
G --> R{"Útvonal alapján"}
R -->|"/a"| A["A szolgáltatás"]
R -->|"/b"| B["B szolgáltatás"]
Routing
A cél választható host, útvonal vagy explicit verzió alapján (az Envoy leírása szerint például útvonal és authority alapján). A szabályokat egyértelmű sorrendben kell alkalmazni; egy túl általános minta egy konkrét útvonalat is elnyelhet. Útvonalátírásnál tisztázni kell, mit lát a belső szolgáltatás. A gateway által továbbított fejlécek bizalmi kérdések: a külső kliens által megadott „user” vagy „role” fejléc nem válhat hiteles kontextussá.
BFF és aggregáció
A BFF egy adott kliens igényeihez igazított szerveroldali réteg. A microservices.io szerint a BFF-mintában kliensfajtánként külön gateway van (például webes, mobil és külső partneri); mindegyik a saját kliensének szabott API-t ad. A BFF feladatai: összeállítja a több szolgáltatásból származó választ (API composition), a belső hibákat a kliens számára kezelhető állapotokká alakítja, és csökkenti a válasz méretét.
Fontos szabályok:
A kötelező adat hiánya hibát, az opcionális adat hiánya jelölt részleges választ jelent; a szerződésnek láthatóvá kell tennie, különben a kliens összekeveri a „nincs értékelés” és a „nem sikerült lekérni” állapotot.
Az összeállított adat eltérő időpontokból származhat; az összefoglaló olvasás nem helyettesíti a végleges döntést a gazdánál.
A webes és a mobil BFF külön változhat, de közös üzleti szabályt ne másoljanak le.
Személyre szabott válasznál a gyorsítótár-kulcsnak tartalmaznia kell a válaszra ható kontextust, különben a megosztott gyorsítótár tilos.
Az API composition kérés idején kéri össze az adatot; a read model (4.3) előre feldolgozott másolat. A választás a frissességi és rendelkezésre állási követelménytől függ.
Előny és ár
A kliensnek kevesebb címet és hitelesítési kapcsolatot kell ismernie; a belső felbontás a publikus API stabilitása mellett változhat; a közös szabályok egy helyen érvényesíthetők. Az ár: egy extra ugrás, közös függőség, saját kapacitás és rendelkezésre állás. Az Azure szerint a gateway ne váljon egyetlen hibaponttá vagy szűk keresztmetszetté (a Strangler Fig minta leírásában is figyelmeztet erre). Ha minden üzleti folyamat a gateway/BFF-be kerül, egy új központi koordinátor, vagyis egy kis monolit alakul ki a szolgáltatások előtt.
Jellemzők (kommunikációs szempontból)
Szempont
Gateway / BFF
Irány
Átereszt: a kliens felől befelé, válasz vissza
Kezdeményező
A kliens
Kapcsolat tartóssága
Kérésenként, vagy a kliens által használt protokoll szerint
Késleltetés
Egy extra ugrás; aggregációnál csökkenhet a kliens körúttal számolva
Terhelés
Összefogja a forgalmat; saját kapacitást igényel
Hibatűrés
Egy hibapont lehet; a részleges válasz szabályát meg kell adni
Mikor jó?
Sok szolgáltatás, eltérő kliensek, közös keresztmetszeti szabályok
Mikor nem?
Egyetlen szolgáltatás; ha az üzleti logika átszivárog a gateway-be
Gyakori tévhitek
Állítás
Pontosítás
„A reverse proxy, a gateway és a load balancer külön szerverek.”
Szerepek; egy termék több szerepet is elláthat.
„A BFF új adatgazda.”
Összeállít és fordít; az adat a szolgáltatásoké.
„A gateway-n átment kérés megbízható.”
A kliens fejléceit nem szabad hitelesnek venni.
„Egy gateway minden kliensnek jó.”
A kliensek eltérő igényei miatt kliensenkénti BFF is lehet.
Röviden
A reverse proxy továbbít, az API gateway közös belépési pont és keresztmetszeti feladatok helye, a BFF kliensre szabott réteg.
A gateway mintái: routing, aggregation, offloading.
A BFF részleges választ is adhat; ezt a szerződésnek jeleznie kell.
A gateway egy hibapont és egy lehetséges új monolit; az adatgazda felelősségét nem veszi át.
Ellenőrző kérdések
Mi a különbség a routing és az aggregation gateway-minta között?
Mit jelöl a részleges válasz, és miért kell jelölni?
Miért kell a szolgáltatásnak a gateway mögött is jogosultságot ellenőriznie?
Reverse proxy, API gateway és BFF
Célok
A lecke végére meg tudod különböztetni a reverse proxy, az API gateway és a BFF szerepét, és fel tudod sorolni a közös belépési pont előnyeit és költségeit.
Miért kell?
Több szolgáltatásnál a kliensnek valahogy el kell jutnia a megfelelő szolgáltatáshoz. Az Azure leírása szerint közvetlen hívásnál a kliens kódja összetett lesz (több végpontot kell követni és hibát kezelni), a kliens a backend felbontásához kötődik, több hálózati körút késleltet, minden publikus szolgáltatásnak külön kell kezelnie a hitelesítést és a korlátozást, és megnő a támadási felület.
Szerepek
A reverse proxy a szerverek előtt áll, és a beérkező kéréseket továbbítja. Elrejtheti a belső címeket, lezárhatja a TLS-kapcsolatot, és több célt kezelhet.
Az API gateway az API-k közös belépési pontja. Az Azure szerint reverse proxyként működik, a kéréseket a megfelelő szolgáltatáshoz irányítja, és keresztmetszeti feladatokat is elláthat: hitelesítés, TLS-lezárás, mutual TLS, korlátozás (rate limiting). A microservices.io megfogalmazásában ez a minta „az egyetlen belépési pont minden kliens számára”: vagy egy szolgáltatáshoz irányít, vagy több szolgáltatásra szétküld.
Az Azure három gateway-mintát különböztet meg:
Egy termék több szerepet is betölthet, ezért az architektúrában a funkciót nevezzük meg, ne a terméket.
flowchart LR C["Külső kliens"] --> G["Gateway: belépési szabályok"] G --> R{"Útvonal alapján"} R -->|"/a"| A["A szolgáltatás"] R -->|"/b"| B["B szolgáltatás"]Routing
A cél választható host, útvonal vagy explicit verzió alapján (az Envoy leírása szerint például útvonal és authority alapján). A szabályokat egyértelmű sorrendben kell alkalmazni; egy túl általános minta egy konkrét útvonalat is elnyelhet. Útvonalátírásnál tisztázni kell, mit lát a belső szolgáltatás. A gateway által továbbított fejlécek bizalmi kérdések: a külső kliens által megadott „user” vagy „role” fejléc nem válhat hiteles kontextussá.
BFF és aggregáció
A BFF egy adott kliens igényeihez igazított szerveroldali réteg. A microservices.io szerint a BFF-mintában kliensfajtánként külön gateway van (például webes, mobil és külső partneri); mindegyik a saját kliensének szabott API-t ad. A BFF feladatai: összeállítja a több szolgáltatásból származó választ (API composition), a belső hibákat a kliens számára kezelhető állapotokká alakítja, és csökkenti a válasz méretét.
Fontos szabályok:
Az API composition kérés idején kéri össze az adatot; a read model (4.3) előre feldolgozott másolat. A választás a frissességi és rendelkezésre állási követelménytől függ.
Előny és ár
A kliensnek kevesebb címet és hitelesítési kapcsolatot kell ismernie; a belső felbontás a publikus API stabilitása mellett változhat; a közös szabályok egy helyen érvényesíthetők. Az ár: egy extra ugrás, közös függőség, saját kapacitás és rendelkezésre állás. Az Azure szerint a gateway ne váljon egyetlen hibaponttá vagy szűk keresztmetszetté (a Strangler Fig minta leírásában is figyelmeztet erre). Ha minden üzleti folyamat a gateway/BFF-be kerül, egy új központi koordinátor, vagyis egy kis monolit alakul ki a szolgáltatások előtt.
Jellemzők (kommunikációs szempontból)
Gyakori tévhitek
Röviden
Ellenőrző kérdések
Források