Molntransformering för banksystem på Azure

Den här artikeln sammanfattar processen och komponenterna i microsofts CSE-team (Commercial Software Engineering) som används för att skapa en lösning för en bankkund. För anonymitetens skull refererar artikeln till kunden som Contoso Bank. Det är en stor internationell FSI-organisation (Financial Services Industry) som ville modernisera ett av sina finansiella transaktionssystem.

Arkitektur

Ladda ned en Visio-fil med den här arkitekturen.

Tre huvudblock utgör lösningen: serverdelstjänster, belastningstestning och övervakning med Event Autoscaler.

De faktiska Contoso-mikrotjänstcontainrarna överfördes manuellt via Docker till Kubernetes-klustret. Det här klustret var:

• Azure Red Hat OpenShift (ARO) i Kubernetes/OpenShift Horizontal Pod Autoscaler (HPA) för:

  • Kanalhållare.

  • Skalbarhet och prestanda för slutprodukt för transaktionssimulering.

• Azure Kubernetes Service (AKS) för nodens autoskalning för Kanalhållare.

CSE-teamet skapade de andra mikrotjänsterna som stubs för att specifikt isolera de faktiska Contoso-mikrotjänsterna från andra externa stordatortjänster som lösningen överförde via Azure Pipelines.

Arbetsflöde

I grunden tillhandahåller serverdelstjänsterna den logik som krävs för att en EFT ska ske:

1. En ny EFT börjar med en HTTP-begäran som tagits emot av kanalhållartjänsten.

   Tjänsten tillhandahåller synkrona svar till beställare med hjälp av ett publiceringsprenumereringsmönster via en Azure Cache for Redis och väntar på ett serverdelssvar.

2. Lösningen validerar den här första begäran med hjälp av EFT Pilot Password-tjänsten.

   Förutom att utföra valideringar berikar tjänsten även data. Databerikningen hjälper serverdelen att avgöra om lösningen ska använda ett äldre mikrotjänstsystem eller ett nytt för att bearbeta EFT.

3. Kanalhållartjänsten startar sedan det asynkrona flödet.

   Tjänsten anropar EFT-styrenheten, som är en reaktiv orkestrerare som samordnar ett transaktionsflöde. Det gör den genom att skapa kommandon och använda händelser från andra mikrotjänster via Azure Event Hubs/Kafka.

4. En av dessa tjänster är EFT-processorn, där lösningen påverkar den faktiska transaktionen och utför kredit- och debetåtgärder.

   CSE-teamet använde Kubernetes Händelsedriven autoskalning (KEDA). Det är ett ramverk som automatiskt skalar program baserat på belastningen på meddelanden som lösningen bearbetade. I lösningen användes den för att skala EFT-processorn när lösningen bearbetade nya EFT:er.

   KEDA stöds i AKS och Azure Container Apps

5. Nästa steg är belastningstestning. 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 utan att behöva distribuera ytterligare resurser. Azure Load Testing har också möjlighet att ta ett befintligt Apache JMeter-skript och använda det för att köra ett belastningstest.

6. Slutligen ansvarade övervakningen för att integrera belastningstestresultat, infrastruktur och programmått.

   Teamet korrelerade en belastningstestkörning med de biverkningar som orsakas av mikrotjänster på lagrings- och containerorkestreringslagret. Det tillät en snabb feedbackcykel för programjustering. Prometheus, Grafana och Application Insights i Azure Monitor var de viktigaste komponenterna som möjliggjorde den här övervaknings- och observerbarhetsfunktionen. Autoskalning av händelse har stöd för validering av ett scenario där program skalas baserat på den mottagna meddelandeinläsningen. För att implementera det här beteendet anpassade CSE-teamet KEDA för att stödja Skalning av Java-program.

Lösningsfunktioner

Lösningen omfattar tre viktiga funktioner:

• Vågrät autoskalning av poddar för kanalhållare

• Autoskalning av noder för kanalhållare

• Skalbarhet och prestanda för transaktionssimuleringsprodukt

Vågrät autoskalning av poddar för kanalhållare

I den här lösningen använde teamet en Kubernetes/OpenShift HPA-mekanism. HPA skalar automatiskt antalet poddar baserat på ett valt mått. Detta ger en effektiv in- och utskalningsmekanism för containrar. Med tanke på den CPU-bundna karaktären hos rest-API:et för kanalhållare valde teamet att använda HPA med CPU så att tjänstreplikerna kan växa när nya EFT:er inträffar.

Den här komponenten kör en tjänst med namnet Channel Holder på Azure Red Hat OpenShift. Den utför automatiska skalningstester för poddar på den här tjänsten. Komponenten var tvungen att uppnå följande funktioner:

