Este exemplo de arquitetura é construído sobre a arquitetura de integração corporativa básica. Ele estende essa arquitetura para mostrar como integrar sistemas de back-end corporativos, usando agentes de mensagens e eventos para dissociar serviços para maior escalabilidade e confiabilidade. Certifique-se de estar familiarizado com esse design e os componentes usados na arquitetura de integração básica. Ele fornece informações fundamentais sobre os principais componentes dessa arquitetura, que não serão reproduzidas 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.
Transfira um ficheiro do Visio desta arquitetura.
Fluxo de trabalho
A arquitetura mostrada aqui se baseia em uma arquitetura mais simples que é mostrada na integração corporativa básica. Essa arquitetura usa aplicativos lógicos para orquestrar fluxos de trabalho diretamente com sistemas de back-end 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 escalável:
Barramento de Serviço do Azure. O Service Bus é um agente de mensagens seguro e confiável.
Grade de Eventos do Azure. A Grade de Eventos é um serviço de roteamento de eventos. Ele usa um modelo de evento de publicação/assinatura (pub/sub).
A comunicação assíncrona usando um agente de mensagens oferece as seguintes vantagens em relação à realização de chamadas diretas e síncronas para serviços de back-end:
- Fornece nivelamento de carga para lidar com picos em cargas de trabalho, usando o padrão de Nivelamento de Carga Baseado em Fila.
- Fornece a transmissão de mensagens para vários consumidores usando o padrão Editor-Assinante.
- Rastreia de forma confiável o progresso de fluxos de trabalho de longa execução que envolvem várias etapas ou vários aplicativos.
- Ajuda a dissociar aplicações.
- Integra-se com sistemas baseados em mensagens existentes.
- Permite que o trabalho seja enfileirado quando um sistema de back-end não está disponível.
A Grade de Eventos permite que os vários componentes do sistema reajam aos eventos à medida que eles acontecem, em vez de depender de sondagens ou tarefas agendadas. Tal como acontece com uma fila de mensagens e tópicos, ajuda a dissociar aplicações e serviços. Uma aplicação ou serviço pode publicar eventos e todos os subscritores interessados serão notificados. Novos assinantes podem ser adicionados sem atualizar o remetente.
Muitos serviços do Azure suportam o envio de eventos para a Grelha de Eventos. Por exemplo, um aplicativo lógico pode escutar um evento quando novos arquivos são adicionados a um repositório de blobs. Esse padrão permite fluxos de trabalho reativos, onde carregar um arquivo ou colocar uma mensagem em uma fila dá início a uma série de processos. Os processos podem ser executados em paralelo ou numa sequência específica.
Recomendações
As recomendações descritas em Integração empresarial básica aplicam-se a esta arquitetura.
Service Bus
O Service Bus tem dois modos de entrega, pull ou proxy push. No modelo pull, o recetor sonda continuamente novas mensagens. A sondagem pode ser ineficiente, especialmente se você tiver muitas filas que recebem algumas mensagens ou se houver muito tempo entre as mensagens. No modelo de push por proxie, o Service Bus envia um evento por meio da Grade de Eventos quando há novas mensagens. O recetor subscreve o evento. Quando o evento é acionado, o recetor extrai o próximo lote de mensagens do Service Bus.
Quando você cria um aplicativo lógico para consumir mensagens do Service Bus, recomendamos o uso do modelo de push por proxy com integração de Grade de Eventos. Muitas vezes, é mais econômico, porque o aplicativo lógico não precisa sondar o Service Bus. Para obter mais informações, consulte Visão geral da integração do Barramento de Serviço do Azure para a Grade de Eventos. Atualmente, a camada Premium do Service Bus é necessária para notificações de Grade de Eventos.
Use PeekLock para acessar um grupo de mensagens. Quando você usa PeekLock, o aplicativo lógico pode executar etapas para validar cada mensagem antes de concluir ou abandonar a mensagem. Esta abordagem protege contra a perda acidental de mensagens.
Event Grid
Quando um gatilho de Grade de Eventos é acionado, isso significa que pelo menos um evento aconteceu. Por exemplo, quando um aplicativo lógico recebe um gatilho de Grade de Eventos para uma mensagem do Service Bus, ele deve assumir que várias mensagens podem estar disponíveis para processamento.
Considerações
Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser usados para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.
Fiabilidade
A confiabilidade garante que seu aplicativo possa atender aos compromissos que você assume com seus clientes. Para obter mais informações, consulte Visão geral do pilar de confiabilidade.
- Microsoft Entra ID: O Microsoft Entra ID é uma plataforma SaaS distribuída globalmente e altamente disponível. Consulte o SLA para obter detalhes de disponibilidade garantida.
- Gerenciamento de API: o Gerenciamento de API pode ser implantado em várias configurações altamente disponíveis, de acordo com os requisitos de negócios e tolerância de custo. Consulte Garantir disponibilidade e confiabilidade do Gerenciamento de API para obter uma revisão completa das opções. Consulte também o SLA para obter detalhes de disponibilidade garantida.
- Aplicativos lógicos: o armazenamento com redundância geográfica está disponível para aplicativos lógicos na camada do plano de consumo. Para obter informações sobre como projetar uma solução de continuidade de negócios e recuperação de desastres, consulte as orientações. Consulte também o SLA para obter detalhes de disponibilidade garantida.
- Grade de Eventos: as definições de recursos da Grade de Eventos para tópicos, tópicos do sistema, domínios e assinaturas de eventos e dados de eventos são replicadas automaticamente em três zonas de disponibilidade (quando disponíveis) na região. Quando há uma falha em uma das zonas de disponibilidade, os recursos da Grade de Eventos fazem failover automaticamente para outra zona de disponibilidade sem qualquer intervenção humana. Consulte a Recuperação de desastres geográficos entre regiões para obter orientações sobre como projetar uma solução de recuperação de desastres para failover em outra região. Consulte também o SLA para obter detalhes de disponibilidade garantida.
- Barramento de serviço: o Service Bus Premium suporta recuperação de desastres geográficos e zonas de disponibilidade. A replicação está disponível para o Service Bus Standard. Consulte também o SLA para obter detalhes de disponibilidade garantida.
Segurança
A segurança oferece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte Visão geral do pilar de segurança.
Para proteger o Service Bus, use a autenticação do Microsoft Entra emparelhada com identidades gerenciadas. A integração do Microsoft Entra para recursos do Service Bus fornece o RBAC (controle de acesso baseado em função) do Azure para controle refinado sobre o acesso de um cliente aos recursos. Você pode usar o RBAC do Azure para conceder permissões a uma entidade de segurança, que pode ser um usuário, um grupo ou uma entidade de serviço de aplicativo (uma identidade gerenciada, neste caso).
Quando o Microsoft Entra ID não estiver disponível, você poderá usar a assinatura de acesso compartilhado (SAS). Você pode conceder a um usuário acesso a recursos do Service Bus com direitos específicos usando a autenticação SAS.
Se você precisar expor uma fila ou tópico do Service Bus como um ponto de extremidade HTTP, por exemplo, para postar novas mensagens, use o Gerenciamento de API para proteger a fila frontando o ponto de extremidade. Em seguida, você pode proteger 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 Grade de Eventos protege a entrega de eventos por meio de um código de validação. Se você usar Aplicativos Lógicos para consumir o evento, a validação será executada automaticamente. Para obter mais informações, consulte Segurança e autenticação da grade de eventos.
Segurança da rede
A segurança da rede deve ser considerada durante todo o projeto.
- O Service Bus Premium pode ser vinculado a um ponto de extremidade de serviço de sub-rede de rede virtual (VNet), protegendo o namespace para aceitar apenas tráfego de redes virtuais autorizadas. Além disso, use pontos de extremidade privados para bloquear seu tráfego de rede virtual para tráfego privado no Private Link.
- Os Aplicativos Lógicos Standard e Premium Logic Apps podem ser configurados para aceitar tráfego de entrada por meio de pontos de extremidade privados e enviar tráfego de saída por meio da integração VNet.
- O Gerenciamento de API fornece várias opções para proteger o acesso à sua instância de Gerenciamento de API e APIs usando uma rede virtual do Azure. Consulte a documentação Usar uma rede virtual com o Gerenciamento de API do Azure para obter uma revisão completa das opções. Pontos de extremidade privados também são suportados.
Otimização de Custos
A otimização de custos consiste em procurar formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Visão geral do pilar de otimização de custos.
No geral, utilize a calculadora de preços do Azure para prever os custos. Aqui estão algumas outras considerações.
Gestão de API
Você será cobrado por todas as instâncias de Gerenciamento de API quando elas estiverem em execução. Se você aumentou a escala e não precisa desse nível de desempenho o tempo todo, reduza manualmente ou configure o dimensionamento automático.
Para cargas de trabalho de uso leve, considere a camada de consumo, que é uma opção de baixo custo e sem servidor. A camada de consumo é cobrada por chamada de API, enquanto as outras camadas são cobradas por hora.
Aplicações Lógicas
O Logic Apps usa um modelo sem servidor. O faturamento é calculado com base na ação e na execução do conector. Para obter mais informações, veja os preços do Logic Apps.
Filas, tópicos e assinaturas do Barramento de Serviço
As filas e assinaturas do Barramento de Serviço oferecem suporte a modelos de push e pull por proxy para entrega de mensagens. No modelo pull, cada solicitação de sondagem é medida como uma ação. Mesmo com sondagens longas de 30 segundos (padrão), o custo pode ser alto. A menos que você precise de entrega de mensagens em tempo real, considere usar o modelo de envio por proxie.
As filas do Barramento de Serviço estão incluídas em todos os níveis (básico, padrão e premium). Enquanto os tópicos e assinaturas do Service Bus estão disponíveis nos níveis padrão e premium. Para obter mais informações, consulte Preços do Barramento de Serviço do Azure.
Event Grid
A Grade de Eventos usa um modelo sem servidor. O faturamento é calculado com base no número de operações (execuções de eventos). As operações incluem a entrada de eventos em Domínios ou Tópicos, correspondências avançadas, tentativas de entrega e chamadas de gestão. O uso de até 100.000 operações é gratuito.
Para obter mais informações, consulte Preços da grade de eventos.
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 Basic Enterprise Integration fornece orientação sobre padrões de DevOps, que se alinham ao pilar de Excelência Operacional da Well-Architected Framework.
Automatizar ao máximo as operações de recuperação é um componente integral da Excelência Operacional. Com a automação em mente, você pode combinar o Monitoramento de Log do Azure com a Automação do Azure para automatizar o failover dos recursos do Service Bus. Consulte o diagrama na documentação de fluxo de failover para obter um exemplo de lógica de automação para iniciar um failover.
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, consulte Visão geral do pilar de eficiência de desempenho.
Para obter maior escalabilidade, a camada Premium do Service Bus pode expandir o número de unidades de mensagens. Consulte a documentação dos níveis de mensagens Premium e Standard do Service Bus para obter uma revisão dos benefícios do nível Premium. Além disso, consulte a documentação do recurso de dimensionamento automático para saber mais sobre como configurar o dimensionamento automático de unidades de mensagens.
Mais recomendações para o Service Bus podem ser encontradas em Práticas recomendadas para melhorias de desempenho usando o Service Bus Messaging.
Próximos passos
Para obter mais informações, consulte a documentação do Service Bus:
- Visão geral da integração do Barramento de Serviço do Azure para a Grade de Eventos
- Escalões de mensagens Standard e Premium do Service Bus
- Recurso de dimensionamento automático do Service Bus
- Práticas recomendadas para melhorias de desempenho usando o Service Bus Messaging