Este artigo aborda os padrões e implementações que a equipe de engenheiro de software comercial (CSE) usou quando criou a transformação na nuvem do sistema bancário no Azure.
Arquitetura
Arquitetura Saga
Transfira um ficheiro do Visio desta arquitetura.
Fluxo de dados
O Contoso Bank tinha uma implementação local de uma saga baseada em orquestração. Na sua implementação, o orquestrador é uma máquina de estado finito (FSM). A equipe do CSE identificou os seguintes desafios no projeto de arquitetura:
Sobrecarga de implementação e complexidade no orquestrador stateful para lidar com gerenciamento de estados, tempos limite e reinicializações em cenários de falha.
Mecanismos de observabilidade para rastrear os estados do fluxo de trabalho da saga por solicitação de transação.
A solução proposta abaixo é uma implementação de padrão de saga por meio de uma abordagem de orquestração usando uma arquitetura sem servidor no Azure. Aborda os desafios utilizando:
Azure Functions para a implementação de participantes da saga.
Azure Durable Functions para orquestração, projetado para fornecer o modelo de programação de fluxo de trabalho e gerenciamento de estado.
Hubs de Eventos do Azure como a plataforma de streaming de dados.
Azure Cosmos DB como o serviço de banco de dados para armazenar modelos de dados.
Para obter mais informações, consulte Pattern: Saga on Microservices.io.
Padrão Saga
Saga é um padrão adequado para o gerenciamento de transações distribuídas, comumente aplicado a serviços financeiros. Surgiu um novo cenário em que as operações são distribuídas entre aplicativos e bancos de dados. No novo cenário, os clientes precisarão de uma nova arquitetura e design de implementação para garantir a consistência dos dados sobre as transações financeiras.
A abordagem tradicional de propriedades de atomicidade, consistência, isolamento e durabilidade (ACID) não é mais adequada. Isso ocorre porque os dados das operações agora são estendidos em bancos de dados isolados. O uso de um padrão de saga aborda esse desafio coordenando um fluxo de trabalho por meio de uma sequência orientada por mensagem de transações locais para garantir a consistência dos dados.
Arquitetura KEDA
Transfira um ficheiro do Visio desta arquitetura.
Para obter mais informações sobre escaladores KEDA, consulte os seguintes documentos KEDA:
Azure Event Hubs Trigger: Compatibilidade para ler o URI de armazenamento de blob do Azure para aplicativos Java. Ele usa o Event Processor Host SDK, permitindo a capacidade de dimensionar consumidores Java que leem mensagens do protocolo AMQP (Advanced Message Queuing Protocols) de Hubs de Eventos. Anteriormente, o dimensionador de Hubs de Eventos funcionava apenas com o Azure Functions.
Apache Kafka topic trigger: Suporte para autenticação SASL_SSL simples, permitindo a capacidade de dimensionar consumidores Java que leem mensagens do protocolo Kafka de Hubs de Eventos.
Fluxo de Trabalho
A equipe CSE implantou o aplicativo no cluster do Serviço Kubernetes do Azure (AKS). A solução necessária para expandir o aplicativo automaticamente com base na contagem de mensagens recebidas. A equipe do CSE usou um escalador Kafka para detetar se a solução deveria ativar ou desativar a implantação do aplicativo. O escalador Kafka também alimenta métricas personalizadas para uma fonte de evento específica. A fonte de eventos neste exemplo é um hub de eventos do Azure.
Quando o número de mensagens no hub de eventos do Azure excede um limite, o KEDA aciona os pods para dimensionamento, aumentando o número de mensagens processadas pelo aplicativo. A redução automática dos pods ocorre quando o número de mensagens na fonte do evento fica abaixo do valor limite.
A equipe do CSE usou o gatilho de tópico Apache Kafka. Ele dá à solução a capacidade de dimensionar o serviço de processador EFT se o processo excedeu o número máximo de mensagens consumidas em um intervalo.
KEDA com suporte Java
O Kubernetes Event-driven Autoscaler (KEDA) determina como a solução deve dimensionar qualquer contêiner dentro do Kubernetes. A decisão é baseada no número de eventos que precisa processar. O KEDA, que tem diferentes tipos de escaladores, dá suporte a vários tipos de cargas de trabalho, dá suporte ao Azure Functions e é independente do fornecedor. Vá para Autoscaling Java applications with KEDA using Azure Event Hubs para explorar um exemplo de trabalho.
Arquitetura de teste de carga
Transfira um ficheiro do Visio desta arquitetura.
A solução usa scripts do Azure Load Testing with JMeter (JMX). O Teste de Carga do Azure é um serviço de teste de carga totalmente gerenciado que permite gerar carga de alta escala. O serviço simula o tráfego para seus aplicativos, independentemente de onde eles estão hospedados e pode utilizar scripts JMeter existentes.
Fluxo de Trabalho
O Teste de Carga do Azure permite que você crie manualmente testes de carga usando o portal do Azure ou a CLI do Azure. Como alternativa, você pode configurar um pipeline de CI/CD para integrar com o Teste de Carga do Azure. Isso permite automatizar um teste de carga para validar continuamente o desempenho e a estabilidade do aplicativo como parte do fluxo de trabalho de CI/CD.
- Entenda como o Teste de Carga do Azure funciona criando e executando um teste de carga.
- Use scripts JMeter novos ou existentes e configure seu fluxo de trabalho de CI/CD para executar testes de carga.
Detalhes do cenário
Esse cenário ajuda você a entender melhor os padrões e implementações de visão geral no setor bancário ao migrar para a nuvem.
Próximos passos
Saiba mais sobre as tecnologias de componentes:
- Introdução às Funções do Azure
- O que são Durable Functions?
- Hubs de Eventos do Azure — Uma plataforma de streaming de big data e um serviço de ingestão de eventos
- Bem-vindo ao Azure Cosmos DB
Recursos relacionados
Explore arquiteturas relacionadas: