Partilhar via

Abordagens arquitetônicas para mensagens em soluções multilocatárias

  • Artigo

As mensagens assíncronas e a comunicação orientada a eventos são ativos críticos ao criar um aplicativo distribuído composto por vários serviços internos e externos. Ao projetar uma solução multilocatário, é crucial realizar uma análise preliminar para definir como compartilhar ou particionar mensagens que pertencem a diferentes locatários.

Compartilhar o mesmo sistema de mensagens ou serviço de streaming de eventos pode reduzir significativamente o custo operacional e a complexidade do gerenciamento. No entanto, usar um sistema de mensagens dedicado para cada locatário fornece melhor isolamento de dados, reduz o risco de vazamento de dados, elimina o problema do vizinho barulhento e permite cobrar seus custos do Azure de volta para seus locatários facilmente.

Neste artigo, você pode encontrar uma distinção entre mensagens e eventos e encontrará diretrizes que os arquitetos de soluções podem seguir ao decidir qual abordagem usar para uma infraestrutura de mensagens ou eventos em uma solução multilocatário.

Mensagens, pontos de dados e eventos discretos

Todos os sistemas de mensagens têm funcionalidades, protocolos de transporte e cenários de uso semelhantes. Por exemplo, a maioria dos sistemas de mensagens modernos suporta comunicações assíncronas que usam filas voláteis ou persistentes, protocolos de transporte AMQP e HTTPS, entrega pelo menos uma vez e assim por diante. No entanto, olhando mais de perto para o tipo de informações publicadas e como os dados são consumidos e processados pelos aplicativos clientes, podemos distinguir entre diferentes tipos de mensagens e eventos. Há uma distinção essencial entre serviços que fornecem um evento e sistemas que enviam uma mensagem. Para obter mais informações, consulte os seguintes recursos:

evento

Um evento é uma notificação simples de uma condição ou alteração de estado. Os eventos podem ser unidades discretas ou fazer parte de uma série. Eventos são mensagens que geralmente não transmitem a intenção de um editor além de informar. Um evento captura um fato e o comunica a outros serviços ou componentes. Um consumidor do evento pode processar o evento como quiser e não atende a nenhuma expectativa específica da editora. Podemos classificar os eventos em duas categorias principais:

  • Eventos discretos contêm informações sobre ações específicas que o aplicativo de publicação realizou. Ao usar a comunicação assíncrona orientada a eventos, um aplicativo publica um evento de notificação quando algo acontece em seu domínio. Um ou mais aplicativos consumidores precisam estar cientes dessa alteração de estado, como uma alteração de preço em um aplicativo de catálogo de produtos. Os consumidores se inscrevem nos eventos para recebê-los de forma assíncrona. Quando um determinado evento acontece, os aplicativos consumidores podem atualizar suas entidades de domínio, o que pode fazer com que mais eventos de integração sejam publicados.
  • Os eventos da série carregam pontos de dados informativos, como leituras de temperatura de dispositivos para análise ou ações do usuário em uma solução de análise de cliques, como elementos em um fluxo contínuo e contínuo. Um fluxo de eventos está relacionado a um contexto específico, como a temperatura ou a umidade relatadas por um dispositivo de campo. Todos os eventos relacionados ao mesmo contexto têm uma ordem temporal estrita que importa ao processar esses eventos com um mecanismo de processamento de fluxo de eventos. A análise de fluxos de eventos que carregam pontos de dados requer o acúmulo desses eventos em um buffer que abrange uma janela de tempo desejada. Ou pode estar em um número selecionado de itens e, em seguida, processar esses eventos, usando uma solução quase em tempo real ou um algoritmo treinado por máquina. A análise de uma série de eventos pode produzir sinais, como a média de um valor medido ao longo de uma janela de tempo que ultrapassa um limite. Esses sinais podem então ser levantados como eventos discretos e acionáveis.

Eventos discretos relatam alterações de estado e são acionáveis. A carga útil do evento tem informações sobre o que aconteceu, mas, em geral, não tem os dados completos que desencadearam o evento. Por exemplo, um evento notifica os consumidores de que um aplicativo de relatório criou um novo arquivo em uma conta de armazenamento. A carga útil do evento pode ter informações gerais sobre o arquivo, mas não tem o arquivo em si. Os eventos discretos são ideais para soluções sem servidor que têm de ser dimensionadas.

