Serverdelar för klientdelsmönster

Det här mönstret beskriver hur du frikopplar serverdelstjänster från klientdelsimplementeringar för att skräddarsy upplevelser för olika klientgränssnitt. Det här mönstret är användbart när du vill undvika att anpassa en serverdel som hanterar flera gränssnitt. Det här mönstret baseras på Backends for Frontends-mönstret av Sam Newman.

Kontext och problem

Överväg ett program som ursprungligen har utformats med ett skrivbordswebbgränssnitt och en motsvarande serverdelstjänst. När affärskraven ändras över tid läggs ett mobilt gränssnitt till. Båda gränssnitten interagerar med samma serverdelstjänst. Men funktionerna i en mobil enhet skiljer sig avsevärt från en skrivbordswebbläsare när det gäller skärmstorlek, prestanda och visningsbegränsningar.

Diagrammet har två avsnitt: serverdelstjänsten och skrivbordsklienten och den mobila klienten. Två dubbelsidiga pilar pekar från serverdelstjänsten till både skrivbordsklienten och den mobila klienten.

En tjänst på serversidan stöter ofta på krav som konkurrerar från flera frontendsystem. Dessa krav resulterar i frekventa uppdateringar och potentiella flaskhalsar i utvecklingen. Motstridiga uppdateringar och behovet av att upprätthålla kompatibiliteten leder till överdriven efterfrågan på en enda distributionsbar resurs.

Att ha ett separat team som hanterar serverdelstjänsten kan skapa en frånkoppling mellan klientdels- och serverdelsteam. Den här frånkopplingen kan orsaka fördröjningar när det gäller att uppnå konsensus- och balanskrav. Ändringar som begärs av ett klientdelsteam måste till exempel verifieras med andra klientdelsteam innan integreringen.

Lösning

Introducera ett nytt lager som endast hanterar de krav som är specifika för gränssnittet. Det här lagret, som kallas tjänsten backend-for-frontend (BFF), ligger mellan klientdelsklienten och serverdelstjänsten. Om programmet stöder flera gränssnitt, till exempel ett webbgränssnitt och en mobilapp, skapar du en BFF-tjänst för varje gränssnitt.

Det här mönstret anpassar klientupplevelsen för ett specifikt gränssnitt utan att påverka andra gränssnitt. Den optimerar också prestanda för att uppfylla behoven i klientdelsmiljön. Eftersom varje BFF-tjänst är mindre och mindre komplex än en delad serverdelstjänst kan det göra programmet enklare att hantera.

Klientdelsteamen hanterar oberoende sin egen BFF-tjänst, vilket ger dem kontroll över val av språk, lanseringstakt, prioritering av arbetsbelastningar och funktionsintegrering. Den här autonomin gör det möjligt för dem att arbeta effektivt utan beroende på ett centraliserat utvecklingsteam för serverdelen.

Många BFF-tjänster förlitade sig traditionellt på REST-API:er, men GraphQL-implementeringar växer fram som ett alternativ. Med GraphQL eliminerar frågemekanismen behovet av ett separat BFF-lager eftersom det gör att klienter kan begära de data som de behöver utan att förlita sig på fördefinierade slutpunkter.

Diagrammet visar tre avsnitt. Det första avsnittet består av skrivbordsklienten och den mobila klienten. Det andra avsnittet består av BFF-tjänsten för skrivbordsklienten och BFF-tjänsten för mobila klienter. Skrivbordsklienten har en solid pil som pekar på skrivbordsklientens BFF-tjänst. Den mobila klienten har en solid pil som pekar på mobilklientens BFF-tjänst. Varje BFF-tjänst har en prickad pil som pekar på avsnittet för bakgrundstjänster.

För mer information, se Backends för Frontends-mönstret av Sam Newman.

Problem och överväganden

• Utvärdera det optimala antalet tjänster beroende på de associerade kostnaderna. Att underhålla och distribuera fler tjänster innebär ökade driftkostnader. Varje enskild tjänst har sin egen livscykel, krav på distribution och underhåll samt säkerhetsbehov.

• Granska servicenivåmålen när du lägger till en ny tjänst. Ökad svarstid kan uppstå eftersom klienter inte kontaktar dina tjänster direkt, och den nya tjänsten introducerar ett extra nätverkshopp.

• När olika gränssnitt gör samma begäranden utvärderar du om begäranden kan konsolideras till en enda BFF-tjänst. Att dela en enda BFF-tjänst mellan flera gränssnitt kan resultera i olika krav för varje klient, vilket kan komplicera BFF-tjänstens tillväxt och support.

  Kodduplicering är ett troligt resultat av det här mönstret. Utvärdera kompromissen mellan kodduplicering och en bättre anpassad upplevelse för varje klient.

• BFF-tjänsten bör endast hantera klientspecifik logik som är relaterad till en specifik användarupplevelse. Övergripande funktioner, till exempel övervakning och auktorisering, bör abstraheras för att upprätthålla effektiviteten. Typiska funktioner som kan uppstå i BFF-tjänsten hanteras separat med mönster för gatekeeping, hastighetsbegränsning och routning .

• Fundera på hur inlärning och implementering av det här mönstret påverkar utvecklingsteamet. Att utveckla nya serverdelssystem kräver tid och arbete, vilket kan leda till tekniska skulder. Att underhålla den befintliga serverdelstjänsten bidrar till den här utmaningen.

• Utvärdera om du behöver det här mönstret. Om din organisation till exempel använder GraphQL med klientdelsspecifika matchare kanske BFF-tjänster inte tillför något värde till dina program.

  Ett annat scenario är ett program som kombinerar en API-gateway med mikrotjänster. Den här metoden kan vara tillräcklig för vissa scenarier där BFF-tjänster vanligtvis rekommenderas.

När du ska använda det här mönstret

Använd det här mönstret i sådana här scenarier:

• En delad eller generell serverdelstjänst kräver betydande utvecklingskostnader att underhålla.

• Du vill optimera serverdelen för kraven för specifika klientgränssnitt.

• Du gör anpassningar till en generell serverdel för att hantera flera gränssnitt.

• Ett programmeringsspråk passar bättre för serverdelen i ett specifikt användargränssnitt, men inte alla användargränssnitt.

Det här mönstret kanske inte är lämpligt när:

• Gränssnitt gör samma eller liknande begäranden till serverdelen.

• Endast ett gränssnitt interagerar med serverdelen.

Design av arbetsbelastning

Utvärdera hur du använder backends for Frontends-mönstret i en arbetsbelastnings design för att uppfylla de mål och principer som beskrivs i Grundpelarna i Azure Well-Architected Framework. Följande tabell innehåller vägledning om hur det här mönstret stöder målen för varje pelare.

Grundpelare	Så här stöder det här mönstret pelarmål
Tillförlitlighets designbeslut hjälper din arbetsbelastning att bli motståndskraftig mot funktionsfel och säkerställer att den återställer sig till ett fullständigt fungerande tillstånd när ett fel uppstår.	När du isolerar tjänster till ett specifikt klientdelsgränssnitt innehåller du fel. Tillgängligheten för en klient påverkar inte tillgängligheten för en annan klients åtkomst. När du behandlar olika klienter på olika sätt kan du prioritera tillförlitlighetsarbetet baserat på förväntade klientåtkomstmönster. - RE:02 Kritiska flöden - RE:07 Självbevarande
Beslut om säkerhetsdesign bidrar till att säkerställa konfidentialitet, integritet och tillgänglighet för arbetsbelastningens data och system.	Tjänstavgränsningen som introducerades i det här mönstret gör att säkerhet och auktorisering i tjänstskiktet kan anpassas efter varje klients specifika behov. Den här metoden kan minska API:ets yta och begränsa lateral rörelse mellan serverdelar som kan exponera olika funktioner. - SE:04 Segmentering - SE:08 Härdningsresurser
Prestandaeffektivitet hjälper din arbetsbelastning effektivt uppfylla kraven genom optimering av skalning, data och kod.	Med serverdelsavgränsningen kan du optimera på ett sätt som kanske inte är möjligt med ett delat tjänstlager. När du hanterar enskilda klienter på olika sätt kan du optimera prestanda för en specifik klients begränsningar och funktioner. - PE:02 Kapacitetsplanering - PE:09 Kritiska flöden

Om detta mönster inför kompromisser inom en pelare bör du överväga dem mot målen för de andra pelarna.

Exempel

Det här exemplet visar ett användningsfall för mönstret där två distinkta klientprogram, en mobilapp och ett skrivbordsprogram, interagerar med Azure API Management (dataplansgateway). Den här gatewayen fungerar som ett abstraktionslager och hanterar vanliga övergripande problem som:

• Auktorisering. Säkerställer att endast verifierade identiteter med rätt åtkomsttoken kan anropa skyddade resurser med hjälp av API Management med Microsoft Entra-ID.

• Övervakning. Samlar in och skickar information om begäranden och svar till Azure Monitor i observerbarhetssyfte.

• Begär cachelagring. Optimerar upprepade begäranden genom att hantera svar från cacheminnet med inbyggda funktioner i API Management.

• Routning och aggregering. Dirigerar inkommande begäranden till lämpliga BFF-tjänster.

Varje klient har en dedikerad BFF-tjänst som körs som en Azure-funktion som fungerar som mellanhand mellan gatewayen och de underliggande mikrotjänsterna. Dessa klientspecifika BFF-tjänster säkerställer en skräddarsydd upplevelse för sidnumrering och andra funktioner. Mobilappen prioriterar bandbreddseffektivitet och drar nytta av cachelagring för att förbättra prestanda. Skrivbordsprogrammet hämtar däremot flera sidor i en enda begäran, vilket skapar en mer uppslukande användarupplevelse.

Diagrammet är uppbyggt i fyra avsnitt som illustrerar flödet av begäranden, autentisering, övervakning och klientspecifik bearbetning. Två klientenheter initierar begäranden: ett mobilprogram som är optimerat för en bandbreddseffektiv användarupplevelse och en webbläsare som tillhandahåller ett fullt funktionellt gränssnitt. Pilarna sträcker sig från båda enheterna mot den centrala startpunkten, som är API Management-gatewayen, för att indikera att alla begäranden måste passera genom det här lagret. I det andra avsnittet, omgivet av en streckad rektangel, är arkitekturen uppdelad i två vågräta grupper. Den vänstra gruppen representerar API Management som hanterar inkommande begäranden och bestämmer hur de ska bearbetas. Två pilar sträcker sig utåt från den här dataplansgatewayen. En pil pekar uppåt till Microsoft Entra-ID, som hanterar auktoriseringen. En annan pil pekar nedåt mot Azure Monitor, som ansvarar för loggning och observerbarhet. En pil loopar tillbaka från gatewayen till den mobila klienten, vilket representerar ett cachelagrat svar när en identisk begäran upprepas, vilket minskar onödig bearbetning. Rätt grupp i den streckade rektangeln fokuserar på att skräddarsy serverdelssvar baserat på vilken typ av klient som gör begäran. Den har två separata backend-för-frontend-tjänster, som båda värdas med hjälp av Azure Functions för serverlös beräkning. Den ena är dedikerad till den mobila klienten och den andra till skrivbordsklienten. Två pilar sträcker sig från gateway till dessa backend-för-frontend-klienter, vilket visar att varje inkommande begäran vidarebefordras till lämplig tjänst beroende på klienttyp. Utöver det här lagret sträcker sig och ansluter streckade pilar backend-för-frontend-klienterna till olika mikrotjänster, som hanterar den faktiska affärslogiken. Bilden visar ett flöde från vänster till höger där klientbegäranden flyttas från mobil- och webbklienter till gatewayen. Den här gatewayen bearbetar varje begäran samtidigt som autentisering delegeras uppåt till identitetsprovidern och loggas nedåt till övervakningstjänsten. Därifrån dirigeras begäranden till lämplig klientdel för klientdelen baserat på om begäran kommer från en mobil- eller skrivbordsklient. Slutligen vidarebefordrar varje backend-för-frontend-klient begäran till specialiserade mikrotjänster, som utför den affärslogik som krävs och returnerar det viktiga svaret. Om ett cachelagrat svar är tillgängligt fångar gatewayen upp begäran och skickar det lagrade svaret direkt till den mobila klienten, vilket förhindrar redundant bearbetning.

