Implement an End-to-End Canary Release by Using an MSE Cloud-Native Gateway - Microservices Engine

En una arquitectura de microservices, las llamadas entre aplicaciones suelen ser aleatorias. Al actualizar una aplicación Spring Cloud o Dubbo, puede resultar difícil enrutar tráfico específico hacia la nueva versión. La función de versión canary de extremo a extremo de MSE Microservices Governance permite implementar un control de tráfico granular y de extremo a extremo sin modificar el código de la aplicación. Los lanes aíslan las versiones de las aplicaciones en entornos de ejecución independientes. Al establecer reglas de enrutamiento para un lane, es posible dirigir las solicitudes que cumplen criterios específicos hacia una versión objetivo de la aplicación.

Proceso de implementación

Limitaciones

La función de versión canary de extremo a extremo utiliza la capacidad de enrutamiento basado en etiquetas de MSE Microservices Governance, la cual es distinta del enrutamiento basado en etiquetas propio del gateway. Para evitar conflictos, no aplique reglas separadas de enrutamiento canary o basado en etiquetas a las aplicaciones gestionadas por esta función.
Para consultar las limitaciones de la función de versión canary de extremo a extremo en aplicaciones Java, consulte Java frameworks supported by MSE Microservices Governance.
Para utilizar las capacidades más recientes de versión canary de extremo a extremo, su gateway nativo para la nube de MSE debe tener la versión 2.0.6 o posterior. Para obtener instrucciones sobre cómo actualizar su gateway, consulte Upgrade an MSE cloud-native gateway.

Escenario de ejemplo

El siguiente escenario de realización de pedidos en una arquitectura de comercio electrónico demuestra el control de tráfico de extremo a extremo desde un gateway nativo para la nube de MSE hasta los microservices del backend. La arquitectura de la aplicación consta de un gateway nativo para la nube de MSE y una arquitectura de microservices backend construida con Spring Cloud. La cadena de llamadas del backend involucra tres servicios: un centro de transacciones (A), un centro de productos (B) y un centro de inventario (C). Los clientes acceden a los servicios backend, los cuales utilizan un registro de servicios MSE Nacos para el descubrimiento de servicios.

Después de realizar un pedido, el gateway nativo para la nube de MSE enruta el tráfico entrante al centro de transacciones (A). Posteriormente, el centro de transacciones (A) llama al centro de productos (B), y este último llama al centro de inventario (C) en sentido descendente. La cadena completa de llamadas es: Cliente > gateway nativo para la nube de MSE > A > B > C.

A medida que evoluciona su negocio, las nuevas funciones requieren que publique versiones nuevas de la Aplicación A y la Aplicación C simultáneamente. Antes de que las nuevas versiones entren en producción, debe validar ambas aplicaciones mediante una versión canary. Una vez que confirme que las nuevas versiones son estables, podrá proceder con la publicación oficial.

Las capacidades de versión canary de extremo a extremo del gateway nativo para la nube de MSE y MSE Microservices Governance permiten construir un pipeline de versión canary desde el gateway hacia múltiples servicios backend. Las solicitudes con características específicas se enrutan de manera consistente al entorno canary correspondiente, lo que permite validar varios servicios simultáneamente. Si una versión canary objetivo no está disponible, el tráfico realiza failover automáticamente al entorno base.

使用场景

Conceptos clave

Gateway nativo para la nube de MSE: Un gateway de próxima generación compatible con el estándar Kubernetes Ingress. Admite múltiples métodos de descubrimiento de servicios, incluidos Container Service for Kubernetes (ACK) y MSE Nacos, y ofrece diversos métodos de autenticación para proteger sus servicios.
Lane: Un entorno aislado definido para un grupo de versiones específicas de aplicaciones, como todas las versiones "canary". Solo el tráfico que coincide con las reglas de enrutamiento se dirige a las aplicaciones etiquetadas dentro del lane correspondiente. Una aplicación puede pertenecer a varios lanes y un lane puede contener múltiples aplicaciones, formando una relación de muchos a muchos.
Grupo de lanes: Una colección de lanes. Los grupos de lanes se utilizan principalmente para separar entornos por equipos o escenarios.
Entorno base: El entorno para aplicaciones sin etiquetar. Funciona como entorno de respaldo o de producción para todos los demás entornos.

Requisitos previos

Creación de un clúster de Kubernetes

Para obtener más información, consulte Create an ACK dedicated cluster (discontinued) o Create an ACK managed cluster.

Habilitación de la gobernanza de microservicios de MSE

Importante

Asegúrese de que su agente Java de MSE tenga la versión 3.2.3 o posterior. De lo contrario, sus operaciones comerciales podrían verse afectadas.

Active la Professional Edition en la página de activación de MSE Microservices Governance.
Conecte sus aplicaciones de microservicios ACK al Centro de gobernanza de MSE tal como se describe en Connect ACK microservice applications to the MSE Governance Center.

Creación de un gateway nativo para la nube de MSE

Para obtener más información, consulte Create an MSE cloud-native gateway.

Asociación de un origen de servicio con el gateway nativo para la nube

Para obtener más información, consulte Add a service source.

Nota

Para la función de versión canary de extremo a extremo, los gateways nativos para la nube de MSE actualmente solo admiten clústeres de Container Service for Kubernetes (ACK) e instancias de MSE Nacos como orígenes de servicio.
El gateway nativo para la nube de MSE y el clúster ACK o la instancia MSE Nacos deben estar en la misma virtual private cloud (VPC).

Paso 1: Configuración del entorno base

Paso 1: Despliegue de las aplicaciones base

Inicie sesión en la consola de ACK.
En el panel de navegación izquierdo, haga clic en Clusters. Luego, haga clic en el nombre del clúster que desea gestionar.
En el panel de navegación izquierdo, seleccione Workloads > Deployments.
En la parte superior de la página, seleccione el namespace del clúster y haga clic en Create from YAML.

Despliegue las aplicaciones base.

MSE Nacos

Copie el siguiente contenido YAML para desplegar las versiones base de las aplicaciones A, B y C.

Nota

Reemplace nacos server address en el código por el nombre de dominio interno de su instancia MSE Nacos. Elimine las llaves {}.

Show YAML code

# Base version of Application A
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-a
  namespace: default
spec:
  selector:
    matchLabels:
      app: spring-cloud-a
  template:
    metadata:
      labels:
        app: spring-cloud-a
        msePilotCreateAppName: spring-cloud-a
        msePilotAutoEnable: 'on'
    spec:
      containers:
      - name: spring-cloud-a
        image: registry.cn-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-a:3.0.1
        imagePullPolicy: Always
        ports:
          - containerPort: 20001
        livenessProbe:
          tcpSocket:
            port: 20001
          initialDelaySeconds: 30
          periodSeconds: 60
        env:
        - name: spring.cloud.nacos.discovery.server-addr
          value: {nacos server address}
        - name: dubbo.registry.address
          value: 'nacos://{nacos server address}:8848'
---
# Base version of Application B
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-b
  namespace: default
spec:
  selector:
    matchLabels:
      app: spring-cloud-b
  template:
    metadata:
      labels:
        app: spring-cloud-b
        msePilotCreateAppName: spring-cloud-b
        msePilotAutoEnable: 'on'
    spec:
      containers:
      - name: spring-cloud-b
        image: registry.cn-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-b:3.0.1
        imagePullPolicy: Always
        ports:
          - containerPort: 20002
        livenessProbe:
          tcpSocket:
            port: 20002
          initialDelaySeconds: 30
          periodSeconds: 60
        env:
        - name: spring.cloud.nacos.discovery.server-addr
          value: {nacos server address}
        - name: dubbo.registry.address
          value: 'nacos://{nacos server address}:8848'
---
# Base version of Application C
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-c
  namespace: default
spec:
  selector:
    matchLabels:
      app: spring-cloud-c
  template:
    metadata:
      labels:
        app: spring-cloud-c
        msePilotCreateAppName: spring-cloud-c
        msePilotAutoEnable: 'on'
    spec:
      containers:
      - name: spring-cloud-c
        image: registry.cn-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-c:3.0.1
        imagePullPolicy: Always
        ports:
          - containerPort: 20003
        livenessProbe:
          tcpSocket:
            port: 20003
          initialDelaySeconds: 30
          periodSeconds: 60
        env:
        - name: spring.cloud.nacos.discovery.server-addr
          value: {nacos server address}
        - name: dubbo.registry.address
          value: 'nacos://{nacos server address}:8848'

Container Service (ACK)

Copie el siguiente contenido YAML para desplegar Nacos y simular un registro de servicios autoadministrado.

Show YAML code

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nacos-server
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nacos-server
  template:
    metadata:
      labels:
        msePilotAutoEnable: "off"
        app: nacos-server
    spec:
      containers:
        - name: nacos-server
          image: 'registry.cn-hangzhou.aliyuncs.com/mse-governance-demo/nacos-server:v2.1.2'
          env:
            - name: MODE
              value: standalone
            - name: JVM_XMS
              value: 512M
            - name: JVM_XMX
              value: 512M
            - name: JVM_XMN
              value: 256M
          imagePullPolicy: Always
          livenessProbe:
            failureThreshold: 3
            initialDelaySeconds: 15
            periodSeconds: 10
            successThreshold: 1
            tcpSocket:
              port: 8848
            timeoutSeconds: 3
          readinessProbe:
            failureThreshold: 5
            initialDelaySeconds: 15
            periodSeconds: 15
            successThreshold: 1
            tcpSocket:
              port: 8848
            timeoutSeconds: 3
          resources:
            requests:
              cpu: '1'
              memory: 2Gi
      dnsPolicy: ClusterFirst
      restartPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
  name: nacos-server
spec:
  type: ClusterIP
  ports:
    - name: nacos-server-8848-8848
      port: 8848
      protocol: TCP
      targetPort: 8848
    - name: nacos-server-9848-9848
      port: 9848
      protocol: TCP
      targetPort: 9848
  selector:
    app: nacos-server

Copie el siguiente contenido YAML para desplegar las versiones base de las aplicaciones A, B y C.

Show YAML code

# Base version of Application A
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-a
  namespace: default
spec:
  selector:
    matchLabels:
      app: spring-cloud-a
  template:
    metadata:
      labels:
        app: spring-cloud-a
        msePilotCreateAppName: spring-cloud-a
        msePilotAutoEnable: 'on'
    spec:
      containers:
      - name: spring-cloud-a
        image: registry.cn-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-a:3.0.1
        imagePullPolicy: Always
        ports:
          - containerPort: 20001
        livenessProbe:
          tcpSocket:
            port: 20001
          initialDelaySeconds: 30
          periodSeconds: 60
        # Access the self-managed Nacos instance by using the Nacos Service.
        env:
        - name: spring.cloud.nacos.discovery.server-addr
          value: nacos-server
        - name: dubbo.registry.address
          value: 'nacos://nacos-server:8848'
---
# Base version of Application B
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-b
  namespace: default
spec:
  selector:
    matchLabels:
      app: spring-cloud-b
  template:
    metadata:
      labels:
        app: spring-cloud-b
        msePilotCreateAppName: spring-cloud-b
        msePilotAutoEnable: 'on'
    spec:
      containers:
      - name: spring-cloud-b
        image: registry.cn-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-b:3.0.1
        imagePullPolicy: Always
        ports:
          - containerPort: 20002
        livenessProbe:
          tcpSocket:
            port: 20002
          initialDelaySeconds: 30
          periodSeconds: 60
        # Access the self-managed Nacos instance by using the Nacos Service.
        env:
        - name: spring.cloud.nacos.discovery.server-addr
          value: nacos-server
        - name: dubbo.registry.address
          value: 'nacos://nacos-server:8848'
---
# Base version of Application C
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-c
  namespace: default
spec:
  selector:
    matchLabels:
      app: spring-cloud-c
  template:
    metadata:
      labels:
        app: spring-cloud-c
        msePilotCreateAppName: spring-cloud-c
        msePilotAutoEnable: 'on'
    spec:
      containers:
      - name: spring-cloud-c
        image: registry.cn-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-c:3.0.1
        imagePullPolicy: Always
        ports:
          - containerPort: 20003
        livenessProbe:
          tcpSocket:
            port: 20003
          initialDelaySeconds: 30
          periodSeconds: 60
        # Access the self-managed Nacos instance by using the Nacos Service.
        env:
        - name: spring.cloud.nacos.discovery.server-addr
          value: nacos-server
        - name: dubbo.registry.address
          value: 'nacos://nacos-server:8848'

Copie el siguiente contenido YAML para crear un Service para la aplicación de entrada A.

Show YAML code

# Expose Application A.
apiVersion: v1
kind: Service
metadata:
  name: sc-a
  namespace: default
spec:
  ports:
    - port: 20001
      protocol: TCP
      targetPort: 20001
  selector:
    app: spring-cloud-a
  type: ClusterIP

Paso 2: Exposición de la Aplicación A

New service

Si no ha agregado la Aplicación A al gateway nativo para la nube, siga estos pasos para exponerla.

Inicie sesión en MSE console. Vaya a Cloud-native Gateway > Gateways y haga clic en el nombre de su instancia de gateway. En el panel de navegación izquierdo, seleccione Routes. En la página que aparece, seleccione la pestaña Services y haga clic en Add Service. Para obtener más información, consulte Add a service.
- Si su origen de servicio es un clúster ACK:
  - Service Source: Seleccione Container Service.
  - Namespace: Seleccione default.
  - Services: Seleccione sc-a.
- Si su origen de servicio es una instancia MSE Nacos:
  - Service Source: Seleccione MSE Nacos.
  - Namespace: Seleccione public.
  - Services: Seleccione sc-A.

En la página Routes, seleccione la pestaña Routes. Haga clic en Add Route para crear una ruta para el servicio sc-a/sc-A y exponerlo. Para obtener más información, consulte Create a route.

Parámetro	Descripción
Path	Seleccione el tipo de coincidencia Prefix y establezca el valor de la ruta en /a.
Route Target	Seleccione Single Service.
Backend service	Seleccione sc-A.

Existing service

Si la Aplicación A ya es un servicio en línea en su gateway, siga estos pasos para exponerla.

Inicie sesión en MSE console. Vaya a Cloud-native Gateway > Gateways y seleccione su instancia de gateway. En el panel de navegación izquierdo, seleccione Routes. En la página que aparece, seleccione la pestaña Routes. Edite una ruta existente para exponer el servicio.

Parámetro	Descripción
Path	Seleccione el tipo de coincidencia Prefix y establezca el valor de la ruta en /a.
Route Target	Seleccione Single Service.
Backend service	Seleccione sc-A.

Paso 3: Prueba del tráfico del entorno base

Inicie sesión en la consola de MSE. En la barra de navegación superior, seleccione una región.
En el panel de navegación izquierdo, seleccione Cloud-native Gateway > Gateways. En la página Gateways, haga clic en el ID del gateway.
En el panel de navegación izquierdo, haga clic en Overview.
En la pestaña Endpoint, busque la Ingress IP Address del SLB en la sección Gateway Ingress.
Ejecute el comando curl para probar el tráfico del entorno base. El resultado muestra que el tráfico pasa por las versiones base de las aplicaciones A, B y C.
```
# Test command
curl x.x.1.1/a
# Test result
A[10.0.3.178][config=base] -> B[10.0.3.195] -> C[10.0.3.201]
```
La ausencia de un sufijo de versión para las aplicaciones B y C en la salida indica que las solicitudes se enrutan a sus versiones base.

Paso 2: Configuración del entorno canary

Si una nueva función requiere publicar versiones nuevas de la Aplicación A y la Aplicación C simultáneamente, puede utilizar una versión canary de extremo a extremo para validarlas.

Paso 1: Despliegue de las aplicaciones canary

Inicie sesión en la consola de ACK.
En el panel de navegación izquierdo, haga clic en Clusters. Luego, haga clic en el nombre del clúster que desea gestionar.
En el panel de navegación izquierdo, seleccione Workloads > Deployments.
En la parte superior de la página, seleccione el namespace del clúster y haga clic en Create from YAML.

Copie el siguiente contenido YAML para desplegar las versiones canary de las aplicaciones A y C.

MSE Nacos

Nota

Reemplace {nacos server address} en el código por el nombre de dominio interno de su instancia MSE Nacos. No incluya las llaves {}.

Show YAML code

# Canary version of Application A
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-a-gray
  namespace: default
spec:
  selector:
    matchLabels:
      app: spring-cloud-a-gray
  template:
    metadata:
      labels:
        alicloud.service.tag: gray
        app: spring-cloud-a-gray
        msePilotCreateAppName: spring-cloud-a
        msePilotAutoEnable: 'on'
    spec:
      containers:
      - name: spring-cloud-a
        image: registry.cn-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-a:3.0.1
        imagePullPolicy: Always
        ports:
          - containerPort: 20001
        livenessProbe:
          tcpSocket:
            port: 20001
          initialDelaySeconds: 30
          periodSeconds: 60
        env:
        - name: spring.cloud.nacos.discovery.server-addr
          value: {nacos server address}
        - name: dubbo.registry.address
          value: 'nacos://{nacos server address}:8848'
---
# Canary version of Application C
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-c-gray
  namespace: default
spec:
  selector:
    matchLabels:
      app: spring-cloud-c-gray
  template:
    metadata:
      labels:
        alicloud.service.tag: gray
        app: spring-cloud-c-gray
        msePilotCreateAppName: spring-cloud-c
        msePilotAutoEnable: 'on'
    spec:
      containers:
      - name: spring-cloud-c
        image: registry.cn-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-c:3.0.1
        imagePullPolicy: Always
        ports:
          - containerPort: 20003
        livenessProbe:
          tcpSocket:
            port: 20003
          initialDelaySeconds: 30
          periodSeconds: 60
        env:
        - name: spring.cloud.nacos.discovery.server-addr
          value: {nacos server address}
        - name: dubbo.registry.address
          value: 'nacos://{nacos server address}:8848'

Container Service (ACK)

Show YAML code

# Canary version of Application A
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-a-gray
  namespace: default
spec:
  selector:
    matchLabels:
      app: spring-cloud-a
  template:
    metadata:
      labels:
        alicloud.service.tag: gray
        app: spring-cloud-a
        msePilotCreateAppName: spring-cloud-a
        msePilotAutoEnable: 'on'
    spec:
      containers:
      - name: spring-cloud-a
        image: registry.cn-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-a:3.0.1
        imagePullPolicy: Always
        ports:
          - containerPort: 20001
        livenessProbe:
          tcpSocket:
            port: 20001
          initialDelaySeconds: 30
          periodSeconds: 60
        # Access the self-managed Nacos instance by using the Nacos Service.
        env:
        - name: spring.cloud.nacos.discovery.server-addr
          value: nacos-server
        - name: dubbo.registry.address
          value: 'nacos://nacos-server:8848'
---
# Canary version of Application C
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-c-gray
  namespace: default
spec:
  selector:
    matchLabels:
      app: spring-cloud-c
  template:
    metadata:
      labels:
        alicloud.service.tag: gray
        app: spring-cloud-c
        msePilotCreateAppName: spring-cloud-c
        msePilotAutoEnable: 'on'
    spec:
      containers:
      - name: spring-cloud-c
        image: registry.cn-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-c:3.0.1
        imagePullPolicy: Always
        ports:
          - containerPort: 20003
        livenessProbe:
          tcpSocket:
            port: 20003
          initialDelaySeconds: 30
          periodSeconds: 60
        # Access the self-managed Nacos instance by using the Nacos Service.
        env:
        - name: spring.cloud.nacos.discovery.server-addr
          value: nacos-server
        - name: dubbo.registry.address
          value: 'nacos://nacos-server:8848'

Paso 2: Creación de un grupo de lanes

Inicie sesión en la consola de MSE y seleccione una región en la barra de navegación superior.
En el panel de navegación izquierdo, seleccione Microservices Governance > Full link grayscale.
Si no existe ningún grupo de lanes en el namespace de microservicios seleccionado, haga clic en Create Lane Groups and Lanes. Si ya existe un grupo de lanes, haga clic en + Create Lane Group.

En el panel Create Lane Group, configure los siguientes parámetros y haga clic en OK.

Parámetro	Descripción
Name of Lane Group	Introduzca un nombre para el grupo de lanes.
Entry Type	Seleccione MSE Cloud-native Gateway.
Gateway	Seleccione el gateway nativo para la nube objetivo.
Lane Group Application	Seleccione spring-cloud-a, spring-cloud-b y spring-cloud-c.

Una vez creado el grupo de lanes, podrá consultarlo en la sección Lane Group de la página Full link Grayscale. Para modificar la información del grupo de lanes, haga clic en el icono de edición () y actualice la configuración.

Paso 3: Crear una lane

Nota

Al utilizar la función de versión canary de extremo a extremo, debe agregar una tag especial a sus aplicaciones canary para distinguirlas de otros nodos. En un entorno de contenedores, agregue la etiqueta alicloud.service.tag: ${tag} en spec.template.metadata.labels. En un entorno de ECS, añada el parámetro de inicio de Java -Dalicloud.service.tag=${tag}.
Cuando se utiliza un cloud-native gateway como ingreso para una versión canary de extremo a extremo, MSE admite dos modos de versión canary para las lanes.
- Versión canary por contenido: Recomendado cuando el contenido de la solicitud permite identificar el tráfico canary. De lo contrario, considere modificar su sistema para añadir identificadores canary y obtener mejores resultados; por ejemplo, mantener la consistencia en las solicitudes de un mismo usuario.
- Versión canary por proporción: Modo alternativo para cuando el contenido de la solicitud no permite identificar el tráfico canary y no es posible modificar los sistemas heredados. Este modo puede enrutar solicitudes del mismo origen a diferentes lanes, lo que provoca un comportamiento inconsistente en las solicitudes canary.
El modo de versión canary debe ser consistente en todas las lanes dentro de un grupo de lanes. Solo puede establecer el modo de versión canary al crear la primera lane de un grupo.

En la parte inferior de la página Full link Grayscale, si no existe ninguna lane en el namespace seleccionado, haga clic en Click to create the first shunt Lane. Si ya existe una lane, haga clic en + Create swim lanes.

En el panel Create swim lanes, configure los ajustes de la lane y haga clic en OK.

Por contenido

Parámetro	Descripción
Add Node Tag	Agregue una tag a los nodos de su aplicación canary para distinguirlos de los nodos base.
Enter lane information	Lane Name: Introduzca un nombre para la lane. Lane Tag: La tag de destino para el tráfico que coincide con las reglas de esta lane. Confirm Matching Relationship: Compruebe si la cantidad de nodos de aplicación con esta tag cumple con sus expectativas. Lane Status: Seleccione Enable.
Add Canary Release Rule	Establezca la regla para enrutar el tráfico hacia esta lane. Canary Release Mode: Seleccione Canary Release by Content. Canary Release Condition: Seleccione Meet All Conditions. La condición en este ejemplo se configura de la siguiente manera: Parameter Type: Header. Parameter: canary. Condition: ==. Value: gray.

Modos de enrutamiento canary

Condición de versión canary	Efecto
Meet All Conditions	El tráfico se enruta a la lane correspondiente solo si se cumplen todas las condiciones especificadas.
Meet Any Condition	El tráfico se enruta a la lane correspondiente si se cumple cualquiera de las condiciones especificadas.

Tipos de condiciones

Condición	Descripción	Ejemplo de configuración	Ejemplo de solicitud
==	Coincidencia exacta. La condición se cumple solo si el valor en el tráfico coincide exactamente con el valor especificado.	Por ejemplo, la condición de coincidencia de solicitudes para la lane mse (tag de lane: gray, lista de aplicaciones de lane: `spring-cloud-a,spring-cloud-c`) es Condition: AND header: [name] == xiaoming. Esto significa que cuando el valor del encabezado de solicitud `name` es exactamente igual a `xiaoming`, el tráfico se enruta a esta lane. El estado actual de la lane es Enabled.	Se envía una solicitud GET a la ruta `/a` con el encabezado `name=xiaoming`. La respuesta `Agray[192.168.0.22][config=base] -> B[192.168.0.9] -> Cgray[192.168.0.17]` confirma que el tráfico se enrutó a través de las versiones canary de los servicios A y C.
!=	Coincidencia de desigualdad. La condición se cumple si el valor en el tráfico no coincide con el valor especificado.	Por ejemplo, si la condición de coincidencia de solicitudes para la lane mse se establece en `header: [name] != xiaoming`, el tráfico coincide con esta lane cuando el valor del campo name en el encabezado de la solicitud no es igual a `xiaoming`.	Por ejemplo, si envía una solicitud GET a la ruta `/a` con el encabezado establecido en `name=xiaoming1`, la respuesta muestra que el tráfico se enruta a través del enlace canary: `Agray[10.0.10.58][config=base] -> B[10.0.10.206] -> Cgray[10.0.10.8]`. Esto indica que el tráfico coincide con la regla canary cuando el valor de `name` no es igual al valor de la condición.
in	Coincidencia por inclusión. La condición se cumple si el valor en el tráfico está presente en la lista especificada.	Por ejemplo, la condición de coincidencia de solicitudes para la lane mse se establece en `header: [name] in [xiaoming,xiaohong]`. Esto significa que si el valor del encabezado name en una solicitud es xiaoming o xiaohong, el tráfico se enruta a las aplicaciones grayscale spring-cloud-a y spring-cloud-c que corresponden a esta lane.	Se envía una solicitud GET a la ruta `/a` con el encabezado `name` establecido en `xiaohong`. La respuesta `Agray[10.0.10.58][config=base] -> B[10.0.10.206] -> Cgray[10.0.10.8]` confirma que el tráfico se enrutó a la lane canary porque el valor estaba en la lista.
Percentage	Coincidencia por porcentaje. La condición se cumple si hash(get(key)) % 100 < value es verdadero.	Se configura una regla para enrutar el 10% de las solicitudes a la lane con tag gray, basándose en el hash del parámetro Header name. Esta lane incluye `spring-cloud-a` y `spring-cloud-c`.	Se envía una solicitud GET a la ruta `/a` con el encabezado `name=111`. La respuesta `Agray[10.0.10.58][config=base] -> B[10.0.10.206] -> Cgray[10.0.10.8]` indica que el valor hash de esta solicitud cayó dentro del rango del 10% y se enrutó a la lane canary.
Regex	Coincidencia por expresión regular. La condición se cumple si el valor en el tráfico coincide con la expresión regular especificada.	Se configura una regla para coincidir con solicitudes donde el parámetro Header name coincide con una regex para una cadena alfanumérica de 32 caracteres. La lane con tag gray incluye `spring-cloud-a,spring-cloud-c`.	Se envía una solicitud GET a la ruta `/a` con el encabezado name establecido en `1234567890abcdef1234567890ABCDEF`. La respuesta `Agray[10.0.10.58][config=base] -> B[10.0.10.206] -> Cgray[10.0.10.8]` confirma que el tráfico se enrutó a la lane canary porque el valor coincidió con la regex.

Por proporción

Nota

Para crear una lane para versión canary por proporción, la versión de ack-onepilot debe ser 3.0.18 o posterior y la versión del agente debe ser 3.2.3 o posterior.

Parámetro	Descripción
Add Node Tag	Agregue una tag a los nodos de su aplicación canary para distinguirlos de los nodos base.
Enter lane information	Lane Name: Introduzca un nombre para la lane. Lane Tag: La tag de destino para el tráfico que coincide con las reglas de esta lane. Confirm Matching Relationship: Compruebe si la cantidad de nodos de aplicación con esta tag cumple con sus expectativas. Lane Status: Seleccione Enable.
Configure Routing and Canary Release Rules	Establezca la regla para enrutar el tráfico hacia esta lane. Canary Release Mode: Seleccione Routing by Percentage. Traffic Percentage: 30%.

Nota

También puede establecer diferentes proporciones de tráfico para cada ruta base del gateway. Al habilitar esta función, asegúrese de que la suma de todas las proporciones de tráfico configuradas para esa ruta base en todos los grupos de lanes no exceda el 100%.

Después de crear la lane, puede consultar sus detalles en la sección Traffic Allocation de la página Full link Grayscale y realizar las siguientes acciones:

En la columna Actions, haga clic en Enable para activar la lane. El tráfico se enrutará entonces según las reglas de la lane. El tráfico coincidente tiene prioridad hacia la versión de la aplicación con la tag de lane correspondiente. Si no se encuentra dicha versión, el tráfico se enruta a la versión base sin tag.
En la columna Actions, haga clic en Close para desactivar la lane. El tráfico subsiguiente se enrutará a la versión base sin tag.
Haga clic en el icono de vista () para consultar la proporción de tráfico de la lane.
Haga clic en el icono de estado () para establecer el estado de las aplicaciones dentro de la lane.

Paso 4: Probar el tráfico canary

Por contenido

Utilice el comando curl para probar el tráfico canary. El resultado muestra que el tráfico pasa por los entornos canary de A y C. Dado que no existe una versión canary de la aplicación B (con tag 'gray'), el tráfico se enruta automáticamente a su versión base.

# Test command
curl -H "canary: gray" x.x.x.x/a
# Test result
Agray[10.0.3.177][config=base] -> B[10.0.3.195] -> Cgray[10.0.3.180]

Por proporción

Puede ejecutar el siguiente script de Python para probar la distribución de tráfico para el enrutamiento por proporción. Debe instalar el paquete requests y reemplazar x.x.x.x con la dirección IP de ingreso de su cloud-native gateway.

Show the Python script

# pip3 install requests
# python3 traffic.py
import requests
TOTAL_REQUEST = 100
ENTRY_URL = 'http://x.x.x.x/a'
def parse_tag(text:str):
    '''
    A[10.0.23.64][config=base] -> B[10.0.23.65] -> C[10.0.23.61]
    Agray[10.0.23.64][config=base] -> B[10.0.23.65] -> Cgray[10.0.23.61]
    Ablue[10.0.23.64][config=base] -> B[10.0.23.65] -> Cblue[10.0.23.61]
    '''
    print(text)
    app_parts = text.split(' -> ')
    # tag_app: C[10.0.23.61] / Cgray[10.0.23.61]
    tag_app = app_parts[-1]
    splits = tag_app.split('[')
    # tag_part: C / Cgray
    tag_part = splits[0]
    tag = tag_part[1:]
    return tag if len(tag) > 0 else 'base'
def get_tag(url:str):
    resp = requests.get(url)
    resp.encoding = resp.apparent_encoding
    return parse_tag(resp.text)
def cal_tag_count(url:str, total_request:int):
    count_map = {}
    for i in range(total_request):
        tag = get_tag(url)
        if tag not in count_map:
            count_map[tag] = 1
        else:
            count_map[tag] += 1
    print()
    print('Total Request:', total_request)
    print('Traffic Distribution:', count_map)
if __name__ == '__main__':
    cal_tag_count(ENTRY_URL, TOTAL_REQUEST)

El resultado muestra que aproximadamente el 30% del tráfico se enruta al entorno canary.

(Opcional) Paso 3: Observability

Las funciones de observability de MSE le ayudan a monitorear el rendimiento de la aplicación y diagnosticar problemas rápidamente.

Observability del cloud-native gateway

En la página Routes de la consola de MSE cloud-native gateway, seleccione la pestaña Services. Haga clic en el servicio objetivo y consulte sus métricas de tráfico en el área Monitor.

基础监控

Observability de gobernanza de microservices de MSE

En la página Full link Grayscale de MSE Microservices Governance, haga clic en la aplicación objetivo. En el área Application QPS Monitoring, puede consultar el tráfico de las versiones base (sin tag) y canary de la lane correspondiente.

应用监控

Total QPS: El total de consultas por segundo (QPS) de la aplicación.
Abnormal QPS: La cantidad de solicitudes con errores por segundo de la aplicación.
GrayQPS: Las QPS de la versión 'gray' de la aplicación.

Observability de ARMS

Si su aplicación está conectada a Application Real-Time Monitoring Service (ARMS), puede monitorear las métricas de negocio de su entorno canary en el panel de versión canary de extremo a extremo de ARMS para decidir si revertir o continuar con la versión.

La pestaña end-to-end canary release compara métricas clave para cada aplicación en los entornos online y canary, incluidas requests per second, error rate y average response time. Al seleccionar una aplicación, se muestran sus métricas de instance count, request volume, exception count, error rate y response time, lo que le ayuda a determinar si el tráfico canary funciona según lo esperado.