Az API-átjáró mintája és a közvetlen ügyfél–mikroszolgáltatás közötti kommunikáció

2024-03-12

Jótanács

Ez a tartalom egy részlet a '.NET Microservices Architecture for Containerized .NET Applications' című eBook-ból, amely elérhető a .NET Docs oldalon, vagy ingyenesen letölthető PDF formátumban, amely offline módban is olvasható.

PDF letöltése

A mikroszolgáltatás-architektúrákban minden mikroszolgáltatás részletes végpontokat (általában) tesz elérhetővé. Ez a tény hatással lehet az ügyfél-mikroszolgáltatások közötti kommunikációra, amint azt ebben a szakaszban ismertetik.

Közvetlen ügyfél-mikroszolgáltatás-kommunikáció

Lehetséges megközelítés egy közvetlen ügyfél–mikroszolgáltatás kommunikációs architektúra használata. Ebben a megközelítésben az ügyfélalkalmazás közvetlenül a mikroszolgáltatások egy részéhez tud kéréseket küldeni, ahogyan az a 4–12. ábrán látható.

Az ügyfél-mikroszolgáltatások közötti kommunikációs architektúrát bemutató ábra.

Ábra 4–12 Közvetlen ügyfél–mikroszolgáltatás kommunikációs architektúra használata

Ebben a megközelítésben minden mikroszolgáltatás nyilvános végponttal rendelkezik, néha más TCP-porttal az egyes mikroszolgáltatásokhoz. Egy adott szolgáltatás URL-címe például a következő URL-cím lehet az Azure-ban:

http://eshoponcontainers.westus.cloudapp.azure.com:88/

Egy klaszteren alapuló termelési környezetben ez az URL a klaszterben használt terheléselosztóhoz fog kapcsolódni, amely pedig elosztja a kéréseket a mikroszolgáltatások között. Éles környezetekben például használhatunk egy alkalmazáskézbesítési vezérlőt (ADC), mint az Azure Application Gateway, a mikroszolgáltatások és az internet között. Ez a réteg transzparens rétegként működik, amely nem csak a terheléselosztást végzi el, hanem SSL-lezárással biztosítja a szolgáltatásokat. Ez a megközelítés csökkenti a gazdagépek terhelését azáltal, hogy a processzorigényes SSL-leállítást és más útválasztási feladatokat átadja az Azure Application Gatewaynek. A terheléselosztó és az ADC mindenesetre logikai alkalmazásarchitektúra szempontjából transzparens.

A közvetlen ügyfél-mikroszolgáltatások közötti kommunikációs architektúra elég jó lehet egy kis mikroszolgáltatás-alapú alkalmazáshoz, különösen akkor, ha az ügyfélalkalmazás kiszolgálóoldali webalkalmazás, például egy ASP.NET MVC-alkalmazás. Ha azonban nagy és összetett mikroszolgáltatás-alapú alkalmazásokat hoz létre (például több tucat mikroszolgáltatás-típus kezelésekor), és különösen akkor, ha az ügyfélalkalmazások távoli mobilalkalmazások vagy SPA-webalkalmazások, ez a megközelítés néhány problémával szembesül.

A mikroszolgáltatásokon alapuló nagy alkalmazások fejlesztésekor vegye figyelembe az alábbi kérdéseket:

Hogyan csökkenthetik az ügyfélalkalmazások a háttérbeli kérések számát, és hogyan csökkenthetik a több mikroszolgáltatás közötti csevegést?

Több mikroszolgáltatással való interakció egyetlen felhasználói felület képernyőjének létrehozása során növeli az internetes körútak számát. Ez a megközelítés növeli a felhasználói felület késését és összetettségét. Ideális esetben a válaszokat hatékonyan kell összesíteni a kiszolgáló oldalán. Ez a megközelítés csökkenti a késést, mivel több adatrész is párhuzamosan tér vissza, és néhány felhasználói felület azonnal megjelenítheti az adatokat, amint készen áll.

Hogyan kezelheti az olyan átfogó szempontokat, mint az engedélyezés, az adatátalakítások és a dinamikus kérésküldés?

Az olyan biztonsági és horizontális szempontok megvalósítása, mint a biztonság és az engedélyezés minden mikroszolgáltatásban jelentős fejlesztési erőfeszítéseket igényelhet. Egy lehetséges megközelítés az, hogy ezek a szolgáltatások a Docker-gazdagépen vagy a belső fürtön belül vannak, hogy kívülről korlátozzák a közvetlen hozzáférésüket, és ezeket a horizontális szempontokat központosított helyen, például EGY API Gatewayben implementálják.

Hogyan kommunikálhatnak az ügyfélalkalmazások a nem internetbarát protokollokat használó szolgáltatásokkal?

A kiszolgálóoldalon használt protokollok (például AMQP vagy bináris protokollok) nem támogatottak az ügyfélalkalmazásokban. Ezért a kéréseket olyan protokollokkal kell végrehajtani, mint a HTTP/HTTPS, és ezt követően le kell fordítani a többi protokollra. Ebben a helyzetben a középen belüli megközelítés segíthet.

Hogyan alakítható ki egy kifejezetten mobilalkalmazásokhoz készült homlokzat?

Előfordulhat, hogy több mikroszolgáltatás API-ja nem megfelelő a különböző ügyfélalkalmazások igényeihez. A mobilalkalmazások igényei például eltérhetnek a webalkalmazások igényeiétől. Mobilalkalmazások esetében előfordulhat, hogy még tovább kell optimalizálnia, hogy az adatválaszok hatékonyabbak legyenek. Ezt a funkciót több mikroszolgáltatás adatainak összesítésével és egyetlen adatkészlet visszaadásával is elvégezheti, és néha kiküszöbölheti a mobilalkalmazás által nem szükséges adatokat a válaszban. És természetesen tömörítheti is az adatokat. A mobilalkalmazás és a mikroszolgáltatások közötti homlokzat vagy API is kényelmes lehet ehhez a forgatókönyvhöz.

Miért érdemes az API-átjárókat a közvetlen ügyfél-mikroszolgáltatás közötti kommunikáció helyett figyelembe venni?

A mikroszolgáltatás-architektúrában az ügyfélalkalmazásoknak általában több mikroszolgáltatás funkcióit kell használniuk. Ha ezt a felhasználást közvetlenül hajtja végre, az ügyfélnek több hívást kell kezelnie a mikroszolgáltatás-végpontokra. Mi történik, ha az alkalmazás fejlődik, és új mikroszolgáltatásokat vezetnek be, vagy a meglévő mikroszolgáltatások frissülnek? Ha az alkalmazás sok mikroszolgáltatással rendelkezik, az ügyfélalkalmazásokból származó ennyi végpont kezelése rémálom lehet. Mivel az ügyfélalkalmazás ezekhez a belső végpontokhoz lenne csatolva, a mikroszolgáltatások jövőbeni fejlesztése nagy hatással lehet az ügyfélalkalmazásokra.

Ezért a mikroszolgáltatás-alapú alkalmazások esetében a közbenső szint vagy a közvetettségi szint (Átjáró) kényelmes lehet. Ha nem rendelkezik API-átjárókkal, az ügyfélalkalmazásoknak közvetlenül a mikroszolgáltatásoknak kell küldeniük a kéréseket, és problémákat okoznak, például a következő problémákat:

Összekapcsolás: Az API Gateway-minta nélkül az ügyfélalkalmazások a belső mikroszolgáltatásokhoz vannak csatolva. Az ügyfélalkalmazásoknak tudniuk kell, hogyan bontja le az alkalmazás több területét a mikroszolgáltatásokban. A belső mikroszolgáltatások fejlesztésekor és újrabontásakor ezek a műveletek hatással vannak a karbantartásra, mert az ügyfélalkalmazások belső mikroszolgáltatásaira való közvetlen hivatkozás miatt az ügyfélalkalmazások kompatibilitástörő változásait okozzák. Az ügyfélalkalmazásokat gyakran frissíteni kell, ami megnehezíti a megoldás fejlődését.
Túl sok oda-visszaút: Előfordulhat, hogy az ügyfélalkalmazás egyetlen lapja/képernyője több szolgáltatáshoz is több hívást igényel. Ez a megközelítés az ügyfél és a kiszolgáló közötti több hálózati utazást eredményezhet, ami jelentős késést eredményez. A köztes szinten kezelt összesítés javíthatja az ügyfélalkalmazás teljesítményét és felhasználói élményét.
Biztonsági problémák: Átjáró nélkül az összes mikroszolgáltatást ki kell fedni a "külső világ" számára, ami nagyobbá teszi a támadási felületet, mintha elrejtené az ügyfélalkalmazások által közvetlenül nem használt belső mikroszolgáltatásokat. Minél kisebb a támadási felület, annál biztonságosabb lehet az alkalmazás.
Horizontális szempontok: Minden nyilvánosan közzétett mikroszolgáltatásnak kezelnie kell az olyan aggályokat, mint az engedélyezés és az SSL. Ezek az aggodalmak sok esetben egyetlen szinten kezelhetők, így egyszerűbbé válhatnak a belső mikroszolgáltatások.

Mi az API Gateway-minta?

Ha nagy vagy összetett mikroszolgáltatás-alapú alkalmazásokat tervez és épít több ügyfélalkalmazással, érdemes megfontolni egy API Gatewayt. Ez a minta egy olyan szolgáltatás, amely egy egyszeri belépési pontot biztosít bizonyos mikroszolgáltatás-csoportok számára. Hasonló az objektumorientált tervezés homlokzati mintájához , de ebben az esetben egy elosztott rendszer része. Az API Gateway-minta néha "frontendhez tartozó háttérrendszerként" (BFF) is ismert, mert az ügyfélalkalmazás igényeit szem előtt tartva hozza létre.

Ezért az API-átjáró az ügyfélalkalmazások és a mikroszolgáltatások között helyezkedik el. Fordított proxyként működik, az ügyfelektől a szolgáltatások felé irányuló kérések átirányítása. Emellett egyéb horizontális funkciókat is biztosít, például a hitelesítést, az SSL leállítását és a gyorsítótárat.

A 4–13. ábra azt mutatja be, hogyan fér el egy egyéni API Gateway egy egyszerűsített mikroszolgáltatás-alapú architektúrában, mindössze néhány mikroszolgáltatással.

Egyéni szolgáltatásként implementált API Gatewayt bemutató ábra.

4–13. ábra. Egyéni szolgáltatásként implementált API Gateway használata

Az alkalmazások egyetlen végponthoz, az API Gatewayhez csatlakoznak, amely úgy van konfigurálva, hogy a kéréseket továbbítsa az egyes mikroszolgáltatásoknak. Ebben a példában az API Gateway tárolóként futó egyéni ASP.NET Core WebHost-szolgáltatásként lesz implementálva.

Fontos kiemelni, hogy ebben a diagramban egyetlen egyéni API Gateway-szolgáltatást használna, amely több és különböző ügyfélalkalmazással néz szembe. Ez a tény fontos kockázat lehet, mivel az API Gateway-szolgáltatás az ügyfélalkalmazásoktól eltérő követelmények alapján növekszik és fejlődik. Végül a különböző igények miatt felbomlik, és gyakorlatilag hasonló lehet egy monolitikus alkalmazáshoz vagy monolitikus szolgáltatáshoz. Ezért erősen ajánlott az API Gatewayt több különálló szolgáltatásra vagy kisebb API Gatewaykre felosztani, egyet-egyet például az ügyfélalkalmazás különböző eszközformáihoz igazítva.

Az API Gateway-minta implementálása során óvatosnak kell lennie. Általában nem jó ötlet, ha egyetlen API Gateway összesítve tartalmazza az alkalmazás összes belső mikroszolgáltatását. Ha igen, monolitikus aggregátorként vagy vezénylőként működik, és az összes mikroszolgáltatás összekapcsolásával megsérti a mikroszolgáltatások autonómiáját.

Ezért az API-átjárókat az üzleti határok és az ügyfélalkalmazások alapján kell elkülöníteni, és nem kell egyetlen összesítőként működnie az összes belső mikroszolgáltatáshoz.

Ha az API Gateway-szintet több API Gatewayre osztja fel, ha az alkalmazás több ügyfélalkalmazással rendelkezik, ez lehet az elsődleges kimutatás a több API Gateway-típus azonosításakor, így az egyes ügyfélalkalmazások igényeinek megfelelően eltérő homlokzattal rendelkezhet. Ez az eset egy "Backend for Frontend" (BFF) nevű minta, amelyben az egyes API-átjárók különböző, az ügyfélalkalmazás-típusokhoz szabott API-t biztosíthatnak, akár az ügyfélforma-tényező alapján is, ha konkrét adapterkódot implementálnak, amely alatt több belső mikroszolgáltatást hív meg, ahogy az alábbi képen látható:

Több egyéni API-átjárót bemutató ábra.

Ábra 4-13.1. Több egyéni API-átjáró használata

A 4–13.1. ábra az ügyféltípus szerint elkülönített API Gatewayeket mutatja be; egy mobilalkalmazáshoz és egy webes ügyfélhez. Egy hagyományos webalkalmazás egy MVC mikroszolgáltatáshoz csatlakozik, amely a webes API Gatewayt használja. A példa egy egyszerűsített architektúrát mutat be több részletes API-átjáróval. Ebben az esetben az egyes API-átjárókhoz azonosított határok kizárólag a "Backend for Frontend" (BFF) mintán alapulnak, ezért csak az ügyfélalkalmazásonként szükséges API-n alapulnak. A nagyobb alkalmazásokban azonban érdemes továbbhaladni, és az üzleti határok alapján más API-átjárókat is létrehozni második tervezési kimutatásként.

Az API Gateway-minta fő funkciói

Az API Gateway több funkciót is kínálhat. A terméktől függően gazdagabb vagy egyszerűbb funkciókat kínálhat, azonban az API Gateway legfontosabb és alapvető funkciói a következő tervezési minták:

Fordított proxy vagy átjáró útválasztása. Az API Gateway fordított proxyt kínál a kérések (7. rétegbeli útválasztás, általában HTTP-kérések) átirányításához vagy átirányításához a belső mikroszolgáltatások végpontjaihoz. Az átjáró egyetlen végpontot vagy URL-címet biztosít az ügyfélalkalmazásokhoz, majd belsőleg leképozza a kéréseket egy belső mikroszolgáltatás-csoportra. Ez az útválasztási funkció segít leválasztani az ügyfélalkalmazásokat a mikroszolgáltatásokról, de a monolitikus API modernizálásakor is kényelmes, ha az API Gatewayt a monolitikus API és az ügyfélalkalmazások között osztja el, majd új API-kat adhat hozzá új mikroszolgáltatásokként, miközben továbbra is az örökölt monolitikus API-t használja, amíg a jövőben több mikroszolgáltatásra nem lesz felosztva. Az API Gateway miatt az ügyfélalkalmazások nem fogják észrevenni, hogy a használt API-k belső mikroszolgáltatásként vagy monolitikus API-ként vannak-e implementálva, és ami még fontosabb, amikor a monolitikus API-t mikroszolgáltatásokká alakítják át, az API Gateway útválasztásának köszönhetően az ügyfélalkalmazások nem lesznek hatással az URI-változásra.

További információ: Átjáró útválasztási mintája.

Kérelmek összesítése. Az átjáróminta részeként több ügyfélkérést (általában HTTP-kérést) összesíthet, amely több belső mikroszolgáltatást céloz meg egyetlen ügyfélkérésben. Ez a minta különösen akkor kényelmes, ha egy ügyféloldalnak/képernyőnek több mikroszolgáltatás információira van szüksége. Ezzel a módszerrel az ügyfélalkalmazás egyetlen kérést küld az API Gatewaynek, amely több kérést küld a belső mikroszolgáltatásoknak, majd összesíti az eredményeket, és mindent visszaküld az ügyfélalkalmazásnak. Ennek a tervezési mintának a fő előnye és célja az ügyfélalkalmazások és a háttér API közötti csevegés csökkentése, ami különösen fontos az adatközponton kívüli távoli alkalmazások esetében, ahol a mikroszolgáltatások élnek, például mobilalkalmazások vagy az ügyfél távoli böngészőiben a JavaScriptből származó SPA-alkalmazásokból érkező kérések. A kiszolgálói környezetben (például egy ASP.NET Core MVC-webalkalmazásban) a kéréseket végrehajtó normál webalkalmazások esetében ez a minta nem olyan fontos, mivel a késés sokkal kisebb, mint a távoli ügyfélalkalmazások esetében.

A használt API Gateway-terméktől függően előfordulhat, hogy képes elvégezni ezt az összesítést. Sok esetben azonban rugalmasabb az aggregációs mikroszolgáltatások létrehozása az API Gateway hatókörében, ezért az összesítést kódban (azaz C#-kódban) definiálhatja:

További információkért lásd: Átjáró-összesítési mintázat.

Keresztirányú aggodalmak vagy átjáró-kiszervezés. Az egyes API Gateway-termékek által kínált funkcióktól függően ki lehet kapcsolni a funkciókat az egyes mikroszolgáltatásokból az átjáróra, ami leegyszerűsíti az egyes mikroszolgáltatások megvalósítását azáltal, hogy egy szintre összesíti a horizontális szempontokat. Ez a megközelítés különösen kényelmes olyan speciális funkciókhoz, amelyek bonyolultak lehetnek minden belső mikroszolgáltatásban, például a következő funkciókban:

Hitelesítés és engedélyezés
Szolgáltatásfelderítési integráció
Válasz gyorsítótárazása
Újrapróbálkozási szabályzatok, áramköri megszakító, és QoS
Sebességkorlátozás és szabályozás
Terheléselosztás
Naplózás, nyomkövetés, korreláció
Fejlécek, lekérdezési sztringek és jogcímek átalakítása
IP-engedélyezési lista

További információért lásd: Átjáró tehermentesítési minta.

Termékek használata API Gateway-funkciókkal

Az API Gateways-termékek az egyes implementációktól függően számos további horizontális problémát is kínálhatnak. Itt ismerkedünk meg:

Azure API Management

Az Azure API Management (ahogyan a 4–14. ábrán látható) nemcsak az API Gateway-igényeket oldja meg, hanem olyan funkciókat is biztosít, mint például az API-kból származó elemzések összegyűjtése. Ha API felügyeleti megoldást használ, az API Gateway csak egy összetevő a teljes API felügyeleti megoldáson belül.

Az Azure API Management API-átjáróként való használatát bemutató ábra.

4–14. ábra. Az Azure API Management használata az API Gatewayhez

Az Azure API Management megoldja az API Gateway és a Felügyelet igényeit, például a naplózást, a biztonságot, a mérést stb. Ebben az esetben, ha olyan terméket használ, mint az Azure API Management, az a tény, hogy egyetlen API-átjáróval rendelkezhet, nem olyan kockázatos, mert az ilyen típusú API Gatewayek "vékonyabbak", ami azt jelenti, hogy nem implementál egyéni C#-kódot, amely monolitikus összetevő felé fejlődhet.

Az API Gateway-termékek általában fordított proxyként működnek a bejövő kommunikációhoz, ahol az API-kat a belső mikroszolgáltatásokból is szűrheti, valamint engedélyezheti a közzétett API-kat ebben az egyetlen szinten.

Az API Management-rendszerekből elérhető elemzések segítségével megismerheti az API-k használatát és azok működését. Ezt a tevékenységet úgy hajtják végre, hogy közel valós idejű elemzési jelentéseket tekinthet meg, és azonosíthatja azokat a trendeket, amelyek hatással lehetnek a vállalkozására. Emellett további online és offline elemzés céljából naplókat is készíthet a kérelem- és választevékenységekről.

Az Azure API Management segítségével kulcsokkal, jogkivonatokkal és IP-szűréssel védheti az API-kat. Ezek a funkciók lehetővé teszik a rugalmas és részletes kvóták és sebességkorlátozások kikényszerítését, az API-k alakjának és viselkedésének szabályzatok használatával történő módosítását, valamint a teljesítmény javítását a válasz gyorsítótárazásával.

Ebben az útmutatóban és a referencia-mintaalkalmazásban (eShopOnContainers) az architektúra egy egyszerűbb és egyénileg létrehozott tárolóalapú architektúrára korlátozódik, hogy a PaaS-termékek, például az Azure API Management használata nélkül összpontosítson az egyszerű tárolókra. A Microsoft Azure-ban üzembe helyezett nagy mikroszolgáltatás-alapú alkalmazások esetében azonban javasoljuk, hogy értékelje az Azure API Managementet az éles környezetben futó API Gateway-átjárók alapjaként.

Ocelot

Az Ocelot egy egyszerűsített API Gateway, amely egyszerűbb megközelítésekhez ajánlott. Az Ocelot egy nyílt forráskódú .NET Core-alapú API Gateway, amely kifejezetten olyan mikroszolgáltatás-architektúrákhoz készült, amelyeknek egységes belépési pontokra van szükségük a rendszereikbe. Egyszerű, gyors és méretezhető, és számos más funkció mellett útválasztást és hitelesítést is biztosít.

Az eShopOnContainers referenciaalkalmazás 2.0-s referenciaalkalmazásához az Ocelot kiválasztásának fő oka az, hogy az Ocelot egy .NET Core egyszerűsített API Gateway, amelyet ugyanabban az alkalmazástelepítési környezetben helyezhet üzembe, ahol a mikroszolgáltatásokat/tárolókat helyezi üzembe, például Docker-gazdagépet, Kubernetes-t stb. Mivel a .NET Core-on alapul, platformfüggetlen, így Linuxon vagy Windowson is üzembe helyezhető.

A tárolókban futó egyéni API Gatewayeket bemutató előző diagramok pontosan azt mutatják be, hogyan futtatható az Ocelot egy tároló- és mikroszolgáltatás-alapú alkalmazásban is.

Emellett a piacon számos más termék is kínál API Gateways-funkciókat, például Apigee, Kong, MuleSoft, WSO2 és egyéb termékek, mint például a Linkerd és az Istio a szolgáltatáshálós bejövőforgalom-vezérlő funkcióihoz.

A kezdeti architektúra és minták magyarázata után a következő szakaszok ismertetik, hogyan implementálhatók az API Gatewayek az Ocelottal.

Az API Gateway-minta hátrányai

A legfontosabb hátránya, hogy az API Gateway implementálásakor ezt a szintet a belső mikroszolgáltatásokhoz kapcsoljuk. Az ilyen összekapcsolás komoly nehézségeket okozhat az alkalmazás számára. Clemens Vaster, az Azure Service Bus csapatának tervezője a GOTO 2016 "Üzenetkezelés és mikroszolgáltatások" szekciójának "új ESB-jének" nevezi ezt a lehetséges nehézséget.
A mikroszolgáltatások API-átjárójának használata további lehetséges meghibásodási pontot hoz létre.
Az API-átjárók a további hálózati hívás miatt megnövelhetik a válaszidőt. Azonban ez az extra hívás általában kisebb hatással van, mint egy túlzottan beszédes ügyfélfelület, amely közvetlenül hívja a belső mikroszolgáltatásokat.
Ha nem skálázható ki megfelelően, az API Gateway szűk keresztmetszetté válhat.
Az API Gateway további fejlesztési költségeket és későbbi karbantartást igényel, ha egyéni logikát és adatösszesítést is tartalmaz. A fejlesztőknek frissíteni kell az API Gatewayt, hogy elérhetővé tegyék az egyes mikroszolgáltatások végpontjait. Emellett a belső mikroszolgáltatások implementálási változásai kódmódosításokat okozhatnak az API Gateway szintjén. Ha azonban az API Gateway csak a biztonságot, a naplózást és a verziószámozást alkalmazza (például az Azure API Management használatakor), előfordulhat, hogy ez a további fejlesztési költség nem lesz érvényes.
Ha az API Gatewayt egyetlen csapat fejleszti, a fejlesztés szűk keresztmetszete is lehet. Ez a szempont egy másik oka annak, hogy a jobb módszer az, ha több, a különböző ügyféligényeknek megfelelő, finomított API Gateway-átjáróval rendelkezik. Az API Gatewayt belsőleg is elkülönítheti több olyan területre vagy rétegre, amelyek a belső mikroszolgáltatásokon dolgozó különböző csapatok tulajdonában vannak.