O Simple Message Queue (SMQ, anteriormente MNS) oferece suporte à migração do AWS Simple Queue Service (SQS) e do AWS Simple Notification Service (SNS). Compare recursos, limites e SDKs entre os serviços e siga um processo de quatro etapas com leitura e escrita duplas para migrar suas cargas de trabalho.
Informações básicas
O SMQ, o Amazon SQS e o Amazon SNS compartilham capacidades de mensageria semelhantes:
O SMQ fornece tanto o modelo de mensageria baseado em filas quanto o modelo baseado em tópicos.
O Amazon SQS oferece o modelo de mensageria baseado em filas.
O Amazon SNS disponibiliza o modelo de mensageria baseado em tópicos.
Como há sobreposição funcional entre os serviços, a migração do Amazon SQS ou Amazon SNS para o SMQ é simples.
Pré-requisitos
Antes de começar, conclua as seguintes tarefas:
Uma conta Alibaba Cloud com o SMQ ativado. Ative o SMQ e autorizar usuários RAM a acessá-lo.
Um inventário das suas filas do Amazon SQS e tópicos do Amazon SNS, incluindo configurações como períodos de retenção, timeouts de visibilidade, definições de atraso, assinaturas e políticas de nova tentativa.
Credenciais de acesso para os ambientes AWS e Alibaba Cloud.
Conhecimento claro sobre seus produtores e consumidores de mensagens para planejar o corte com leitura e escrita duplas.
Mapeamento de conceitos
A tabela a seguir mapeia os principais conceitos entre Amazon SQS/Amazon SNS e SMQ. Observe as diferenças comportamentais na terceira coluna.
|
Conceito AWS |
Equivalente no SMQ |
Diferenças comportamentais |
|
Fila Padrão SQS |
Fila SMQ (modelo de mensageria baseado em filas) |
Ambos suportam estados de mensagem Active, Inactive, Deleted e Expired. O SMQ usa um timeout de visibilidade padrão de 30 segundos; o Amazon SQS não possui valor padrão. |
|
Fila FIFO SQS |
Fila FIFO SMQ (sequenciamento) |
Suportado por ambos. |
|
Fila Dead-letter SQS |
Fila Dead-letter SMQ |
Suportado por ambos. |
|
Tópico SNS |
Tópico SMQ (modelo de mensageria baseado em tópicos) |
Os nomes de tópicos do SMQ não diferenciam maiúsculas de minúsculas (1-120 caracteres). Os nomes de tópicos do Amazon SNS diferenciam maiúsculas de minúsculas (3-64 caracteres). |
|
Tópico FIFO SNS |
Tópico FIFO SMQ (sequenciamento) |
Suportado por ambos. |
|
Assinatura SNS (política de filtro JSON) |
Assinatura SMQ (filtragem baseada em tags) |
A filtragem de dados difere: o SMQ usa filtragem baseada em tags; o Amazon SNS utiliza filtragem baseada em políticas JSON. Converta sua lógica de filtro durante a migração. |
|
Endpoints de Assinatura SNS (Queue, HTTP, SMS, Email, Mobile push, Lambda) |
Endpoints de Assinatura SMQ (Queue, HTTP, Text message, Email, Mobile push, Function Compute) |
O Amazon SNS integra-se ao AWS Lambda; o SMQ integra-se ao Function Compute. |
|
Fila Dead-letter SNS |
Fila Dead-letter SMQ (modelo de tópicos) |
Suportado por ambos. |
Comparação de recursos
As tabelas a seguir comparam os recursos do SMQ, Amazon SQS e Amazon SNS por modelo de mensageria.
Modelo de mensageria baseado em filas
|
Recurso |
SMQ |
Amazon SQS |
|
Ciclo de vida da mensagem |
Suportado (estados: Active, Inactive, Deleted, Expired) |
Suportado (estados: Active, Inactive, Deleted, Expired) |
|
Período de retenção personalizado para mensagens |
Suportado |
Suportado |
|
Atraso de mensagem (período agendado) |
Suportado |
Suportado |
|
Período de timeout de visibilidade |
Suportado |
Suportado |
|
Tamanho máximo da mensagem |
Suportado |
Suportado |
|
Fila dead-letter |
Suportado |
Suportado |
|
Fila FIFO (sequenciamento) |
Suportado |
Suportado |
Modelo de mensageria baseado em tópicos
|
Recurso |
SMQ |
Amazon SNS |
|
Filtragem de dados |
Filtragem de dados por tag |
Filtragem de dados por política JSON |
|
Assinatura de fila |
Suportado |
Suportado |
|
Assinatura HTTP |
Suportado |
Suportado |
|
Assinatura de mensagem de texto |
Suportado |
Suportado |
|
Assinatura de e-mail |
Suportado |
Suportado |
|
Push móvel |
Suportado |
Suportado |
|
Function Compute |
Suportado |
Suportado |
|
Fila dead-letter |
Suportado |
Suportado |
|
Tópico FIFO (sequenciamento) |
Suportado |
Suportado |
Comparação de limites
Algumas diferenças de limites podem afetar seu plano de migração. As tabelas a seguir comparam os limites do SMQ, Amazon SQS e Amazon SNS por modelo de mensageria.
Limites do modelo de mensageria baseado em filas
|
Limite |
SMQ |
Amazon SQS |
|
Nomenclatura de filas |
Diferencia maiúsculas de minúsculas, 1-120 caracteres. |
Diferencia maiúsculas de minúsculas, 1-80 caracteres. |
|
Período de retenção de mensagens |
7 dias |
14 dias |
|
Intervalo de long polling |
Valores válidos: 0 a 30. Valor padrão: 15. Unidade: segundos. |
Valores válidos: 0 a 20. Unidade: segundos. |
|
Payload máximo da mensagem |
64 KB. Para aumentar este limite, envie um ticket. |
256 KB |
|
Período de timeout de visibilidade |
Valores válidos: 1 a 43200. Valor padrão: 30. Unidade: segundos. |
Valores válidos: 1 a 43200. Unidade: segundos. Nenhum valor padrão definido. |
|
ID da Fila |
Os nomes das filas são únicos por região. Os IDs das mensagens são globalmente únicos. Os receipt handles são strings personalizadas. |
Os nomes das filas são únicos por região. Os IDs das mensagens são globalmente únicos. Os receipt handles são strings personalizadas. |
|
Atraso de mensagem |
DelaySeconds: 0-604800 segundos. |
DelaySeconds: 0-604800 segundos. |
|
Número máximo de mensagens acumuladas |
Sem limite |
Sem limite |
|
Consultas máximas por segundo (QPS) |
Sem limite por fila. O QPS total (fila + tópico) tem teto de 20.000 por conta e região. Política de limitação. |
Sem limite |
Limites do modelo de mensageria baseado em tópicos
|
Limite |
SMQ |
Amazon SNS |
|
Nome do tópico |
Não diferencia maiúsculas de minúsculas, 1-120 caracteres. |
Diferencia maiúsculas de minúsculas, 3-64 caracteres. |
|
Tamanho máximo da mensagem |
64 KB |
256 KB |
|
Política de nova tentativa |
Backoff: 3 tentativas em intervalos de 10-20 segundos. Decaimento exponencial: 176 tentativas por dia. |
Backoff: 3 tentativas em intervalos de 20 segundos. Decaimento exponencial: Contagem de tentativas configurável. |
|
Número máximo de assinaturas em um único tópico |
100. Para aumentar este limite, envie um ticket. |
12500000 |
|
QPS Máximo |
Sem limite por tópico. O QPS total (fila + tópico) tem teto de 20.000 por conta e região. Política de limitação. |
300 QPS por tópico ou 10 MB/s. A contagem inicia quando o tópico recebe sua primeira solicitação. |
Principais diferenças de limites e soluções alternativas
Preste atenção nestas diferenças importantes de limites:
Payload máximo da mensagem (64 KB vs. 256 KB): O SMQ tem padrão de 64 KB, contra 256 KB do Amazon SQS e Amazon SNS. Para solicitar um limite maior, envie um ticket. Alternativamente, armazene corpos de mensagens grandes no OSS e passe a referência do objeto na mensagem. Transmitir mensagens superdimensionadas.
Assinaturas máximas por tópico (100 vs. 12.500.000): O SMQ permite 100 assinaturas por tópico por padrão, comparado a 12.500.000 do Amazon SNS. Para aumentar esse limite, envie um ticket.
Período de retenção de mensagens (7 dias vs. 14 dias): O SMQ retém mensagens por até 7 dias, enquanto o Amazon SQS retém por 14 dias. Garanta que seus consumidores processem as mensagens dentro da janela de 7 dias.
Filtragem de dados: O SMQ usa filtragem baseada em tags para assinaturas de tópicos; o Amazon SNS emprega filtragem baseada em políticas JSON. Redesenhe sua lógica de filtro durante a migração.
Comparação de SDKs
A tabela abaixo compara os SDKs disponíveis.
|
SDK |
Alibaba Cloud SMQ |
Amazon SQS |
Amazon SNS |
|
Operações de API |
|||
|
SDK HTTP |
SDK for Java, SDK for Python, SDK for C#, SDK for PHP, SDK for C++, SDK for Go e SDK for JMS |
SDK for Java, SDK for JavaScript, SDK for PHP, SDK for Python, SDK for Ruby e SDK for .NET |
SDK for Java, SDK for JavaScript, SDK for PHP, SDK for Python, SDK for Ruby e SDK for .NET |
Processo de migração
Sincronize filas, tópicos e metadados de assinatura entre a AWS e o SMQ, e utilize políticas de leitura e escrita duplas para migrar os dados.
A migração consiste em quatro etapas, cada uma com objetivo, ações necessárias e critérios de saída.
Etapa 1: Linha de base e preparação de recursos
Objetivo: Preparar recursos equivalentes no SMQ.
Ações:
Inventarie todas as filas do Amazon SQS e tópicos do Amazon SNS. Registre suas configurações: períodos de retenção, timeouts de visibilidade, definições de atraso e assinaturas.
Crie filas e tópicos correspondentes no SMQ com configurações equivalentes. Considere as diferenças de limites: tamanho do payload da mensagem, limites de assinatura e períodos de retenção.
Sincronize os metadados de assinatura. Converta as políticas de filtro JSON do Amazon SNS para filtros baseados em tags do SMQ sempre que aplicável.
Configure o monitoramento tanto na AWS quanto no SMQ para comparar o fluxo de mensagens durante a migração.
Critérios de saída: Filas e tópicos do SMQ criados e configurados. Monitoramento implementado para ambos os ambientes.
Etapa 2: Ativar leitura dupla nos consumidores
Objetivo: Habilitar a leitura dupla para que os consumidores processem mensagens de ambos os serviços.
Ações:
Atualize as aplicações consumidoras para ler das filas do Amazon SQS e do SMQ (leitura dupla), garantindo que elas lidem com mensagens do SMQ antes da mudança dos produtores.
Valide se as mensagens do SMQ são consumidas corretamente. Verifique a compatibilidade do formato da mensagem, o comportamento de confirmação e o tratamento de erros.
Monitore o atraso do consumidor e as taxas de erro em ambos os lados para confirmar que o consumo do SMQ está estável.
Critérios de saída: Consumidores processando mensagens do SMQ com sucesso e sem erros por um período sustentado.
Etapa 3: Mudar produtores para o SMQ
Objetivo: Alterar os produtores para escrever no SMQ, mantendo a leitura dupla no lado do consumidor.
Ações:
Atualize as aplicações produtoras para publicar mensagens no SMQ em vez de, ou além do, Amazon SQS.
Se estiver executando escrita dupla, monitore ambos os fluxos de mensagens para confirmar que elas chegam corretamente ao SMQ.
Após a mudança completa dos produtores para o SMQ, interrompa a escrita dupla. Os consumidores devem continuar com a leitura dupla para drenar quaisquer mensagens restantes do Amazon SQS.
Critérios de saída: Todos os produtores publicando com sucesso no SMQ. Entrega de mensagens confirmada via monitoramento.
Etapa 4: Descomissionar recursos da AWS
Objetivo: Descomissionar recursos do Amazon SQS/Amazon SNS.
Ações:
Aguarde a drenagem de todas as mensagens restantes nas filas do Amazon SQS. Monitore a profundidade da fila até que atinja zero.
Remova a lógica de leitura dupla das aplicações consumidoras para que leiam apenas do SMQ.
Descomissione as filas do Amazon SQS e os tópicos do Amazon SNS na AWS.
Atualize sua documentação e runbooks para refletir a nova arquitetura baseada em SMQ.
Critérios de saída: Todos os recursos do Amazon SQS/Amazon SNS descomissionados. Todos os produtores e consumidores operando exclusivamente através do SMQ.
Testes e validação
Execute estes testes antes e durante a migração:
Teste funcional: Envie mensagens de teste pelo SMQ. Verifique se os consumidores as recebem corretamente e se os atributos da mensagem, atrasos e timeouts de visibilidade funcionam conforme o esperado.
Validação de filtro: Confirme se os filtros baseados em tags do SMQ produzem os mesmos resultados que seus filtros de política JSON do Amazon SNS.
Teste de desempenho: Compare o throughput e a latência das mensagens entre sua configuração AWS e o SMQ. O limite de QPS do SMQ é de 20.000 por conta e região. Política de limitação.
Teste de fila dead-letter: Envie mensagens malformadas ou improcessáveis para verificar se as filas dead-letter do SMQ as capturam corretamente.
Teste de comportamento de nova tentativa: Valide se a política de nova tentativa (backoff e decaimento exponencial) atende aos seus requisitos. Note as diferenças nos intervalos e contagens de tentativas entre o SMQ e o Amazon SNS.
Monitoramento e alertas: Confirme se suas ferramentas de monitoramento capturam métricas do SMQ (contagem de mensagens, atraso do consumidor, taxas de erro) e se os alertas disparam conforme esperado.
Preparação para rollback: Mantenha os recursos do Amazon SQS/Amazon SNS ativos durante as Etapas 2 e 3. Se surgirem problemas com o SMQ, reverta os produtores para o Amazon SQS e os consumidores para o modo de leitura dupla até a resolução.