Distribuera mikrotjänster med Azure Container Apps och Dapr

Den här artikeln beskriver en lösning för att köra ett orderhanteringssystem som har 10 mikrotjänster i Azure Container Apps. Lösningen använder också metodtips för mikrotjänster via Dapr (Distributed Application Runtime) och händelsedriven skalning med Kubernetes händelsedriven autoskalning (KEDA).

Dapr är ett varumärke som tillhör respektive företag. Inget godkännande understås av användningen av det här märket.

Arkitektur

Ladda ned en PowerPoint-fil med den här arkitekturen.

Dataflöde

Den här lösningen beskriver ett fiktivt Red Dog-orderhanteringssystem och dess stöd för Azure-infrastruktur. Arkitekturen består av en enda Container Apps-miljö som är värd för 10 .NET mikrotjänstprogram. Azure Container Apps använder ett hanterat Envoy-baserat ingresslager för att dirigera extern trafik från användare till det offentligt exponerade användargränssnittet. Anrop mellan interna tjänster passerar inte den här ingressen. I stället använder de Dapr-tjänstens anrop och Container Apps-tjänstidentifiering i miljön. Lösningen använder Dapr SDK för att integrera med Azure-resurser via byggblocken publish-subscribe, state och binding. Tjänsterna använder också KEDA-skalningsregler för att tillåta skalning baserat på händelseutlösare och scenarier med skalning till noll.

Följande dataflöde motsvarar föregående diagram:

1. Hanterad ingress: Azure Container Apps tillhandahåller ett hanterat Envoy-baserat ingresslager för routning av användarbegäranden till användargränssnittet och API-slutpunkterna som stöder den interaktiva instrumentpanelen.

2. användargränssnitt: En instrumentpanel som visar order i realtid och aggregerade försäljningsdata för Red Dog-orderhanteringssystemet.

3. Virtuell kund: Ett kundsimuleringsprogram som simulerar kunder som gör beställningar via ordertjänsten.

4. Ordertjänst: Skapa, läsa, uppdatera och ta bort API:et för att placera och hantera beställningar.

5. Redovisningstjänst: En tjänst som bearbetar, lagrar och aggregerar orderdata. Den omvandlar kundorder till meningsfulla försäljningsmått som användargränssnittet visar.

6. Kvittotjänst: Ett arkiveringsprogram som genererar och lagrar orderkvitton för granskning och historiska ändamål.

7. Lojalitetstjänst: En tjänst som hanterar lojalitetsprogrammet genom att spåra kundbelöningspoäng baserat på orderutgifter.

8. Makeline-tjänst: En tjänst som hanterar en kö med aktuella beställningar som väntar på att uppfyllas. Tjänsten för virtuella arbetare spårar bearbetningen och slutförandet av beställningarna.

9. Virtuell arbetare: Ett arbetssimuleringsprogram som simulerar slutförandet av kundorder.

Komponenter

• Application Insights är en utökningsbar tjänst för hantering av programprestanda som du kan använda för att övervaka aktiva program och automatiskt identifiera prestandaavvikelser. I den här arkitekturen använder du Application Insights med Azure Monitor för att visa containerloggarna och samla in mått från mikrotjänsterna.

• Blob Storage är en molnbaserad lösning för lagring av enorma mängder ostrukturerade data som text eller binära filer. I den här arkitekturen använder en kvittotjänst Blob Storage via en Dapr-utdatabindning för att lagra orderkvittona.

• Azure Managed Redis tillhandahåller ett minnesinternt datalager baserat på Redis Enterprise-programvara. I den här arkitekturen används den som en Dapr-tillståndslagerkomponent för Makeline-tjänsten för att lagra data på de beställningar som bearbetas.

• Azure Cosmos DB är en NoSQL-hanterad databastjänst med flera modeller. I den här arkitekturen används den som en Dapr state store-komponent för lojalitetstjänsten för att lagra kundernas lojalitetsdata.

• Azure Monitor är en enhetlig plattform som gör att du kan samla in, analysera och agera på kundinnehållsdata från dina Azure-infrastrukturmiljöer. I den här arkitekturen använder du Azure Monitor med Application Insights för att visa containerloggarna och samla in mått från mikrotjänsterna.

• Service Bus är en fullständigt hanterad meddelandebroker för företag som har köer och publicerings- och prenumerationsämnen. I den här arkitekturen använder du Service Bus för implementeringen av Dapr publish-subscribe-komponenten. Flera tjänster använder den här komponenten. Ordertjänsten publicerar meddelanden på bussen och tjänsterna Makeline, accounting, loyalty och receipt prenumererar på dessa meddelanden.

• Container Apps är en fullständigt hanterad, serverlös containertjänst som används för att skapa och distribuera moderna appar i stor skala. I den här arkitekturen är du värd för alla mikrotjänster i Container Apps och distribuerar dem till en enda Container Apps-miljö. Den här miljön fungerar som en säker gräns runt systemet och tillhandahåller hanterad Envoy-baserad ingress för extern routning till användargränssnittet.

• SQL Database är en intelligent, skalbar relationsdatabastjänst som skapats för molnet. I den här arkitekturen fungerar den som datalager för redovisningstjänsten, som använder Entity Framework Core för att interagera med databasen. Bootstrapper-tjänsten ansvarar för att konfigurera SQL-tabellerna i databasen. Den körs en gång innan anslutningen till bokföringstjänsten upprättas.

Alternativ

I den här arkitekturen använder standarddirigeringssökvägen det inbyggda ingresslagret för Container Apps, som implementeras via en hanterad Envoy-proxy. Om en arbetsbelastning kräver anpassat mellanprogram eller protokollbeteende utöver de inbyggda ingressfunktionerna är dedikerade proxyservrar som NGINX eller HAProxy alternativ.

All Azure-infrastruktur, förutom SQL Database, använder Dapr-komponenter för samverkan. En fördel med Dapr är att du kan växla alla dessa komponenter genom att ändra distributionskonfigurationen för containerappar. I det här scenariot visar Service Bus, Azure Cosmos DB, Azure Managed Redis och Blob Storage några av de mer än 70 tillgängliga Dapr-komponenterna. En lista över alternativa publicera-prenumerera mäklare, tillståndsbutiker och utdatabindningar finns tillgängliga i Dapr-dokumentationen.

Information om scenario

Mikrotjänster är en allmänt antagen arkitekturstil. De ger fördelar som skalbarhet, flexibilitet och oberoende distributioner. Du kan använda containrar som en mekanism för att distribuera mikrotjänstprogram och sedan använda en containerorkestrerare som Kubernetes för att förenkla åtgärderna. Det finns många faktorer att tänka på för storskaliga mikrotjänstarkitekturer. Infrastrukturplattformen kräver vanligtvis en betydande förståelse för komplexa tekniker som containerorkestrerare.

Container Apps är en fullständigt hanterad serverlös containertjänst för att köra moderna program i stor skala. Det gör att du kan distribuera containerbaserade appar genom en abstraktion av den underliggande plattformen. Med den här metoden behöver du inte hantera en komplicerad infrastruktur.

Den här arkitekturen använder Container Apps-integrering med en hanterad version av Dapr. Dapr är ett projekt med öppen källkod som hjälper utvecklare att övervinna de inneboende utmaningarna i distribuerade program, till exempel tillståndshantering och tjänstanrop.

Container Apps tillhandahåller också en hanterad version av KEDA. MED KEDA kan dina containrar skalas automatiskt baserat på inkommande händelser från externa tjänster som Service Bus och Azure Managed Redis.

Container Apps tillhandahåller även hanterad Envoy-baserad ingress, så att du kan exponera HTTP-slutpunkter, använda anpassade domäner och hanterade TLS och stödja trafikdelningsscenarier utan att distribuera en separat proxynivå.

Mer information finns i Jämför containerappar med andra Azure-containeralternativ.

Den här artikeln beskriver en lösning för att köra ett orderhanteringssystem som har 10 mikrotjänster i Container Apps. Lösningen använder också metodtips för mikrotjänster via Dapr och händelsedriven skalning med KEDA.

Potentiella användningsfall

Den här lösningen gäller för alla organisationer som använder tillståndslösa och tillståndskänsliga mikrotjänster för distribuerade system. Lösningen är bäst för konsumentpaketerade varor och tillverkningsindustrier som har ett beställnings- och uppfyllandesystem.

Följande lösningar har liknande design:

• Arkitektur för mikrotjänster på Azure Kubernetes Service (AKS)
• Arkitektur för mikrotjänster i Azure Functions
• Händelsedrivna arkitekturer

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som du kan använda för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Well-Architected Framework.

Tillförlitlighet

Tillförlitlighet hjälper till att säkerställa att ditt program kan uppfylla de åtaganden som du gör gentemot dina kunder. Mer information finns i checklistan för Designgranskning för tillförlitlighet.

Container Apps bygger på en Kubernetes-grund som fungerar som den underliggande infrastrukturen. Återhämtningsmekanismer är inbyggda i Kubernetes som övervakar och startar om containrar, eller poddar, om det finns problem. Återhämtningsmekanismerna omfattar en inbyggd lastbalanserare som distribuerar trafik över flera repliker av varje containerapp. Med den här redundansen kan systemet fortsätta att fungera, även om en replik blir otillgänglig.

Container Apps tillhandahåller även principer för tjänstidentifiering och återhämtning som du kan använda för att tillämpa timeouter och kretsbrytarbeteende mellan tjänster. För Dapr-aktiverade tjänster konfigurerar du hälsoinställningar för appen så att ohälsosamma repliker upptäcks tidigare och trafik leds bort från degraderade instanser innan fel sprider sig vidare till nedströmskomponenter.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Checklista för designgranskning för säkerhet.

I följande lista beskrivs flera säkerhetsfunktioner som utelämnas i den här arkitekturen, tillsammans med andra rekommendationer och överväganden:

• Den här arkitekturen använder inte privata slutpunkter, vilket möjliggör säkrare, privata anslutningar till Azure-tjänster genom att tilldela dem en IP-adress från ditt virtuella nätverk. När privata slutpunkter används kan åtkomst till offentliga nätverk inaktiveras. Den här metoden behåller trafiken på Microsofts stamnät och förbättrar säkerhet och efterlevnad.

  Som ett alternativ till privata slutpunkter bör du överväga att använda Azure Nätverkssäkerhetsperimeter för att begränsa nätverksåtkomsten till Microsoft.ServiceBus/namespaces och Microsoft.Storage/storageAccounts. Med en nätverkssäkerhetsperimeter kan du associera dessa resurser med en delad perimeter och definiera regler för inkommande åtkomst. I den här arkitekturen distribueras inte Container Apps med ett anpassat virtuellt nätverk eller en statisk utgående IP-adress, så begränsa den inkommande regeln till prenumerationen som är värd för Container Apps-miljön i stället för till ett IP-intervall, eftersom det kräver en stabil, känd käll-IP-adress för att vara effektiv.

• Nätverksaktiviteten bör övervakas kontinuerligt för att upptäcka och förhindra missbruk. Du kan uppnå den här metoden med hjälp av en Azure Firewall och routningstabeller. Routningstabellerna gör det möjligt att skicka trafik som lämnar ett virtuellt nätverk genom brandväggen först. Den här processen är ett viktigt steg för att säkerställa att din arkitektur inte är sårbar för dataexfiltreringsattacker.

• Använd en brandvägg för webbprogram (WAF) för att skydda mot vanliga säkerhetsrisker. Använd Azure Front Door eller Azure Application Gateway för att implementera en WAF i den här arkitekturen.

• Överväg att använda den inbyggda autentiserings- och auktoriseringsfunktionen för Container Apps, som kallas Easy Auth. Easy Auth hanterar integrering med identitetsprovidrar utanför webbappen, vilket kan minska mängden kod som du behöver underhålla.

• Använd hanterad identitet för arbetsbelastningsidentiteter. Hanterad identitet eliminerar behovet av att utvecklare hanterar autentiseringsuppgifter. Till exempel autentiserar den grundläggande arkitekturen till SQL Server via lösenord i en anslutningssträng. När det är möjligt använder du Microsoft Entra-ID:t för att autentisera till Azure SQL Server.

Kostnadsoptimering

Kostnadsoptimering fokuserar på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i checklistan Designgranskning för kostnadsoptimering.

Använd Priskalkylatorn för Azure för att beräkna kostnaden för tjänsterna i den här arkitekturen.

Operativ skicklighet

Operational Excellence omfattar de driftsprocesser som distribuerar ett program och håller det igång i produktion. Mer information finns i Checklista för designgranskning för Operational Excellence.

