Integração empresarial usando filas e eventos

Grade de Eventos
Barramento de Serviço

Essa arquitetura de referência integra sistemas de back-end corporativos usando filas de mensagens e eventos para separar os serviços e fornecer mais escalabilidade e confiabilidade. Os sistemas de back-end podem incluir sistemas SaaS (software como serviço), serviços do Azure e serviços da Web existentes em sua empresa.

Arquitetura de referência para integração empresarial com filas e eventos

Arquitetura

A arquitetura mostrada aqui se baseia em uma arquitetura mais simples, mostrada em Integração empresarial básica. Essa arquitetura usa os Aplicativos Lógicos para orquestrar fluxos de trabalho, e Gerenciamento de API para criar catálogos de APIs.

Esta versão da arquitetura adiciona dois componentes que ajudam a tornar o sistema mais confiável e escalonável:

A comunicação assíncrona usando um agente de mensagens oferece inúmeras vantagens em relação às chamadas síncronas, diretas aos serviços de back-end:

  • Ela fornece o nivelamento de carga para lidar com intermitências nas cargas de trabalho, usando o padrão de nivelamento de carga baseado em fila.
  • Acompanhe de forma confiável o progresso de fluxos de trabalho de longa execução que envolvem vários aplicativos ou várias etapas.
  • Ajuda a separar os aplicativos.
  • Integra-se com sistemas existentes baseados em mensagens.
  • Permite o enfileiramento do trabalho quando um sistema de back-end não estiver disponível.

A Grade de Eventos permite que os vários componentes no sistema reaja a eventos conforme eles acontecem, em vez de depender de tarefas agendadas ou de sondagem. Assim como acontece com uma fila de mensagens, ela ajuda a separar aplicativos e serviços. Um aplicativo ou serviço pode publicar eventos, e os assinantes interessados receberão uma notificação. É possível adicionar novos assinantes sem atualizar o remetente.

Muitos serviços do Azure dão suporte ao envio de eventos à Grade de Eventos. Por exemplo, um aplicativo lógico pode escutar um evento quando novos arquivos são adicionados a um armazenamento de blobs. Esse padrão permite fluxos de trabalho reativos, nos quais o carregamento de um arquivo ou posicionamento de uma mensagem em uma fila dá início a uma série de processos. Os processos podem ser executados em paralelo ou em uma sequência específica.

Recomendações

As recomendações descritas em Integração corporativa básica se aplicam a essa arquitetura. As seguintes recomendações também se aplicam ao:

Barramento de Serviço

O Barramento de Serviço tem dois modos de entrega, pull ou push. No modelo de pull, o receptor faz uma sondagem contínua em busca de novas mensagens. A sondagem pode ser ineficiente, especialmente se você tiver várias filas, com cada uma recebendo algumas mensagens, ou se houver muito tempo entre as mensagens. No modelo de push, o Barramento de Serviço envia um evento por meio da Grade de Eventos quando há novas mensagens. O receptor assina o evento. Quando o evento é disparado, o receptor efetua o pull do próximo lote de mensagens do Barramento de Serviço.

Quando você cria um aplicativo lógico para consumir mensagens do Barramento de Serviço, recomendamos o uso do modelo de push com a integração da Grade de Eventos. Geralmente, isso é mais econômico, porque o aplicativo lógico não precisa sondar o Barramento de Serviço. Para saber mais, confira Visão geral da integração do Barramento de Serviço do Azure com a Grade de Eventos. Atualmente, a camada Premium do Barramento de Serviço é exigida para notificações da Grade de Eventos.

Use PeekLock para acessar um grupo de mensagens. Ao usar o PeekLock pode executar etapas para validar cada mensagem antes de concluir ou abandonar a mensagem. Essa abordagem protege contra a perda acidental de mensagens.

Grade de Eventos

Quando um gatilho da Grade de Eventos é acionado, significa que pelo menos um evento aconteceu. Por exemplo, quando um aplicativo lógico recebe um gatilho da Grade de Eventos para uma mensagem do Barramento de Serviço, ele deve supor que há várias mensagens disponíveis para processar.

Considerações sobre escalabilidade

Para obter maior escalabilidade, a camada Premium do Barramento de Serviço pode aumentar o número de unidades do sistema de mensagens. Configurações de camada Premium podem ter um, dois ou quatro unidades de mensagens. Para saber mais informações sobre escalonar Barramento de Serviço, consulte Práticas recomendadas para melhorias de desempenho usando o Sistema de Mensagens do Barramento de Serviço.

Considerações sobre disponibilidade

Examine o SLA para cada serviço:

Para habilitar o failover em caso de uma interrupção grave, considere implementar a recuperação de desastre geográfico no Barramento de Serviço Premium. Para obter mais informações, consulte recuperação de desastre geográfico do barramento de serviço do Azure.

Considerações de DevOps

Consulte as considerações de DevOps na arquitetura de referência de Enterprise Integration básica

Considerações de segurança

Para proteger o Barramento de Serviço, use a SAS (Assinatura de Acesso Compartilhado). É possível conceder a um usuário acesso aos recursos do Barramento de Serviço com direitos específicos usando a autenticação SAS. Para saber mais, confira Autenticação e autorização do barramento de Serviço.

Se for necessário expor uma fila do Barramento de Serviço como um ponto de extremidade HTTP, por exemplo, para postar novas mensagens, use o Gerenciamento de API para proteger a fila administrando o ponto de extremidade. Em seguida, proteja o ponto de extremidade com certificados ou autenticação OAuth, conforme apropriado. A maneira mais fácil de proteger um ponto de extremidade é usando um aplicativo lógico com um gatilho de solicitação/resposta HTTP como intermediário.

O serviço da Grade de Eventos protege a entrega de eventos por meio de um código de validação. Se você usar os Aplicativos Lógicos para consumir o evento, a validação será realizada automaticamente. Para saber mais, confira Event Grid security and authentication (Segurança e autenticação da Grade de Eventos).

Considerações sobre custo

Em geral, use a calculadora de preços do Azure para estimar os custos. Aqui estão algumas outras considerações.

Gerenciamento de API

Você será cobrado por todas as instâncias de Gerenciamento de API quando estiverem em execução. Se você tiver escalado verticalmente e não precisar desse nível de desempenho o tempo todo, reduza verticalmente de forma manual ou configure o dimensionamento automático.

Aplicativos Lógicos

Os Aplicativos lógicos usam um modelo sem servidor. A cobrança é calculada com base na ação e execução do conector. Para obter mais informações, consulte Preços de Aplicativos Lógicos.

Filas do Barramento de Serviço

As filas do barramento de serviço dão suporte a modelos push e pull para entrega de mensagens. No modelo de pull, cada solicitação de sondagem é medida como uma ação. Mesmo com sondagem longa em 30 segundos (padrão), o custo pode ser alto. A menos que você precise de entrega em tempo real de mensagens, considere o uso do modelo de push.

As filas do barramento de serviço são incluídas em todas as camadas (camadas Basic, Standard e Premium). Para obter mais informações, consulte preços do barramento de serviço do Azure.

Grade de Eventos

A Grade de Eventos usam um modelo sem servidor. A cobrança é calculada com base no número de operações (execuções do evento). As operações incluem a entrada de eventos em domínios ou tópicos, correspondências avançadas, tentativas de entrega e chamadas de gerenciamento. O uso de até 100.000 operações é gratuito.

Consulte mais informações, consulte Preço da Grade de Eventos.

Para obter mais informações, confira a seção de custo em Estrutura Bem Projetada do Microsoft Azure.

Próximas etapas