Integração empresarial com o mediador de mensagens e eventos

Event Grid
Service Bus

Esta arquitetura de exemplo baseia-se na arquitetura de integração empresarial básica . Expande essa arquitetura para mostrar como integrar sistemas de back-end empresariais, utilizando mediadores de mensagens e eventos para desassociar os serviços para uma maior escalabilidade e fiabilidade. Certifique-se de que está familiarizado com essa estrutura e com os componentes utilizados na arquitetura de integração básica. Fornece informações fundamentais sobre os componentes principais desta arquitetura, que não serão reproduzidos aqui.

Arquitetura

Os sistemas de back-end referenciados neste design podem incluir sistemas SaaS (software como serviço), serviços do Azure e serviços Web existentes na sua empresa.

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

Transfira um ficheiro do Visio desta arquitetura.

Fluxo de trabalho

A arquitetura aqui mostrada baseia-se numa arquitetura mais simples que é mostrada na integração empresarial básica. Essa arquitetura utiliza o Logic Apps para orquestrar fluxos de trabalho diretamente com sistemas de back-end e Gestão de API para criar catálogos de APIs.

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

A comunicação assíncrona com um mediador de mensagens fornece as seguintes vantagens em fazer chamadas diretas e síncronas para serviços de back-end:

  • Fornece o nivelamento de carga para lidar com rajadas em cargas de trabalho, utilizando o padrão de Nivelamento de Carga Baseado em Filas.
  • Fornece a difusão de mensagens para vários consumidores através do padrão Publisher-Subscritor.
  • Monitoriza de forma fiável o progresso dos fluxos de trabalho de execução prolongada que envolvem vários passos ou várias aplicações.
  • Ajuda a desassociar aplicações.
  • Integra-se em sistemas baseados em mensagens existentes.
  • Permite que o trabalho seja colocado em fila quando um sistema de back-end não está disponível.

O Event Grid permite que os vários componentes do sistema reajam a eventos à medida que acontecem, em vez de dependerem de consultas ou tarefas agendadas. Tal como acontece com uma fila de mensagens e tópicos, ajuda a desassociar aplicações e serviços. Uma aplicação ou serviço pode publicar eventos e todos os subscritores interessados serão notificados. Os novos subscritores podem ser adicionados sem atualizar o remetente.

Muitos serviços do Azure suportam o envio de eventos para o Event Grid. Por exemplo, uma aplicação lógica pode escutar um evento quando são adicionados novos ficheiros a um arquivo de blobs. Este padrão permite fluxos de trabalho reativos, em que carregar um ficheiro ou colocar uma mensagem numa fila inicia uma série de processos. Os processos podem ser executados em paralelo ou numa sequência específica.

Recomendações

As recomendações descritas na integração empresarial básica aplicam-se a esta arquitetura.

Service Bus

O Service Bus tem dois modos de entrega, solicitação ou push proxied. No modelo Pull, o recetor procura continuamente novas mensagens. As consultas podem ser ineficientes, especialmente se tiver muitas filas que cada uma recebe algumas mensagens ou se houver muito tempo entre mensagens. No modelo push proxied, o Service Bus envia um evento através do Event Grid quando existem novas mensagens. O recetor subscreve o evento. Quando o evento é acionado, o recetor solicita o próximo lote de mensagens do Service Bus.

Quando cria uma aplicação lógica para consumir mensagens do Service Bus, recomendamos que utilize o modelo push proxied com a integração do Event Grid. Muitas vezes, é mais económica, porque a aplicação lógica não precisa de consultar o Service Bus. Para obter mais informações, veja Azure Service Bus descrição geral da integração do Event Grid. Atualmente, o escalão Premium do Service Bus é necessário para notificações do Event Grid.

Utilize PeekLock para aceder a um grupo de mensagens. Quando utiliza o PeekLock, a aplicação lógica pode executar passos para validar cada mensagem antes de concluir ou abandonar a mensagem. Esta abordagem protege contra perda acidental de mensagens.

Event Grid

Quando um acionador do Event Grid é acionado, significa que ocorreu pelo menos um evento. Por exemplo, quando uma aplicação lógica recebe acionadores do Event Grid para uma mensagem do Service Bus, deve assumir que várias mensagens podem estar disponíveis para processar.

Considerações

Estas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser utilizados para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, veja Microsoft Azure Well-Architected Framework.

Fiabilidade

A fiabilidade garante que a sua aplicação pode cumprir os compromissos que assumiu com os seus clientes. Para obter mais informações, veja Descrição geral do pilar de fiabilidade.

  • Azure AD: Azure AD é uma plataforma SaaS distribuída globalmente e de elevada disponibilidade. Veja o SLA para obter detalhes de disponibilidade garantidos.
  • Gestão de API: Gestão de API podem ser implementadas em várias configurações de elevada disponibilidade, de acordo com os requisitos empresariais e a tolerância a custos. Veja Garantir Gestão de API disponibilidade e fiabilidade para obter uma revisão completa das opções. Veja também o SLA para obter detalhes de disponibilidade garantidos.
  • Logic Apps: O armazenamento georredundante está disponível para o Logic Apps no escalão do Plano de consumo. Para obter informações sobre como conceber uma solução de continuidade de negócio e recuperação após desastre, veja a documentação de orientação. Veja também o SLA para obter detalhes de disponibilidade garantidos.
  • Event Grid: As definições de recursos do Event Grid para tópicos, tópicos de sistema, domínios e subscrições de eventos e dados de eventos são automaticamente replicadas em três zonas de disponibilidade (quando disponíveis) na região. Quando ocorre uma falha numa das zonas de disponibilidade, os recursos do Event Grid efetuam a ativação pós-falha automaticamente para outra zona de disponibilidade sem qualquer intervenção humana. Veja a Recuperação após desastre geográfico entre regiões para obter orientações sobre a conceção de uma solução de recuperação após desastre para efetuar a ativação pós-falha para outra região. Veja também o SLA para obter detalhes de disponibilidade garantidos.
  • Service Bus: O Service Bus Premium suporta recuperação após desastre geográfico e Zonas de Disponibilidade. A replicação está disponível para o Service Bus Standard. Veja também o SLA para obter detalhes de disponibilidade garantidos.