Dapr lägger till ett portabilitetslager mellan dina tjänster och deras infrastruktur för säkerhetskopiering. Det här lagret ger värde när du förväntar dig att säkerhetskopieringstjänsterna ska ändras eller när du vill byta en komponent, till exempel ett tillståndsarkiv eller meddelandekö, via konfiguration i stället för kod. Dapr lägger också till ett beroende och en indirekt nivå. När du har en relativt stabil uppsättning Azure-interna slutpunkter som du inte förväntar dig att ersätta, är det ett rimligt alternativ att anropa Azures inbyggda SDK:er direkt, vilket tar bort Dapr-abstraktionen. Väg flexibiliteten hos Dapr-komponenter mot den operativa enkelheten i direkta anrop via SDK.

Du kan använda Azure Monitor och Application Insights för att övervaka Container Apps. För distribuerade program använder du en OpenTelemetry-baserad pipeline för att skicka spårningar, loggar och mått till Azure Monitor och Application Insights. Du kan också visa containerloggar genom att navigera i portalen till fönstret Loggar i varje containerapp och sedan köra följande Kusto-fråga. I det här exemplet visas loggar för Makeline-tjänstappen.

ContainerAppConsoleLogs_CL |
    where ContainerAppName_s contains "make-line-service" |
    project TimeGenerated, _timestamp_d, ContainerGroupName_s, Log_s |
    order by _timestamp_d asc

Programkartan i Application Insights visar också hur tjänsterna kommunicerar i realtid. Du kan sedan använda dem för felsökningsscenarier. Gå till programkartan under Application Insights-resursen för att visa något som liknar följande karta.

Mer information finns i Övervaka en app i Container Apps.

Prestandaeffektivitet

Prestandaeffektivitet syftar på arbetsbelastningens förmåga att skala för att effektivt uppfylla användarnas krav. Mer information finns i checklistan för Designgranskning för prestandaeffektivitet.

Den här lösningen är starkt beroende av KEDA-implementeringen i Container Apps för händelsedriven skalning. När du distribuerar den virtuella kundtjänsten lägger den kontinuerligt beställningar. Den här skalningsåtgärden gör att ordertjänsten skalas upp via en HTTP-skalningsregel. När ordertjänsten publicerar ordrarna på Service Bus gör Service Bus skalningsregler att tjänsterna för bokföring, kvitto, Makeline och lojalitet skalas upp. Användargränssnittet och Makeline-tjänsten kan också använda HTTP-skalningsregler så att apparna skalas när fler användare kommer åt instrumentpanelen.

När den virtuella kunden inte körs skalas alla mikrotjänster i den här lösningen till noll förutom för virtual worker- och Makeline-tjänster. Den virtuella arbetaren skalas inte ned eftersom den kontinuerligt söker efter orderuppfyllelse. Mer information finns i Ange skalningsregler i Container Apps.

Arbetsbelastningsprofiler

Använd arbetsbelastningsprofiler för att separera tjänster som behöver varm kapacitet från tjänster som drar mest nytta av serverlös elasticitet. I det här diagrammet visas ordertjänsten och redovisningstjänsten i en dedikerad profil eftersom de hanterar transaktionsarbete och stöder live-affärsmått. Kvittotjänsten och lojalitetstjänsten visas i en förbrukningsprofil eftersom de är händelsedrivna tjänster som kan dra bättre nytta av serverlös elasticitet.

KEDA-baserade skalningsregler fungerar för både förbruknings- och dedikerade arbetsbelastningsprofiler. Förbrukning är bäst för tjänster som kan skalas till noll, medan Dedicated är bättre för tjänster som fortfarande drar nytta av automatisk skalning men som behöver varm kapacitet eller stabilare prestanda.

Deltagare

Microsoft ansvarar för den här artikeln. Följande deltagare skrev den här artikeln.

Huvudförfattare:

• Alice Gibbons | Molnbaserat globalt svart bälte

Övriga medarbetare:

• Lynn Orrell | Huvudlösningsspecialist (GBB)
• Kendall Roden | Senior Program Manager

Om du vill se linkedin-profiler som inte är offentliga loggar du in på LinkedIn.

Nästa steg

• Container Apps-dokumentation
• Jämför Container Apps med andra Azure-containeralternativ

Relaterade resurser

• Arkitektur för mikrotjänster i AKS
• Avancerad ARKITEKTUR för AKS-mikrotjänster
• Kontinuerlig integrering och kontinuerlig leverans för AKS-appar med Azure-pipelines