Upravit

Sdílet prostřednictvím

Vzory a implementace pro transformaci bankovního cloudu

Azure Cosmos DB
Azure Event Hubs
Azure Functions
Azure Kubernetes Service (AKS)
Azure Pipelines

Tento článek popisuje vzory a implementace týmu komerčního softwarového inženýra (CSE), který se používá při vytváření cloudové transformace bankovního systému v Azure.

Architektura

Architektura Saga

Saga založená na orchestraci na bezserverové architektuře

Stáhněte si soubor aplikace Visio s touto architekturou.

Tok dat

Contoso Bank měla místní implementaci orchestrační ságy založené na orchestraci. Orchestrátor je ve své implementaci konečný stavový počítač (FSM). Tým CSE identifikoval v návrhu architektury následující výzvy:

  • Režie a složitost implementace stavového orchestrátoru pro zpracování se správou stavů, vypršením časových limitů a restartováním ve scénářích selhání

  • Mechanismy pozorovatelnosti pro sledování stavů pracovního postupu ság na žádost o transakci

Navrhované řešení je implementace vzoru saga prostřednictvím přístupu orchestrace s využitím bezserverové architektury v Azure. Řeší problémy s využitím:

Další informace naleznete v tématu Pattern: Saga na Microservices.io.

Vzor Saga

Saga je vzor vhodný pro správu distribuovaných transakcí, běžně používaný u finančních služeb. Objevil se nový scénář, kdy se operace distribuují napříč aplikacemi a databázemi. V novém scénáři budou zákazníci potřebovat nový návrh architektury a implementace, aby zajistili konzistenci dat u finančních transakcí.

Tradiční přístup k vlastnostem atomicity, konzistence, izolace a odolnosti (ACID) už není vhodný. Je to proto, že data operací jsou teď rozložená do izolovaných databází. Použití vzoru saga řeší tento problém tím, že koordinuje pracovní postup prostřednictvím sekvence místních transakcí řízených zprávami, aby se zajistila konzistence dat.

Architektura KEDA

Trigger tématu Automatické škálování procesoru EFT s využitím triggeru automatického škálování řízeného událostmi Kubernetes (KEDA) Kafka

Stáhněte si soubor aplikace Visio s touto architekturou.

Další informace o škálovacích modelech KEDA najdete v následujících dokumentech KEDA:

  • Trigger služby Azure Event Hubs: Kompatibilita pro čtení identifikátoru URI úložiště objektů blob v Azure pro aplikace v Javě Používá sadu SDK event Processor Host , která umožňuje škálovat uživatele Javy, kteří čtou zprávy protokolu AMQP (Advanced Message Queuing Protocol) ze služby Event Hubs. Dříve škálovací nástroj služby Event Hubs fungoval pouze se službou Azure Functions.

  • Trigger tématu Apache Kafka: Podpora SASL_SSL prostého ověřování, což umožňuje škálovat uživatele Javy, kteří čtou zprávy protokolu Kafka ze služby Event Hubs.

Workflow

  1. Tým CSE nasadil aplikaci do clusteru Azure Kubernetes Service (AKS). Řešení potřebné k automatickému horizontálnímu navýšení kapacity aplikace na základě počtu příchozích zpráv. Tým CSE pomocí škálovače Kafka zjistil, jestli by řešení mělo aktivovat nebo deaktivovat nasazení aplikace. Škálovací nástroj Kafka také podává vlastní metriky pro konkrétní zdroj událostí. Zdrojem událostí v tomto příkladu je centrum událostí Azure.

  2. Když počet zpráv v centru událostí Azure překročí prahovou hodnotu, keDA aktivuje horizontální navýšení kapacity podů a zvýší počet zpráv zpracovaných aplikací. Automatické vertikální snížení kapacity podů nastane, když počet zpráv ve zdroji událostí klesne pod prahovou hodnotu.

  3. Tým CSE použil trigger tématu Apache Kafka. Poskytuje řešení možnost škálovat službu procesoru EFT, pokud proces překročil maximální počet zpráv spotřebovaných v intervalu.

PODPORA KEDA s Javou

Automatické škálování řízené událostmi Kubernetes (KEDA) určuje, jak by řešení mělo škálovat libovolný kontejner v rámci Kubernetes. Rozhodnutí vychází z počtu událostí, které potřebuje zpracovat. KEDA, která má různé druhy škálovacích nástrojů, podporuje více typů úloh, podporuje Azure Functions a je nezávislá na dodavatelích. Pokud chcete prozkoumat funkční ukázku, přejděte k automatickému škálování aplikací v Javě pomocí KEDA pomocí služby Azure Event Hubs .

Architektura zátěžového testování

Kanál zátěžového testování s využitím JMeter a zátěžového testování Azure

Stáhněte si soubor aplikace Visio s touto architekturou.

Řešení používá azure Load Testing se skripty JMX (JMX). Azure Load Testing je plně spravovaná služba zátěžového testování, která umožňuje generovat zatížení ve velkém měřítku. Služba simuluje provoz pro vaše aplikace bez ohledu na to, kde jsou hostované, a může využívat existující skripty JMeter.

Workflow

Zátěžové testování Azure umožňuje ručně vytvářet zátěžové testy pomocí webu Azure Portal nebo Azure CLI. Případně můžete nakonfigurovat kanál CI/CD pro integraci se službou Azure Load Testing. Díky tomu můžete automatizovat zátěžový test, který bude nepřetržitě ověřovat výkon a stabilitu aplikace v rámci pracovního postupu CI/CD.

  1. Seznamte se s fungováním zátěžového testování Azure vytvořením a spuštěním zátěžového testu.
  2. Použijte nové nebo existující skripty JMeter a nakonfigurujte pracovní postup CI/CD pro spouštění zátěžových testů.

Podrobnosti scénáře

Tento scénář vám pomůže lépe pochopit vzory a implementace v bankovním odvětví při přechodu do cloudu.

Další kroky

Další informace o technologiích komponent:

Prozkoumejte související architektury: