Escenario de desarrollo: Aislamiento de entornos basado en Message Queue for Apache RocketMQ - Serverless App Engine

Serverless App Engine (SAE) se integra con ApsaraMQ for RocketMQ para extender el aislamiento de entornos de extremo a extremo a las rutas de mensajes asíncronos, sin necesidad de modificar su código de negocio.

Funcionamiento

dg_rocket_mq_workflow

Cuando la función de canary release está habilitada, SAE utiliza las propiedades de los mensajes de RocketMQ para enrutarlos según la etiqueta de entorno. La etiqueta de cada mensaje determina qué grupo de consumidores lo recibe:

Etiqueta de entorno	Grupo de consumidores (ejemplo)	Destino del enrutamiento de mensajes
(Ninguna — línea base)	`group1`	Solo consumidores de la línea base
`gray`	`group1_gray`	Solo consumidores de canary release

El entorno de línea base puede consumir mensajes de ambos entornos. Las llamadas desencadenadas por el consumo de mensajes siguen las mismas reglas de enrutamiento que el tráfico síncrono: las solicitudes del entorno de canary release se dirigen a los servicios posteriores de canary release, y las solicitudes de la línea base se dirigen a los servicios posteriores de la línea base.

La función de canary release solo es efectiva para los mensajes si está habilitada tanto en los productores como en los consumidores. Si solo uno de los lados la habilita, la función no surte efecto.

Requisitos previos

Antes de empezar, asegúrese de contar con lo siguiente:

Una versión compatible de Message Queue for Apache RocketMQ. Versiones compatibles: 4.2.0 y posteriores.

Variante de RocketMQ	Requisito de versión
Apache RocketMQ (código abierto)	RocketMQ Server y RocketMQ Client 4.5.0 o posterior
ApsaraMQ for RocketMQ (comercial)	Platinum Edition; Ons Client 1.8.0.Final o posterior. Para más información, consulte the quick start overview.

Filtrado SQL92 habilitado en el broker. Establezca enablePropertyFilter=true en broker.conf y reinicie el broker.
Se admiten tanto el modo pull como el modo push.
Al habilitar la función de canary release basada en RocketMQ, SAE modifica los grupos de consumidores de mensajes. Por ejemplo, si su grupo de consumidores original es group1 y su etiqueta de entorno es gray, SAE lo renombra a group1_gray tras activar la función. Si utiliza ApsaraMQ for RocketMQ, cree previamente los grupos de consumidores que la función de canary release renombrará antes de habilitarla.

Paso 1: Despliegue de las aplicaciones de demostración

Descargue el paquete de demostración.
Despliegue las aplicaciones principales: Aplicación A, Aplicación B y Aplicación C. Para más detalles, consulte Host Spring Cloud applications to SAE.
Despliegue las aplicaciones de canary release: Aplicación A-gray, Aplicación B-gray y Aplicación C-gray. Agregue -Dalicloud.service.tag=gray al comando de inicio de cada aplicación de canary release para distinguirlas de las aplicaciones principales.

Si utiliza un registro de servicios no integrado en SAE, agregue los siguientes parámetros de inicio a cada aplicación: -Dnacos.use.endpoint.parsing.rule=false -Dnacos.use.cloud.namespace.parsing=false .

Paso 2: Habilitar la función de canary release

En esta demostración, spring-cloud-c actúa como productor y spring-cloud-a como consumidor. Habilite la función de canary release en ambos agregando el siguiente parámetro de inicio:

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

Agregue este parámetro al comando de inicio tanto de spring-cloud-c como de spring-cloud-a, y luego vuelva a desplegar cada aplicación en la consola de SAE.

Para deshabilitar la función, elimine el parámetro y vuelva a desplegar.

Paso 3: Compruebe el aislamiento de entornos

dg_implement_end_to_end_canary_release_via_rocket_mq

La cadena de llamadas funciona de la siguiente manera:

spring-cloud-zuul recibe una solicitud a /A/dubbo y la reenvía a spring-cloud-a.
spring-cloud-a llama a spring-cloud-b mediante el protocolo Dubbo; spring-cloud-b llama a spring-cloud-c.
spring-cloud-c produce un mensaje de RocketMQ y devuelve su etiqueta de entorno y dirección IP.
spring-cloud-a consume el mensaje y simultáneamente llama a spring-cloud-b mediante el protocolo Spring Cloud; spring-cloud-b vuelve a llamar a spring-cloud-c.
Los resultados aparecen en los registros.

Envíe una solicitud de prueba a /A/dubbo. La respuesta esperada y la salida del registro son:

# 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 consultar los registros, inicie sesión en la consola de SAE y abra el registro de la aplicación spring-cloud-a.

Confirme que:

Los mensajes producidos por una aplicación de canary release solo los consumen los consumidores de canary release.
Los mensajes producidos por una aplicación de línea base solo los consumen los consumidores de línea base.
El entorno de línea base también puede consumir mensajes producidos por aplicaciones de canary release.