Os eventos de série comunicam uma condição e são analisáveis. Os eventos discretos são ordenados no tempo e inter-relacionados. Em alguns contextos, o consumidor precisa receber a sequência completa de eventos para analisar o que aconteceu e tomar as medidas necessárias.

Mensagens

As mensagens contêm dados brutos que são produzidos por um serviço para serem consumidos ou armazenados em outro lugar. As mensagens geralmente carregam informações necessárias para que um serviço de recebimento execute etapas em um fluxo de trabalho ou uma cadeia de processamento. Um exemplo desse tipo de comunicação é o padrão Command. O editor também pode esperar que o(s) recetor(es) de uma mensagem execute(m) uma série de ações e relatem o resultado de seu processamento com uma mensagem assíncrona. Existe um contrato entre o editor e o(s) recetor(es) da mensagem. Por exemplo, o editor envia uma mensagem com alguns dados brutos e espera que o consumidor crie um arquivo a partir desses dados e envie de volta uma mensagem de resposta quando terminar. Em outras situações, um processo de remetente pode enviar uma mensagem assíncrona unidirecional para solicitar que outro serviço execute uma determinada operação, mas sem expectativa de receber de volta uma mensagem de confirmação ou resposta dele.

Esse tipo de tratamento contratual de mensagens é bem diferente de um editor que publica eventos discretos para uma audiência de agentes do consumidor, sem qualquer expectativa específica de como eles lidarão com essas notificações.

Cenários de exemplo

Aqui está uma lista de alguns exemplos de cenários multilocatários para mensagens, pontos de dados e eventos discretos:

  • Eventos discretos:
    • Uma plataforma de compartilhamento de música rastreia o fato de que um usuário específico em um locatário específico ouviu uma faixa de música específica.
    • Em um aplicativo Web de loja online, o aplicativo de catálogo envia um evento usando o padrão Publisher-Subscriber para outros aplicativos para notificá-los de que o preço de um item foi alterado.
    • Uma empresa de fabricação envia informações em tempo real para clientes e terceiros sobre manutenção de equipamentos, integridade dos sistemas e atualizações de contratos.
  • Pontos de dados:
    • Um sistema de controle de construção recebe eventos de telemetria, como leituras de temperatura ou umidade de sensores que pertencem a vários clientes.
    • Um sistema de monitoramento orientado a eventos recebe e processa logs de diagnóstico quase em tempo real de vários serviços, como servidores Web.
    • Um script do lado do cliente em uma página da Web coleta ações do usuário e as envia para uma solução de análise de cliques.
  • Mensagens:
    • Um aplicativo de finanças B2B recebe uma mensagem para começar a processar os registros bancários de um inquilino.
    • Um fluxo de trabalho de longa execução recebe uma mensagem que aciona a execução da próxima etapa.
    • O aplicativo de cesta de um aplicativo de loja online envia um comando CreateOrder usando uma mensagem assíncrona e persistente para o aplicativo de pedidos.

Principais considerações e requisitos

O modelo de implantação e locação escolhido para sua solução tem um impacto profundo na segurança, no desempenho, no isolamento de dados, no gerenciamento e na capacidade de cobrar custos de recursos cruzados para os locatários. Essa análise inclui o modelo selecionado para sua infraestrutura de mensagens e eventos. Nesta seção, analisamos algumas das principais decisões que você deve tomar ao planejar um sistema de mensagens em sua solução multilocatário.

Escala

O número de locatários, a complexidade dos fluxos de mensagens e fluxos de eventos, o volume de mensagens, o perfil de tráfego esperado e o nível de isolamento devem orientar as decisões ao planejar uma infraestrutura de mensagens ou eventos.

A primeira etapa consiste em realizar um planejamento exaustivo da capacidade e estabelecer a capacidade máxima necessária para um sistema de mensagens em termos de taxa de transferência para lidar adequadamente com o volume esperado de mensagens sob tráfego regular ou de pico.

Algumas ofertas de serviço, como a camada Premium do Barramento de Serviço do Azure, fornecem isolamento de recursos no nível de CPU e memória para que cada carga de trabalho do cliente seja executada isoladamente. Este contentor de recursos é designado por unidade de mensagens. A cada espaço de nomes premium é atribuído, pelo menos, uma unidade de mensagens. Você pode comprar 1, 2, 4, 8 ou 16 unidades de mensagens para cada namespace Premium do Service Bus. Uma única carga de trabalho ou entidade pode abranger várias unidades de mensagens e você pode alterar o número de unidades de mensagens conforme necessário. O resultado é um desempenho previsível e repetível para sua solução baseada em Service Bus. Para obter mais informações, consulte Camadas de mensagens Premium e Standard do Service Bus. Da mesma forma, as camadas de preços dos Hubs de Eventos do Azure permitem dimensionar o namespace, com base no volume esperado de eventos de entrada e saída. Por exemplo, a oferta Premium é faturada por unidades de processamento (PUs), que correspondem a uma parte de recursos isolados (CPU, memória e armazenamento) na infraestrutura subjacente. A ingestão efetiva e a taxa de transferência de fluxo por PU dependerão dos seguintes fatores:

  • Número de produtores e consumidores
  • Tamanho da carga útil
  • Contagem de partições
  • Taxa de pedidos de saída
  • Uso de Captura de Hubs de Eventos, Registro de Esquema e outros recursos avançados

Para obter mais informações, consulte Visão geral dos Hubs de Eventos Premium.

Quando sua solução lida com um número considerável de locatários e você decide adotar um sistema de mensagens separado para cada locatário, você precisa ter uma estratégia consistente para automatizar a implantação, o monitoramento, os alertas e o dimensionamento de cada infraestrutura, separadamente uns dos outros.

Por exemplo, um sistema de mensagens para um determinado locatário pode ser implantado durante o processo de provisionamento usando uma ferramenta de infraestrutura como código (IaC), como modelos JSON Terraform, Bíceps ou Azure Resource Manager (ARM) e um sistema DevOps, como Azure DevOps ou GitHub Actions. Para obter mais informações, consulte Abordagens arquitetônicas para a implantação e configuração de soluções multilocatário.

O sistema de mensagens pode ser dimensionado com uma taxa de transferência máxima de mensagens por unidade de tempo. Se o sistema suportar dimensionamento automático dinâmico, sua capacidade poderá ser aumentada ou diminuída automaticamente, com base nas condições de tráfego e métricas para atender ao contrato de nível de serviço esperado.

Previsibilidade e fiabilidade do desempenho

Ao projetar e construir um sistema de mensagens para um número limitado de locatários, o uso de um único sistema de mensagens pode ser uma excelente solução para atender aos requisitos funcionais, em termos de taxa de transferência, e pode reduzir o custo total de propriedade. Um aplicativo multilocatário pode compartilhar as mesmas entidades de mensagens, como filas e tópicos em vários clientes. Ou eles podem usar um conjunto dedicado de componentes para cada um, a fim de aumentar o isolamento do locatário. Por outro lado, compartilhar a mesma infraestrutura de mensagens entre vários locatários pode expor toda a solução ao problema do vizinho barulhento. A atividade de um inquilino pode prejudicar outros inquilinos, em termos de desempenho e operacionalidade.

Nesse caso, o sistema de mensagens deve ser dimensionado adequadamente para sustentar a carga de tráfego esperada no horário de pico. Idealmente, deve suportar o dimensionamento automático. O sistema de mensagens deve ser dimensionado dinamicamente quando o tráfego aumenta e dimensionado quando o tráfego diminui. Um sistema de mensagens dedicado para cada locatário também poderia mitigar o risco de vizinho barulhento, mas gerenciar um grande número de sistemas de mensagens poderia aumentar a complexidade da solução.

Um aplicativo multilocatário pode, eventualmente, adotar uma abordagem híbrida, em que os serviços principais usam o mesmo conjunto de filas e tópicos em um único sistema de mensagens compartilhado, para implementar comunicações internas assíncronas. Em contraste, outros serviços poderiam adotar um grupo dedicado de entidades de mensagens ou até mesmo um sistema de mensagens dedicado, para cada locatário para mitigar o problema do vizinho barulhento e garantir o isolamento dos dados.

Ao implantar um sistema de mensagens em máquinas virtuais, você deve colocalizar essas máquinas virtuais com os recursos de computação, para reduzir a latência da rede. Essas máquinas virtuais não devem ser compartilhadas com outros serviços ou aplicativos, para evitar que a infraestrutura de mensagens compita pelos recursos do sistema, como CPU, memória e largura de banda de rede com outros sistemas. As máquinas virtuais também podem se espalhar pelas zonas de disponibilidade, para aumentar a resiliência dentro da região e a confiabilidade de cargas de trabalho críticas para os negócios, incluindo sistemas de mensagens. Suponha que você decida hospedar um sistema de mensagens, como RabbitMQ ou Apache ActiveMQ, em máquinas virtuais. Nesse caso, recomendamos implantá-lo em um conjunto de dimensionamento de máquina virtual e configurá-lo para dimensionamento automático, com base em métricas como CPU ou memória. Dessa forma, o número de nós de agente que hospedam o sistema de mensagens será dimensionado e dimensionado corretamente, com base nas condições de tráfego. Para obter mais informações, consulte Visão geral do dimensionamento automático com conjuntos de dimensionamento de máquina virtual do Azure.

Da mesma forma, ao hospedar seu sistema de mensagens em um cluster Kubernetes, considere usar seletores de nós e taints para agendar a execução de seus pods em um pool de nós dedicado, não compartilhado com outras cargas de trabalho, a fim de evitar o problema do Vizinho barulhento. Ao implantar um sistema de mensagens em um cluster AKS com redundância de zona, use as restrições de propagação da topologia do Pod para controlar como os pods são distribuídos pelo cluster do AKS entre domínios de falha, como regiões, zonas de disponibilidade e nós. Ao hospedar um sistema de mensagens de terceiros no AKS, use o dimensionamento automático do Kubernetes para dimensionar dinamicamente o número de nós de trabalho quando o tráfego aumentar. Com o Horizontal Pod Autoscaler e o AKS cluster autoscaler, os volumes de nós e pods são ajustados dinamicamente em tempo real, para corresponder à condição de tráfego e evitar tempos de inatividade causados por problemas de capacidade. Para obter mais informações, consulte Dimensionar automaticamente um cluster para atender às demandas de aplicativos no Serviço Kubernetes do Azure (AKS). Considere usar o Kubernetes Even-Driven Autoscaling (KEDA), se quiser expandir o número de pods de um sistema de mensagens hospedado no Kubernetes, como RabbitMQ ou Apache ActiveMQ, com base no comprimento de uma determinada fila. Com o KEDA, você pode conduzir o dimensionamento de qualquer contêiner no Kubernetes, com base no número de eventos que precisam ser processados. Por exemplo, você pode usar o KEDA para dimensionar aplicativos com base no comprimento de uma fila do Barramento de Serviço do Azure, de uma fila RabbitMQ ou de uma fila ActiveMQ. Para obter mais informações sobre o KEDA, consulte Kubernetes Event-driven Autoscaling.

Isolamento

Ao projetar o sistema de mensagens para uma solução multilocatário, você deve considerar que diferentes tipos de aplicativos exigem um tipo diferente de isolamento, que se baseia nos requisitos de desempenho, privacidade e auditoria dos locatários.

  • Vários locatários podem compartilhar as mesmas entidades de mensagens, como filas, tópicos e assinaturas, no mesmo sistema de mensagens. Por exemplo, um aplicativo multilocatário pode receber mensagens que carregam dados para vários locatários, de uma única fila do Barramento de Serviço do Azure. Esta solução pode levar a problemas de desempenho e escalabilidade. Se alguns dos locatários gerarem um volume maior de pedidos do que outros, isso pode causar uma lista de pendências de mensagens. Esse problema, também conhecido como problema de vizinho barulhento, pode degradar o contrato de nível de serviço em termos de latência para alguns locatários. O problema é mais evidente se o aplicativo consumidor lê e processa mensagens da fila, uma de cada vez, em uma ordem cronológica estrita, e se o tempo necessário para processar uma mensagem depende do número de itens na carga útil. Ao compartilhar um ou mais recursos de fila entre vários locatários, a infraestrutura de mensagens e os sistemas de processamento devem ser capazes de acomodar o tráfego esperado baseado em requisitos de escala e taxa de transferência. Essa abordagem arquitetônica é adequada nos cenários em que uma solução multilocatária adota um único pool de processos de trabalho para receber, processar e enviar mensagens para todos os locatários.
  • Vários locatários compartilham o mesmo sistema de mensagens, mas usam recursos de tópico ou fila diferentes. Essa abordagem oferece melhor isolamento e proteção de dados a um custo mais alto, maior complexidade operacional e menor agilidade porque os administradores de sistema precisam provisionar, monitorar e manter um número maior de recursos de fila. Essa solução garante uma experiência consistente e previsível para todos os locatários, em termos de desempenho e contratos de nível de serviço, pois evita que qualquer locatário crie um gargalo que pode afetar os outros locatários.
  • Um sistema de mensagens separado e dedicado é usado para cada locatário. Por exemplo, uma solução multilocatária pode usar um namespace distinto do Barramento de Serviço do Azure para cada locatário. Esta solução proporciona o máximo grau de isolamento, com maior complexidade e custo operacional. Essa abordagem garante um desempenho consistente e permite ajustar o sistema de mensagens, com base nas necessidades específicas do locatário. Quando um novo locatário é integrado, além de um sistema de mensagens totalmente dedicado, o aplicativo de provisionamento também pode precisar criar uma identidade gerenciada separada ou uma entidade de serviço com as permissões RBAC adequadas para acessar o namespace recém-criado. Por exemplo, quando um cluster Kubernetes é compartilhado por várias instâncias do mesmo aplicativo SaaS, uma para cada locatário e cada uma em execução em um namespace separado, cada instância de aplicativo pode usar uma entidade de serviço ou identidade gerenciada diferente para acessar um sistema de mensagens dedicado. Nesse contexto, o sistema de mensagens pode ser um serviço PaaS totalmente gerenciado, como um namespace do Barramento de Serviço do Azure, ou um sistema de mensagens hospedado pelo Kubernetes, como o RabbitMQ. Ao excluir um locatário do sistema, o aplicativo deve remover o sistema de mensagens e qualquer recurso dedicado que tenha sido criado anteriormente para o locatário. A principal desvantagem desta abordagem é que aumenta a complexidade operacional e reduz a agilidade, especialmente quando o número de inquilinos cresce ao longo do tempo.

Analise as seguintes considerações e observações adicionais:

  • Se os locatários precisarem usar sua própria chave para criptografar e descriptografar mensagens, uma solução multilocatária deverá fornecer a opção de adotar um namespace Premium do Azure Service Bus separado para cada locatário. Para obter mais informações, consulte Configurar chaves gerenciadas pelo cliente para criptografar dados do Barramento de Serviço do Azure em repouso.
  • Se os locatários precisarem de um alto nível de resiliência e continuidade de negócios, uma solução multilocatária deverá fornecer a capacidade de provisionar um namespace Premium do Service Bus com zonas de disponibilidade e recuperação de desastres geográficos habilitadas. Para obter mais informações, consulte Recuperação de desastres geográficos do Barramento de Serviço do Azure.
  • Ao usar recursos de fila separados ou um sistema de mensagens dedicado para cada locatário, é razoável adotar um pool separado de processos de trabalho, para que cada um deles aumente o nível de isolamento de dados e reduza a complexidade de lidar com várias entidades de mensagens. Cada instância do sistema de processamento pode adotar credenciais diferentes, como uma cadeia de conexão, uma entidade de serviço ou uma identidade gerenciada, para acessar o sistema de mensagens dedicado. Essa abordagem fornece um melhor nível de segurança e isolamento entre locatários, mas requer uma maior complexidade no gerenciamento de identidades.

Da mesma forma, um aplicativo controlado por eventos pode fornecer diferentes níveis de isolamento:

  • Um aplicativo controlado por eventos recebe eventos de vários locatários, por meio de uma única instância compartilhada dos Hubs de Eventos do Azure. Essa solução fornece um alto nível de agilidade, porque a integração de um novo locatário não requer a criação de um recurso dedicado de ingestão de eventos, mas fornece um baixo nível de proteção de dados, pois mistura mensagens de vários locatários na mesma estrutura de dados.
  • Os locatários podem optar por um hub de eventos dedicado ou tópico Kafka para evitar o problema do vizinho barulhento e atender aos seus requisitos de isolamento de dados, quando os eventos não devem ser misturados com os de outros locatários, para segurança e proteção de dados.
  • Se os locatários precisarem de um alto nível de resiliência e continuidade de negócios, um multilocatário deverá fornecer a capacidade de provisionar um namespace Premium de Hubs de Eventos, com zonas de disponibilidade e recuperação de desastres geográficos habilitadas. Para obter mais informações, consulte Hubs de Eventos do Azure - Recuperação de desastres geográficos.
  • Hubs de Eventos dedicados, com a Captura de Hubs de Eventos habilitada, devem ser criados para os clientes que precisam arquivar eventos em uma Conta de Armazenamento do Azure, por motivos e obrigações de conformidade regulamentar. Para obter mais informações, consulte Capturar eventos por meio dos Hubs de Eventos do Azure no Armazenamento de Blobs do Azure ou no Armazenamento do Azure Data Lake.
  • Um único aplicativo multilocatário pode enviar notificações para vários sistemas internos e externos, usando a Grade de Eventos do Azure. Nesse caso, uma assinatura de grade de eventos separada deve ser criada para cada aplicativo de consumidor. Se seu aplicativo usa várias instâncias de Grade de Eventos para enviar notificações a um grande número de organizações externas, considere o uso de domínios de eventos, que permitem que um aplicativo publique eventos em milhares de tópicos, como um para cada locatário. Para obter mais informações, consulte Compreender domínios de evento para gerenciar tópicos de grade de eventos.

Complexidade da execução

Ao projetar uma solução multilocatário, é essencial considerar como o sistema evoluirá a médio e longo prazo, a fim de evitar que sua complexidade cresça ao longo do tempo, até que seja necessário redesenhar parte ou toda a solução. Esta reformulação irá ajudá-lo a lidar com um número crescente de inquilinos. Ao projetar um sistema de mensagens, você deve considerar o crescimento esperado em volumes de mensagens e locatários nos próximos anos e, em seguida, criar um sistema que possa ser expandido, a fim de acompanhar o tráfego previsto e reduzir a complexidade das operações, como provisionamento, monitoramento e manutenção.

A solução deve criar ou excluir automaticamente as entidades de mensagens necessárias sempre que um aplicativo locatário for provisionado ou não provisionado, sem a necessidade de operações manuais.

Uma preocupação particular para soluções de dados multilocatários é o nível de personalização que você suporta. Qualquer personalização deve ser configurada e aplicada automaticamente pelo sistema de provisionamento de aplicativos (como um sistema DevOps), que se baseia em um conjunto de parâmetros iniciais, sempre que um aplicativo de locatário único ou multilocatário é implantado.

Complexidade da gestão e das operações

Planeje desde o início como você pretende operar, monitorar e manter sua infraestrutura de mensagens e eventos e como sua abordagem de multilocação afeta suas operações e processos. Por exemplo, considere as seguintes possibilidades:

  • Você pode planejar hospedar o sistema de mensagens usado pelo seu aplicativo em um conjunto dedicado de máquinas virtuais, uma para cada locatário. Em caso afirmativo, como você planeja implantar, atualizar, monitorar e dimensionar esses sistemas?
  • Da mesma forma, se você colocar em contêineres e hospedar seu sistema de mensagens em um cluster Kubernetes compartilhado, como planeja implantar, atualizar, monitorar e dimensionar sistemas de mensagens individuais?
  • Suponha que você compartilhe um sistema de mensagens entre vários locatários. Como sua solução pode coletar e relatar as métricas de uso por locatário ou limitar o número de mensagens que cada locatário pode enviar ou receber?
  • Quando seu sistema de mensagens aproveita um serviço PaaS, como o Barramento de Serviço do Azure, você deve fazer a seguinte pergunta:
    • Como você pode personalizar a camada de preços para cada locatário, com base nos recursos e no nível de isolamento (compartilhado ou dedicado) solicitados pelo locatário?
    • Como você pode criar uma identidade de gerenciamento por locatário e uma atribuição de função do Azure para atribuir as permissões adequadas somente às entidades de mensagens, como filas, tópicos e assinaturas, que o locatário pode acessar? Para obter mais informações, consulte Autenticar uma identidade gerenciada com a ID do Microsoft Entra para acessar os recursos do Barramento de Serviço do Azure.
  • Como você migrará locatários, se eles precisarem migrar para um tipo diferente de serviço de mensagens, uma implantação diferente ou outra região?

Custo

Geralmente, quanto maior a densidade de locatários para sua infraestrutura de implantação, menor o custo para provisionar essa infraestrutura. No entanto, a infraestrutura compartilhada aumenta a probabilidade de problemas como o problema do vizinho barulhento, portanto, considere as compensações cuidadosamente.

Abordagens e padrões a considerar

Vários Padrões de Design de Nuvem da Central de Arquitetura do Azure podem ser aplicados a um sistema de mensagens multilocatário. Você pode optar por seguir um ou mais padrões de forma consistente, ou pode considerar misturar e combinar padrões, com base em suas necessidades. Por exemplo, você pode usar um namespace do Service Bus multilocatário para a maioria dos seus locatários, mas depois pode implantar um namespace dedicado do Service Bus de locatário único para os locatários que pagam mais ou que têm requisitos mais altos, em termos de isolamento e desempenho. Da mesma forma, geralmente é uma boa prática dimensionar usando carimbos de implantação, mesmo quando você usa um namespace do Service Bus multilocatário ou namespaces dedicados dentro de um carimbo.

Padrão de selos de implantação

Para obter mais informações sobre o padrão de carimbos de implantação e multilocação, consulte a seção Padrão de carimbos de implantação de Abordagens arquitetônicas para multilocação. Para obter mais informações sobre modelos de locação, consulte Modelos de locação a serem considerados para uma solução multilocatário.

Sistema de mensagens compartilhadas

Você pode considerar implantar um sistema de mensagens compartilhado, como o Barramento de Serviço do Azure, e compartilhá-lo entre todos os seus locatários.

Diagrama mostrando um único sistema de mensagens multilocatário compartilhado para todos os locatários.

Essa abordagem fornece a maior densidade de locatários para a infraestrutura, reduzindo assim o custo total total de propriedade. Muitas vezes, também reduz a sobrecarga de gerenciamento, uma vez que há um único sistema de mensagens ou recurso para gerenciar e proteger.

No entanto, ao compartilhar um recurso ou uma infraestrutura inteira entre vários locatários, considere as seguintes advertências:

  • Tenha sempre em mente e considere as restrições, capacidades de escala, cotas e limites do recurso em questão. Por exemplo, o número máximo de namespaces do Service Bus em uma assinatura do Azure, o número máximo de Hubs de Eventos em um único namespace ou os limites máximos de taxa de transferência podem eventualmente se tornar um bloqueador rígido, se e quando sua arquitetura crescer para oferecer suporte a mais locatários. Considere cuidadosamente a escala máxima que você precisa alcançar em termos do número de namespaces por assinatura única do Azure ou filas por namespace único. Em seguida, compare suas estimativas atuais e futuras com as cotas e limites existentes do sistema de mensagens de sua escolha, antes de selecionar esse padrão.
  • Como mencionado nas seções acima, o problema do vizinho barulhento pode se tornar um fator, quando você compartilha um recurso entre vários locatários, especialmente se alguns estiverem particularmente ocupados ou se gerarem tráfego maior do que outros. Nesse caso, considere aplicar o padrão de Limitação ou o padrão de Limitação de Taxa para mitigar esses efeitos. Por exemplo, você pode limitar o número máximo de mensagens que um único locatário pode enviar ou receber na unidade de tempo.
  • Você pode ter dificuldade em monitorar a atividade e medir o consumo de recursos para um único locatário. Alguns serviços, como o Barramento de Serviço do Azure, cobram por operações de mensagens. Assim, quando você compartilha um namespace entre vários locatários, seu aplicativo deve ser capaz de acompanhar o número de operações de mensagens feitas em nome de cada locatário e os custos de estorno para eles. Outros serviços não fornecem o mesmo nível de detalhe.

Os locatários podem ter requisitos diferentes de segurança, resiliência dentro da região, recuperação de desastres ou localização. Se eles não corresponderem à configuração do seu sistema de mensagens, talvez você não consiga acomodá-los apenas com um único recurso.

Padrão de fragmentação

O padrão de compartilhamento envolve a implantação de vários sistemas de mensagens, chamados fragmentos, que contêm uma ou mais entidades de mensagens de locatários, como filas e tópicos. Ao contrário dos carimbos de implantação, os fragmentos não implicam que toda a infraestrutura seja duplicada. Você pode fragmentar sistemas de mensagens sem também duplicar ou fragmentar outra infraestrutura em sua solução.

Diagrama mostrando um sistema de mensagens fragmentado. Um sistema de mensagens contém as filas para os locatários A e B e o outro contém as filas para o locatário C.

Cada sistema de mensagens ou fragmento pode ter características diferentes em termos de confiabilidade, SKU e localização. Por exemplo, você pode fragmentar seus locatários em vários sistemas de mensagens com características diferentes, com base em sua localização ou necessidades em termos de desempenho, confiabilidade, proteção de dados ou continuidade de negócios.

Ao usar o padrão de fragmentação, você precisa usar uma estratégia de fragmentação para mapear um determinado locatário para o sistema de mensagens que contém suas filas. A estratégia de pesquisa usa um mapa para individualizar o sistema de mensagens de destino, com base no nome ou ID do locatário. Vários locatários podem compartilhar o mesmo fragmento, mas as entidades de mensagens usadas por um único locatário não serão distribuídas por vários fragmentos. O mapa pode ser implementado com um único dicionário que mapeia o nome do locatário para o nome ou referência do sistema de mensagens de destino. O mapa pode ser armazenado em um cache distribuído acessível, por todas as instâncias de um aplicativo multilocatário, ou em um armazenamento persistente, como uma tabela em um banco de dados relacional ou uma tabela em uma conta de armazenamento.

O padrão de compartilhamento pode ser dimensionado para um número muito grande de locatários. Além disso, dependendo da sua carga de trabalho, você pode conseguir uma alta densidade de inquilinos para fragmentos, para que o custo possa ser atraente. O padrão de compartilhamento também pode ser usado para abordar cotas, limites e restrições de assinatura e serviço do Azure.

Aplicativo multilocatário com sistema de mensagens dedicado para cada locatário

Outra abordagem comum é implantar um único aplicativo multilocatário, com sistemas de mensagens dedicados para cada locatário. Nesse modelo de locação, você tem alguns componentes compartilhados, como recursos de computação, enquanto outros serviços são provisionados e gerenciados usando uma abordagem de implantação dedicada de locatário único. Por exemplo, você pode criar uma única camada de aplicativo e, em seguida, implantar sistemas de mensagens individuais para cada locatário, conforme mostrado na ilustração a seguir.

Diagrama mostrando diferentes sistemas de mensagens para cada locatário.

Implantações particionadas horizontalmente podem ajudá-lo a mitigar um problema de vizinho barulhento, se você identificou que a maior parte da carga em seu sistema se deve a componentes específicos que podem ser implantados separadamente para cada locatário. Por exemplo, talvez seja necessário usar um sistema de mensagens ou streaming de eventos separado para cada locatário porque uma única instância não é suficiente para acompanhar o tráfego gerado por vários locatários. Ao usar um sistema de mensagens dedicado para cada locatário, se um único locatário causar um grande volume de mensagens ou eventos, isso poderá afetar os componentes compartilhados, mas não os sistemas de mensagens de outros locatários.

Como você provisiona recursos dedicados para cada locatário, o custo dessa abordagem pode ser maior do que um modelo de hospedagem compartilhada. Por outro lado, é mais fácil cobrar de volta os custos de recursos de um sistema dedicado ao inquilino único que faz uso dele, ao adotar esse modelo de locação. Essa abordagem permite que você obtenha alta densidade para outros serviços, como recursos de computação, e reduz os custos desses componentes.

Com uma implantação particionada horizontalmente, você precisa adotar um processo automatizado para implantar e gerenciar os serviços de um aplicativo multilocatário, especialmente aqueles usados por um único locatário.

Padrão Geodes

O padrão Geode envolve a implantação de uma coleção de serviços de back-end em um conjunto de nós geográficos. Cada um pode atender qualquer solicitação para qualquer cliente em qualquer região. Esse padrão permite que você atenda solicitações em um estilo ativo-ativo, o que melhora a latência e aumenta a disponibilidade, distribuindo o processamento de solicitações em todo o mundo.

Diagrama mostrando o padrão Geode, com sistemas de mensagens implantados em várias regiões que sincronizam entre si.

O Barramento de Serviço do Azure e os Hubs de Eventos do Azure dão suporte à recuperação de desastres de metadados, em namespaces de recuperação de desastres primários e secundários e em regiões e zonas de disponibilidade separadas, para fornecer suporte para a melhor resiliência dentro da região. Além disso, o Barramento de Serviço do Azure e os Hubs de Eventos do Azure implementam um conjunto de padrões de federação que replicam ativamente o mesmo tópico lógico, fila ou hub de eventos para estar disponível em vários namespaces, eventualmente localizados em regiões diferentes. Para obter mais informações, consulte os seguintes recursos:

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

  • Paolo Salvatori - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure

Outros contribuidores:

  • John Downs - Brasil | Engenheiro de Software Principal
  • Clemens Vasters - Brasil | Arquiteto Principal, Serviços de Mensagens e Padrões
  • Arsen Vladimirskiy - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure

Próximos passos

Para obter mais informações sobre padrões de design de mensagens, consulte os seguintes recursos: