Modelli e implementazioni per una trasformazione del cloud per il sistema bancario

Azure Cosmos DB
Hub eventi di Azure
Funzioni di Azure
Servizio Azure Kubernetes
Azure Pipelines

Questo articolo illustra i modelli e le implementazioni usati dal team Commercial Software Engineer (CSE) durante la creazione del processo di trasformazione del cloud per il sistema bancario in Azure.

Architettura

Architettura Saga

Saga basata sull'orchestrazione sull'architettura serverless

Scaricare un file di Visio di questa architettura.

Flusso di dati

In Contoso Bank è stata eseguita l'implementazione locale di un'architettura Saga basata su orchestrazione. In questa implementazione, l'agente di orchestrazione è una macchina a stati finiti (FSM, Finite State Machine). Il team CSE ha identificato le seguenti problematiche nella progettazione dell'architettura:

  • Complessità e overhead di implementazione nell'agente di orchestrazione con stato, risolvibili mediante operazioni di gestione degli stati, di timeout e di riavvio negli scenari di errore.

  • Meccanismi di osservabilità per monitorare gli stati del flusso di lavoro Saga per ogni richiesta di transazione.

La soluzione proposta di seguito rappresenta l'implementazione di un modello Saga tramite un approccio di orchestrazione che usa un'architettura serverless in Azure. Per la risoluzione delle problematiche, usa:

  • Funzioni di Azure per l'implementazione dei partecipanti all'architettura Saga.

  • Azure Durable Functions per l'orchestrazione, progettato per fornire il modello di programmazione del flusso di lavoro e consentire la gestione dello stato.

  • Hub eventi di Azure come piattaforma di streaming dei dati.

  • Azure Cosmos DB come servizio di database per archiviare i modelli di dati.

Per altre informazioni, vedere Pattern: Saga (Modello: Saga) in Microservices.io.

Modello Saga

Saga è un modello indicato in particolar modo per la gestione di transazioni distribuite, comunemente applicato ai servizi finanziari. È stato creato un nuovo scenario in cui le operazioni vengono distribuite tra più applicazioni e database. Nel nuovo scenario, i clienti dovranno disporre di una nuova architettura e di un nuovo design di implementazione per garantire la coerenza dei dati nelle transazioni finanziarie.

L'approccio tradizionale basato sulle proprietà ACID (atomicità, coerenza, isolamento e durabilità) non è più adatto, in quanto i dati delle operazioni sono ora distribuiti tra più database isolati. L'adozione di un modello Saga risolve questa problematica coordinando un flusso di lavoro tramite una sequenza di transazioni locali, basata su messaggi, per garantire la coerenza dei dati.

Architettura KEDA

Scalabilità automatica del processore EFT con trigger di argomento Kafka KEDA

Scaricare un file di Visio di questa architettura.

Per altre informazioni sugli scaler KEDA, vedere i documenti KEDA seguenti:

  • Trigger di Hub eventi di Azure: compatibilità per la lettura dell'URI di Archiviazione BLOB di Azure per applicazioni Java. Usa Event Processor Host SDK, che offre funzioni di scalabilità dei consumer Java in grado di leggere da Hub eventi messaggi basati sul procotocollo AMQP (Advanced Message Queuing Protocol). In precedenza, gli scaler di Hub eventi potevano essere usati solo con Funzioni di Azure.

  • Trigger dell'argomento Apache Kafka: offre il supporto per l'autenticazione SASL_SSL Plain, che consente la scalabilità dei consumer Java in grado di leggere da Hub eventi messaggi basati sul protocollo Kafka.

Workflow

  1. Il team CSE ha distribuito l'applicazione nel cluster del servizio Azure Kubernetes (AKS). Era necessaria una soluzione in grado di aumentare automaticamente le prestazioni dell'applicazione in base al numero di messaggi in ingresso. Il team CSE ha usato un scaler Kafka per capire se la soluzione doveva attivare o disattivare la distribuzione dell'applicazione. Lo scaler Kafka offre anche metriche personalizzate per un'origine evento specifica. L'origine evento in questo esempio è un hub eventi di Azure.

  2. Quando il numero di messaggi nell'hub eventi di Azure supera una soglia, KEDA attiva la scalabilità orizzontale dei pod, aumentando il numero di messaggi elaborati dall'applicazione. Le prestazioni dei pod vengono automaticamente ridotte quando il numero di messaggi nell'origine evento scende sotto il valore soglia.

  3. Il team CSE ha usato il trigger dell'argomento Apache Kafka, che offre alla soluzione la possibilità di aumentare le prestazioni del servizio EFT Processor nel momento in cui viene superato il numero massimo di messaggi inviati in un determinato intervallo.

KEDA con supporto Java

Kubernetes Event-driven Autoscaler (KEDA) determina il modo in cui la soluzione deve ridimensionare qualsiasi contenitore presente in Kubernetes. Questa decisione si basa sul numero di eventi che devono essere elaborati. KEDA, che dispone di diversi tipi di scaler, è in grado di gestire più tipi di carichi di lavoro, supporta Funzioni di Azure ed è indipendente dal fornitore. Vedere Scalabilità delle applicazioni Java con KEDA e Hub eventi di Azure: esempio di KEDA per Java per consultare un esempio.

Architettura dei test di carico

Pipeline di test di carico con JMeter e test di carico di Azure

Scaricare un file di Visio di questa architettura.

La soluzione usa test di carico di Azure con script JMeter (JMX). Test di carico di Azure è un servizio di test di carico completamente gestito che consente di generare un carico su larga scala. Il servizio simula il traffico per le applicazioni, indipendentemente dalla posizione in cui sono ospitate e può usare script JMeter esistenti.

Workflow

Test di carico di Azure consente di creare manualmente test di carico usando il portale di Azure o l'interfaccia della riga di comando di Azure. In alternativa, è possibile configurare una pipeline CI/CD per l'integrazione con Test di carico di Azure. In questo modo è possibile automatizzare un test di carico per convalidare continuamente le prestazioni e la stabilità dell'applicazione come parte del flusso di lavoro CI/CD.

  1. Comprendere il funzionamento dei test di carico di Azure creando ed eseguendo un test di carico.
  2. Usare script JMeter nuovi o esistenti e configurare il flusso di lavoro CI/CD per l'esecuzione di test di carico.

Dettagli dello scenario

Questo scenario consente di comprendere meglio i modelli e le implementazioni di big picture nel settore bancario, quando si passa al cloud.

Passaggi successivi

Altre informazioni sulle tecnologie dei componenti:

Esplorare le architetture correlate: