Compartilhar via

Abordagens de arquitetura para mensagens em soluções multilocatário

  • Artigo

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

Compartilhar o mesmo sistema de mensagens ou serviço de transmissão de eventos pode reduzir significativamente o custo operacional e a complexidade de gerenciamento. No entanto, o uso de 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 estornar facilmente os custos do Azure para seus locatários.

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 de eventos em uma solução multilocatário.

Mensagens, pontos de dados e eventos discretos

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

Eventos

Um evento é uma notificação leve de uma condição ou de uma alteração de estado. Os eventos podem ser unidades discretas ou parte de uma série. Eventos são mensagens que geralmente não transmitem a intenção de um publicador 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 às expectativas específicas que o publicador tem. Podemos classificar 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 controlada por eventos, um aplicativo publica um evento de notificação quando algo acontece dentro do domínio dele. 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 assinam os eventos para recebê-los de forma assíncrona. Quando um determinado evento ocorre, os aplicativos consumidores podem atualizar as próprias entidades de domínio, o que pode causar a publicação de mais eventos de integração.
  • Eventos de 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 em curso, contínuo. Um fluxo de eventos está relacionado a um contexto específico, como a temperatura ou a umidade relatada por um dispositivo de campo. Todos os eventos relacionados ao mesmo contexto têm uma ordem temporal estrita que é importante ao processar esses eventos com um mecanismo de processamento de fluxo de eventos. Analisar fluxos de eventos que carregam pontos de dados requer acumular esses 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 computador. A análise de uma série de eventos pode gerar sinais, como a média de um valor medido em uma janela de tempo que ultrapassa um limite. Esses sinais podem ser gerados como eventos discretos e acionáveis.

Eventos discretos relatam alterações de estado e são acionáveis. A carga do evento têm informações sobre o que aconteceu, mas, em geral, não têm os dados completos que dispararam 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 do evento pode ter informações gerais sobre o arquivo, mas não possui o arquivo em si. Eventos discretos são ideais para soluções sem servidor que precisam ser dimensionadas.

Eventos de série relatam uma condição e são analisáveis. Eventos discretos são ordenados por 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

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

Esse tipo de tratamento de mensagens contratuais é bem diferente de um publicador que está publicando eventos discretos para um público-alvo de agentes consumidores, sem qualquer expectativa específica de como eles lidarão com essas notificações.

Cenários de exemplo

Aqui está uma lista de alguns cenários multilocatários de exemplo 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 de 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 controlado por 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 financeiro B2B recebe uma mensagem para começar a processar os registros bancários de um locatário.
    • Um fluxo de trabalho de longa execução recebe uma mensagem que dispara 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.

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 fazer cobrança cruzada de custos de recursos para os locatários. Essa análise inclui o modelo selecionado para sua infraestrutura de mensagens e eventos. Nesta seção, examinaremos 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 conduzir as decisões ao planejar uma infraestrutura de mensagens ou eventos.

A primeira etapa consiste na realização de exaustivo planejamento de capacidade e no estabelecimento da 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 em tráfego regular ou de pico.

Algumas ofertas de serviço, como a camada Barramento de Serviço do Azure Premium, fornecem isolamento de recursos no nível de CPU e memória para que a carga de trabalho de cada cliente seja executada isoladamente. Esse contêiner de recurso é chamado de unidade do sistema de mensagens. Cada namespace premium é alocado para pelo menos uma unidade do sistema de mensagens. Você pode adquirir 1, 2, 4, 8 ou 16 unidades do sistema de mensagens para cada namespace do Barramento de Serviço Premium. Uma única carga de trabalho ou entidade pode incluir várias unidades do sistema de mensagens, e é possível alterar esse número conforme o necessário. O resultado é um desempenho previsível e repetível para sua solução baseada no Barramento de Serviço. Para saber mais, confira asCamadas do sistema de mensagens do Barramento de Serviço Premium e Standard. Da mesma forma, as camadas de preço do 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 é cobrada por PUs (unidades de processamento) que correspondem a um compartilhamento de recursos isolados (CPU, memória e armazenamento) na infraestrutura subjacente. A ingestão efetiva e a taxa de transferência do fluxo por PU dependerão dos seguintes fatores:

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

Para obter mais informações, confira a Visão Geral do 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, é necessário ter uma estratégia consistente para automatizar a implantação, o monitoramento, os alertas e o dimensionamento de cada infraestrutura separadamente.

Por exemplo, um sistema de mensagens para um determinado locatário pode ser implantado durante o processo de provisionamento usando uma ferramenta IaC (infraestrutura como código), como modelos JSON do Terraform, Bicep ou ARM (Azure Resource Manager) e um sistema DevOps, como o Azure DevOps ou o GitHub Actions. Para obter mais informações, confira Abordagens de arquitetura para 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 em mensagens por unidade de tempo. Se o sistema der suporte ao dimensionamento automático dinâmico, a capacidade dele poderá ser aumentada ou reduzida automaticamente, com base nas condições de tráfego e nas métricas para atender ao contrato de nível de serviço esperado.

Previsibilidade e confiabilidade do desempenho

Ao projetar e criar 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 poderia reduzir o custo total de propriedade. Um aplicativo multilocatário pode compartilhar as mesmas entidades do sistemas de mensagens, como filas e tópicos, entre vários clientes. Ou eles podem usar um conjunto dedicado de componentes para cada um, a fim de aumentar o isolamento de locatário. Por outro lado, o compartilhamento da mesma infraestrutura do sistema de mensagens entre vários locatários pode expor toda a solução ao problema do Vizinho Barulhento. A atividade de um locatário pode prejudicar outros locatários em termos de desempenho e operabilidade.

Nesse caso, o sistema de mensagens deve ser dimensionado corretamente para sustentar a carga de tráfego esperada no horário de pico. Idealmente, ele deve dar suporte ao dimensionamento automático. O sistema de mensagens deve ser escalado dinamicamente quando o tráfego aumenta e reduzido quando o tráfego diminui. Um sistema de mensagens dedicado para cada locatário também pode atenuar o risco do Vizinho Barulhento, mas o gerenciamento de um grande número de sistemas de mensagens pode aumentar a complexidade da solução.

Um aplicativo multilocatário pode eventualmente adotar uma abordagem híbrida, em que os principais serviços usam o mesmo conjunto de filas e tópicos em um único sistema de mensagens compartilhado, a fim de implementar comunicações internas assíncronas. Por outro lado, outros serviços poderiam adotar um grupo dedicado de entidades do sistema de mensagens ou até mesmo um sistema de mensagens dedicado, para que cada locatário atenuasse o problema do Vizinho Barulhento e garantisse o isolamento de dados.

Ao implantar um sistema de mensagens em máquinas virtuais, você deve co-localizar essas máquinas virtuais com os recursos de computação para reduzir a latência de rede. Essas máquinas virtuais não devem ser compartilhadas com outros serviços ou aplicativos, para evitar que a infraestrutura do sistema de mensagens concorra aos recursos do sistema como CPU, memória e largura de banda da rede com outros sistemas. As máquinas virtuais também podem se propagar nas zonas de disponibilidade, para aumentar a resiliência intra-região e a confiabilidade das cargas de trabalho comercialmente críticas, incluindo os 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áquinas virtuais 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á escalado e reduzido corretamente, com base nas condições de tráfego. Para saber mais, confira aVisão geral sobre dimensionamento automático com os conjuntos de dimensionamento de máquinas virtuais do Azure.

Da mesma forma, ao hospedar seu sistema de mensagens em um cluster do Kubernetes, considere usar seletores de nó e taints para agendar a execução dos 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 restrições de propagação de topologia do Pod para controlar como os pods são distribuídos no cluster 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 escalar dinamicamente o número de nós de trabalho quando o tráfego aumentar. Com o Dimensionador Automático de Pod Horizontal e o dimensionador automático do cluster AKS, os volumes de nó e pod são ajustados dinamicamente em tempo real, de acordo com a condição de tráfego e para evitar tempos de inatividade causados por problemas de capacidade. Para obter mais informações, confira Escalar automaticamente um cluster para atender às demandas de aplicativo no AKS (Serviço de Kubernetes do Azure). Considere usar o KEDA (Dimensionamento Automático Controlado por Eventos do Kubernetes), se você quiser escalar o número de pods de um sistema de mensagens hospedado pelo Kubernetes, como RabbitMQ ou Apache ActiveMQ, com base no comprimento de uma determinada fila. Com o KEDA, você pode impulsionar 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, uma fila do RabbitMQ ou uma fila do ActiveMQ. Para obter mais informações sobre o KEDA, confira o Dimensionamento Automático Controlado por Eventos do Kubernetes.

Isolamento

Ao criar 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 do sistema de mensagens, como filas, tópicos e assinaturas, no mesmo sistema de mensagens. Por exemplo, um aplicativo multilocatário pode receber mensagens que transportam dados para vários locatários, de uma única fila doBarramento de Serviço do Azure. Essa 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 poderá causar uma lista de pendências de mensagens. Esse problema, também conhecido como o problema do Vizinho Barulhento, pode prejudicar o contrato de nível de serviço em termos de latência para alguns locatários. O problema ficará mais evidente se o aplicativo consumidor ler e processar mensagens da fila uma de cada vez, em ordem cronológica estrita e se o tempo necessário para processar uma mensagem depender do número de itens no conteúdo. Ao compartilhar um ou mais recursos de fila entre vários locatários, a infraestrutura do sistema de mensagens e os sistemas de processamento devem ser capazes de acomodar o tráfego esperado baseado em requisitos de dimensionamento e taxa de transferência. Essa abordagem arquitetônica é adequada em cenários nos quais uma solução multilocatário adota um único pool de processos de trabalho a fim de receber, processar e enviar mensagens para todos os locatários.
  • Vários locatários compartilham o mesmo sistema de mensagens, mas usam diferentes recursos de tópico ou fila. Essa abordagem fornece melhor isolamento e proteção de dados a um custo mais alto, maior complexidade operacional e menor agilidade porque os administradores do 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 impede que um locatário crie um gargalo que possa afetar os outros locatários.
  • Um sistema de mensagens separado e dedicado é usado para cada locatário. Por exemplo, uma solução multilocatário pode usar um namespace do Barramento de Serviço do Azure distinto para cada locatário. Essa solução fornece o grau máximo de isolamento, com maior complexidade e custo operacional. Essa abordagem garante um desempenho consistente e permite fazer ajustes finos no sistema de mensagens com base em 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 do 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 de PaaS totalmente gerenciado, como um namespace do Barramento de Serviço do Azure ou um sistema de mensagens hospedado pelo Kubernetes, como 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 dessa abordagem é que ela aumenta a complexidade operacional e reduz a agilidade, especialmente quando o número de locatários cresce ao longo do tempo.

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

  • Se os locatários precisarem usar a própria chave para criptografar e descriptografar mensagens, uma solução multilocatário deverá fornecer a opção de adotar um namespace do Barramento de Serviço do Azure Premium separado para cada locatário. Para obter mais informações, veja Configurar chaves gerenciadas pelo cliente para criptografar dados inativos do Barramento de Serviço do Azure.
  • Se os locatários precisarem de um alto nível de resiliência e continuidade dos negócios, uma solução multilocatário deverá fornecer a capacidade de provisionar um namespace do Barramento de Serviço Premium com recuperação de desastre geográfico e zonas de disponibilidade habilitadas. Para mais informações consulte Recuperação de desastre em área geográfica 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 cada um deles aumentar o nível de isolamento de dados e reduzir a complexidade de lidar com várias entidades de sistemas de mensagens. Cada instância do sistema de processamento poderia 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 complexidade maior 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 do Hubs de Eventos do Azure compartilhada. Essa solução fornece um alto nível de agilidade, pois a integração de um novo locatário não requer a criação de um recurso de ingestão de eventos dedicado, mas fornece um baixo nível de proteção de dados, pois intercala 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 requisitos de isolamento de dados, no qual 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 dos negócios, um multilocatário deverá fornecer a capacidade de provisionar um namespace do Hubs de Eventos Premium, com recuperação de desastre geográfico e zonas de disponibilidade habilitadas. Para saber mais, consulte Hubs de Eventos do Azure - Recuperação de desastre geográfico.
  • Os Hubs de Eventos Dedicados, com a Captura do 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 regulatória. Para obter mais informações, consulte Capturar eventos por meio dos Hubs de Eventos do Azure no Armazenamento de Blobs do Azure ou no Azure Data Lake Storage.
  • 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 separada da Grade de Eventos deve ser criada para cada aplicativo consumidor. Se o aplicativo usar várias instâncias da Grade de Eventos para enviar notificações a um grande número de organizações externas, considere usar 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, confira Noções básicas sobre domínios de eventos para gerenciar tópicos da Grade de Eventos.

Complexidade da implementação

Ao criar uma solução multilocatário, é essencial considerar como o sistema evoluirá a médio e longo prazo, a fim de impedir que a complexidade cresça ao longo do tempo até que seja necessário reformular parte ou toda a solução. Essa reformulação ajudará a lidar com um número crescente de locatários. Ao criar um sistema de mensagens, você deve considerar o crescimento esperado em volumes de mensagens e locatários nos próximos anos e criar um sistema que possa escalar, a fim de acompanhar o tráfego previsto e reduzir a complexidade de operações como provisionamento, monitoramento e manutenção.

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

Uma preocupação específica para soluções de dados multilocatário é o nível de personalização que você dá suporte. Qualquer personalização deve ser configurada e aplicada automaticamente pelo sistema de provisionamento de aplicativo (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 for implantado.

Complexidade de gerenciamento e operações

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

  • Você pode planejar hospedar o sistema de mensagens usado pelo aplicativo em um conjunto dedicado de máquinas virtuais, um para cada locatário. Nesse caso, como você planeja implantar, atualizar, monitorar e escalar esses sistemas?
  • Da mesma forma, se você conteinerizar e hospedar o sistema de mensagens em um cluster compartilhado do Kubernetes, como planeja implantar, atualizar, monitorar e escalar 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 o sistema de mensagens aproveita um serviço PaaS, como o Barramento de Serviço do Azure, você deve fazer as seguintes perguntas:
  • Como você migrará locatários se eles precisarem mudar 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 questões como o problema do Vizinho Barulhento, portanto, considere as desvantagens com cuidado.

Abordagens e padrões a serem considerados

Vários Padrões de Design na Nuvem do Centro 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 multilocatário do Barramento de Serviço para a maioria dos locatários, mas pode implantar um namespace dedicado de locatário único do Barramento de Serviço para os locatários que pagam mais ou 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 multilocatário do Barramento de Serviço ou namespaces dedicados dentro de um carimbo.

Padrão de Carimbos de Implantação

Para obter mais informações sobre o padrão de Carimbos de Implantação e multilocação, confira 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, confira os Modelos de locação a serem considerados para uma solução multilocatário.

Sistema de mensagens compartilhado

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 e, portanto, reduz o custo total da propriedade. Ela também geralmente reduz a sobrecarga de gerenciamento, já 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:

  • Sempre tenha em mente e considere as restrições, os recursos de dimensionamento, as cotas e os limites do recurso em questão. Por exemplo, o número máximo de namespaces do Barramento de Serviço 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 aumentar para dar suporte a mais locatários. Considere com cuidado o dimensionamento máximo 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 escolha antes de selecionar esse padrão.
  • Conforme 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 forem particularmente ativos ou se gerarem mais tráfego do que os outros. Nesse caso, considere aplicar o Padrão de limitação ou o Padrão de limitação de taxa para atenuar 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 do sistema de mensagens. Portanto, quando você compartilha um namespace entre vários locatários, seu aplicativo deve ser capaz de acompanhar o número de operações do sistema 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 detalhes.

Os locatários podem ter diferentes requisitos de segurança, resiliência intra-região, recuperação de desastre 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 Sharding envolve a implantação de vários sistemas de mensagens, chamados de fragmentos, que contêm uma ou mais entidades do sistema 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 entre vários sistemas de mensagens com características diferentes com base na localização ou necessidades deles em termos de desempenho, confiabilidade, proteção de dados ou continuidade dos 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 as filas dele. 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 do sistema de mensagens usadas por um único locatário não serão propagadas entre 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 fragmentação pode dimensionar para um número muito grande de locatários. Além disso, dependendo da carga de trabalho, você poderá obter uma alta densidade de locatários para fragmentos, de modo que o custo possa ser atraente. O Padrão de fragmentação também pode ser usado para lidar com cotas, limites e restrições do serviço e assinatura 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. Neste 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 sistemas de mensagens diferentes para cada locatário.

Implantações particionadas horizontalmente podem ajudar a atenuar um problema de vizinho barulhento se você tiver identificado que a maior parte da carga em seu sistema se deve a componentes específicos que pode implantar separadamente para cada locatário. Por exemplo, talvez seja necessário usar um sistema de transmissão de mensagens ou 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 compartilhado. Por outro lado, é mais fácil estornar os custos de recursos de um sistema dedicado para o locatário exclusivo que faz uso dele ao adotar esse modelo de locação. Essa abordagem permite alcançar 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 serviços de um aplicativo multilocatário, especialmente aqueles usados por um único locatário.

Padrão Geode

O padrão de 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 a qualquer solicitação de 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 de Geode, com sistemas de mensagens implantados entre várias regiões que sincronizam em conjunto.

O Barramento de Serviço do Azure e o Hubs de Eventos do Azure dão suporte à recuperação de desastre de metadados em namespaces de recuperação de desastres primários e secundários, em regiões separadas e zonas de disponibilidade, a fim de fornecer suporte para a melhor resiliência intra-região. Além disso, o Barramento de Serviço do Azure e o 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 saber mais, consulte os recursos a seguir:

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

Outros colaboradores:

Próximas etapas

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