Modifier

Partager via


Modèles et implémentations pour une transformation cloud bancaire

Azure Cosmos DB
Hubs d'événements Azure
Azure Functions
Azure Kubernetes Service (AKS)
Azure Pipelines

Cet article décrit les modèles et les implémentations que l’équipe CSE a utilisés lors de la création de la transformation cloud de système bancaire sur Azure.

Architecture

Architecture Saga

Saga basé sur une orchestration sur une architecture serverless

Téléchargez un fichier Visio de cette architecture.

Dataflow

Contoso Bank avait une implémentation locale de Saga basé sur une orchestration. Dans cette implémentation, l’orchestrateur est une machine à états finis (FSM). L’équipe CSE a identifié les problèmes suivants dans la conception de l’architecture :

  • Gestion de la surcharge et de la complexité de l’implémentation sur l’orchestrateur avec état avec la gestion des états, les délais d’attente et les redémarrages dans les scénarios d’échec.

  • Mécanismes de capacité d’observation pour le suivi des états de workflow Saga par demande de transaction.

La solution proposée ci-dessous est une implémentation de modèle Saga par le biais d’une approche d’orchestration utilisant une architecture serverless sur Azure. Elle résout les problèmes à l’aide des éléments suivants :

  • Azure Functions pour l’implémentation des participants Saga.

  • Azure Durable Functions pour l’orchestration, conçu pour fournir le modèle de programmation de workflow et la gestion des états.

  • Azure Event Hubs en tant que plateforme de streaming des données.

  • Azure Cosmos DB en tant que service de base de données pour stocker des modèles de données.

Pour plus d’informations, consultez l’article Pattern: Saga sur Microservices.io.

Modèle Saga

Saga est un modèle adapté à la gestion des transactions distribuées, généralement appliqué aux services financiers. Un nouveau scénario a émergé où les opérations sont réparties entre des applications et des bases de données. Dans le nouveau scénario, les clients auront besoin d’une nouvelle architecture et d’une nouvelle conception d’implémentation pour garantir la cohérence des données sur les transactions financières.

L’approche avec les propriétés ACID (atomicité, cohérence, isolement et durabilité) traditionnelles n’est plus applicable. Cela est dû au fait que les données des opérations sont désormais réparties dans des bases de données isolées. L’utilisation d’un modèle Saga résout ce problème en coordonnant un workflow via une séquence de transactions locales pilotée par message pour garantir la cohérence des données.

Architecture KEDA

Mise à l’échelle automatique du processeur EFT avec déclencheur de rubrique Kafka basé sur les événements Kubernetes

Téléchargez un fichier Visio de cette architecture.

Pour plus d’informations sur les mécanismes de mise à l’échelle KEDA, consultez les documents KEDA suivants :

  • Déclencheur Azure Event Hubs : Compatibilité pour la lecture de l’URI Stockage Blob Azure pour les applications Java. Il utilise le kit SDK Hôte du processeur d’événements, ce qui permet de mettre à l’échelle les consommateurs Java qui lisent les messages de protocole AMQP (Advanced Message Queuing Protocols) à partir d’Event Hubs. Auparavant, le mécanisme de mise à l’échelle Event Hubs fonctionnait uniquement avec Azure Functions.

  • Déclencheur de rubrique Kafka Apache : Prise en charge de l’authentification simple SASL_SSL, ce qui permet de mettre à l’échelle les consommateurs Java qui lisent les messages de protocole Kafka à partir d’Event Hubs.

Workflow

  1. L’équipe CSE a déployé l’application sur le cluster Azure Kubernetes Service (AKS). La solution devait effectuer un scale-out de l’application automatiquement en fonction du nombre de messages entrants. L’équipe CSE a utilisé un mécanisme de mise à l’échelle Kafka pour détecter si la solution devait activer ou désactiver le déploiement de l’application. Le mécanisme de mise à l’échelle Kafka alimente également des métriques personnalisées pour une source d’événement spécifique. Dans cet exemple, la source d’événement est un Azure Event Hub.

  2. Lorsque le nombre de messages dans le hub Azure Event Hub dépasse un seuil, KEDA déclenche le scale-out des pods, augmentant le nombre de messages traités par l’application. Le scale-down automatique des pods se produit lorsque le nombre de messages dans la source d’événement passe sous la valeur de seuil.

  3. L’équipe CSE a utilisé le déclencheur de rubrique Kafka Apache. Il permet à la solution de mettre à l’échelle le service EFT Processor si le processus a dépassé le nombre maximal de messages consommés durant un intervalle.

KEDA avec prise en charge Java

KEDA (Kubernetes Event-driven Autoscaler) détermine la façon dont la solution doit mettre à l’échelle un conteneur dans Kubernetes. La décision est basée sur le nombre d’événements à traiter. KEDA, qui a différents types de mécanismes de mise à l’échelle, prend en charge plusieurs types de charges de travail, prend en charge Azure Functions et est indépendant du fournisseur. Accédez à Autoscaling d’applications Java avec KEDA à l’aide d’Azure Event Hubs pour explorer un exemple fonctionnel.

Architecture du test de charge

Pipeline de test de charge avec JMeter et Test de charge Azure

Téléchargez un fichier Visio de cette architecture.

La solution utilise le test de charge Azure avec des scripts JMeter (JMX). Test de charge Azure est un service complètement managé qui permet de générer une charge à grande échelle. Le service simule le trafic de vos applications, quel que soit l'endroit où elles sont hébergées, et peut utiliser des scripts JMeter existants.

Workflow

Test de charge Azure vous permet de créer manuellement des tests de charge à l'aide du portail Azure ou d'Azure CLI. Vous pouvez également configurer un pipeline CI/CD pour qu'il s'intègre à Test de charge Azure. Ce faisant, vous pouvez automatiser un test de charge pour valider en continu les performances et la stabilité de votre application dans le cadre de votre workflow CI/CD.

  1. Comprenez le fonctionnement du test de charge Azure en créant et en exécutant un test de charge.
  2. Utilisez des scripts JMeter nouveaux ou existants et configurez votre workflow CI/CD pour l'exécution des tests de charge.

Détails du scénario

Ce scénario vous aide à mieux comprendre les modèles et les implémentations au sens large dans le secteur bancaire au moment de passer au cloud.

Étapes suivantes

En savoir plus sur les technologies des composants :

Explorer les architectures connexes :