• Ange en DevOps-pipeline från lokal plats till Azure för kanalhållartjänsten.

• Tillhandahålla OpenShift-klusterövervakning via en Grafana-instrumentpanel.

• Kör horisontella autoskalningstester för poddar för kanalhållartjänsten.

• Tillhandahålla observerbarhet på kanalhållaren genom att aktivera måttinsamling (till exempel användning) med Prometheus och Grafana.

• Ange en detaljerad rapport om de tester som körs, programmets beteende och eventuella Kafka-partitioneringsstrategier.

Autoskalning av noder för kanalhållare

Först skalar HPA replikerna upp till en punkt där den mättar klusterinfrastrukturen. Sedan behåller en in- och utskalningsmekanism för noderna de program som tar emot och bearbetar nya begäranden. För den mekanismen använde teamet autoskalning av Kubernetes-noder, vilket gjorde att klustret kunde växa även när alla noder var nära sin fulla kapacitet.

Den här komponenten fokuserar på att köra kanalhållartjänsten på AKS för att tillåta automatiska nodskalningstester. Den var tvungen att uppnå följande funktioner:

• Tillhandahålla AKS-klusterövervakning via en Grafana-instrumentpanel.

• Kör autoskalningstester för noder för kanalhållartjänsten.

• Tillhandahålla observerbarhet på kanalhållaren genom att aktivera måttinsamling med Prometheus och Grafana.

• Ange en detaljerad rapport om de tester som körs, programmets beteende och eventuella Kafka-partitioneringsstrategier.

Skalbarhet och prestanda för transaktionssimuleringsprodukt

Med hjälp av ramverket för belastningstestning genererade CSE-teamet tillräckligt med belastning för att utlösa mekanismer för automatisk skalning av både HPA och noder. När lösningen utlöste komponenterna genererade den infrastruktur- och programmått för teamet för att validera svarstiderna för kanalinnehavarens skalning och programbeteendet under hög belastning.

Den här komponenten fokuserar på att köra kanalhållare, EFT-styrenhet och EFT-processortjänster på ARO och AKS. Dessutom utför den automatiska skalnings- och prestandatester för poddar och noder på alla tjänster. Den var tvungen att uppnå följande funktioner:

• Kör prestandatester över mikrotjänsterna tills de når eller överskrider 2 000 transaktioner per sekund.

• Kör horisontella autoskalningstester för poddar/noder över mikrotjänsterna.

• Tillhandahålla observerbarhet på kanalhållaren genom att aktivera måttinsamling med Prometheus och Grafana.

• Ange en detaljerad rapport om de tester som körs, programmets beteende och de kafka-partitioneringsstrategier som har antagits.

Komponenter

I listan nedan sammanfattas de tekniker som CSE-teamet använde för att skapa den här lösningen:

• Azure

  • Azure Pipelines

  • Azure Kubernetes Services (AKS)

  • Azure Red Hat OpenShift

  • Azure SQL Database

  • Azure Event Hubs - (Kafka)

  • Azure Monitor

  • Azure Container Registry

  • Azure Container Instances (ACI)

  • Azure Cache for Redis

• Tredje part

  • Contoso Banks serverdelstjänster

  • Docker

  • Grafana

  • Prometheus

• Öppen källkod

  • Jenkins

  • KEDA

  • Apache JMeter

  • Redis

Information om scenario

Contoso Bank är en stor internationell FSI-organisation (Financial Services Industry) som ville modernisera ett av sina finansiella transaktionssystem.

Contoso Bank ville använda simulerade och faktiska program och befintliga arbetsbelastningar för att övervaka reaktionen i lösningsinfrastrukturen för skalbarhet och prestanda. Lösningen måste vara kompatibel med kraven i det befintliga betalningssystemet.

Potentiella användningsfall

Contoso Bank ville använda en uppsättning simuleringar för att:

• Fastställa effekten av infrastrukturens skalbarhet.

• Fastställa reaktionen på fel i den befintliga arkitekturdesignen för specifik stordatorprogramvara.

Den föreslagna lösningen skulle använda ett virtuellt program för att simulera funktionella scenarier. Syftet är att övervaka infrastrukturens prestanda och skalbarhet. Syftet var att fastställa effekten av fel i eft-systemets arbetsbelastningar (Electronic Funds Transfer) via denna uppsättning simuleringar.

Det fanns också ett krav på att föreslå en smidig DevOps-övergång från lokal plats till molnet. Övergången var tvungen att inkludera bankens process och metodik, och den var tvungen att använda Contoso Banks befintliga verktyg. Att använda befintlig teknik skulle minska utvecklarnas kompetenspåverkan. Övergången skulle hjälpa Contoso Bank att granska aktuella och framtida designbeslut. Övergången skulle också ge förtroende för att Azure är en miljö som är tillräckligt robust för att vara värd för de nya distribuerade systemen.

Att tänka på

Framgångskriterier

Contoso-teamet och CSE-teamet definierade följande framgångskriterier för det här åtagandet:

Allmänna kriterier

Contoso Bank ansåg att följande allmänna punkter var lyckade kriterier för alla komponenter:

• Ge Contosos tekniska team möjlighet att tillämpa digital omvandling och molnimplementering. CSE-teamet:

  • Tillhandahöll nödvändiga verktyg och processer i Azure.

  • Visade hur Contosos tekniska team kunde fortsätta använda sina befintliga verktyg.

• Varje komponent skulle ha ett dokument som omfattar:

  • Resultat av skalbarhets- och prestandatester.

  • Parametrar och mått som beaktas vid varje test.

  • Eventuell kod- eller infrastrukturändring vid behov under varje test.

  • Lärdomar om prestandajusteringar, prestandajustering och parametrar som beaktas för varje test.

  • Lärdomar och vägledning om strategier för Kafka-partitionering.

  • Allmänna rekommendationer/vägledning för arkitektur baserat på lärdomarna över slutprodukten.

Kriterier för slutprodukt

Teknisk lösning

Lösningen från teamet innehöll övergripande problem och specifika implementeringar för att uppnå målprodukt. Det var också tvunget att följa vissa designbegränsningar baserade på Contoso Banks policyer.

Det är värt att notera att Contoso på grund av en funktionsbegränsning i Azure Red Hat OpenShift 3.11 begärde att Azure Kubernetes Service skulle användas för att testa scenarier för automatisk skalning av noder.

Det fanns ett antal designbegränsningar som CSE-teamet var tvungna att överväga:

• På grund av interna krav begärde Contoso Bank att följande tekniker skulle användas:

  • OpenShift 3.11 som containerorkestreringsplattform.

  • Java och Spring Boot för utveckling av mikrotjänster.

  • Kafka som händelseströmningsplattform med funktionen Confluent Schema Registry.

• Lösningen måste vara molnagnostisk.

• DevOps och övervakningsverktyg måste vara samma som Contoso redan använde i sin lokala utvecklingsmiljö.

• Lösningen kunde inte dela källkoden som Contoso är värd för i den lokala miljön till externa miljöer. Contoso-principen tillåter endast flytt av containeravbildningar från lokal plats till Azure.

• Contoso-principen begränsar möjligheten för en ci-pipeline (constant integration) att fungera mellan både lokala miljöer och alla moln. Contoso distribuerade manuellt all källkod som finns i den lokala miljön, som containeravbildningar, till Azure Container Registry. Distributionen på den lokala sidan var Contosos ansvar.

• Det simulerade scenariot för tester var tvunget att använda en delmängd av EFT-arbetsbelastningar för stordatorer som flödesreferens.

• Contoso Bank var tvungen att göra alla HPA- och prestandatester på ARO.

Övergripande problem med lösningen

Meddelandeströmning

CSE-teamet bestämde sig för att använda Apache Kafka som plattform för distribuerad meddelandeströmning för mikrotjänster. För bättre skalbarhet tänkte teamet på att använda en konsumentgrupp per mikrotjänst. I den konfigurationen är varje mikrotjänstinstans en skalningsenhet för att dela upp och parallellisera bearbetning av händelser.

De använde en formel för att beräkna det uppskattade ideala antalet partitioner per ämne för att stödja det uppskattade dataflödet. Mer information om formeln finns i Så här väljer du antalet ämnen eller partitioner i ett Kafka-kluster.

CI/CD-hastighet

För DevOps använde Contoso Bank redan en lokal instans av GitLab för sin kodlagringsplats. De skapade pipelines för kontinuerlig integrering och kontinuerlig leverans (CI/CD) för utvecklingsmiljöer med hjälp av en anpassad Jenkins-baserad lösning som de utvecklade internt. Det gav inte en optimal DevOps-upplevelse.

För att leverera en förbättrad DevOps-upplevelse för Contoso använde CSE-teamet Azure Pipelines i Azure DevOps för att hantera programlivscykeln . CI-pipelinen körs på varje pull-begäran, medan CD-pipelinen körs vid varje lyckad sammanslagning till huvudgrenen. Varje medlem i utvecklingsteamet ansvarade för att hantera lagringsplatser och pipelines för varje tjänst. De var också tvungna att tillämpa kodgranskningar, enhetstester och linting (statisk källkodsanalys).

CSE-teamet distribuerade tjänster samtidigt utan ömsesidigt beroende och använde Jenkins-agenter på begäran av Contoso Bank.

De införlivade Prometheus som en del av lösningen för att övervaka tjänsterna och klustret. Förutom att generera meningsfulla data för lösningen kan Contoso Bank använda Prometheus i framtiden för att förbättra produkterna baserat på den dagliga användningen. En Grafana-instrumentpanel visar dessa mått.

Distributionsstrategi

Teamet distribuerade lösningen till utvecklingsmiljön via Azure Pipelines. Varje tjänst hade en egen bygg- och distributionspipeline. De använde en distributionspipeline som kan utlösas manuellt. Den bör framtvinga en fullständig distribution av miljön och containrarna i en specifik grenversion.

CSE-teamet skapade versionsgrenar som genererade stabila versioner för distribution. Sammanslagning av grenar till huvudgrenen sker bara när teamet är säkra på att de är redo att distribuera lösningen. En återställningsstrategi, förutom att distribuera den tidigare stabila versionen, var utanför omfånget för det här åtagandet. Godkännandegrindar finns för varje steg. Varje grind begär distributionsgodkännande.

Haveriberedskap

Lösningen använder Terraform-skript och Azure Pipelines för alla tjänster. Om ett haveri inträffar kan Contoso Bank återskapa hela miljön med hjälp av Terraform-skript eller genom att köra versionspipelinen igen. Terraform förstår att miljön har ändrats och återskapat den. Lösningen etablerar och förstör infrastrukturen i Azure dynamiskt efter behov. Lagringskonton är zonredundant lagring (ZRS). En säkerhetskopieringsstrategi låg utanför omfånget för det här åtagandet.

Säkerhet och sekretess

• Ett privat register (Azure Container Registry) lagrade alla containeravbildningar.

• Lösningen använder ARO- och AKS-hemligheter för att mata in känsliga data i poddar, till exempel anslutningssträng och nycklar.

• Åtkomst till Kubernetes API-server kräver autentisering via Microsoft Entra-ID för ARO och AKS.

• Åtkomst till Jenkins kräver autentisering via Microsoft Entra-ID.

Slutsatser

I slutet av projektet delade CSE-teamet med sig av följande insikter:

• Lösnings- och engagemangsresultat

  • Teamet observerade en hög kompatibilitetsnivå mellan AKS och ARO för distribution av tjänster.

  • Application Insights Codeless gör det enklare att skapa observerbarhet och samarbeta med molnimplementeringen vid lift-and-shift-migreringar.

  • Belastningstestning är en viktig del av storskaliga lösningar och kräver tidigare analys och planering för att ta hänsyn till mikrotjänstspecifika egenskaper.

  • Belastningstestningspotentialen för att hitta biverkningar av mikrotjänster underskattas ofta av kunderna.

  • Att skapa en testmiljö kan kräva en strategi för borttagning av infrastruktur för att undvika onödiga infrastrukturkostnader.

• Viktiga lärdomar

  • Det finns en smidig programmigrering från ARO till AKS.

  • Funktionen för automatisk skalning av noder var inte tillgänglig på Red Hat OpenShift version 3.11, som var den version som användes under åtagandet. Därför utförde CSE-teamet testscenarier för automatisk skalning av noder via AKS.

  • En produkts livslängd kan kräva kreativa anpassningar. En förberedelsefas spelar en viktig roll när teamet levererar en lyckad lösning.

  • När den här artikeln skapades skapade CSE-teamet en lösning för belastningstestning som integrerar containerinstanser och JMeter i en Azure DevOps-pipeline. Azure Load Testing har sedan dess gjorts tillgängligt som en fullständigt hanterad belastningstestningstjänst utan att ytterligare beräkningsresurser behöver distribueras.

  • Teamet rekommenderade användning av Azure-händelsehubbar för Kafka, men för Contoso Bank var schemaregistret en viktig funktion. För att ta hand om Contoso Bank inom den begärda tidsramen var teamet tvunget att överväga användningen av schemaregistret i en annan instans av AKS.

  • Kafka-protokollet med Schema Registry stöds inte av Event Hubs Scaler i KEDA.

Nästa steg

• Autoskalning av Java-program med KEDA med Azure Event Hubs: KEDA för Java-exempel

• Mönster: Saga: Information om Saga-mönstret på Microservices.io

Relaterade resurser

Mer information om de processer och tekniker som används för att skapa den här lösningen finns i följande artiklar:

• Mönster och implementeringar