Előtérminta háttérrendszerei

Ez a minta bemutatja, hogyan lehet leválasztani a háttérszolgáltatásokat az előtérbeli implementációkról a különböző ügyfélfelületek felhasználói élményének testreszabásához. Ez a minta akkor hasznos, ha el szeretné kerülni a több felületet kiszolgáló háttérrendszer testreszabását. Ez a minta Sam Newman Backends for Frontends mintáján alapul.

Környezet és probléma

Fontolja meg az eredetileg asztali webes felhasználói felülettel és egy megfelelő háttérszolgáltatással tervezett alkalmazást. Ahogy az üzleti követelmények idővel változnak, a rendszer mobilfelületet ad hozzá. Mindkét felület ugyanazt a háttérszolgáltatást használja. A mobileszköz képességei azonban jelentősen eltérnek az asztali böngészőtől a képernyőméret, a teljesítmény és a megjelenítés korlátai tekintetében.

A diagram két szakaszból áll: a háttérszolgáltatásból, valamint az asztali ügyfél- és mobilügyfélből. Két kétoldalas nyíl a háttérszolgáltatásról az asztali ügyfélre és a mobilügyfélre is mutat.

A háttérszolgáltatás gyakran találkozik több előtérbeli rendszer versengő igényeivel. Ezek az igények gyakori frissítéseket és potenciális fejlesztési szűk keresztmetszeteket eredményeznek. Az ütköző frissítések és a kompatibilitás fenntartásának szükségessége túlzott keresletet eredményez egyetlen üzembe helyezhető erőforrás esetében.

Ha egy külön csapat kezeli a háttérszolgáltatást, megszakadhat a kapcsolat az előtérbeli és a háttérbeli csapatok között. Ez a kapcsolat megszakadása késleltetheti a konszenzus és a kiegyensúlyozási követelmények megszerzését. Az integráció előtt például az egyik előtérbeli csapat által kért módosításokat más előtérbeli csapatokkal kell ellenőrizni.

Megoldás

Vezessen be egy új réteget, amely csak az interfészre jellemző követelményeket kezeli. Ez a réteg, más néven backend-for-frontend (BFF) szolgáltatás, az előtérbeli ügyfél és a háttérrendszer között helyezkedik el. Ha az alkalmazás több felületet támogat, például egy webes felületet és egy mobilalkalmazást, hozzon létre egy BFF-szolgáltatást minden felülethez.

Ez a minta testre szabja az ügyfélélményt egy adott felülethez anélkül, hogy más felületekre hatással van. Emellett optimalizálja a teljesítményt az előtérbeli környezet igényeinek megfelelően. Mivel minden BFF-szolgáltatás kisebb és kevésbé összetett, mint a megosztott háttérszolgáltatás, egyszerűbbé teheti az alkalmazást.

Az előtérbeli csapatok önállóan kezelik saját BFF-szolgáltatásukat, amely lehetővé teszi számukra a nyelv kiválasztását, a kiadási ütemet, a számítási feladatok rangsorolását és a funkcióintegrációt. Ez az autonómia lehetővé teszi számukra, hogy hatékonyan működjenek anélkül, hogy egy központi háttérrendszer fejlesztési csapatától függenek.

Számos BFF-szolgáltatás hagyományosan REST API-kra támaszkodik, de a GraphQL-implementációk alternatívaként jelennek meg. A GraphQL használatával a lekérdezési mechanizmus révén nincs szükség külön BFF-rétegre, mivel lehetővé teszi az ügyfelek számára, hogy a szükséges adatokat kérjék le anélkül, hogy előre definiált végpontokra támaszkodnának.

Az ábrán három szakasz látható. Az első szakasz az asztali ügyfélből és a mobilügyfélből áll. A második szakasz az asztali ügyfél BFF szolgáltatásából és a mobilügyfél BFF szolgáltatásából áll. Az asztali ügyfél egy szilárd nyíllal rendelkezik, amely az asztali ügyfél BFF szolgáltatására mutat. A mobilügyfél egy szilárd nyíllal rendelkezik, amely a mobilügyfél BFF szolgáltatására mutat. Minden BFF-szolgáltatás rendelkezik egy pontozott nyíllal, amely a háttérszolgáltatás szakaszára mutat.

További információért lásd Sam Newman Backends for Frontends mintáját.

Problémák és szempontok

• A kapcsolódó költségektől függően értékelje ki a szolgáltatások optimális számát. A további szolgáltatások fenntartása és üzembe helyezése nagyobb üzemeltetési többletterhelést jelent. Minden egyes szolgáltatás saját életciklussal, üzembe helyezési és karbantartási követelményekkel, valamint biztonsági követelményekkel rendelkezik.

• Új szolgáltatás hozzáadásakor tekintse át a szolgáltatási szintű célkitűzéseket. Nagyobb késést okozhat, hogy az ügyfelek nem közvetlenül lépnek kapcsolatba a szolgáltatásaival, és az új szolgáltatás további hálózati ugrást vezet be.

• Ha a különböző interfészek ugyanazokat a kéréseket készítik, értékelje ki, hogy a kérések egyetlen BFF-szolgáltatásba konszolidálhatók-e. Ha egyetlen BFF-szolgáltatást oszt meg több interfész között, az eltérő követelményeket eredményezhet az egyes ügyfelek számára, ami megnehezítheti a BFF szolgáltatás növekedését és támogatását.

  A kódismétlődés valószínű eredménye ennek a mintának. Értékelje ki a kódismétlődések közötti kompromisszumot, és az egyes ügyfelek számára jobban szabott élményt.

• A BFF szolgáltatásnak csak egy adott felhasználói élményhez kapcsolódó ügyfélspecifikus logikát kell kezelnie. A hatékonyság fenntartása érdekében el kell absztrakcióra bírni a horizontális jellemzőket, például a monitorozást és az engedélyezést. A BFF szolgáltatásban felszínre kerülhető tipikus funkciókat a gatekeeping, a sebességkorlátozás és az útválasztási minták külön kezelik.

• Gondolja át, hogyan befolyásolja a minta tanulása és megvalósítása a fejlesztői csapatot. Az új háttérrendszerek fejlesztése időt és energiát igényel, ami technikai adósságot eredményezhet. A meglévő háttérszolgáltatás fenntartása növeli ezt a kihívást.

• Értékelje ki, hogy szüksége van-e erre a mintára. Ha például a szervezet a GraphQL-t használja előtér-specifikus feloldókkal, előfordulhat, hogy a BFF-szolgáltatások nem adnak értéket az alkalmazásoknak.

  Egy másik forgatókönyv egy olyan alkalmazás, amely egyesíti az API-átjárót a mikroszolgáltatásokkal. Ez a megközelítés elegendő lehet bizonyos helyzetekben, ahol a BFF-szolgáltatások általában ajánlottak.

Mikor érdemes használni ezt a mintát?

Használja ezt a mintát, ha:

• A megosztott vagy általános célú háttérszolgáltatás fenntartása jelentős fejlesztési többletterhelést igényel.

• A háttérrendszert az adott ügyfélfelületek követelményeihez szeretné optimalizálni.

• Testre szabhat egy általános célú háttérrendszert, hogy több interfészt is elférjen.

• A programozási nyelv jobban megfelel egy adott felhasználói felület háttérrendszerének, de nem minden felhasználói felületnek.

Ez a minta nem feltétlenül megfelelő, ha:

• Az interfészek ugyanazokat vagy hasonló kéréseket intéznek a háttérrendszerhez.

• Csak egy felület kommunikál a háttérrendszerrel.

Munkaterhelés tervezés

Értékelje ki, hogyan alkalmazhatja a Backends for Frontends mintázatot egy munkafolyamat tervezésében az Azure Well-Architected Framework pilléreiben foglalt célok és alapelvek elérésére. Az alábbi táblázat útmutatást nyújt arról, hogy ez a minta hogyan támogatja az egyes pillérek céljait.

Pillér	Hogyan támogatja ez a minta a pillércélokat?
A megbízhatósági tervezési döntések segítenek a számítási feladatnak ellenállóvá válni a hibás működéssel szemben, és biztosítják, hogy a hiba bekövetkezése után teljesen működőképes állapotba kerüljön.	Ha a szolgáltatásokat egy adott előtérbeli felületre különíti el, hibás működést fog tartalmazni. Az egyik ügyfél rendelkezésre állása nem befolyásolja egy másik ügyfél hozzáférését. Ha különböző ügyfeleket kezel, a megbízhatósági erőfeszítéseket a várt ügyfélhozzáférési minták alapján rangsorolhatja. - RE:02 Kritikus folyamatok - RE:07 Önmegőrzés
A biztonsági tervezési döntések segítenek biztosítani a számítási feladatok adatainak és rendszereinek titkosságát, integritását és rendelkezésre állását.	Az ebben a mintában bevezetett szolgáltatáselválasztás lehetővé teszi a szolgáltatásréteg biztonságának és engedélyezésének testreszabását az egyes ügyfelek egyedi igényeihez. Ez a megközelítés csökkentheti az API felületét, és korlátozhatja az oldalirányú mozgást a háttérrendszerek között, amelyek különböző képességeket tehetnek elérhetővé. - SE:04 Szegmentálás - SE:08 Erőforrások keményítése
A teljesítményhatékonyság a skálázás, az adatok és a kód optimalizálásával segíti a számítási feladatok hatékony kielégítését .	A háttérbeli elkülönítés lehetővé teszi, hogy olyan módon optimalizáljon, amely megosztott szolgáltatási réteggel esetleg nem lehetséges. Ha másként kezeli az egyes ügyfeleket, optimalizálhatja a teljesítményt egy adott ügyfél korlátaihoz és funkcióihoz. - PE:02 Kapacitástervezés - PE:09 Kritikus folyamatok

Ha ez a minta kompromisszumokat vezet be egy pilléren belül, vegye figyelembe őket a többi pillér céljaival szemben.

példa

Ez a példa azt a használati esetet mutatja be, amelyben két különálló ügyfélalkalmazás, egy mobilalkalmazás és egy asztali alkalmazás használja az Azure API Managementet (adatsík-átjáró). Ez az átjáró absztrakciós rétegként szolgál, és kezeli az olyan általános szempontokat, mint például:

• Engedélyezés. Biztosítja, hogy csak a megfelelő hozzáférési jogkivonatokkal rendelkező ellenőrzött identitások hívhatnak meg védett erőforrásokat az API Management és a Microsoft Entra ID használatával.

• Megfigyelés. Rögzíti és elküldi a kérések és válaszok részleteit az Azure Monitornak a megfigyelhetőség érdekében.

• Gyorsítótárazás kérése. Optimalizálja az ismétlődő kéréseket az API Management beépített funkciói által a gyorsítótárból érkező válaszok kiszolgálásával.

• Útválasztás és összesítés. A bejövő kéréseket a megfelelő BFF-szolgáltatásokhoz irányítja.

Minden ügyfél dedikált BFF-szolgáltatással rendelkezik, amely Azure-függvényként fut, amely közvetítőként szolgál az átjáró és a mögöttes mikroszolgáltatások között. Ezek az ügyfélspecifikus BFF-szolgáltatások személyre szabott felületet biztosítanak a lapozáshoz és más funkciókhoz. A mobilalkalmazás rangsorolja a sávszélesség hatékonyságát, és kihasználja a gyorsítótárazás előnyeit a teljesítmény növelése érdekében. Ezzel szemben az asztali alkalmazás egyetlen kérelemben több lapot kér le, ami magával ragadóbb felhasználói élményt eredményez.

A diagram négy szakaszra van strukturálva, amelyek a kérések folyamatát, a hitelesítést, a monitorozást és az ügyfélspecifikus feldolgozást szemléltetik. Két ügyféleszköz kezdeményezi a kéréseket: egy sávszélesség-hatékony felhasználói élményre optimalizált mobilalkalmazást és egy teljes funkcionalitású felületet biztosító webböngészőt. A nyilak mindkét eszközről a központi belépési pontig, vagyis az API Management-átjáróig terjednek, hogy jelezzék, hogy minden kérésnek ezen a rétegen kell áthaladnia. A második, szaggatott vonalú téglalapba zárt szakaszban az architektúra két vízszintes csoportra van osztva. A bal oldali csoport azt az API Managementet jelöli, amely kezeli a bejövő kéréseket, és meghatározza azok feldolgozásának módját. Ebből az adatsík-átjáróból két nyíl mutat kifelé. Egy nyíl felfelé mutat az engedélyezést kezelő Microsoft Entra-azonosítóra. Egy másik nyíl lefelé mutat az Azure Monitorra, amely a naplózásért és a megfigyelhetőségért felelős. A nyíl visszatér az átjárótól a mobil klienshez, jelezve egy gyorsítótárazott választ, amikor egy azonos kérést ismételnek, ami csökkenti a szükségtelen feldolgozást. A szaggatott téglalapon belüli jobb csoport a háttérbeli válaszok testre szabására összpontosít a kérést küldő ügyfél típusa alapján. Két különálló frontend ügyfelet tartalmaz, amelyek különálló háttérrendszert használnak, és mindkettőt az Azure Functions segítségével üzemeltetik a kiszolgáló nélküli számítástechnika érdekében. Az egyik a mobilügyfélnek, a másik pedig az asztali ügyfélnek van szentelve. Két nyíl az átjárótól a háttérbeli ügyfelekig terjed, amely azt mutatja, hogy minden bejövő kérést a rendszer az ügyfél típusától függően a megfelelő szolgáltatásnak továbbít. Ezen a rétegen túl a szaggatott nyilak kiterjesztik és összekapcsolják a háttérbeli ügyfeleket különböző mikroszolgáltatásokhoz, amelyek a tényleges üzleti logikát kezelik. A képen egy balról jobbra irányuló folyamat látható, ahol az ügyfélkérések mobil- és webes ügyfelekről az átjáróra kerülnek. Ez az átjáró feldolgozza az egyes kéréseket, miközben a hitelesítést felfelé delegálja az identitásszolgáltatóra, és lefelé naplóz a figyelési szolgáltatásba. Innen átirányítja a kéréseket a megfelelő háttérrendszerbeli ügyfélhez annak alapján, hogy a kérés mobil vagy asztali ügyfélről származik-e. Végül minden előtérbeli háttérügyfél továbbítja a kérést speciális mikroszolgáltatásoknak, amelyek végrehajtják a szükséges üzleti logikát, és visszaadják a szükséges választ. Ha elérhető egy gyorsítótárazott válasz, az átjáró elfogja a kérést, és közvetlenül a mobilügyfélnek küldi el a tárolt választ, ami megakadályozza a redundáns feldolgozást.

A Flow A a mobilklienstől érkező első oldalkéréshez

1. A mobilkliens egy GET kérést küld a 1 oldalra, amely tartalmazza az OAuth 2.0 tokent az engedélyezési fejlécben.

2. A kérés eléri az API felügyeleti átjárót, amely elfogja, majd:

   1. Ellenőrzi az engedélyezési állapotot. Az API Management részletesen implementálja a védelmet, így ellenőrzi a hozzáférési jogkivonat érvényességét.

   2. Naplóként továbbítja a kérés aktivitását az Azure Monitorba. A kérelem részletei rögzítve vannak a naplózáshoz és a monitorozáshoz.

3. A szabályzatok érvénybe lépnek, majd az API Management átirányítja a kérést az Azure-függvény mobil BFF szolgáltatásához.

4. Az Azure-függvény mobil BFF szolgáltatása ezután együttműködik a szükséges mikroszolgáltatásokkal egyetlen oldal lekéréséhez és a kért adatok feldolgozásához, hogy egyszerű felhasználói élményt nyújtson.

5. A rendszer visszaadja a választ az ügyfélnek.

Mobilkliensek első oldalkéréseire vonatkozó B folyamat gyorsítótárazott verziója

1. A mobilügyfél ismét elküldi ugyanazt GET a lapkérelmet 1 , beleértve az OAuth 2.0 tokent az engedélyezési fejlécben.

2. Az API Management-átjáró felismeri, hogy ez a kérés korábban történt, és:

   1. A szabályzatok érvénybe lépnek. Ezután az átjáró azonosít egy gyorsítótárazott választ, amely megfelel a kérés paramétereinek.

   2. Azonnal visszaadja a gyorsítótárazott választ. Ez a gyors válasz szükségtelenné teszi a kérés továbbítását az Azure funkció mobil BFF szolgáltatásához.

C folyamat az asztali ügyféltől érkező első kéréshez

1. Az asztali ügyfél először küld kérést GET , beleértve az OAuth 2.0 jogkivonatot az engedélyezési fejlécben.

2. A kérés eléri az API Management-átjárót, ahol a rendszer kezeli a horizontális problémákat.

   1. Felhatalmazás: A jogkivonat érvényesítése mindig kötelező.

   2. A kérelemtevékenység streamelése: A kérelem részletei rögzítve vannak a megfigyelhetőség érdekében.

3. Az összes szabályzat kényszerítése után az API Management átirányítja a kérést az Azure-függvény asztali BFF szolgáltatásához, amely kezeli az adatigényes alkalmazások feldolgozását. Az asztali BFF szolgáltatás több kérést összesít a mögöttes mikroszolgáltatás-hívások használatával, mielőtt többoldalas választ ad az ügyfélnek.

Dizájn

• A Microsoft Entra ID felhőalapú identitásszolgáltatóként szolgál. Személyre szabott célközönség-jogcímeket biztosít mobil- és asztali ügyfelek számára is. Ezeket a jogcímeket ezután a rendszer az engedélyezéshez használja.

• Az API Management proxyként szolgál az ügyfelek és a BFF-szolgáltatások között, amely szegélyt hoz létre. Az API Management szabályzatokkal van konfigurálva a JSON-webjogkivonatok érvényesítéséhez, és elutasítja a jogkivonat nélküli vagy érvénytelen jogcímeket tartalmazó kéréseket a célzott BFF szolgáltatás számára. Emellett streameli az összes tevékenységnaplót az Azure Monitorba.

• Az Azure Monitor központosított monitorozási megoldásként működik. Összesíti az összes tevékenységnaplót az átfogó, teljes körű megfigyelhetőség biztosítása érdekében.

• Az Azure Functions egy kiszolgáló nélküli megoldás, amely hatékonyan teszi elérhetővé a BFF szolgáltatáslogikát több végponton, ami leegyszerűsíti a fejlesztést. Az Azure Functions emellett minimalizálja az infrastruktúra többletterhelését, és segít csökkenteni az üzemeltetési költségeket.

Következő lépések

• Háttérrendszerek a Frontendekhez mintában Sam Newman-féle
• Hitelesítés és api-k engedélyezése az API Managementben
• Az API Management integrálása az Application Insightsszal

Kapcsolódó erőforrások

• Átjáróösszesítés minta
• Átjárókiürítés minta
• Átjáró-útválasztási minta
• kiszolgáló nélküli webalkalmazás referenciaarchitektúrája