Alibaba Cloud Service Mesh:Integre filas de mensagens a swimlanes no modo permissivo

Requisitos da fila de mensagens

A fila de mensagens precisa oferecer suporte a:

• Metadados personalizados nas mensagens — os produtores anexam informações da swimlane a cada mensagem.

• Filtragem no lado do consumidor — os consumidores se inscrevem seletivamente com base em uma chave de filtro (também conhecida como campo de condição de filtragem por tag) para receber apenas mensagens da própria swimlane.

Restrições de implantação

Em uma fila de mensagens baseada em pull, o consumidor não acessa informações de descoberta de serviço da swimlane. Por isso, implante produtores e consumidores juntos: ambos na swimlane ou nenhum deles.

import os
from flask import request

# Read the swimlane assignment from the environment variable
# that ASM injects into the workload pod.
producer_swimlane = os.environ.get("ASM_SWIMLANE_TAG", "default")

# Read the swimlane routing tag from the incoming HTTP request header.
routing_tag = request.headers.get("x-asm-prefer-tag", "")

# Attach both values to the message metadata before publishing.
message = {
    "body": payload,
    "metadata": {
        "filter_key": producer_swimlane,       # Consumer-side filtering
        "x-asm-prefer-tag": routing_tag         # Downstream routing
    }
}

mq_client.publish(topic="order-events", message=message)

Message metadata:
  filter_key:        "v1"              # Swimlane of the producer (APP-B is deployed in v1)
  x-asm-prefer-tag:  "v2"              # Swimlane tag from the original request
Message body:
  { ... actual payload ... }

import os

consumer_swimlane = os.environ.get("ASM_SWIMLANE_TAG", "default")

# Subscribe only to messages whose filter_key matches this consumer's swimlane.
mq_client.subscribe(
    topic="order-events",
    filter_expression=f"filter_key = '{consumer_swimlane}'"
)

Cenário 1: Produtor e consumidor implantados em cada swimlane

Quando ambas as swimlanes v1 e v2 possuem produtores e consumidores:

• O APP-C(v1) se inscreve com a chave de filtro v1 e consome apenas mensagens do APP-B(v1).

• O APP-C(v2) se inscreve com a chave de filtro v2 e consome apenas mensagens do APP-B(v2).

O tráfego permanece isolado dentro de cada swimlane.

Cenário 2: Nem produtor nem consumidor implantados em uma swimlane

Quando a swimlane v2 tem apenas APP-A(v2) e APP-D(v2) — sem produtor ou consumidor:

1. O APP-A(v2) envia uma requisição. Como o APP-B(v2) não existe, o modo permissivo roteia a requisição para o APP-B(v1).

2. O APP-B(v1) grava a mensagem na fila com a chave de filtro v1. O valor de x-asm-prefer-tag nos metadados da mensagem permanece v2 (a tag da swimlane da requisição original).

3. O APP-C(v1) consome a mensagem (a chave de filtro corresponde a v1).

4. O APP-C(v1) remove a tag da swimlane v1 transportada na mensagem, lê o valor de x-asm-prefer-tag (v2) dos metadados e o define na requisição HTTP de saída.

5. O proxy da malha roteia a requisição para o APP-D(v2) com base no cabeçalho x-asm-prefer-tag: v2.

Esse processo preserva o roteamento de swimlane ponta a ponta, mesmo que a mensagem tenha passado pela swimlane de base.

import requests

def on_message(message):
    # Extract the swimlane routing tag from the consumed message.
    routing_tag = message.metadata.get("x-asm-prefer-tag", "")

    # Set the tag as a request header on all downstream HTTP calls.
    headers = {"x-asm-prefer-tag": routing_tag}

    response = requests.post(
        "http://app-d:8080/process",
        json=message.body,
        headers=headers
    )