Essa arquitetura é baseada na arquitetura básica de integração empresarial, mas inclui como integrar sistemas back-end corporativos. Essa arquitetura usa agentes de mensagens e eventos para dissociar serviços para maior escalabilidade e confiabilidade. Certifique-se de estar familiarizado com o design e os componentes da arquitetura de integração básica. Esses elementos fornecem informações fundamentais sobre os componentes principais dessa arquitetura.
Arquitetura
Os sistemas back-end aos quais este design faz referência incluem sistemas SaaS (software como serviço), serviços do Azure, serviços baseados em mensagens e serviços Web existentes em sua empresa.
Transfira um ficheiro do Visio desta arquitetura.
Detalhes do cenário
A arquitetura anterior baseia-se na arquitetura de integração empresarial básica mais simples que utiliza as Aplicações Lógicas do Azure para orquestrar fluxos de trabalho diretamente com sistemas back-end e utiliza a Gestão de API do Azure 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:
O Barramento de Serviço do Azure é um agente de mensagens seguro e confiável.
A Grade de Eventos do Azure é um serviço de roteamento de eventos. Ele usa um modelo de evento de publicação e assinatura .
Essa arquitetura usa comunicação assíncrona por meio de um agente de mensagens em vez de fazer chamadas diretas e síncronas para serviços back-end. A comunicação assíncrona oferece as seguintes vantagens:
Usa o padrão de Nivelamento de Carga Baseado em Fila para lidar com picos de cargas de trabalho por meio do nivelamento de carga
Usa o padrão Editor-Assinante para que você possa transmitir mensagens para vários consumidores
Acompanha o progresso de fluxos de trabalho de longa execução de forma confiável, mesmo quando eles envolvem várias etapas ou vários aplicativos
Ajuda a dissociar aplicações
Integra-se com sistemas baseados em mensagens existentes
Fornece a capacidade de enfileirar mensagens quando um sistema back-end não está disponível
Use a Grade de Eventos para que vários componentes do sistema possam reagir a eventos quando eles acontecerem, em vez de depender de sondagens ou tarefas agendadas. Semelhante a uma fila de mensagens e tópicos, a Grade de Eventos ajuda a desacoplar aplicativos e serviços. Se um aplicativo ou serviço publicar eventos, todos os assinantes interessados serão notificados. Você pode adicionar novos assinantes sem atualizar o remetente.
Muitos serviços do Azure suportam o envio de eventos para a Grade 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 cria fluxos de trabalho reativos nos quais carregar um arquivo ou colocar uma mensagem em uma fila inicia uma série de processos. Os processos podem ser executados em paralelo ou em uma sequência específica.
Recomendações
Considere as seguintes recomendações. Para obter mais recomendações, consulte Arquitetura básica de integração empresarial.
Service Bus
O Service Bus tem dois modelos de entrega, o modelo pull e o modelo proxy push :
Modelo Pull: O recetor sonda continuamente para novas mensagens. Se você precisar gerenciar várias filas e tempos de sondagem, a sondagem pode ser ineficiente. Mas esse modelo pode simplificar sua arquitetura porque remove componentes extras e saltos de dados.
Modelo de envio por proxie: o recetor inicialmente se inscreve em um tipo de evento específico em um tópico de grade de eventos. Quando uma nova mensagem está disponível, o Service Bus gera e envia um evento por meio da Grade de Eventos. Em seguida, esse evento aciona o recetor para extrair o próximo lote de mensagens do Service Bus. Este modelo permite que os sistemas recebam mensagens quase em tempo real, mas sem usar recursos para pesquisar continuamente novas mensagens. Essa arquitetura usa componentes extras que você deve implantar, gerenciar e proteger.
Quando você cria um fluxo de trabalho de Aplicativos Lógicos Padrão que consome mensagens do Service Bus, recomendamos que você use os gatilhos de conector internos do Service Bus. O conector embutido aciona a maior parte da configuração do modelo pull sem adicionar custo extra. Esse recurso fornece o equilíbrio certo entre custo, gerenciamento de área de superfície e segurança, pois o conector faz loops contínuos dentro do mecanismo de tempo de execução dos Aplicativos Lógicos. Para obter mais informações, consulte Gatilhos de conector internos do Service Bus.
Use o modo 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. Essa abordagem evita 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, pode haver várias mensagens disponíveis para processar.
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 Lista de verificação de revisão de design para confiabilidade.
O Microsoft Entra ID é uma plataforma SaaS distribuída globalmente e altamente disponível.
Você pode implantar o Gerenciamento de API em várias configurações altamente disponíveis, de acordo com os requisitos de negócios e a tolerância de custos. Para obter mais informações, consulte Garantir a disponibilidade e a confiabilidade do Gerenciamento de API.
A camada de consumo de aplicativos lógicos oferece suporte a armazenamento com redundância geográfica. Para obter mais informações, consulte Continuidade de negócios e recuperação de desastres para aplicativos lógicos.
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 em uma 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. Para obter mais informações, consulte Recuperação de desastres entre regiões e continuidade de negócios.
O Service Bus Premium suporta zonas de disponibilidade e recuperação de desastres geográficos. O Service Bus Standard oferece suporte à replicação.
Para obter informações sobre detalhes de disponibilidade garantida de cada serviço, consulte SLAs para serviços online.
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 Lista de verificação de revisão de design para segurança.
Para ajudar a proteger o Service Bus, emparelhe a autenticação do Microsoft Entra com identidades gerenciadas. A integração do Microsoft Entra ID 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, como um usuário, um grupo ou uma entidade de serviço de aplicativo. A entidade de serviço do aplicativo neste cenário é uma identidade gerenciada.
Se você não puder usar a ID do Microsoft Entra, use a autenticação de assinatura de acesso compartilhado (SAS) para conceder aos usuários acesso e direitos específicos aos recursos do Service Bus.
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 ajudar a proteger a fila frontando o ponto de extremidade. Em seguida, você pode usar certificados ou autenticação OAuth para ajudar a proteger o ponto de extremidade. A maneira mais fácil de ajudar a proteger um ponto de extremidade é usar um aplicativo lógico que tenha uma solicitação HTTP ou gatilho de resposta como intermediário.
O serviço Grade de Eventos ajuda a proteger 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á automática. Para obter mais informações, consulte Segurança e autenticação da grade de eventos.
Segurança da rede
Considere a segurança da rede em todo o seu projeto.
Você pode vincular o Service Bus Premium a um ponto de extremidade de serviço de sub-rede de rede virtual. Essa configuração ajuda a proteger o namespace porque só aceita tráfego de redes virtuais autorizadas. Também pode utilizar a Ligação Privada do Azure para permitir apenas tráfego privado para a sua rede virtual através de pontos de extremidade privados.
Você pode configurar os Aplicativos Lógicos Standard e Premium 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 de rede virtual.
Você pode usar uma rede virtual do Azure para ajudar a proteger o acesso à sua instância de Gerenciamento de API e APIs. Este método suporta pontos de extremidade privados. Para obter mais informações, consulte Usar uma rede virtual com o Gerenciamento de API.
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 Lista de verificação de revisão de design para otimização de custos.
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 forem executadas. Se você aumentar a escala e, em seguida, não precisar mais desse nível de desempenho, reduza manualmente ou configure o dimensionamento automático.
Para cargas de trabalho de uso leve, considere a camada Consumo, que é uma opção de baixo custo e sem servidor. A camada Consumo é cobrada por chamada de API. Outros níveis são cobrados por hora.
Logic Apps
O Logic Apps usa um modelo sem servidor. O faturamento é calculado com base no número de ações e chamadas do conector. Para obter mais informações, veja os preços do Logic Apps.
Filas, tópicos e subscrições do Service Bus
As filas e assinaturas do Barramento de Serviço oferecem suporte a modelos de push e pull por proxy para entregar mensagens. No modelo pull, cada solicitação de sondagem é medida como uma ação. Mesmo se você definir sondagem longa para o padrão de 30 segundos, 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, Standard e Premium. Os tópicos e assinaturas do Service Bus estão disponíveis nas camadas Standard e Premium. Para obter mais informações, consulte Preços do Service Bus.
Event Grid
A Grade de Eventos usa um modelo sem servidor. O faturamento é calculado com base no número de operações. As operações incluem eventos que vão para 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.
Para obter mais informações, consulte Preços da grade de eventos e Otimização de custos da estrutura bem arquitetada.
Excelência Operacional
A Excelência Operacional abrange os processos operacionais que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, consulte Lista de verificação de revisão de design para excelência operacional.
A arquitetura de referência de integração corporativa básica fornece orientação sobre padrões de DevOps, que se alinham ao pilar de Excelência Operacional da estrutura bem arquitetada.
Automatize as operações de recuperação tanto quanto possível para ajudar a melhorar a 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. Para obter um exemplo de lógica de automação para iniciar um failover, consulte Fluxo de failover.
Eficiência de Desempenho
Eficiência de desempenho é a capacidade de sua carga de trabalho de escalar para atender às demandas colocadas pelos usuários de maneira eficiente. Para obter mais informações, consulte Lista de verificação de revisão de projeto para eficiência de desempenho.
Para obter maior escalabilidade, a camada Premium do Service Bus pode expandir o número de unidades de mensagens. Para obter mais informações, consulte Camadas de mensagens Premium e Standard do Service Bus e Recurso de dimensionamento automático.
Para obter mais recomendações do Service Bus, consulte Práticas recomendadas para melhorias de desempenho usando mensagens do Service Bus.
Próximos passos
- Visão geral da integração do Service Bus to Event Grid
- Tutorial que usa mensagens para integrar sistemas que não são da Microsoft via NServiceBus