In dit artikel worden de patronen en implementaties besproken die het CSE-team (commercial software engineer) heeft gebruikt bij het maken van de cloudtransformatie van het banksysteem in Azure.
Architectuur
Saga-architectuur
Een Visio-bestand van deze architectuur downloaden.
Gegevensstroom
Contoso Bank had een on-premises implementatie van een orchestration-based saga. In hun implementatie is de orchestrator een eindige statusmachine (FSM). Het CSE-team heeft de volgende uitdagingen in het architectuurontwerp geïdentificeerd:
Implementatieoverhead en complexiteit van de stateful orchestrator voor verwerking met statusbeheer, time-outs en opnieuw opstarten in foutscenario's.
Waarneembaarheidsmechanismen voor het bijhouden van de saga-werkstroomstatussen per transactieaanvraag.
De voorgestelde oplossing hieronder is een saga-patroon-implementatie via een indelingsbenadering met behulp van een serverloze architectuur in Azure. De oplossing biedt een oplossing voor de uitdagingen met behulp van:
Azure Functions voor de implementatie van saga-deelnemers.
Azure Durable Functions voor indeling, ontworpen om het werkstroomprogrammeringsmodel en statusbeheer te bieden.
Azure Event Hubs als het gegevensstreamingplatform.
Azure Cosmos DB als databaseservice voor het opslaan van gegevensmodellen.
Zie Pattern: Saga op Microservices.io voor meer informatie.
Saga-patroon
Saga is een patroon dat geschikt is voor gedistribueerd transactiebeheer, dat vaak wordt toegepast op financiële diensten. Er is een nieuw scenario ontstaan waarin bewerkingen worden gedistribueerd over toepassingen en databases. In het nieuwe scenario hebben klanten een nieuw architectuur- en implementatieontwerp nodig om gegevensconsistentie voor financiële transacties te garanderen.
De traditionele atomische, consistentie-, isolatie- en duurzaamheidseigenschappen (ACID) zijn niet meer geschikt. Dit komt doordat de gegevens van bewerkingen nu zijn opgenomen in geïsoleerde databases. Met behulp van een saga-patroon wordt deze uitdaging aangepakt door een werkstroom te coördineren via een berichtengestuurde reeks lokale transacties om gegevensconsistentie te garanderen.
KEDA-architectuur
Een Visio-bestand van deze architectuur downloaden.
Zie de volgende KEDA-documenten voor meer informatie over KEDA-schaalders:
Azure Event Hubs-trigger: compatibiliteit voor het lezen van URI voor Azure Blob Storage voor Java-toepassingen. Het maakt gebruik van de Event Processor Host SDK, waardoor java-consumenten kunnen worden geschaald die geavanceerde AMQP-protocolberichten (Message Queuing Protocols) van Event Hubs lezen. Eerder werkte de Event Hubs-schaalfunctie alleen met Azure Functions.
Apache Kafka-onderwerptrigger: ondersteuning voor SASL_SSL niet-geverifieerde verificatie, zodat Java-gebruikers die Kafka-protocolberichten van Event Hubs lezen, kunnen schalen.
Workflow
Het CSE-team heeft de toepassing geïmplementeerd in het AKS-cluster (Azure Kubernetes Service). De oplossing die nodig is om de toepassing automatisch uit te schalen op basis van het aantal binnenkomende berichten. Het CSE-team heeft een Kafka-scaler gebruikt om te detecteren of de oplossing de implementatie van toepassingen moet activeren of deactiveren. De Kafka-scaler voedt ook aangepaste metrische gegevens voor een specifieke gebeurtenisbron. De gebeurtenisbron in dit voorbeeld is een Azure Event Hub.
Wanneer het aantal berichten in de Azure Event Hub een drempelwaarde overschrijdt, activeert KEDA de pods om uit te schalen, waardoor het aantal berichten dat door de toepassing wordt verwerkt, wordt verhoogd. Automatisch omlaag schalen van de pods gebeurt wanneer het aantal berichten in de gebeurtenisbron onder de drempelwaarde valt.
Het CSE-team heeft de apache Kafka-onderwerptrigger gebruikt. Het biedt de oplossing de mogelijkheid om de EFT-processorservice te schalen als het proces het maximum aantal berichten overschrijdt dat wordt verbruikt onder een interval.
KEDA met Java-ondersteuning
Kubernetes Event Driven Autoscaler (KEDA) bepaalt hoe de oplossing elke container binnen Kubernetes moet schalen. De beslissing is gebaseerd op het aantal gebeurtenissen dat moet worden verwerkt. KEDA, dat verschillende soorten schaalders heeft, ondersteunt meerdere typen workloads, ondersteunt Azure Functions en is leverancierneutraal. Ga naar Java-toepassingen voor automatisch schalen met KEDA met behulp van Azure Event Hubs om een werkend voorbeeld te verkennen.
Architectuur voor belastingstests
Een Visio-bestand van deze architectuur downloaden.
De oplossing maakt gebruik van Azure Load Testing met JMeter-scripts (JMX). Azure Load Testing is een volledig beheerde service voor belastingstests waarmee u grootschalige belasting kunt genereren. De service simuleert verkeer voor uw toepassingen, ongeacht waar ze worden gehost en kan gebruikmaken van bestaande JMeter-scripts.
Workflow
Met Azure Load Testing kunt u handmatig belastingstests maken met behulp van Azure Portal of Azure CLI. U kunt ook een CI/CD-pijplijn configureren om te integreren met Azure Load Testing. Hierdoor kunt u een belastingstest automatiseren om de prestaties en stabiliteit van uw toepassing continu te valideren als onderdeel van uw CI/CD-werkstroom.
- Meer informatie over hoe Azure Load Testing werkt door een belastingstest te maken en uit te voeren.
- Gebruik nieuwe of bestaande JMeter-scripts en configureer uw CI/CD-werkstroom voor het uitvoeren van belastingstests.
Scenariodetails
Dit scenario helpt u beter inzicht te krijgen in patronen en implementaties in de banksector, wanneer u overstapt naar de cloud.
Volgende stappen
Meer informatie over de onderdeeltechnologieën:
- Inleiding tot Azure Functions
- Wat zijn Durable Functions?
- Azure Event Hubs : een streamingplatform voor big data en een service voor gebeurtenisopname
- Welkom bij Azure Cosmos DB
Verwante resources
Gerelateerde architecturen verkennen: