Klientkommunikation på klientsidan

Dricks

Det här innehållet är ett utdrag från eBook, Architecting Cloud Native .NET Applications for Azure, tillgängligt på .NET Docs eller som en kostnadsfri nedladdningsbar PDF som kan läsas offline.

Ladda ned PDF

I ett molnbaserat system kräver klientdelsklienter (mobil-, webb- och skrivbordsprogram) en kommunikationskanal för att interagera med oberoende serverdelsmikrotjänster.

Vilka alternativ har du?

För att hålla det enkelt kan en klientdelsklient kommunicera direkt med serverdelsmikrotjänsterna, som visas i bild 4–2.

Bild 4-2. Dirigera kommunikation mellan klienter och tjänster

Med den här metoden har varje mikrotjänst en offentlig slutpunkt som är tillgänglig för klientdelsklienter. I en produktionsmiljö skulle du placera en lastbalanserare framför mikrotjänsterna och dirigera trafiken proportionellt.

Även om det är enkelt att implementera, skulle direkt klientkommunikation endast vara acceptabelt för enkla mikrotjänstprogram. Det här mönstret parar nära klientdelsklienter till kärntjänster på serverdelen, vilket öppnar dörren för många problem, inklusive:

• Klientens känslighet för serverdelstjänstens refaktorisering.
• En bredare attackyta som kärntjänster för serverdelen exponeras direkt.
• Duplicering av övergripande problem för varje mikrotjänst.
• Alltför komplex klientkod – klienter måste hålla reda på flera slutpunkter och hantera fel på ett motståndskraftigt sätt.

I stället är ett allmänt accepterat mönster för molndesign att implementera en API Gateway-tjänst mellan klientdelsprogram och serverdelstjänster. Mönstret visas i bild 4-3.

Bild 4-3. API Gateway-mönster

I föregående bild bör du notera hur API Gateway-tjänsten abstraherar serverdelens kärnmikrotjänster. Implementerad som ett webb-API fungerar den som en omvänd proxy och dirigerar inkommande trafik till de interna mikrotjänsterna.

Gatewayen isolerar klienten från intern tjänstpartitionering och refaktorisering. Om du ändrar en serverdelstjänst kan du hantera den i gatewayen utan att bryta klienten. Det är också din första försvarslinje för övergripande problem, till exempel identitet, cachelagring, återhämtning, mätning och begränsning. Många av dessa övergripande problem kan avlastas från serverdelstjänsterna till gatewayen, vilket förenklar serverdelstjänsterna.

Var noga med att hålla API Gateway enkel och snabb. Vanligtvis hålls affärslogik borta från gatewayen. En komplex gateway riskerar att bli en flaskhals och så småningom en monolit själv. Större system exponerar ofta flera API Gateways segmenterade efter klienttyp (mobil, webb, skrivbord) eller serverdelsfunktioner. Backend for Frontends-mönstret ger vägledning för att implementera flera gatewayer. Mönstret visas i bild 4-4.

Bild 4-4. Serverdel för klientdelsmönster

Observera i föregående bild hur inkommande trafik skickas till en specifik API-gateway – baserat på klienttyp: webb, mobil eller skrivbordsapp. Den här metoden är meningsfull eftersom funktionerna för varje enhet skiljer sig avsevärt mellan formfaktorer, prestanda och visningsbegränsningar. Vanligtvis exponerar mobila program mindre funktioner än en webbläsare eller skrivbordsprogram. Varje gateway kan optimeras för att matcha funktionerna och funktionerna i motsvarande enhet.

Enkla gatewayer

Till att börja med kan du skapa en egen API Gateway-tjänst. En snabbsökning av GitHub innehåller många exempel.

För enkla .NET-molnbaserade program kan du överväga Ocelot Gateway. Den är öppen källkod och har skapats för .NET-mikrotjänster och är lätt, snabb och skalbar. Precis som alla API Gateway är dess primära funktioner att vidarebefordra inkommande HTTP-begäranden till underordnade tjänster. Dessutom har den stöd för en mängd olika funktioner som kan konfigureras i en .NET-mellanprogramspipeline.

YARP (Ännu en omvänd proxy) är en annan öppen källkod omvänd proxy som leds av en grupp Microsoft-produktteam. YARP kan laddas ned som ett NuGet-paket och ansluts till det ASP.NET ramverket som mellanprogram och är mycket anpassningsbart. Du hittar YARP väldokumenterat med olika användningsexempel.

För företagsmolnbaserade program finns det flera hanterade Azure-tjänster som kan hjälpa dig att få igång dina ansträngningar.

Azure Application Gateway

För enkla gatewaykrav kan du överväga Azure Application Gateway. Den är tillgänglig som en Azure PaaS-tjänst och innehåller grundläggande gatewayfunktioner som URL-routning, SSL-avslutning och en brandvägg för webbprogram. Tjänsten stöder layer-7-belastningsutjämningsfunktioner . Med Layer 7 kan du dirigera begäranden baserat på det faktiska innehållet i ett HTTP-meddelande, inte bara TCP-nätverkspaket på låg nivå.

I den här boken evangeliserar vi värd för molnbaserade system i Kubernetes. Kubernetes är en containerorkestrerare och automatiserar distribution, skalning och driftsproblem för containerbaserade arbetsbelastningar. Azure Application Gateway kan konfigureras som en API-gateway för Azure Kubernetes Service-kluster .

Application Gateway-ingresskontrollanten gör det möjligt för Azure Application Gateway att arbeta direkt med Azure Kubernetes Service. Bild 4.5 visar arkitekturen.

Bild 4-5. Application Gateway, inkommande styrenhet

Kubernetes innehåller en inbyggd funktion som stöder HTTP-belastningsutjämning (nivå 7), som kallas Ingress. Ingress definierar en uppsättning regler för hur mikrotjänstinstanser i AKS kan exponeras för omvärlden. I föregående bild tolkar ingresskontrollanten de ingressregler som konfigurerats för klustret och konfigurerar automatiskt Azure Application Gateway. Baserat på dessa regler dirigerar Application Gateway trafik till mikrotjänster som körs i AKS. Ingresskontrollanten lyssnar efter ändringar i ingressregler och gör lämpliga ändringar i Azure Application Gateway.

Azure API Management

För måttliga till storskaliga molnbaserade system kan du överväga Azure API Management. Det är en molnbaserad tjänst som inte bara löser dina API Gateway-behov, utan ger en komplett utvecklar- och administrativ upplevelse. API Management visas i bild 4–6.

Bild 4-6. Azure API Management

Till att börja med exponerar API Management en gateway-server som tillåter kontrollerad åtkomst till serverdelstjänster baserat på konfigurerbara regler och principer. Dessa tjänster kan finnas i Azure-molnet, ditt lokala datacenter eller andra offentliga moln. API-nycklar och JWT-token avgör vem som kan göra vad. All trafik loggas i analyssyfte.

För utvecklare erbjuder API Management en utvecklarportal som ger åtkomst till tjänster, dokumentation och exempelkod för att anropa dem. Utvecklare kan använda Swagger/Open API för att inspektera tjänstslutpunkter och analysera deras användning. Tjänsten fungerar på de viktigaste utvecklingsplattformarna: .NET, Java, Golang med mera.

Utgivarportalen exponerar en instrumentpanel för hantering där administratörer exponerar API:er och hanterar deras beteende. Tjänståtkomst kan beviljas, tjänstens hälsotillstånd övervakas och tjänsttelemetri samlas in. Administratörer tillämpar principer på varje slutpunkt för att påverka beteendet. Principer är fördefinierade instruktioner som körs sekventiellt för varje tjänstanrop. Principer konfigureras för ett inkommande anrop, utgående anrop eller anropas vid ett fel. Principer kan tillämpas på olika tjänstomfattningar för att aktivera deterministisk ordning när principer kombineras. Produkten levereras med ett stort antal fördefinierade principer.

Här är exempel på hur principer kan påverka beteendet för dina molnbaserade tjänster:

• Begränsa tjänståtkomst.
• Framtvinga autentisering.
• Begränsa anrop från en enda källa, om det behövs.
• Aktivera cachelagring.
• Blockera anrop från specifika IP-adresser.
• Kontrollera flödet för tjänsten.
• Konvertera begäranden från SOAP till REST eller mellan olika dataformat, till exempel från XML till JSON.

Azure API Management kan exponera serverdelstjänster som finns var som helst – i molnet eller i ditt datacenter. För äldre tjänster som du kan exponera i dina molnbaserade system stöder det både REST- och SOAP-API:er. Även andra Azure-tjänster kan exponeras via API Management. Du kan placera ett hanterat API ovanpå en Azure-säkerhetskopieringstjänst som Azure Service Bus eller Azure Logic Apps. Azure API Management innehåller inte inbyggt stöd för belastningsutjämning och bör användas tillsammans med en belastningsutjämningstjänst.

Azure API Management är tillgängligt på fyra olika nivåer:

• Utvecklare
• Basic
• Standard
• Premium

Nivån Developer är avsedd för icke-produktionsarbetsbelastningar och utvärdering. De andra nivåerna erbjuder progressivt mer kraft, funktioner och avtal på högre servicenivå (SLA). Premium-nivån ger stöd för Azure Virtual Network och flera regioner. Alla nivåer har ett fast pris per timme.

Azure-molnet erbjuder även en serverlös nivå för Azure API Management. Tjänsten kallas prisnivå för förbrukning och är en variant av API Management som utformats kring den serverlösa databehandlingsmodellen. Till skillnad från de "förallokerade" prisnivåerna som tidigare visades tillhandahåller förbrukningsnivån omedelbar etablering och prissättning för betalning per åtgärd.

Den aktiverar API Gateway-funktioner för följande användningsfall:

• Mikrotjänster som implementeras med hjälp av serverlösa tekniker som Azure Functions och Azure Logic Apps.
• Azure-säkerhetskopieringstjänstresurser som Service Bus-köer och -ämnen, Azure Storage och andra.
• Mikrotjänster där trafiken har enstaka stora toppar men förblir låg för det mesta.

Förbrukningsnivån använder samma underliggande API Management-komponenter för tjänsten, men använder en helt annan arkitektur baserat på dynamiskt allokerade resurser. Den överensstämmer perfekt med den serverlösa databehandlingsmodellen:

• Ingen infrastruktur att hantera.
• Ingen inaktiv kapacitet.
• Hög tillgänglighet.
• Automatisk skalning.
• Kostnaden baseras på den faktiska användningen.

Den nya förbrukningsnivån är ett bra val för molnbaserade system som exponerar serverlösa resurser som API:er.

Kommunikation i realtid

Kommunikation i realtid eller push-överföring är ett annat alternativ för klientdelsprogram som kommunicerar med molnbaserade backend-system via HTTP. Program, till exempel finansiella tickers, onlineutbildning, spel och jobbförloppsuppdateringar, kräver omedelbara realtidssvar från serverdelen. Med normal HTTP-kommunikation finns det inget sätt för klienten att veta när nya data är tillgängliga. Klienten måste kontinuerligt avsöka eller skicka begäranden till servern. Med realtidskommunikation kan servern när som helst skicka nya data till klienten.

Realtidssystem kännetecknas ofta av högfrekventa dataflöden och ett stort antal samtidiga klientanslutningar. Manuellt implementering av realtidsanslutningar kan snabbt bli komplext, vilket kräver icke-trivial infrastruktur för att säkerställa skalbarhet och tillförlitliga meddelanden till anslutna klienter. Du kan hantera en instans av Azure Redis Cache och en uppsättning lastbalanserare som konfigurerats med klibbiga sessioner för klienttillhörighet.

Azure SignalR Service är en fullständigt hanterad Azure-tjänst som förenklar realtidskommunikationen för dina molnbaserade program. Teknisk implementeringsinformation som kapacitetsetablering, skalning och beständiga anslutningar abstraheras bort. De hanteras åt dig med ett serviceavtal på 99,9 %. Du fokuserar på programfunktioner, inte infrastruktur-VVS.

När den är aktiverad kan en molnbaserad HTTP-tjänst skicka innehållsuppdateringar direkt till anslutna klienter, inklusive webbläsare, mobil- och skrivbordsprogram. Klienter uppdateras utan att servern behöver avsökas. Azure SignalR abstraherar de transporttekniker som skapar realtidsanslutningar, inklusive WebSockets, Server-Side Events och Long Polling. Utvecklare fokuserar på att skicka meddelanden till alla eller specifika delmängder av anslutna klienter.

Bild 4–7 visar en uppsättning HTTP-klienter som ansluter till ett molnbaserat program med Azure SignalR aktiverat.

Bild 4-7. Azure SignalR

En annan fördel med Azure SignalR Service är att implementera serverlösa molnbaserade tjänster. Kanske körs koden på begäran med Azure Functions-utlösare. Det här scenariot kan vara knepigt eftersom koden inte upprätthåller långa anslutningar med klienter. Azure SignalR Service kan hantera den detta eftersom tjänsten redan hanterar anslutningar för dig.

Azure SignalR Service integreras nära med andra Azure-tjänster, till exempel Azure SQL Database, Service Bus eller Redis Cache, vilket öppnar många möjligheter för dina molnbaserade program.

FöregåendeNästa