Patrones e implementaciones para una transformación de la nube en el sector bancario

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

En este artículo se describen los patrones y las implementaciones que el equipo de ingenieros de software comercial (CSE) ha usado al crear la transformación en la nube del sistema bancario en Azure.

Architecture

Arquitectura de saga

Saga basado en orquestación en la arquitectura sin servidor

Descargue un archivo Visio de esta arquitectura.

Flujo de datos

Contoso Bank tenía una implementación local de un patrón saga basado en orquestación. En su implementación, el orquestador es una máquina de estados finitos (FSM). El equipo de CSE identificó los desafíos siguientes en el diseño de la arquitectura:

  • Sobrecarga y complejidad de implementación en el orquestador con estado para controlar la administración de estados, los tiempos de espera y los reinicios en escenarios de error.

  • Mecanismos de observabilidad para realizar el seguimiento de los estados de flujos de trabajo de saga por solicitud de transacción.

La solución propuesta a continuación es una implementación de patrón saga a través de un enfoque de orquestación que usa una arquitectura sin servidor en Azure. Aborda los desafíos mediante lo siguiente:

  • Azure Functions para la implementación de los participantes de saga.

  • Azure Durable Functions para la orquestación, diseñada con el objetivo de proporcionar el modelo de programación de flujo de trabajo y la administración de estado.

  • Azure Event Hubs como la plataforma de streaming de datos.

  • Azure Cosmos DB como el servicio de base de datos para almacenar modelos de datos.

Para más información, consulte Pattern: saga en Microservices.io.

Patrón saga

Saga es un patrón adecuado para la administración de transacciones distribuidas, que se aplica normalmente a los servicios financieros. Ha surgido un nuevo escenario en el que las operaciones se distribuyen entre las aplicaciones y las bases de datos. En el escenario nuevo, los clientes necesitarán un nuevo diseño de arquitectura e implementación para garantizar la coherencia de los datos en las transacciones financieras.

El enfoque de propiedades tradicional Atomicidad, coherencia, aislamiento y durabilidad (ACID) ya no es adecuado. Se debe a que los datos de las operaciones ahora se distribuyen en bases de datos aisladas. El uso de un patrón saga soluciona este desafío mediante la coordinación de un flujo de trabajo a través de una secuencia controlada por mensajes de transacciones locales para garantizar la coherencia de los datos.

Arquitectura KEDA

Escalado automático del procesador EFT con el desencadenador del tema Kafka de KEDA

Descargue un archivo Visio de esta arquitectura.

Para obtener más información sobre los escaladores KEDA, vea los documentos siguientes de KEDA:

  • Desencadenador de Azure Event Hubs: compatibilidad para leer el URI del almacenamiento de blobs de Azure para aplicaciones Java. Usa el SDK del Host del procesador de eventos, lo que permite escalar a los consumidores de Java que leen los mensajes del protocolo Advanced Message Queuing Protocol (AMQP) de Event Hubs. Anteriormente, el escalador de Event Hubs solo funcionaba con Azure Functions.

  • Desencadenador del tema Apache Kafka: compatibilidad con la autenticación sin formato SASL_SSL, lo que permite escalar a los consumidores de Java que leen los mensajes del protocolo Kafka de Event Hubs.

Flujo de trabajo

  1. El equipo de CSE ha implementado la aplicación en el clúster de Azure Kubernetes Service (AKS). La solución necesitaba escalar horizontalmente la aplicación de forma automática en función del número de mensajes entrantes. El equipo de CSE ha usado un escalador de Kafka para detectar si la solución debe activar o desactivar la implementación de la aplicación. El escalador de Kafka también suministra métricas personalizadas para un origen del evento específico. El origen del evento en este ejemplo es un centro de eventos de Azure.

  2. Cuando el número de mensajes del centro de eventos de Azure supera un umbral, KEDA desencadena los pods que se van a escalar horizontalmente, lo que aumenta el número de mensajes que procesa la aplicación. La reducción vertical automática de los pods se produce cuando el número de mensajes del origen del evento cae por debajo del valor del umbral.

  3. El equipo de CSE ha usado el desencadenador del tema Apache Kafka. Proporciona a la solución la capacidad de escalar el servicio del procesador EFT si el proceso supera el número máximo de mensajes consumidos en un intervalo.

KEDA con compatibilidad con Java

El escalador automático basado en eventos de Kubernetes (KEDA) determina cómo la solución debe escalar cualquier contenedor en Kubernetes. La decisión se basa en el número de eventos que necesita procesar. KEDA, que tiene diferentes tipos de escaladores, admite varios tipos de cargas de trabajo, admite Azure Functions y es independiente del proveedor. Vaya a Escalado automático de aplicaciones Java con KEDA mediante Azure Event Hubs para explorar un ejemplo en funcionamiento.

Arquitectura de la prueba de carga

Canalización de pruebas de carga con JMeter y Azure Load Testing

Descargue un archivo Visio de esta arquitectura.

La solución usa Azure Load Testing con scripts de JMeter (JMX). Azure Load Testing es un servicio de prueba de carga totalmente administrado que permite generar una carga a gran escala. El servicio simula el tráfico de las aplicaciones, independientemente de dónde estén alojadas, y puede utilizar los scripts de JMeter existentes.

Flujo de trabajo

Azure Load Testing permite crear manualmente pruebas de carga mediante Azure Portal o la CLI de Azure. Como alternativa, puede configurar una canalización de CI/CD para integrarla con Azure Load Testing. Esto le permite automatizar una prueba de carga para validar continuamente el rendimiento y la estabilidad de la aplicación como parte del flujo de trabajo de CI/CD.

  1. Comprenda cómo funciona Azure Load Testing mediante la creación y ejecución de una prueba de carga.
  2. Use scripts de JMeter nuevos o existentes y configure el flujo de trabajo de CI/CD para ejecutar pruebas de carga.

Detalles del escenario

Este escenario ayuda a comprender mejor los patrones e implementaciones generales en el sector bancario al pasar a la nube.

Pasos siguientes

Más información sobre las tecnologías de los componentes:

Explore las arquitecturas relacionadas: