Introducción: en la arquitectura de microservicios, las dependencias entre los servicios son complejas y, a veces, una versión de función depende de que se actualicen y lancen varios servicios al mismo tiempo. Esperamos que las nuevas versiones de estos servicios se puedan verificar con poco tráfico al mismo tiempo. Esta es la única escena en escala de grises de enlace completo en la arquitectura de microservicios. Al construir un entorno aislado desde la puerta de enlace hasta todo el servicio backend, múltiples las versiones pueden ser verificadas servicio para verificación en escala de grises.
Autor: diez duermen
¿Qué es la escala de grises de enlace completo?
En la arquitectura de microservicios, las dependencias entre servicios son complejas y, a veces, una versión de función depende de que se actualicen y lancen varios servicios al mismo tiempo. Esperamos que las nuevas versiones de estos servicios se puedan verificar con poco tráfico al mismo tiempo. Esta es la única escena en escala de grises de enlace completo en la arquitectura de microservicios. Al construir un entorno aislado desde la puerta de enlace hasta todo el servicio backend, múltiples las versiones pueden ser verificadas servicio para verificación en escala de grises.
Haga clic en el siguiente enlace para ver el tutorial en vivo:
Durante el proceso de lanzamiento, solo necesitamos implementar la versión en escala de grises del servicio. Cuando el tráfico fluye en el enlace de la llamada, el tráfico en escala de grises es identificado por las puertas de enlace, el middleware y los microservicios a través de los cuales fluye, y se reenvía dinámicamente al servicio correspondiente. Versión en escala de grises. Como se muestra abajo:
La figura anterior puede mostrar bien el efecto de este esquema. Usamos diferentes colores para representar el tráfico en escala de grises de diferentes versiones. Se puede ver que tanto la puerta de enlace de microservicio como el microservicio en sí necesitan identificar el tráfico y tomar decisiones dinámicas de acuerdo con a las reglas de gobierno. Cuando cambie la versión del servicio, el desvío de este enlace de llamada también cambiará en tiempo real. En comparación con el entorno de escala de grises construido por máquinas, esta solución no solo puede ahorrar una gran cantidad de costos de máquinas y mano de obra de operación y mantenimiento, sino que también ayuda a los desarrolladores a realizar un control refinado de enlace completo del tráfico en línea en tiempo real y rápidamente.
OpenSergo[1] Estándar de enrutamiento de tráfico
P: ¿Qué es OpenSergo?
R: OpenSergo es un conjunto de estándares abiertos de gobernanza de servicios de propósito general orientados a la arquitectura de servicios distribuidos y que cubre la ecología heterogénea de enlace completo. Forma un estándar de gobernanza de servicios generales basado en escenarios y prácticas de gobernanza de servicios de la industria. La característica más importante de OpenSergo es definir las reglas de gobierno del servicio con un conjunto unificado de configuración/DSL/protocolo, orientado hacia una arquitectura heterogénea multilingüe y lograr una cobertura ecológica de enlace completo. Ya sea que el lenguaje del microservicio sea Java, Go, Node.js u otros lenguajes, ya sea un microservicio estándar o un acceso Mesh, desde la puerta de enlace hasta el microservicio, desde la base de datos hasta la memoria caché, desde el descubrimiento del registro del servicio hasta la configuración, los desarrolladores pueden usar el mismo El conjunto de configuración estándar de OpenSergo CRD realiza un gobierno y control unificados para cada capa, sin prestar atención a las diferencias entre marcos e idiomas, lo que reduce la complejidad del gobierno y control de servicios heterogéneos y de enlace completo.
P: ¿Por qué me presentaron OpenSergo antes de aprender acerca de la escala de grises de enlace completo?
R: OpenSergo define un método de configuración YAML unificado para implementar especificaciones de gobierno de servicio de enlace completo para arquitecturas distribuidas. Al presentar las especificaciones y estándares, podemos comprender la implementación de los detalles técnicos, y también podemos aplicar nuevos. Los componentes se implementan con el Estándar OpenSergo.
El enrutamiento del tráfico, como su nombre lo indica, consiste en enrutar el tráfico con ciertas características de atributos a un destino específico. El enrutamiento del tráfico es una parte importante de la gobernanza del tráfico. Los desarrolladores pueden implementar varios escenarios en función de los estándares de enrutamiento del tráfico, como la publicación en escala de grises, la publicación canary, el enrutamiento de recuperación ante desastres y el enrutamiento de etiquetas.
Ejemplo de enlace completo en escala de grises:
Las reglas de enrutamiento de tráfico (v1alpha1) se dividen principalmente en tres partes:
- Regla de etiqueta de carga de trabajo (WorkloadLabelRule): etiqueta un grupo de cargas de trabajo con las etiquetas correspondientes. Este bloque puede entenderse como el etiquetado de la carga de la base de datos (base de datos, tabla) para la aplicación o la capa de almacenamiento correspondiente.
- Regla de etiqueta de tráfico (TrafficLabelRule): etiquete el tráfico con ciertas características de atributo con las etiquetas correspondientes
- Realice rutas coincidentes de acuerdo con la etiqueta de carga de trabajo y la etiqueta de tráfico, y enrute el tráfico con la etiqueta especificada a la carga de trabajo coincidente
Para marcar el tráfico:
El tráfico con ciertas características de atributo debe marcarse con las etiquetas correspondientes.
假设现在需要将深圳地域的用户灰度到新版主页，测试用户 location=cn-shenzhen，cn-shenzhen 位于 location header 中：
apiVersion: traffic.opensergo.io/v1alpha1
kind: TrafficLabelRule
metadata:
name: my-traffic-label-rule
labels:
app: spring-cloud-zuul
spec:
selector:
app: spring-cloud-zuul
trafficLabel: gray
match:
- condition: "==" # 匹配表达式
type: header # 匹配属性类型
key: 'location' # 参数名
value: cn-shenzhen # 参数值
复制代码通过上述配置，location header 为 cn-shenzhen 的 HTTP 流量，打上 gray 标，代表这个流量为灰度流量。
给 Workload 打标签：
在使用 Nacos 作为服务发现的业务系统中，一般是需要业务根据其使用的微服务框架来决定打标方式。如果 Java 应用使用的 Spring Cloud 微服务开发框架，我们可以为业务容器添加对应的环境变量来完成标签的添加操作。比如我们希望为节点添加版本灰度标，那么为业务容器添加 traffic.opensergo.io/label: gray ，这样框架向 Nacos 注册该节点时会为其添加一个 gray 标签。
对于一些复杂的 workload 打标场景（如数据库实例、缓存实例标签），我们可以利用 WorkloadLabelRule CRD 进行打标。示例：
apiVersion: traffic.opensergo.io/v1alpha1
kind: WorkloadLabelRule
metadata:
name: gray-sts-label-rule
spec:
workloadLabels: ['gray']
selector:
db: mse-demo
table: mse_demo_table_gray
复制代码全链路灰度在数据库上的常见方案
方案一：影子库
每个单独维护一套独立的库，假设基线环境的库的名称为 mse-demo，那么 gray 环境的流量可以映射到 mse-demo-gray 的库中，我们在同一个实例上建立对应环境流量的影子库，我们在业务中维护着各个库连接的连接池，根据不同的流量标选择对应的影子库的连接去访问，以此达到数据和基线环境库隔离的效果，从而避免了灰度环境流量产生的数据对基线环境库造成污染。
方案二：影子表
类似影子库方案，针对影子表方案，是在同一个实例上的同一个数据库上建立对应的影子表。我们在执行 SQL 的过程中，对灰度流量的 SQL 进行解析与修改，实现不同环境流量的 SQL 分别访问对应的表，假设基线环境的表的名称为 mse_demo_table，那么 gray 环境的流量可以映射到 mse_demo_table_gray 的表中。从而实现灰度数据和基线环境数据表隔离的效果。
MSE[2] 数据库全链路灰度能力
MSE 提供了一种数据隔离的方案，您可以在不需要修改任何业务代码的情况下，实现数据库层面全链路灰度。下面介绍 MSE 基于 Mysql 数据存储通过影子表的方案实现全链路灰度的能力。
前提条件
- 应用接入 MSE
- 部署 Demo 应用
在阿里云容器服务中部署 A、B、C 三个应用，每个应用分别部署⼀个 base 版本和⼀个 gray 版本；并部署⼀个 Nacos Server 应用，用于实现服务发现。具体可参考教程完成应用部署：部署 Demo 应用程序[3]。
Demo 应用介绍，本 Demo 中的 C 应用会向数据库执行如下语句：
CREATE TABLE `mse_demo_table` (
`id` int NOT NULL AUTO_INCREMENT,
`location` varchar(255) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb3
复制代码其中涉及到的数据库建表语句：
CREATE TABLE `mse_demo_table` (
`id` int NOT NULL AUTO_INCREMENT,
`location` varchar(255) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb3
复制代码-
创建影子表，我们 Demo涉及到的数据库表有 mse_demo_table，因为我们需要创建灰度 gray 环境，因此我们需要提前创建 mse_demo_table_gray 表。
CREATE TABLE
mse_demo_table_gray(idint NOT NULL AUTO_INCREMENT,locationvarchar(255) DEFAULT NULL, PRIMARY KEY (id) ) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb3 ;
第一步：配置全链路灰度规则
您需要配置完成 MSE 的全链路发布，具体操作细节可参考教程：配置全链路灰度[4]。
创建如下泳道规则：
第二步：配置数据库全链路灰度
- 我们需要配置以下环境变量来额外开启/配置数据库的全链路灰度能力
第三步：结果验证
我们发起灰度请求，发现流量请求均访问灰度环境：
curl -H "location: cn-shenzhen" http://106.14.XX.XX/a
Agray[172.18.XX.XX] -> Bgray[172.18.XX.XX] -> Cgray[172.18.XX.XX]%
复制代码我们通过如下 SQL 查询影子表：
SELECT * FROM `mse_demo_table_gray`
复制代码发现灰度环境的数据都插入至影子表。
不仅仅是全链路灰度
目前为止 MSE 服务治理全链路灰度能力已经支持了云原生网关、ALB、APISIX、Apache Dubbo、Spring Cloud、RocketMQ 以及数据库。在数据库层面我们通过影子表的方式实现了数据层面的流量隔离，下一步我们会将该能力进行进一步产品化，全链路灰度也会支持缓存层面的能力。
服务治理是微服务改造深入到一定阶段之后的必经之路，在这个过程中我们不断有新的问题出现。
- 除了全链路灰度，服务治理还有没其他能力？
- 服务治理能力有没一个标准的定义，服务治理能力包含哪些？
- 多语言场景下，有无全链路的最佳实践或者标准？
- 异构微服务如何可以统一治理？
当我们在探索服务治理的过程中，我们在对接其他微服务的时候，我们发现治理体系不同造成的困扰是巨大的，打通两套甚者是多套治理体系的成本也是巨大的。为此我们提出了 OpenSergo 项目。OpenSergo 要解决的是不同框架、不同语言在微服务治理上的概念碎片化、无法互通的问题。
OpenSergo 社区也在联合各个社区进行进一步的合作，社区来一起讨论与定义统一的服务治理标准。当前社区也在联合 bilibili、字节跳动等企业一起共建标准，也欢迎感兴趣的开发者、社区与企业一起加入到 OpenSergo 服务治理标准共建中。欢迎大家加入 OpenSergo 社区交流群（钉钉群）进行讨论：34826335
参考链接：
[1]
OpenSergo：
[2] MSE 微服务引擎：
[3] 部署Demo 应用程序：
[4] 配置全链路灰度：
MSE 注册配置中心专业版首购享 9 折优惠，MSE 云原生网关预付费全规格享 9 折优惠。点击此处，即享优惠！
原文链接：click.aliyun.com/m/100034974…
Este artículo es contenido original de Alibaba Cloud y no se puede reproducir sin permiso.