Flöde A för den första sidbegäran från mobilklienten

1. Mobilklienten skickar en GET begäran för sidan 1, inklusive OAuth 2.0-token i auktoriseringshuvudet.

2. Begäran når API Management-gatewayen, som fångar upp den och:

   1. Kontrollerar behörighetsstatusen. API Management implementerar skydd på djupet, så det kontrollerar giltigheten för åtkomsttoken.

   2. Strömmar förfrågningsaktiviteten som loggar till Azure Monitor. Information om begäran registreras för granskning och övervakning.

3. Principerna tillämpas och SEDAN dirigerar API Management begäran till Azure-funktionens mobila BFF-tjänst.

4. Azure-funktionens mobila BFF-tjänst interagerar sedan med nödvändiga mikrotjänster för att hämta en enda sida och bearbeta begärda data för att ge en enkel upplevelse.

5. Svaret returneras till klienten.

Flöde B för den första sidans cachelagrade begäran från mobilklienten

1. Den mobila klienten skickar samma GET begäran för sidan 1 igen, inklusive OAuth 2.0-token i auktoriseringshuvudet.

2. API Management-gatewayen identifierar att den här begäran gjordes tidigare och:

   1. Principerna tillämpas. Sedan identifierar gatewayen ett cachelagrat svar som matchar parametrarna för begäran.

   2. Returnerar det cachelagrade svaret omedelbart. Det här snabbsvaret eliminerar behovet av att vidarebefordra begäran till Azure-funktionens mobila BFF-tjänst.

Flow C för den första begäran från skrivbordsklienten

1. Skrivbordsklienten skickar en GET begäran för första gången, inklusive OAuth 2.0-token i auktoriseringshuvudet.

2. Begäran når API Management-gatewayen, där övergripande problem hanteras.

   1. Auktorisering: Tokenverifiering krävs alltid.

   2. Strömma begärandeaktiviteten: Information om begäran registreras för observerbarhet.

3. När alla principer har tillämpats dirigerar API Management begäran till BFF-tjänsten för Azure-funktionsskrivbord, som hanterar dataintensiv programbearbetning. BFF-tjänsten för skrivbord aggregerar flera begäranden med hjälp av underliggande mikrotjänstanrop innan den svarar på klienten med ett svar på flera sidor.

Utformning

• Microsoft Entra ID fungerar som molnbaserad identitetsprovider. Det ger skräddarsydda målgruppsanspråk för både mobil- och skrivbordsklienter. Dessa anspråk används sedan för auktorisering.

• API Management fungerar som en proxy mellan klienterna och deras BFF-tjänster, som upprättar en perimeter. API Management har konfigurerats med principer för att verifiera JSON-webbtoken och avvisar begäranden som saknar en token eller innehåller ogiltiga anspråk för den riktade BFF-tjänsten. Den strömmar även alla aktivitetsloggar till Azure Monitor.

• Azure Monitor fungerar som centraliserad övervakningslösning. Den aggregerar alla aktivitetsloggar för att säkerställa omfattande observerbarhet från slutpunkt till slutpunkt.

• Azure Functions är en serverlös lösning som effektivt exponerar BFF-tjänstlogik över flera slutpunkter, vilket förenklar utvecklingen. Azure Functions minimerar även infrastrukturkostnaderna och hjälper till att sänka driftskostnaderna.

Nästa steg

• Backends for Frontends-mönster av Sam Newman
• Autentisering och auktorisering till API:er i API Management
• Integrera API Management med Application Insights

Relaterade resurser

• Mönstret Gateway-samling
• Mönstret Gateway-avlastning
• Mönstret Gateway-routning
• referensarkitektur för serverlösa webbprogram