Este artigo aborda os padrões e as implementações que a equipe de CSE (engenharia de software comercial) usou ao criar a transformação de nuvem para o sistema de serviços bancários no Azure.
Arquitetura
Arquitetura do Saga
Baixe um Arquivo Visio dessa arquitetura.
Fluxo de dados
O Contoso Bank tinha uma implementação local de um Saga baseado em orquestração. Na implementação, o orquestrador é uma FSM (máquina de estado finito). A equipe de CSE identificou os seguintes desafios no design de arquitetura:
Sobrecarga de implementação e complexidade no orquestrador com estado para lidar com gerenciamento de estados, tempos limite e reinicializações em cenários de falha.
Mecanismos de observabilidade para acompanhar os estados do fluxo de trabalho do Saga por solicitação de transação.
A solução proposta abaixo é uma implementação de padrão do Saga por meio de uma abordagem de orquestração usando uma arquitetura sem servidor no Azure. Ela aborda os desafios usando:
O Azure Functions para a implementação de participantes do Saga.
O Azure Durable Functions para orquestração, projetado para fornecer o modelo de programação de fluxo de trabalho e o gerenciamento de estado.
Os Hubs de Eventos do Azure como a plataforma de streaming de dados.
O Azure Cosmos DB como o serviço de banco de dados para armazenar modelos de dados.
Para obter mais informações, confira Padrão: Saga em Microservices.io.
Padrão do Saga
O Saga é um padrão adequado para o gerenciamento de transações distribuídas, normalmente aplicado aos serviços financeiros. Um novo cenário surgiu, em que as operações são distribuídas entre aplicativos e bancos de dados. No novo cenário, os clientes precisarão ter uma nova arquitetura e um design de implementação para garantir a consistência dos dados em transações financeiras.
A abordagem tradicional de propriedades ACID (atomicidade, consistência, isolamento e durabilidade) não é mais adequada. Isso porque os dados de operações agora estão distribuídos em bancos de dados isolados. O uso de um padrão do Saga resolve esse desafio pela coordenação de um fluxo de trabalho por meio de uma sequência controlada por mensagens de transações locais visando garantir a consistência dos dados.
Arquitetura do KEDA
Baixe um Arquivo Visio dessa arquitetura.
Para obter mais informações sobre os dimensionadores do KEDA, confira os seguintes documentos do KEDA:
Gatilho dos Hubs de Eventos do Azure: compatibilidade para leitura do URI do armazenamento de blobs do Azure para aplicativos Java. Ele usa o SDK do Host do Processador de Eventos, permitindo a capacidade de escalar consumidores Java que leem mensagens do protocolo AMQP (Advanced Message Queuing Protocol) por meio dos Hubs de Eventos. Anteriormente, o dimensionador dos Hubs de Eventos funcionava apenas com o Azure Functions.
Gatilho de tópico do Apache Kafka: suporte para autenticação simples SASL_SSL, permitindo a capacidade de escalar consumidores Java que leem mensagens do protocolo Kafka por meio dos Hubs de Eventos.
Workflow
A equipe de CSE implantou o aplicativo no cluster do AKS (Serviço de Kubernetes do Azure). A solução precisava escalar horizontalmente o aplicativo de modo automático com base na contagem de mensagens de entrada. A equipe de CSE usou um dimensionador do Kafka para detectar se a solução devia ativar ou desativar a implantação do aplicativo. O dimensionador do Kafka também alimenta métricas personalizadas de uma origem de evento específica. A origem do evento 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 vertical automática dos pods ocorre quando o número de mensagens na origem do evento está abaixo do valor limite.
A equipe de CSE usou o gatilho de tópico do Apache Kafka. Ele oferece à solução a capacidade de escalar o serviço Processador de TEF se o processo excede o número máximo de mensagens consumidas em um intervalo.
KEDA com suporte a Java
O KEDA (Dimensionador Automático Orientado a Eventos do Kubernetes) determina como a solução deve escalar qualquer contêiner no Kubernetes. A decisão é baseada no número de eventos que ela precisa processar. O KEDA, que tem diferentes tipos de dimensionadores, dá suporte a vários tipos de cargas de trabalho, dá suporte ao Azure Functions e é independente de fornecedor. Acesse Dimensionamento automático de aplicativos Java com o KEDA usando os Hubs de Eventos do Azure para explorar um exemplo funcional.
Arquitetura do teste de carga
Baixe um Arquivo Visio dessa arquitetura.
A solução usa scripts do Teste de Carga do Azure com JMeter (JMX). O Teste de Carga do Azure é um serviço de teste de carga totalmente gerenciado que permite gerar cargas 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.
Workflow
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 se integrar ao 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 gerais no setor bancário, ao migrar para a nuvem.
Próximas etapas
Saiba mais sobre as tecnologias dos componentes:
- Introdução ao Azure Functions
- 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(a) ao Azure Cosmos DB
Recursos relacionados
Explorar arquiteturas relacionadas: