Melhores práticas de SLA - ApsaraMQ for RabbitMQ: Central de Documentação do Alibaba Cloud

O ApsaraMQ for RabbitMQ oferece um service de mensagens altamente disponível e compatível com RabbitMQ, que suporta o protocolo AMQP 0-9-1. O SLA do product garante a disponibilidade do service no lado da plataforma, o que não equivale a 100% de disponibilidade ponta a ponta para o seu negócio.

SLA do product e disponibilidade do negócio

De acordo com o Contrato de Nível de Service oficial do ApsaraMQ for RabbitMQ, a disponibilidade do service é medida por instância em uma base mensal. O compromisso básico no contrato atual é de, no mínimo, 99,95%. Com base em um mês civil de 30 dias, 99,95% corresponde a aproximadamente 21,6 minutos de indisponibilidade, conforme definido pelo contrato. Esse valor ilustra apenas a métrica de SLA e não define a janela de falha aceitável para o seu negócio. Os cálculos reais estão sujeitos às definições de indisponibilidade do service, às exclusões e ao contrato vigente no momento da compra.

A disponibilidade do negócio também é afetada pela reconexão do cliente, condições de rede e DNS, implantação de aplicações, capacidade de processamento de consumo, recursos de processamento idempotente, desastres entre regiões, ciclo de vida da versão e configurações específicas do cliente. Se o objetivo de continuidade do seu negócio exceder o SLA de uma única instância, você deve criar recursos de multi-instância, multirregião, failover e idempotência de mensagens tanto no lado da aplicação quanto na arquitetura de recursos.

As métricas de SLA podem variar conforme o tipo de instância ou especificação. Os direitos específicos estão sujeitos à página de compra, ao site oficial da Alibaba Cloud e ao contrato vigente no momento da aquisição. Uma solução multi-instância não cria um novo SLA de product, nem é possível multiplicar os SLAs de duas instâncias. A disponibilidade do negócio depende do isolamento de falhas, sincronização de mensagens, failover do cliente e da eficácia dos simulados.

Limites da arquitetura

O ApsaraMQ for RabbitMQ é compatível com o protocolo AMQP 0-9-1 e utiliza uma arquitetura gerenciada de múltiplos nós no lado do servidor. Métodos de acesso como endpoint público, VPC e ponto de acesso de conexão de rede privada PrivateLink estão sujeitos ao console e à documentação oficial.

O ApsaraMQ for RabbitMQ melhora a disponibilidade da instância por meio de recursos de múltiplos nós e multizona. O lado do servidor usa vários nós para lidar com conexões e solicitações. Quando um único nó ou zona do servidor apresenta uma anomalia, os recursos de múltiplos nós ajudam a reduzir o impacto na disponibilidade da instância. As capacidades específicas dependem do tipo de instância, região e página de compra.

As conexões do cliente são tratadas na granularidade de Connection. Estabelecer várias Connections de longa duração distribui o tráfego de forma mais uniforme entre vários nós, mas não garante que cada Connection seja direcionada a um nó diferente. Criar vários Channels em uma única Connection AMQP melhora a multiplexação simultânea dentro dessa Connection, mas não substitui a distribuição de nós no lado do servidor no nível de Connection. Para cargas de trabalho de alta concorrência ou críticas, estabeleça várias Connections de longa duração e distribua produtores e consumidores pelo pool de conexões para evitar concentrar todo o tráfego em uma única Connection ou em poucas Connections.

Os cenários a seguir não são resolvidos por uma arquitetura de instância única:

Falhas no nível da região, falhas de rede entre regiões ou anomalias de VPC, DNS ou grupo de segurança no lado do cliente
Clientes que não configuraram reconexão automática, recriação de Channel ou ressinscrição de consumidor
Clientes que usam apenas algumas Connections de longa duração, fazendo com que o tráfego não seja suficientemente distribuído entre os nós do servidor
Processamento lento pelo consumidor, falhas no processamento do negócio, acúmulo de mensagens ou limitação devido a cotas excedidas
Falta de processamento idempotente, causando consumo duplicado, entrega fora de ordem ou efeitos colaterais no negócio durante failover ou replay

Melhorias no lado do cliente

Independentemente da solução de implantação escolhida, verifique se sua implementação de cliente atende aos seguintes requisitos. Para obter orientações completas, consulte as Notas de uso do SDK e as melhores práticas para usar um cliente Spring Boot.

Reconexão automática — Recrie automaticamente a Connection após a desconexão. Dependendo do SDK utilizado, verifique os recursos de recuperação de topologia e de consumidor. Para mais informações, consulte Configurar reconexão automática para um cliente.
Múltiplas Connections para distribuição de tráfego — Configure várias Connections de longa duração com base na concorrência de produção e consumo e na cota de Connections da instância. Use Connections separadas para produção e consumo. Não concentre toda a produção e consumo em uma única Connection e não crie ou feche Connections frequentemente. Para recomendações gerais, consulte Connections e channels. Para clientes Spring, consulte as melhores práticas para usar um cliente Spring Boot.
Recriação de Channel — Os Channels do RabbitMQ não são recursos permanentes. Se ocorrerem exceções de protocolo, conflitos de declaração de recursos ou limitação, recrie o Channel. Em caso de conflitos de declaração de recursos, corrija primeiro os parâmetros de declaração. Para cenários de limitação, aplique backoff e redução de carga antes de recriar, evitando loops de recriação. Os Channels podem reutilizar Connections, mas não substituem a distribuição de nós no lado do servidor no nível de Connection. Para mais informações, consulte as melhores práticas para limitação de instância.
Recuperação de consumidor — Após a reconexão, restabeleça as assinaturas de consumidor restaurando basic.consume e os callbacks do consumidor. Verifique se o comportamento de recuperação de Queues exclusivas, Consumer Tags e outros recursos após a reconexão atende às suas expectativas.
Publisher Confirm — Use o Publisher Confirm no lado de produção para determinar se o servidor recebeu e assumiu a responsabilidade pela mensagem. O Publisher Confirm não significa que o consumidor processou a mensagem. Quando a confirmação expirar ou não for reconhecida, tente novamente com o mesmo ID de mensagem de negócio seguindo regras idempotentes.
ACK e nova tentativa do consumidor — Envie o ACK somente após o processamento bem-sucedido do negócio. Em caso de falha, execute reject, nack, nova tentativa com contagem limitada ou encaminhe para uma fila de mensagens mortas (dead letter queue), conforme sua estratégia de negócio. Evite reenfileiramento infinito que crie loops de nova tentativa.
Processamento idempotente — Produção, roteamento, failover e replay podem gerar mensagens duplicadas. O produtor deve manter um ID de mensagem de negócio estável para a mesma mensagem, e o consumidor deve deduplicar por ID de negócio. Para mais informações, consulte Idempotência de mensagens.
Limitação e circuit breaking — Quando a instância estiver anormal ou o downstream não estiver saudável, o produtor deve limitar e aplicar backoff com limites máximos de novas tentativas para evitar amplificação de retentativas, acúmulo e falhas em cascata. Para mais informações, consulte as melhores práticas para limitação de instância.
Atualização do endereço de acesso — Se você alternar instâncias por meio de um centro de configuração ou nomes de domínio gerenciados pelo cliente, o cliente deve suportar a atualização do endereço de acesso para evitar manter endereços obsoletos indefinidamente. Ao usar nomes de domínio gerenciados pelo cliente, verifique o TTL do DNS, o cache de DNS do cliente ou da JVM e o comportamento de verificação de nome de host TLS.

Soluções recomendadas

As seções a seguir descrevem quatro soluções de implantação em níveis crescentes de disponibilidade. A tabela abaixo resume cada solução para ajudar você a identificar a mais adequada para sua carga de trabalho. Além das considerações específicas de cada solução, verifique se seu cliente atende aos requisitos descritos em Melhorias no lado do cliente.

Para cargas de trabalho que exigem maior estabilidade, isolamento de recursos ou previsibilidade de capacidade, selecione a Platinum Edition ou a Serverless Exclusive Edition. As capacidades específicas e os termos de SLA estão sujeitos à descrição do tipo de instância e à página de compra.

Solução	Escopo aplicável	Pré-requisitos principais	Limitação principal
Linha de base de instância única	Caminhos não críticos com requisitos flexíveis de RTO/RPO	Reconexão de cliente, monitoramento e alertas	Apenas o SLA de plataforma do tipo de instância
Standby com duas instâncias na mesma região	Cargas de trabalho principais que precisam de recuperação de falhas no nível da instância dentro da mesma região	Centro de configuração, sincronização de mensagens e processamento idempotente	Não substitui a recuperação de desastres entre regiões
Primário-standby entre regiões	Cargas de trabalho que precisam de proteção contra falhas no nível da região	Instâncias entre regiões, roteamento de mensagens e condições definidas de RTO/RPO e switchback	Sem failover transparente por padrão
Ativo-ativo	Cargas de trabalho com processamento idempotente, deduplicação e resolução de conflitos maduros	IDs de mensagem globais, estratégias de deduplicação e resolução de conflitos	Não recomendado como solução padrão

Solução de linha de base de instância única

Esta solução aplica-se a caminhos não críticos, cargas de trabalho que toleram curta indisponibilidade e cenários com requisitos flexíveis de RTO e RPO.

Considerações principais de design

Com base nos tipos de instância e nos limites, selecione uma especificação de instância que atenda aos requisitos do seu negócio para TPS, Queues, Connections, tamanho de mensagem e período de retenção.
Ative a reconexão automática de Connection no cliente e garanta que ele tenha recursos de recriação de Channel e recuperação de consumidor.
Estabeleça várias Connections AMQP de longa duração por instância de aplicação, conforme a concorrência do negócio, e distribua o tráfego de produção e consumo por meio de um pool de conexões. Não transporte todo o tráfego em uma única Connection para depois apenas aumentar o número de Channels.
Configure Publisher Confirm, ACK do consumidor, nova tentativa por tempo limite, filas de mensagens mortas (dead letter queues) e alertas.
Conclua as atualizações de versão da instância conforme exigido pela política oficial de gerenciamento de versões e notificações de atualização. Não execute versões expiradas ou sem manutenção por longos períodos.
Configure alertas para métricas principais, incluindo contagem de conexões, throughput de envio e consumo, códigos de erro, acúmulo em Queue, latência de consumo e limitação, com base em monitoramento e alertas.

Riscos e limitações

Uma solução de instância única fornece apenas o SLA do product correspondente ao tipo de instância, o que não equivale a 100% de disponibilidade no lado do negócio.
Se o seu negócio não puder tolerar a janela de falha de uma única instância, atualize para uma solução de recuperação de desastres multi-instância.

Solução de standby com duas instâncias na mesma região

Esta solução destina-se a cargas de trabalho principais que precisam melhorar a recuperação de falhas no nível da instância dentro da mesma região, mas não exigem recuperação de desastres entre regiões.

Visão geral da arquitetura

Considerações principais de design

Adquira duas instâncias RabbitMQ na mesma região. Uma configuração de duas instâncias na mesma região não substitui a recuperação de desastres entre regiões.
Mantenha o Vhost, Exchange, Queue, Binding, permissões de conta e políticas de acesso à rede das instâncias primária e standby funcionalmente equivalentes. (Recomendado) Gerencie recursos por meio de configuração automatizada ou declarações de inicialização da aplicação para evitar desvio de configuração. Gerencie as credenciais das instâncias primária e standby separadamente e faça o rodízio delas conforme sua política de segurança.
Opções de sincronização de mensagens:
- Escrita dupla pela aplicação — O produtor escreve nas instâncias primária e standby simultaneamente. A escrita dupla pela aplicação pode reduzir lacunas de dados causadas por falhas de escrita em caminho único, mas não fornece garantias de atomicidade entre instâncias. Trate sucesso parcial, tempo limite de confirmação, nova tentativa idempotente e compensação.
- Roteamento global de mensagens — Use o roteamento global de mensagens para encaminhar mensagens assincronamente de uma Queue de origem na instância primária para uma Queue ou Exchange na instância standby. Este método possui latência de sincronização, e o RPO depende do acúmulo de roteamento e das condições de rede. O suporte a recursos está sujeito à descrição do tipo de instância e ao console.
O roteamento global de mensagens consome da Queue de origem e encaminha mensagens para o destino. Não se trata de uma replicação sidecar da Queue de origem. Não reutilize diretamente uma Queue que os consumidores do negócio estão consumindo ativamente como fonte de roteamento. Vincule a Exchange de origem tanto a uma Queue de negócio quanto a uma Queue dedicada de sincronização de recuperação de desastres, e use a Queue dedicada como source de roteamento. Para detalhes sobre a semântica, consulte roteamento global de mensagens e RabbitMQ Shovel.
Se o tipo de destino do roteamento global de mensagens estiver definido como Exchange, verifique se a Exchange de destino possui Queues vinculadas capazes de armazenar mensagens. Caso contrário, as mensagens roteadas para a Exchange poderão ser perdidas se nenhuma Queue estiver disponível para recebê-las.
Por padrão, os consumidores consomem apenas da instância primária. Durante o failover, inicie ou escale os consumidores na instância standby e impeça que as instâncias primária e standby consumam simultaneamente o mesmo fluxo de negócio para evitar efeitos colaterais duplicados.
Implemente processamento idempotente por ID de mensagem de negócio, permitindo entrega duplicada ou compensatória após o failover.

Procedimento de failover recomendado

Confirme por meio de monitoramento que a instância primária está indisponível ou apresentando anomalias de desempenho que afetam as operações de envio ou consumo do negócio e não se recuperou dentro da janela esperada.
Pause, limite ou degrade as escritas no lado da produção conforme seu plano de contingência de negócio para evitar que a lacuna de dados entre primário e standby aumente durante a janela de falha.
Alterne para a instância standby por meio do centro de configuração ou da configuração de endereço de acesso da aplicação. Se você usar DNS gerenciado pelo cliente, verifique se o cache de DNS e a verificação TLS não bloqueiam o failover.
Inicie consumidores na instância standby ou aumente o peso de consumo da instância standby.
Monitore a taxa de sucesso de envio, taxa de consumo, acúmulo em Queue e taxa de sucesso do negócio.
Após a recuperação da instância primária, conclua a reconciliação, compensação e deduplicação com base nos registros de envio e consumo do negócio, métricas de acúmulo e IDs de mensagem de negócio antes de retornar (switchback) por meio de um processo de mudança controlado.

Solução de recuperação de desastres primário-standby entre regiões

Esta solução aplica-se a cargas de trabalho principais que precisam de proteção contra falhas no nível da região ou a cargas de trabalho inerentemente implantadas em várias regiões.

Visão geral da arquitetura

Considerações principais de design

Crie instâncias RabbitMQ em duas regiões distintas. Mantenha a topologia, as permissões de conta e as políticas de acesso à rede funcionalmente equivalentes. Gerencie as credenciais separadamente para cada instância.
Use o roteamento global de mensagens, escrita dupla pela aplicação ou um mecanismo de Outbox de negócio para sincronizar mensagens críticas. O suporte a recursos para roteamento global de mensagens está sujeito à descrição do tipo de instância e ao console.
Ao usar roteamento global de mensagens, aplique o mesmo design de Queue dedicada de sincronização de recuperação de desastres da solução de mesma região para evitar competir com os consumidores do negócio pela Queue de origem.
Se o tipo de destino do roteamento global de mensagens estiver definido como Exchange, verifique se a Exchange de destino possui Queues vinculadas capazes de armazenar mensagens.
Ao utilizar roteamento global de mensagens, avalie os custos do EventBridge e da Cloud Enterprise Network (CEN), a latência de sincronização de mensagens e o acúmulo de roteamento. Ao usar escrita dupla pela aplicação ou Outbox, planeje separadamente a rede do cliente, pontos de acesso, listas de permissões, custos de link e abordagem de failover.
O limite de tamanho de mensagem no destino não deve ser inferior ao da origem. Mensagens que excederem o limite do destino podem falhar no roteamento.
O roteamento global de mensagens não suporta roteamento transitivo. Uma rota de A para B para C não encaminha automaticamente mensagens de A através de B para C. Se precisar de roteamento de A para C, configure uma rota direta de A para C.
A recuperação de desastres entre regiões não deve presumir failover totalmente transparente por padrão. Defina claramente o RTO, RPO, aprovadores de failover, condições de switchback e mecanismo de compensação de dados.

Solução ativo-ativo

Esta solução destina-se a cargas de trabalho que já possuem recursos robustos de processamento idempotente, deduplicação, resolução de conflitos e consistência eventual, e onde ambas as regiões ou instâncias precisam lidar com tráfego simultaneamente. O modelo ativo-ativo é um design de arquitetura de aplicação do cliente e não significa que o product forneça automaticamente recursos ativo-ativo entre instâncias ou consistência global.

Considerações principais de design

O produtor deve usar IDs de mensagem de negócio globalmente únicos que permaneçam estáveis durante novas tentativas.
O consumidor deve implementar processamento idempotente e deduplicação por chave primária de negócio. Não confie na contagem de entregas do RabbitMQ como única source de verdade.
Defina claramente o caminho de escrita primário e a direção de sincronização para cada mensagem, evitando loops de sincronização bidirecional ou amplificação de duplicação.
Estabeleça limites claros para a semântica de ordenação. O modelo ativo-ativo entre instâncias geralmente não fornece garantias de ordenação estrita global.
Defina estratégias claras de resolução de conflitos, incluindo pagamentos duplicados, pedidos duplicados, deduções de estoque e outros efeitos colaterais do negócio.
Mantenha capacidades contínuas de simulados e reconciliação automatizada.

Riscos e limitações

A solução ativo-ativo não é recomendada como padrão. A maioria das cargas de trabalho deve preferir primário-standby ou degradação em camadas para evitar perda de estabilidade causada pela complexidade.

Simulados e critérios de aceitação

Antes de lançar uma solução de recuperação de desastres multi-instância, conclua pelo menos os seguintes simulados:

Item do simulado	Objetivo de verificação
Falha de acesso à instância primária	O cliente faz failover para a instância standby conforme esperado. O RTO atinge a meta.
Falha de envio na instância primária	O produtor identifica falhas e tenta novamente ou compensa sem duplicação descontrolada.
Distribuição de multi-conexão	As instâncias da aplicação estabelecem várias Connections de longa duração conforme configurado. Após reinicialização ou failover, o pool de conexões se recupera e o tráfego não permanece concentrado em uma única Connection.
Reinicialização do consumidor	A aplicação recria Channels e restabelece as assinaturas de consumidor.
Latência do roteamento global de mensagens	O acúmulo na Queue dedicada de origem, o fluxo de entrada no destino e a latência de sincronização são observáveis.
Assunção de consumo pela instância standby	Os consumidores da instância standby processam mensagens existentes após a inicialização. A idempotência do negócio é eficaz.
Retorno para a instância primária	A reconciliação do negócio, compensação, deduplicação e switchback canário são concluídos com sucesso.

As métricas a seguir definem os critérios de aceitação para sua solução de recuperação de desastres:

RTO — Tempo desde o momento em que o negócio é afetado ou as condições de failover são atendidas até a recuperação do negócio.
RPO — Faixa máxima de mensagens que podem ser perdidas ou exigir compensação durante a janela de falha.
Taxa de duplicação — Percentual de mensagens duplicadas durante failover e replay e seu impacto no negócio.
Tempo de recuperação de acúmulo — Tempo para o acúmulo em Queue retornar aos níveis normais após o failover.
Taxa de sucesso de recuperação do cliente — Taxa de sucesso de reconexão de Connection, recriação de Channel e ressinscrição de consumidor.
Distribuição de Connections — Após reinicialização da aplicação, scale-out ou failover, o tráfego de produção e consumo continua distribuído entre várias Connections de longa duração. Evite o uso prolongado de apenas uma única Connection.