Den här artikeln beskriver de mönster och implementeringar som cse-teamet (Commercial Software Engineer) använde när de skapade molnomvandlingen för banksystem i Azure.
Arkitektur
Saga-arkitektur
Ladda ned en Visio-fil med den här arkitekturen.
Dataflöde
Contoso Bank hade en lokal implementering av en orkestreringsbaserad saga. I implementeringen är orkestratorn en begränsad tillståndsdator (FSM). CSE-teamet identifierade följande utmaningar i arkitekturdesignen:
Implementeringskostnader och komplexitet på den tillståndskänsliga orkestratorn att hantera med tillståndshantering, timeouter och omstarter i felscenarier.
Observerbarhetsmekanismer för spårning av saga-arbetsflödestillstånd per transaktionsbegäran.
Den föreslagna lösningen nedan är en saga-mönsterimplementering via en orkestreringsmetod med hjälp av en serverlös arkitektur i Azure. Den hanterar utmaningarna med hjälp av:
Azure Functions för implementering av saga-deltagare.
Azure Durable Functions för orkestrering, utformad för att tillhandahålla programmeringsmodellen för arbetsflödet och tillståndshantering.
Azure Cosmos DB som databastjänst för att lagra datamodeller.
Mer information finns i Mönster: Saga på Microservices.io.
Saga-mönster
Saga är ett mönster som lämpar sig för distribuerad transaktionshantering, som ofta tillämpas på finansiella tjänster. Ett nytt scenario har uppstått där åtgärder distribueras mellan program och databaser. I det nya scenariot behöver kunderna en ny arkitektur och implementeringsdesign för att säkerställa datakonsekvens för finansiella transaktioner.
Den traditionella metoden för atomitet, konsekvens, isolering och hållbarhet (ACID) är inte längre lämplig. Det beror på att data för åtgärder nu sträcker sig över till isolerade databaser. Med hjälp av ett saga-mönster hanteras den här utmaningen genom att samordna ett arbetsflöde genom en meddelandedriven sekvens med lokala transaktioner för att säkerställa datakonsekvens.
KEDA-arkitektur
Ladda ned en Visio-fil med den här arkitekturen.
Mer information om KEDA-skalare finns i följande KEDA-dokument:
Azure Event Hubs-utlösare: Kompatibilitet för att läsa Azure Blob Storage URI för Java-program. Den använder eventprocessorns värd-SDK , vilket gör det möjligt att skala Java-konsumenter som läser AMQP-protokollmeddelanden (Advanced Message Queuing Protocols) från Event Hubs. Tidigare fungerade Event Hubs-skalningsfunktionen endast med Azure Functions.
Apache Kafka-ämnesutlösare: Stöd för SASL_SSL oformaterad autentisering, vilket gör det möjligt att skala Java-konsumenter som läser Kafka-protokollmeddelanden från Event Hubs.
Arbetsflöde
CSE-teamet distribuerade programmet i AKS-klustret (Azure Kubernetes Service). Lösningen som behövs för att skala ut programmet automatiskt baserat på antalet inkommande meddelanden. CSE-teamet använde en Kafka-skalning för att identifiera om lösningen ska aktivera eller inaktivera programdistribution. Kafka-skalningsappen matar även anpassade mått för en specifik händelsekälla. Händelsekällan i det här exemplet är en Azure-händelsehubb.
När antalet meddelanden i Azure-händelsehubben överskrider ett tröskelvärde utlöser KEDA poddarna för att skala ut, vilket ökar antalet meddelanden som bearbetas av programmet. Automatisk nedskalning av poddarna sker när antalet meddelanden i händelsekällan understiger tröskelvärdet.
CSE-teamet använde Apache Kafka-ämnesutlösaren. Det ger lösningen möjlighet att skala EFT-processortjänsten om processen överskred det maximala antalet meddelanden som förbrukades under ett intervall.
KEDA med Java-stöd
Kubernetes Händelsedriven autoskalning (KEDA) avgör hur lösningen ska skala alla containrar i Kubernetes. Beslutet baseras på antalet händelser som det behöver bearbeta. KEDA, som har olika typer av skalare, stöder flera typer av arbetsbelastningar, stöder Azure Functions och är leverantörsoberoende. Gå till Autoskalning av Java-program med KEDA med Hjälp av Azure Event Hubs för att utforska ett fungerande exempel.
Arkitektur för belastningstestning
Ladda ned en Visio-fil med den här arkitekturen.
Lösningen använder Azure Load Testing med JMX-skript (JMX). Azure Load Testing är en fullständigt hanterad tjänst för belastningstestning som gör att du kan generera högskalig belastning. Tjänsten simulerar trafik för dina program, oavsett var de finns och kan använda befintliga JMeter-skript.
Arbetsflöde
Med Azure Load Testing kan du skapa belastningstester manuellt med hjälp av Azure Portal eller Azure CLI. Du kan också konfigurera en CI/CD-pipeline för integrering med Azure Load Testing. På så sätt kan du automatisera ett belastningstest för att kontinuerligt verifiera programmets prestanda och stabilitet som en del av ditt CI/CD-arbetsflöde.
- Förstå hur Azure Load Testing fungerar genom att skapa och köra ett belastningstest.
- Använd nya eller befintliga JMeter-skript och konfigurera ditt CI/CD-arbetsflöde för att köra belastningstester.
Information om scenario
Det här scenariot hjälper dig att bättre förstå övergripande mönster och implementeringar i bankbranschen när du flyttar till molnet.
Nästa steg
Läs mer om komponentteknikerna:
- Introduktion till Azure Functions
- Vad Durable Functions?
- Azure Event Hubs – en stordataströmningsplattform och händelseinmatningstjänst
- Välkommen till Azure Cosmos DB