La imagen anterior es la versión en escala de grises de Tencent, los usuarios normales pueden acceder a ella, el servidor de Alibaba Cloud no puede ser accedido, el ping es normal y la resolución IP también es normal
Simplemente es inaccesible, se puede ver que a Tencent también le gusta jugar con la liberación en escala de grises...
1. Por qué el lanzamiento en escala de grises
- Los servicios de Internet cambian con frecuencia y los ciclos de lanzamiento son cortos. La velocidad y la calidad siempre son difíciles de combinar.
- La publicación en escala de grises puede reducir el riesgo de la publicación y disminuir el alcance del impacto.
- Reducir la dependencia de las pruebas y reducir el coste de construcción de datos para autopruebas offline.
- Es conveniente monitorizar los registros de forma centralizada y publicarlos completos. Debido al papel del balanceo de carga en cada capa, es difícil rastrear un enlace de llamada completo.
- Puedes usar cuentas de prueba en escala de gris y luego cuentas reales de usuario en escala de grises después de que la cuenta de prueba pase para reducir aún más el riesgo e impacto de publicar.
- Retroceso fácil.
Problemas que no pueden resolverse con lanzamientos en escala de grises
Cabe destacar que el "impacto tolerable" mencionado anteriormente debe ser recuperable; por ejemplo, la API no puede ser llamada durante un periodo de tiempo, pero tras la reparación, puede ser llamada con éxito. La pérdida o destrucción permanente de datos de los usuarios (como información de productos, datos de pedidos, etc.) es intolerable. Por lo tanto, es responsabilidad de los arquitectos de las empresas de Internet restaurar los datos de usuario perdidos a un estado reciente (como hace una hora o una semana) mediante intervención manual en caso de pérdida de datos de usuario debido a desórdenes del sistema de producción (como copias de seguridad regulares de datos de usuario, escritura de registros de operaciones, etc.).
CONSEJOS: Prueba primero la política de escala de grises de tu cuenta para reducir el riesgo de dañar o perder los datos reales de los usuarios.
2. ¿Qué efecto se espera?
Independientemente del cambio, queremos que las solicitudes específicas se dirijan a nuestra versión del cambio (versión en escala de grises) para su observación y validación.
3. Estrategia en escala de grises
De hecho, es a qué peticiones deberían dirigirse a nuestra versión en escala de grises (máquina en escala de grises). Esto suele estar fuertemente relacionado con los negocios. Por ejemplo, para las APIs, generalmente existen los siguientes requisitos:
Usuarios específicos (por ejemplo, cuentas de prueba)
Aplicaciones específicas (por ejemplo, aplicaciones de prueba o aplicaciones asociadas)
Módulos e interfaces específicos (solo algunas interfaces necesitan escala de grises, que generalmente es una modificación de los contenedores de API, y algunas APIs que no son muy importantes se usan para pruebas en escala de grises). ）
Máquina específica (algunas IPs de solicitud se reenvían a la máquina en escala de grises)
4. Discusión sobre esquemas en escala de grises
Solución 1: El nivel de código se juzga por la bandera acordada, y el antiguo y el nuevo se intercambian dinámicamente - enfoque de Amazon
Implementación:
Enterra el interruptor en el código, haz un juicio if-else y pon el interruptor en activado para máquinas que requieren escala de grises, de lo contrario está desactivado. Hay dos versiones para cada lanzamiento.
mérito
Retroceso rápido, no hace falta volver a publicar ni reiniciar el sistema.
defecto
Sé inclinado por el código.
La lógica ramificada aporta complejidad.
Este método fue utilizado por el autor cuando yo estaba en Alibaba, cambiando la base de datos de mercancías de Oracle a MySQL y usando una variable de estado para el control. Así se logra el efecto de una migración suave.
Opción 2: Máquina previa al lanzamiento - Práctica de Alibaba
De hecho, esto no es en escala de grises en el sentido verdadero. Porque esta máquina de pre-lanzamiento es una IP interna y no tiene servicio externo. La vinculación de dominio es necesaria para la verificación. Pero los datos están completamente en línea. Así que es esencialmente un enfoque sencillo para algunos usuarios específicos de Grayscale (usuarios que tienen acceso a la máquina de Grayscale, usuarios de pruebas internas). De hecho, existe un enfoque similar en el lado de la API, que es nuestro entorno Gamma, y también proporcionamos el nombre de dominio de la máquina Gamma para facilitar que usuarios cooperativos externos cooperen con las pruebas.
mérito
Sencillo
defecto
Desperdicia una máquina (esto puede ponerse en el entorno de producción tras completar la pre-lanzamiento, y retirarse de nginx durante la pre-lanzamiento, pero se requiere soporte O&M.) ）
No es lo suficientemente flexible
Los servicios IDL solo pueden usarse para máquinas de capa de acceso, y los servicios IDL deben considerarse por separado.
Opción 3: Despliegue de SET
1. Desplegarse de forma aislada según los servicios
Por ejemplo, en la práctica actual de contenedores API, la granularidad del despliegue puede alcanzarse hasta el nivel de API, y el front-end reenvía según nginx. Como qué:
Contenedor API de Microcompras: api.weigou.qq.com
Pat API Container:api.paipai.com
Yixun API Container: api.yixun.com
API de compras online Container:api.buy.qq.com
Lo anterior es un despliegue aislado a nivel de gran empresa. También puede perfeccionarse aún más a nivel de módulo, como la API del comercio electrónico de servicios virtuales, que es un submódulo de negocio que está bajo Paipai, pero como están conectados a WeChat, el número de visitas ha aumentado significativamente para evitar afectar a otros negocios de Paipai, y para evitar verse afectados por otros negocios, la API aquí es desplegar dos máquinas por separado para ellas, nginx puede configurarse para drenar el acceso a la API virtual:
Contenedor virtual de API: http://api.paipai.com/v2/virbiz
De este modo, cuando lanzamos una versión, primero podemos elegir Yixun con el menor volumen de negocio para publicar, y luego observar que no hay problema antes de usar todas las demás plataformas.
2. Despliegue por aislamiento del usuario
Esto no es muy adecuado para plataformas abiertas, pero sí es muy adecuado para escenarios de aplicación como SNS. Por ejemplo, el sistema QQ se divide en varios conjuntos según los segmentos de número de usuario, y cada conjunto contiene 100 millones de números consecutivos. Suponiendo que el último número QQ esté cerca de 1.000 millones, hay un total de 10 conjuntos (del Conjunto 1 al Conjunto 10). De este modo, puedes elegir uno de los SETS para publicar cada vez, y QQ de alto nivel a menudo no es un usuario muy importante, por lo que SET10 se lanzará primero.
mérito
Despliegue aislado con un impacto mínimo en todas las líneas de negocio. Soporta automáticamente la publicación en escala de grises.
defecto
La granularidad de la escala de grises depende de la granularidad del despliegue aislado, que generalmente es grande.
Desperdicio de máquinas comparado con el despliegue centralizado.
Las versiones de cada línea de negocio pueden ser inconsistentes, lo que no favorece una gestión unificada.
Existen ciertos costes de implementación y despliegue
Esquema 4: Enrutamiento dinámico
Método: Utilizar una política de escala de grises que pueda configurarse de forma flexible para afectar el comportamiento del balance de carga y permitir que devuelva la IP y el puerto del servicio en escala de grises según dicha política.
Adecuado para escala de grises de servicio con IDL de back-office.
mérito
Flexible, controlable.
defecto
El centro de configuración actual y L5 en sí no consideran políticas de enrutamiento específicas y no son escalables, por lo que deben desarrollarse fuera de ellas.
Las fuentes de metadatos de las APIs están relativamente dispersas, y actualmente los metadatos de API e IDL, los niveles de API y los límites de frecuencia están distribuidos entre diferentes fuentes de datos, por lo que ahora es necesario añadir una fuente de datos de enrutamiento en escala de grises.
Generalmente hay tres formas de publicar nginx+lua en escala de grises: nginx se distribuye según cookies y nginx se asigna según el peso:
nginx+lua distingue según la dirección IP del visitante, porque la empresa exporta una dirección IP y el sitio web será accedido a la versión antigua o a la nueva, que no es adecuada para este método
Nginx asigna pesos en función de pesos, lo cual es sencillo de implementar y puede probarse
Nginx se divide en función de cookies y Grayscale publica en función de los usuarios
|
Publicado en 9/3/2017 15:48:27
|
|
|
|
