Autor | Equipo de I+D de Baidu Zhizhi

guía

Baidu sabe que, como una línea de productos antigua que ha estado en línea durante más de diez años, tiene muchos escenarios comerciales, una arquitectura obsoleta y un estilo de código inconsistente. Al mismo tiempo, el negocio itera rápidamente, la capacidad de carga general es grande y los requisitos de estabilidad son altos, lo que genera grandes desafíos para la nube para todas las empresas. Basado en la práctica, este artículo presenta cómo seleccionar e implementar soluciones basadas en la nube y, al mismo tiempo, realizar una evolución de la arquitectura para mejorar la estabilidad del servicio en línea y las capacidades de recuperación ante desastres.

El texto completo tiene 5302 palabras y el tiempo de lectura previsto es de 16 minutos.

01 Antecedentes y desafíos

1.1 Antecedentes

Con la promoción de la estrategia PaaS del grupo y la estrategia de Baidu en la nube, la actual plataforma de operaciones en línea ORP entró oficialmente en la etapa de mantenimiento de la estabilidad y ya no realiza actualizaciones de funciones ni reparaciones de seguridad; al mismo tiempo, la capa de acceso ORP no puede cumplir con los requisitos de implementación en la nube en términos de estabilidad y eficiencia de cambio. OXP se ha convertido gradualmente en el cuello de botella del desarrollo y la iteración de negocios. Para resolver este problema, mejorar la elasticidad de los recursos, reducir los costos de los recursos comerciales, acceder a varias capacidades nativas de la nube, mejorar la eficiencia de la implementación y garantizar la estabilidad del servicio en línea, completaremos gradualmente la evolución general de la arquitectura y la migración a la nube después de comenzar el proyecto especial OXP.

1.2 Desafíos

1. Sepa que la línea de productos es antigua y tiene mucha deuda histórica. Baidu Zhizhi es una línea de productos de 18 años con modelos comerciales complejos, muchas dependencias ascendentes y descendentes, diferentes direcciones de enfoque en diferentes períodos, arquitectura antigua, estilo de código inconsistente y altos costos de transformación;

2. Saber que el negocio se está desarrollando rápidamente y los cambios iterativos son rápidos. Aunque la línea de productos tiene una larga historia, para adaptarse a los nuevos cambios, las iteraciones comerciales son ágiles y los escenarios centrales se actualizan con frecuencia. Las necesidades comerciales en línea promedio anuales son más de 780. Es necesario completar la migración a la nube bajo la premisa de garantizar el logro de los objetivos comerciales, para que el proceso comercial sea fluido;

3. Sepa que el tráfico es grande, los ingresos comerciales son grandes y los requisitos de estabilidad son altos. Como una línea de productos TOP doble con ingresos de tráfico de conocimiento, sabiendo que el PV diario promedio supera los 100 millones, cualquier tráfico e ingresos comerciales no pueden verse afectados durante el proceso de migración, y el objetivo de estabilidad del servicio central debe ser más de cuatro 9;

4. Vaya a la nube mientras la arquitectura evoluciona razonablemente. La migración a la nube es un cambio tecnológico importante en la historia de Zhizhi. Además de brindar capacidades nativas de la nube avanzadas a la antigua línea de productos y optimizar los costos de TI, también espera promover la optimización y evolución de la arquitectura general de Zhizhi y mejorar las capacidades de recuperación ante desastres y la estabilidad del servicio en línea.

1.3 Beneficios

1. Todo el tráfico se carga en la nube, brindando capacidades avanzadas de suministro de recursos elásticos al público, mejorando en gran medida la eficiencia de expansión y contracción, evitando los riesgos de capacidad en línea causados por las fluctuaciones del tráfico y mejorando la estabilidad de los servicios en línea;

2. Introducir capacidades de venta de contenedores flexibles, uso bajo demanda, pago por uso y ajustes dinámicos para optimizar el nivel general de recursos de los servicios en línea, desocupar una gran cantidad de máquinas OXP para reducir en gran medida los costos de TI;

3. Sabiendo que la arquitectura continúa evolucionando con la nube, el tráfico principal se implementará de 0 a 1 en la nube en tres lugares y cuatro salas de computadoras, reduciendo el consumo de tiempo de extremo a extremo de las páginas principales, permitiendo que las páginas principales tengan capacidades de recuperación ante desastres redundantes N+1 y mejorando la resistencia al riesgo comercial.

02 Introducción al concepto

2.1 Conoce el perfil empresarial

Zhizhi es una empresa tradicional de producción de contenido de conocimientos gráficos. En primer lugar, los usuarios hacen preguntas espontáneamente, o filtran y extraen consultas de búsqueda diarias para obtener problemas no resueltos; en segundo lugar, guían a varios productores para que respondan preguntas en diferentes páginas y fondos, y producen contenido de respuesta; en tercer lugar, los pares de preguntas y respuestas producidos se empujan a buscar, alimentar y otros escenarios para que los usuarios naveguen y consuman.

Sabiendo que después de años de operación, ha acumulado una gran cantidad de recursos de preguntas y respuestas, y ha cubierto de manera estable muchas necesidades de cola larga en el ecosistema de búsqueda; al mismo tiempo, mediante la identificación de las necesidades de los usuarios, la extracción de clientes potenciales de alto valor y la introducción de cuentas institucionales o de MCN, ha creado contenido de alta calidad de varias categorías y ha formado gradualmente una ecología de contenido de varios niveles relativamente estable y conciencia de marca.

imagen

2.2 Arquitectura empresarial

Conozca la estructura general del negocio como se muestra en la siguiente figura:

imagen

2.3 Arquitectura del tráfico

Conozca la arquitectura de tráfico general antes de ir a la nube, como se muestra en la siguiente figura:

imagen

03 Diseño y práctica de la nube

3.1 Selección de soluciones en la nube

El orp de la plataforma PaaS, que se usa ampliamente en el módulo php en la categoría vertical de conocimiento, ha anunciado que dejará de mantener el mantenimiento a fines de 2022. Al mismo tiempo, el sistema orp existente tiene algunos problemas en el nivel de gestión de orquestación de contenedores, y la gestión de recursos presupuestarios también es inconsistente con el mecanismo y el proceso de la empresa existente. La arquitectura existente conocida se basa en la implementación nativa de odp, que está más incorporada como una aplicación única a gran escala. A través de esta actualización, sabemos que necesitamos migrar a una plataforma PaaS que esté más cerca del entorno nativo de la nube y llevar a cabo una nueva ronda de iteraciones de arquitectura para crear una arquitectura ideal que satisfaga la situación empresarial actual.

Si bien Kubernetes, el sistema de código abierto que administra aplicaciones en contenedores, es una comunidad y una tendencia de desarrollo futuro, considerando factores como los costos de transformación, los nodos de tiempo y la mano de obra de desarrollo, sabemos que la selección final de esta migración a la nube es consistente con otras líneas de productos verticales de conocimiento: pandora se usa para la capa inferior y "Zhiyun Platform" se usa para la administración de recursos y en línea .

3.1.1 por qué pandora

Hay principalmente varios aspectos a considerar:

1. Pandora se adapta a los principales negocios C-end de la empresa, como Dasou, feed, handbai, Baijiahao, video (bonito), etc. Estos negocios están más cerca del sistema de conocimiento en términos de escenarios, y la investigación y evaluación detalladas pueden respaldar los planes de cambio existentes;

2. Pandora es el único en el PaaS existente que puede admitir el despliegue simultáneo de muchos módulos (soporte máximo 2K), sin requerir demasiadas fusiones y transformaciones comerciales, y es más adecuado para la arquitectura única grande odp existente;

3. La facilidad de uso de pandora es temporalmente inferior a opera, pero Zhiyun lo resolvió; al mismo tiempo, Zhiyun proporcionará servicios orp que incluyen acceso, recursos estáticos, proxy, distribución de datos, etc., por lo que no afectará la conclusión de la selección final.

3.1.2 por qué Zhiyun

Las verticales de conocimiento y otras empresas basadas en oxp tienen una estructura relativamente obvia: isomorfismo de aplicaciones múltiples bajo el modo de monómero grande, y esta parte de la demanda no es compatible con la plataforma PaaS existente. Al mismo tiempo, debido a la estandarización del empaque y los servicios en la parte inferior de Pandora, la línea de negocios necesita llevar a cabo una transformación y regresión de código específicas, y esta parte del trabajo es obviamente repetitiva. La plataforma Zhiyun tiene como objetivo proporcionar un conjunto de soluciones en la nube más acorde con el negocio del conocimiento (y basado en oxp), y tiene principalmente las siguientes ventajas:

1. Cambios en línea: además de la gestión de configuración básica en línea y la reversión, el núcleo admite el modo isomorfo de varias aplicaciones y la implementación de varios módulos. Puede reducir el costo de migrar el proyecto oxp a Zhiyun Idealmente, no hay necesidad de fusionar/dividir la base de código, y puede admitirse en la traducción;

2. Servicios de plataforma: en comparación con los servicios existentes de oxp, brinda soporte y soluciones que incluyen segmentación de registros, tareas de sincronización, capa de acceso, recursos estáticos, líneas de vuelo, control central, etc., y admite la implementación comercial y servicios personalizados basados en el modelo de servicio abierto basado en ideas nativas de la nube;

3. Entorno de tiempo de ejecución empresarial: rápida implementación y personalización del entorno de tiempo de ejecución básico de odp;

4. Entorno básico (contenedor): integre la entrada y brinde una solución de operación más conveniente durante la operación y el mantenimiento diarios.

3.2 Práctica de corte y expansión de arroyos

3.2.1 Transformación antes de ir a la nube

Para cada clúster de tráfico, antes de migrar Pandora, involucra principalmente los siguientes aspectos:

1. Zhiyun crea líneas de productos y aplicaciones. Es necesario crear el entorno básico de la línea de productos en la plataforma Zhiyun, crear la información básica de la aplicación, solicitar los recursos 2 de la sala de computadoras ECI y la configuración de la instancia, agregar el entorno operativo básico de ODP y la información relacionada con el contenedor de distribución de datos, crear la configuración correspondiente de los componentes del contenedor, agregar direcciones de almacenamiento de archivos estáticos, modificar rutas de implementación y configurar configuraciones derivadas, crear plantillas en línea, etc.;

2. Transformación y autorización de la capa de acceso. La capa de acceso crea variables BNS correspondientes a la nueva APP, y realiza varias autorizaciones de DB y redis para el nuevo BNS, involucrando nuevas salas de computación, y también necesita actualizar y adaptar cada configuración de mysql y redis;

3. Transformación y testeo de la capa de negocio. Sabiendo que esta vez, la actualización del lenguaje back-end HHVM->PHP7 se completará sincrónicamente. La actualización de la versión del lenguaje traerá más mejoras en seguridad y rendimiento. Al mismo tiempo, PHP7 también proporciona muchas funciones de sintaxis nuevas, que no se pueden usar en versiones anteriores. Es necesario completar la modificación de los problemas de compatibilidad del módulo PHP7 correspondiente y completar la prueba fuera de línea;

4. Agregue monitoreo y recopilación de registros. Es necesario agregar el monitoreo de noah y sia en todos los niveles correspondientes a la aplicación, ajustar cada elemento de monitoreo y optimizar el umbral de monitoreo; modificar la ruta de recopilación de registros correspondiente, fusionar grupos de servicios y verificar el efecto de almacenamiento fuera de línea.

3.2.2 Esquema de corte de flujo

El esquema de experimento de flujo pequeño se muestra en la siguiente figura:

imagen

Transformación de la capa de acceso:

Puede usar el script Lua en la capa de acceso para implementar pequeños cambios de tráfico. El script implementa las siguientes reglas:

['strategy_1_1_98']   = {1, 1, 98},
['strategy_5_5_90']   = {5, 5, 90},
['strategy_10_10_80'] = {10, 10, 80},
['strategy_20_20_60'] = {20, 20, 60},
.....,
['strategy_80_20_0']  = {80, 20, 0},
['strategy_95_5_0']   = {95, 5, 0},
['strategy_100_0_0']  = {100, 0, 0}

El valor devuelto tiene tres resultados: "opera", "abtest", "orp", correspondientes a tres números de izquierda a derecha, es decir, la probabilidad de ocurrencia de cada resultado, para que el control de flujo se pueda realizar de acuerdo con el resultado devuelto;

Use la variable recién agregada $upstream_target para marcar el valor final del proxy. Los cuatro valores corresponden al tráfico del grupo de prueba/grupo de control en el lado de la PC y el lado móvil respectivamente:

#设置最终proxy的值：pc_orp、pc_pandora、wap_orp、wap_pandora
set $upstream_target "${terminal_target}_${target_cluster}";
#知道上云切流实验配置结束

Agregado a la bandera de entrega del servicio, los valores son "pandora", "abtest", "orp", que se utilizan para identificar el tráfico del grupo experimental, grupo de control y grupo irrelevante respectivamente.

Transformación de la capa empresarial

La capa comercial captura las marcas de tráfico anteriores, crea y utiliza respectivamente nuevos Eid para iniciar solicitudes comerciales y luego obtiene los datos de tráfico comercial de cada página del grupo experimental/grupo de control actual.

if ($_SERVER['HTTP_X_BD_TARGET'] == 'pandora') {
    $adsEids = array(
        'asp'  => array(50001),
    );
} else if ($_SERVER['HTTP_X_BD_TARGET'] == 'abtest') {
    $adsEids = array(
        'asp'  => array(50002),
    );
}

3.2.3 Correlación de expansión

Tome el conocimiento de la página principal de preguntas y respuestas como ejemplo, cada etapa de expansión tiene contenido de trabajo en el que debe enfocarse en esa etapa y una lista de acceso para ingresar a la siguiente etapa. Solo cuando todo el contenido de la lista cumpla con los estándares se puede iniciar la siguiente etapa del experimento de expansión. Las instrucciones específicas son las siguientes:

imagen

3.2.4 Cambio de puerta de enlace en la nube

Después de migrar la capa empresarial a la nube, el flujo descendente de la puerta de enlace cambia de un entorno orp que apenas migra a un entorno de nube que migra con frecuencia. La capa de acceso orp original no puede ser sensible a los cambios descendentes frecuentes, por lo que la capa de acceso orp original debe cambiarse a la nube. La puerta de enlace de Janus ha sido ampliamente utilizada en líneas de productos como Handbai, Encyclopedia, Ask, Experience y Baijiahao. En comparación con el enrutador original, tiene las siguientes ventajas y se ha sometido a muchas verificaciones prácticas. Por lo tanto, sabemos que Shangyun eligió a Janus en el sistema Zhiyun para cambiar las puertas de enlace.

imagen

Sabiendo que después de 18 años de iteraciones, las reglas de enrutamiento y reenvío de la puerta de enlace se han inflado, la lógica es engorrosa y el costo de mantenimiento es muy alto, un poco de descuido puede causar serios accidentes en línea. Como servicio para el control de reenvío de tráfico, la puerta de enlace debe ser lo más simple y clara posible, con buena legibilidad y facilidad de mantenimiento. Por lo tanto, cuando la puerta de enlace se cambia a la nube, la reconstrucción y la gestión en profundidad del enrutamiento deben llevarse a cabo de forma síncrona, en lugar de una simple reubicación. El proceso central de la reconstrucción de la migración es el siguiente:

imagen

El efecto final conseguido:

1. Percepción sensible en sentido descendente: la nueva puerta de enlace es sensible al desvío de instancias en sentido descendente, la estrategia de reintento superpuesto y el desvío de instancias casi no tiene impacto en el SLA empresarial;

2. Mejore en gran medida la capacidad de mantenimiento: los nombres de dominio de vista previa, intranet y extranet están separados y construidos, y la división es clara, y el uso y el mantenimiento son claros de un vistazo. Integre y converja las 2768 líneas de las reglas de reenvío originales de nginx a 18 reglas en el archivo conf, aclarando la carga histórica de 18 años;

3. La seguridad se ha mejorado aún más: la línea se detalla para cada servicio, cada ruta y cada regla de reenvío, y el área de impacto es controlable. Además de las versiones graduadas, el verificador superpuesto, la inspección en línea, los casos de prueba y otros medios han mejorado en gran medida la seguridad de los cambios en línea de la puerta de enlace.

3.3 Evolución de la arquitectura

3.3.1 Estado y problemas

Sabiendo que durante mucho tiempo, más del 95% del tráfico principal se ha concentrado en el norte, el tráfico central llega a la sala de computadoras tc+jx y el tráfico no central llega a la sala de computadoras yq. Desde el punto de acceso a la red externa hasta la capa empresarial real, los servicios básicos subyacentes y los importantes servicios dependientes de terceros, no se han creado otros recursos y servicios regionales. Esto crea un riesgo de seguridad muy evidente: una vez que ocurre una falla en la región del norte de China, es imposible cortar completamente el flujo para evitar pérdidas en línea.

3.3.2 Esquema de evolución

1. Conozca el tráfico central de la página QB de tres terminales, que representa más del 80% del tráfico total. Es la fuente de más del 99% de los ingresos comerciales. El tráfico natural es grande, hay muchas interacciones de usuarios, es sensible a los accidentes en línea y la estabilidad requiere más de cuatro 9. Esta parte es la línea de vida del conocimiento. Con la migración a la nube esta vez, se construirán cuatro salas de computadoras en tres lugares simultáneamente, de modo que la página QB tenga la capacidad de cambiar rápidamente a los otros dos lugares para una falla de una sola región y mejorar la confiabilidad general del sistema;

2. El tráfico no central que no sea la página QB, debido al tiempo prolongado, involucra muchos módulos, tipos complejos de recursos subyacentes y básicamente no contribuye a los ingresos comerciales. La proporción de tráfico en cada subsistema es relativamente baja. Teniendo en cuenta el costo de transformación y la rentabilidad, esta migración a la nube moverá el tráfico no central a salas de computadoras duales en el norte de China, que tiene capacidades redundantes de recuperación ante desastres para diferentes salas de computadoras en la misma región, y no construirá otras regiones por el momento;

3. Para el tráfico central, es necesario llevar a cabo "punto de acceso a la red externa -> BFE -> capa de acceso -> capa empresarial -> confiar en sus propios servicios -> confiar en servicios de terceros -> confiar en almacenamiento subyacente" construcción de recursos de tres sitios de enlace completo y realizar pruebas de conectividad;

4. Para el tráfico central, una vez que los recursos de servicio en todos los niveles estén en su lugar, se deben realizar pruebas de presión integrales y simulacros de recuperación ante desastres para garantizar la capacidad de presión de tráfico de la sala de computadoras en la nueva región y para cambiar libremente a las otras dos regiones cuando falla una sola región. Para servicios importantes de tres partes que no se pueden probar en línea, como solicitudes de anuncios comerciales, coopere con OP, RD, QA y otras funciones de la otra parte para formular conjuntamente un plan de observación de corte de flujo para evitar riesgos de seguridad en línea causados por cambios en la distribución del tráfico;

5. Para el tráfico principal, diseñe un plan de corte de flujo y establezca un mecanismo de sincronización de servicios de tres partes. Durante el corte de flujo, observen juntos si los subsistemas aguas arriba y aguas abajo cumplen con las expectativas.

3.3.3 Implementación

Se sabe que la evolución de la arquitectura de tráfico después de que se completa la construcción de las tres regiones centrales de tráfico es la siguiente:

imagen

04 Resumen y Beneficios

1. Al 31 de marzo de 23, la proporción de tráfico en la nube alcanzó el 100 % y el negocio se migró por completo a la nube.

imagen

2. En el tercer trimestre de 2022, comenzamos a cambiar a la nube, y el SLA cumplió con cuatro 9 durante tres trimestres consecutivos, y la cantidad de problemas en línea introducidos por la nube fue 0.

imagen

3. Sepa que la página central ha completado la construcción de cuatro salas de computadoras en tres lugares, sepa que la relación de distribución del tráfico central en línea es China del Norte: China Central: China del Sur = 4:3:3, sepa que por primera vez en la historia, tiene capacidad de recuperación ante desastres con redundancia interregional N+1.

imagen

4. El consumo de tiempo promedio de extremo a extremo de la interfaz central QB del applet se redujo en un 12%, y el percentil FMP80 es estable en 1 segundo, y se puede abrir en segundos sin otra optimización técnica.

imagen

5. Completó el ajuste de los puntos de acceso GTC en tres lugares, y el costo compartido de IP de red pública ha disminuido mes a mes desde 2023. Al mismo tiempo, la entrega por lotes de máquinas OXP fuera de línea ha ahorrado una gran cantidad de costos de investigación y desarrollo.

imagen