Cenário de desenvolvimento: Isolar ambientes com base no Message Queue for Apache RocketMQ - Serverless App Engine: Central de Documentação do Alibaba Cloud

Como funciona

dg_rocket_mq_workflow

Ao ativar o recurso de canary release, o SAE usa propriedades das mensagens do RocketMQ para roteá-las conforme a tag de ambiente. Essa tag define qual grupo de consumidores receberá cada mensagem:

Tag de ambiente	Grupo de consumidores (exemplo)	Destino das mensagens
(nenhuma — linha de base)	`group1`	Apenas consumidores da linha de base
`gray`	`group1_gray`	Apenas consumidores do canary release

O ambiente de linha de base pode consumir mensagens de ambos os ambientes. As chamadas acionadas pelo consumo de mensagens seguem as mesmas regras de roteamento do tráfego síncrono: solicitações originadas no ambiente de canary release são direcionadas aos serviços downstream de canary release, enquanto as solicitações da linha de base vão para os serviços downstream de linha de base.

O recurso de canary release só é efetivo para mensagens quando ativado tanto nos produtores quanto nos consumidores. Se apenas um dos lados estiver habilitado, o recurso não funcionará.

Pré-requisitos

Antes de começar, verifique se você possui:

Uma versão compatível do Message Queue for Apache RocketMQ. Versões suportadas: 4.2.0 e posteriores.

Variante do RocketMQ	Requisito de versão
Apache RocketMQ (open-source)	RocketMQ Server e RocketMQ Client 4.5.0 ou superior
ApsaraMQ for RocketMQ (comercial)	Platinum Edition; Ons Client 1.8.0.Final ou superior. Para mais informações, consulte a visão geral do início rápido.

Filtragem SQL92 ativada no broker. Defina enablePropertyFilter=true em broker.conf e reinicie o broker.
Suporte tanto ao modo pull quanto ao modo push.
Após ativar o recurso de canary release baseado em RocketMQ, o SAE modifica os grupos de consumidores de mensagens. Por exemplo, se o grupo original for group1 e a tag de ambiente for gray, o SAE o renomeará para group1_gray após a ativação do recurso. Caso utilize o ApsaraMQ for RocketMQ, crie previamente todos os grupos de consumidores que serão renomeados pelo recurso de canary release antes de ativá-lo.

Etapa 1: Implantar as aplicações de demonstração

Baixe o pacote de demonstração.
Implante as aplicações principais — Application A, Application B e Application C. Para obter detalhes, consulte Hospedar aplicações Spring Cloud no SAE.
Implante as aplicações de canary release — Application A-gray, Application B-gray e Application C-gray. Adicione -Dalicloud.service.tag=gray ao comando de inicialização de cada aplicação de canary release para diferenciá-las das aplicações principais.

Se você utilizar um registro de serviços não nativo do SAE, adicione os seguintes parâmetros de inicialização a cada aplicação: -Dnacos.use.endpoint.parsing.rule=false -Dnacos.use.cloud.namespace.parsing=false .

Etapa 2: Ativar o recurso de canary release

Na demonstração, spring-cloud-c atua como produtor e spring-cloud-a como consumidor. Ative o recurso de canary release em ambos adicionando o seguinte parâmetro de inicialização:

-Dprofiler.micro.service.mq.gray.enable=true

Adicione esse parâmetro ao comando de inicialização tanto do spring-cloud-c quanto do spring-cloud-a e, em seguida, reimplante cada aplicação no console do SAE.

Para desativar o recurso, remova o parâmetro e faça uma nova implantação.

Etapa 3: Verificar o isolamento de ambiente

dg_implement_end_to_end_canary_release_via_rocket_mq

A cadeia de chamadas funciona da seguinte forma:

O spring-cloud-zuul recebe uma solicitação para /A/dubbo e a encaminha ao spring-cloud-a.
O spring-cloud-a chama o spring-cloud-b usando o protocolo Dubbo; o spring-cloud-b chama o spring-cloud-c.
O spring-cloud-c produz uma mensagem RocketMQ e retorna sua tag de ambiente e endereço IP.
O spring-cloud-a consome a mensagem e, simultaneamente, chama o spring-cloud-b usando o protocolo Spring Cloud; o spring-cloud-b chama o spring-cloud-c novamente.
Os resultados aparecem nos logs.

Envie uma solicitação de teste para /A/dubbo. A resposta esperada e a saída de log são:

# Response:
A[10.25.xx.xx] -> B[10.25.xx.xx] -> C[10.25.xx.xx]

# Log on spring-cloud-a after consuming the message:
c.a.mse.demo.service.MqConsumer: topic:TEST_MQ,producer:C[10.25.xx.xx],invoke result:A[10.25.xx.xx] -> B[10.25.xx.xx] -> C[10.25.xx.xx]

Para visualizar os logs, acesse o console do SAE e abra o log da aplicação spring-cloud-a.

Confirme se:

As mensagens produzidas por uma aplicação de canary release são consumidas exclusivamente por consumidores de canary release.
As mensagens geradas por uma aplicação da linha de base são consumidas apenas por consumidores da linha de base.
O ambiente de linha de base também consegue consumir mensagens produzidas pelas aplicações de canary release.