Prefacio
En este artículo, continuaremos hablando de la otra parte de "Revelación de las razones detrás del lanzamiento suave como la seda en el escenario de alto tráfico", el lanzamiento en escala de grises, también llamado lanzamiento canario. Otro motivo importante por el que muchas empresas de Internet no tienen el lanzamiento de medianoche es la posibilidad de ser gris, un error u otras razones afectarán a los nuevos clientes de la versión online, la desesperación solo puede optar por publicar en mitad de la noche para reducir la superficie de impacto.
Sabemos que, de forma predeterminada, ya sea Kubernetes o ECS, cuando existan versiones nuevas y antiguas, se enrutarán aleatoriamente a diferentes instancias de acuerdo con un algoritmo de equilibrio de carga específico. Aleatorio significa que los problemas también ocurrirán al azar. Necesitamos un conjunto de enrutamiento dinámico para completar la solución de liberación en escala de grises.
En el campo de RPC, llamamos liberación gris como enrutamiento dinámico. Enrutamiento dinámico significa que el tráfico se puede enrutar dinámicamente a una instancia específica.
Escenario de enrutamiento dinámico
El enrutamiento dinámico es una función fundamental en los microservicios. El enrutamiento dinámico del tráfico significa que se pueden hacer muchas cosas. De esto se derivan varios escenarios:
- Versión de Canary: solo el tráfico que cumpla con ciertas reglas (como el parámetro de consulta, el encabezado y las COOKIE, ciertas KEYs cumplen con algunas condiciones) o una proporción de tráfico fija ingresará a la nueva versión y el resto del tráfico se enrutará a la versión anterior.
- Enrutamiento prioritario en la misma sala de computadoras: cuando la empresa se expanda, las aplicaciones se implementarán en las salas de computadoras para lograr una alta disponibilidad. Debido al problema de demora de la red que ocurre cuando se llaman a través de salas de computadoras en diferentes lugares, es necesario asegurarse de que los consumidores de servicios puedan llamar preferentemente a los consumidores de servicios en la misma sala de computadoras, lo que requiere la capacidad de enrutar preferentemente en la misma sala de computadoras.
- Tag routing: una nueva escena lanzada por Canary. Las versiones de Canary generalmente tienen solo dos versiones, la nueva y la antigua. El enrutamiento de etiquetas puede implementar múltiples versiones en línea y cada versión tiene una etiqueta.
- Escala de grises de enlace completo: en el escenario donde el negocio es más complejo y el enlace de llamada de servicio es largo, es muy engorroso establecer reglas de enrutamiento para cada aplicación. La escala de grises de enlace completo se agrega sobre la base del enrutamiento canario / de etiquetas Con la capacidad de "transmisión de etiquetas transparentes", el tráfico en escala de grises se enruta solo entre versiones de escala de grises.
A continuación, discutiré estos escenarios en detalle en varios artículos, hoy hablaremos primero del lanzamiento canario. El lanzamiento canario nos permite publicar online durante el pico de tráfico diurno, tomando té y comiendo semillas de melón, sin tener que preocuparnos por publicar cosas en medio de la noche.
Estado de implementación de la aplicación con mucho tráfico
Demostración de la aplicación
La demostración usa Spring Cloud como ejemplo. El enlace de llamada de servicio se muestra en la siguiente figura:
Cuando ingrese tráfico del Ingress correspondiente a Netflix Zuul, llamará al servicio correspondiente a la aplicación SC-A, la aplicación SC-A llamará al servicio de la aplicación SC-B y la aplicación SC-B llamará al servicio de la aplicación SC-C. SC-A tiene dos versiones: versión online y versión gris.
Demostración de implementación de Helm
La demostración es una arquitectura pura de Spring Cloud de código abierto.
Después de la implementación, la carga de trabajo en Alibaba Cloud Container Service es la siguiente:
Usamos el comando de shell "while true; do curl http: // {ip: port} / A / a; echo; done" para acceder continuamente a los servicios de Spring Cloud. La función de cada servicio es solo imprimir la IP del servicio actual, por lo que Puede ver el enlace de la llamada general:
while true; do curl http://{ip:port}/A/a;echo;done
A[10.0.0.73] -> B[10.0.0.180] -> C[10.0.0.72]
A1[10.0.0.20] -> B[10.0.0.180] -> C[10.0.0.72]
A1[10.0.0.20] -> B[10.0.0.180] -> C[10.0.0.72]
A[10.0.0.73] -> B[10.0.0.180] -> C[10.0.0.72]
A[10.0.0.73] -> B[10.0.0.180] -> C[10.0.0.72]
A1[10.0.0.20] -> B[10.0.0.180] -> C[10.0.0.72]
A[10.0.0.73] -> B[10.0.0.180] -> C[10.0.0.72]
A1[10.0.0.20] -> B[10.0.0.180] -> C[10.0.0.72]
A[10.0.0.73] -> B[10.0.0.180] -> C[10.0.0.72]
...A partir de este proceso, podemos ver claramente que se accede aleatoriamente al enlace Netflix Zuul -> SC-A. Dado que la versión en línea y la versión en escala de grises de SC-A solo tienen 1 Pod cada una, estos dos POD se imprimen al azar IP.
Implementación de canary de código abierto
La esencia del enrutamiento dinámico es encontrar una dirección de instancia calificada durante el proceso de direccionamiento.
Apache Dubbo proporciona la capacidad de RouterChain para filtrar la lista de Invoker. RouterChain mantiene la lista de enrutadores internamente. Cada enrutador hará la lógica de filtrar el Invoker, y finalmente entregará la lista de Invoker a LoadBalance para balancear la carga y obtener el Invoker final.
Los enrutadores integrados ScriptRouter, ConditionRouter y TagRouter son todas capacidades de enrutamiento dinámico integradas de Dubbo.
Ribbon implementa las capacidades de enrutamiento de Spring Cloud. Ribbon diseñó la interfaz ILoadBalancer para obtener la lista de servidores y finalmente entregó esta lista a IRule para la estrategia de equilibrio de carga para obtener el último servidor. Esta pieza tiene un diseño defectuoso en comparación con Dubbo.
ILoadBalancer en Spring Cloud Ribbon es equivalente a un enrutador en Dubbo RouterChain, e IRule es equivalente a Dubbo LoadBalance.
La última versión de Spring Cloud ha agregado el componente Spring Cloud LoadBalancer en lugar de Ribbon para el equilibrio de carga. El ServiceInstanceListSupplier en Spring Cloud LoadBalancer se usa para obtener información de la lista de instancias, y ReactiveLoadBalancer usa una estrategia de equilibrio de carga para obtener la última instancia.
Esta es la descripción de los componentes correspondientes de los 3:
Aunque Apache Dubbo tiene varios enrutadores integrados, existen muchos problemas en el uso real. Por ejemplo, TagRouter está vinculado a IP y no puede funcionar con Kubernetes; ScriptRouter usa ScriptEngine para realizar el procesamiento de scripts, lo que provocará problemas de rendimiento; Dubbo Admin tiene una experiencia muy mala.
Spring Cloud no proporciona oficialmente capacidades de enrutamiento dinámico. Solo algunos desarrolladores de la comunidad han ampliado esta capacidad ellos mismos y no hay una interfaz de interacción de UI en la comunidad.
En este momento, MSE le dice que la solución de microservicio de MSE proporciona capacidades de enrutamiento dinámico. Puede usar la API OPEN o la interacción de la interfaz de usuario para completar el lanzamiento de Canary sin ningún cambio de código ni configuración. Simplemente conecte su aplicación a la gobernanza del servicio MSE y podrá disfrutar de las capacidades de Canary.
Siempre que su aplicación se base en Spring Cloud o en el desarrollo de la versión de Dubbo en los últimos cinco años, puede usar directamente las capacidades completas de gobernanza de microservicios de MSE sin modificar ningún código o configuración.
¿No suena bien poder lograr un enrutamiento dinámico sin ninguna modificación de código?
Capacidades canarias de MSE
Las aplicaciones pueden acceder a MSE para disfrutar de las capacidades de enrutamiento dinámico proporcionadas por MSE sin ninguna modificación de código.
Presentamos el concepto de etiqueta
MSE introduce el concepto de etiquetas. Se pueden establecer reglas de enrutamiento para cada etiqueta. El tráfico que cumpla con las reglas de enrutamiento se enrutará a la instancia correspondiente a esta etiqueta. Modificamos un poco la demostración de Spring Cloud y marcamos la versión gris de SC-A con la etiqueta "azul" (Helm ya ha completado este paso).
Después de acceder a MSE, MSE asignará una regla de enrutamiento del 100% a la instancia sin marcar de forma predeterminada. En este punto, continuamos ejecutando el comando de shell "while true; do curl http: // {ip: port} / A / a; echo; done". En este momento, llamar a SC-A devolverá la IP de la versión en línea:
while true; do curl http://{ip:port}/A/a;echo;done
A[10.0.0.73] -> B[10.0.0.180] -> C[10.0.0.72]
A[10.0.0.73] -> B[10.0.0.180] -> C[10.0.0.72]
A[10.0.0.73] -> B[10.0.0.180] -> C[10.0.0.72]
A[10.0.0.73] -> B[10.0.0.180] -> C[10.0.0.72]
A[10.0.0.73] -> B[10.0.0.180] -> C[10.0.0.72]
...Configurar reglas de enrutamiento canary
Establecemos el valor CLAVE de env en el ENCABEZADO en la página de la pestaña Canary de la página de detalles de la aplicación en el MSE para probar las condiciones de enrutamiento de Canary:
Pase HEADER para continuar usando la ejecución de shell:
while true; do curl -H "env:test" http://139.196.200.40/A/a;echo;done
A1[10.0.0.20] -> B[10.0.0.180] -> C[10.0.0.72]
A1[10.0.0.20] -> B[10.0.0.180] -> C[10.0.0.72]
A1[10.0.0.20] -> B[10.0.0.180] -> C[10.0.0.72]
A1[10.0.0.20] -> B[10.0.0.180] -> C[10.0.0.72]
A1[10.0.0.20] -> B[10.0.0.180] -> C[10.0.0.72]
A1[10.0.0.20] -> B[10.0.0.180] -> C[10.0.0.72]
A1[10.0.0.20] -> B[10.0.0.180] -> C[10.0.0.72]
A1[10.0.0.20] -> B[10.0.0.180] -> C[10.0.0.72]
A1[10.0.0.20] -> B[10.0.0.180] -> C[10.0.0.72]
...En este momento, encontramos que todo el tráfico que cumple con las Reglas de Canary iba a la versión en escala de grises de SC-A.
Análisis de reglas de enrutamiento Canary
Como puede ver, hay dos diferencias en la interfaz de reglas de enrutamiento de Canary, a saber, la proporción de tráfico y la regla de tráfico :
Regla de tráfico: indica que el tráfico que cumpla con la regla se enrutará a la instancia de la etiqueta correspondiente (en este artículo se usa azul como etiqueta gris). Por ejemplo, en el ejemplo de este artículo, el tráfico con env = test en HEADER definitivamente irá a la instancia correspondiente a la etiqueta azul.
Proporción de tráfico: el tráfico que no cumpla con las normas de tráfico se enrutará de acuerdo con el porcentaje de tráfico. Por ejemplo, en el ejemplo de este artículo, el tráfico que no cumple con la prueba env = en el HEADER se enrutará a la instancia sin marcar con reglas del 100%. Debido a que es 100%, todo el tráfico que no cumple con las reglas va a la instancia sin marcar ( Este artículo no marca la versión en línea).
Las condiciones en las reglas de tráfico proporcionadas por MSE son compatibles con HEADER, Query Parameter, COOKIE y Request BODY .
Query Parameter, HEADER, COOKIE y Request Body no solo admiten operadores regulares, sino que también admiten en (lista blanca), módulo 100 y porcentaje. El porcentaje aquí no es el porcentaje de tráfico total en la regla proporcional, sino que se refiere al módulo del valor hash del parámetro correspondiente, de modo que un valor fijo siempre puede cumplir con las condiciones de enrutamiento (si de acuerdo con el índice de tráfico, el usuario A está visitando en línea esta vez Versión, se puede acceder a la versión gris la próxima vez). Por ejemplo, si hay una ID de usuario en HEADER, quiero que algunos usuarios siempre puedan acceder a la instancia de escala de grises. En este momento, el valor hash de la ID de usuario se puede modular para completar (por supuesto, esto también se puede hacer a través de la lista blanca. Las deficiencias de la lista no son aleatorias, debe ingresar a cada lista).
El cuerpo de la solicitud actualmente admite el análisis de cadenas json, como las siguientes cadenas:
{
"a": "aa",
"b": [
1,2,3
],
"c": [
{
"d": "dd"
}
],
"e": {
"f": "ff"
}
}El valor de la expresión de acceso JSON .a es aa.
El valor de la expresión de acceso JSON .b [0] es 1.
El valor de la expresión de acceso JSON .c [0] .d es dd.
El valor de la expresión de acceso JSON .ef es ff.
para resumir
Este artículo presenta la capacidad de la versión canary bajo la gobernanza de microservicios y resuelve el problema de verificar nuevas funciones con una pequeña cantidad de tráfico durante la versión. Su aplicación solo necesita acceder a la administración de servicios MSE y puede disfrutar de capacidades de enrutamiento dinámico sin ninguna operación. Además de MSE (Micro Service Engine), Canary Release también está integrado con productos en la nube como EDAS y SAE.
Este artículo es el contenido original de Alibaba Cloud y no se puede reproducir sin permiso.