Segurança

A segurança fornece garantias contra ataques deliberados e abuso dos seus valiosos dados e sistemas. Para obter mais informações, veja Descrição geral do pilar de segurança.

Para proteger o Service Bus, utilize a autenticação do Azure Active Directory (Azure AD) emparelhada com identidades geridas. A integração do AAD para os recursos do Service Bus proporciona controlo de acesso baseado em funções (RBAC) para um controlo mais detalhado do acesso de um cliente aos recursos. Pode utilizar o RBAC do Azure para conceder permissões a um principal de segurança, que pode ser um utilizador, um grupo ou um principal de serviço de aplicação (uma identidade gerida neste caso).

Quando Azure AD não estiver disponível, pode utilizar a assinatura de acesso partilhado (SAS). Pode conceder a um utilizador acesso aos recursos do Service Bus com direitos específicos através da autenticação SAS.

Se precisar de expor uma fila ou tópico do Service Bus como um ponto final HTTP, por exemplo, para publicar novas mensagens, utilize Gestão de API para proteger a fila ao colocar o ponto final à frente. Em seguida, pode proteger o ponto final com certificados ou autenticação OAuth conforme adequado. A forma mais fácil de proteger um ponto final é utilizar uma aplicação lógica com um acionador de pedido/resposta HTTP como intermediário.

O serviço Event Grid protege a entrega de eventos através de um código de validação. Se utilizar o Logic Apps para consumir o evento, a validação é efetuada automaticamente. Para obter mais informações, veja Segurança e autenticação do Event Grid.

Segurança da rede

A segurança de rede deve ser considerada ao longo da estrutura.

Otimização de Custos

A otimização de custos consiste em analisar formas de reduzir as despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, veja Descrição geral do pilar de otimização de custos.

Em geral, utilize a calculadora de preços do Azure para estimar os custos. Seguem-se outras considerações.

Gestão de API

São-lhe cobradas todas as instâncias Gestão de API quando estão em execução. Se tiver aumentado verticalmente e não precisar sempre desse nível de desempenho, reduza verticalmente manualmente ou configure o dimensionamento automático.

Para cargas de trabalho de utilização leve, considere o escalão de consumo, que é uma opção de baixo custo e sem servidor. O escalão de consumo é faturado por chamada à API, enquanto os outros escalões são faturados por hora.

Logic Apps

O Logic Apps utiliza um modelo sem servidor . A faturação é calculada com base na execução da ação e do conector. Para obter mais informações, veja Preços do Logic Apps.

Filas, tópicos e subscrições do Service Bus

As filas e subscrições do Service Bus suportam modelos push e pull proxied para entregar mensagens. No modelo Pull, todos os pedidos de consulta são medidos como uma ação. Mesmo com consultas longas a 30 segundos (predefinição), o custo pode ser elevado. A menos que precise de entregar mensagens em tempo real, considere utilizar o modelo push proxied.

As filas do Service Bus estão incluídas em todos os escalões (escalões Básico, standard e premium). Enquanto os tópicos e subscrições do Service Bus estão disponíveis em escalões standard e premium. Para obter mais informações, veja Azure Service Bus preços.

Event Grid

O Event Grid utiliza um modelo sem servidor. A faturação é calculada com base no número de operações (execuções de eventos). As operações incluem a entrada de eventos para Domínios ou Tópicos, correspondências avançadas, tentativas de entrega e chamadas de gestão. A utilização de até 100 000 operações é gratuita.

Para obter mais informações, veja Preços do Event Grid.

Para obter mais informações, veja a secção de custos Well-Architected Framework do Microsoft Azure.

Excelência Operacional

A arquitetura de referência da Integração Empresarial Básica fornece orientações sobre padrões de DevOps, que se alinham com o pilar de Excelência Operacional do Well-Architected Framework.

Automatizar as operações de recuperação tanto quanto possível é um componente integral da Excelência Operacional. Com a automatização em mente, pode combinar a Monitorização de Registos do Azure com Automatização do Azure para automatizar a ativação pós-falha dos seus recursos do Service Bus. Veja o diagrama na documentação do fluxo de ativação pós-falha para obter um exemplo de lógica de automatização para iniciar uma ativação pós-falha.

Eficiência de desempenho

Eficiência de desempenho é a capacidade da sua carga de trabalho para dimensionar para satisfazer as exigências que os utilizadores lhe colocam de forma eficiente. Para obter mais informações, veja Descrição geral do pilar Eficiência do desempenho.

Para alcançar uma escalabilidade mais elevada, o escalão Premium do Service Bus pode aumentar horizontalmente o número de unidades de mensagens. Veja a documentação dos escalões de mensagens Premium e Standard do Service Bus para obter uma revisão dos benefícios do escalão Premium. Veja também a documentação da funcionalidade de dimensionamento automático para saber mais sobre como configurar o dimensionamento automático de unidades de mensagens.

Pode encontrar mais recomendações para o Service Bus nas Melhores práticas para melhorar o desempenho com as Mensagens do Service Bus.

Passos seguintes

Para obter mais informações, veja a documentação do Service Bus: