En eBay, hay muchos escenarios que requieren un sistema distribuido. Un caso de uso típico es cuando se lanza una gran cantidad de bibliotecas. Hay más de 3000 bibliotecas heredadas aún creadas por el antiguo sistema de compilación basado en Ant, que ya no es compatible. Estas bibliotecas ahora se están migrando a un código fuente mavenizado siguiendo la experiencia de desarrollo estándar de maven. Después de la migración del código, se necesita una nueva solución de lanzamiento para admitir el lanzamiento periódico de todas las bibliotecas, que debe ser liviana, escalable, estable y rápida. Para lograr esto, se deben resolver los siguientes desafíos.
Desafíos
El requisito previo para el lanzamiento de una biblioteca es que todas sus dependencias ya se hayan publicado, pero teniendo en cuenta la gran cantidad de bibliotecas candidatas y las complicadas relaciones de dependencia entre sí, causará un impacto considerable en el rendimiento del lanzamiento si las bibliotecas lanzan la secuencia. no se puede orquestar bien.
En eBay, Jenkins es la herramienta estándar de CI/CD para realizar lanzamientos expertos. Para hacer que las bibliotecas se publiquen más en paralelo, se involucrarán varios nodos de Jenkins. El desafío es encontrar los nodos de Jenkins óptimos para liberar de forma estable más de 3000 bibliotecas con eficiencia y mantener los nodos para un uso a largo plazo. Entonces, la capacidad del sistema de liberación debe ser:
- Capaz de proporcionar la capacidad maximizada en paralelo para realizar lanzamientos basados en la relación de dependencia entre bibliotecas;
- Ligero y fácil de configurar, escalar y mantener; y
- Estable y tolerante a fallas para que todo el proceso de lanzamiento se realice sin problemas.
Solución
Priorizar bibliotecas por dependencia
Como biblioteca experta, es fácil obtener relaciones de dependencia analizando las dependencias definidas en pom.xml. Si una biblioteca puede descifrar un “árbol de dependencia” para identificar la relación, entonces, para la gran cantidad de bibliotecas, habrá un DAG pesado (gráfico acíclico dirigido) para identificar las relaciones complicadas entre ellas. El siguiente es un DAG de muestra que refleja la relación de las bibliotecas y cada ciclo representa una sola biblioteca.
Se puede liberar una biblioteca si se han liberado todas sus dependencias (nodos secundarios). Entonces, en el diagrama anterior, los números dos, tres y cuatro se pueden soltar en paralelo después de que se suelte el número uno. Y los nodos con color azul se pueden liberar por separado ya que no depende de otras ramas.
El servicio central del sistema de liberación distribuida calcula el DAG y analiza la relación, luego configura todos los nodos que pueden liberarse en paralelo con la misma prioridad y los pone a todos en una cola. Luego, la prioridad decide la secuencia de liberación, por lo que el nodo hoja (número uno) será la primera prioridad que debe liberarse primero y los nodos principales (números dos, tres y cuatro) se liberarán de forma secundaria.
Sintonización prioritaria
Para las bibliotecas que pueden publicarse en paralelo, no es la mejor manera de publicarlas aleatoriamente aunque parezca que tienen la misma prioridad y están listas para publicarse, porque algunos nodos pueden ralentizar todo el proceso de publicación. El siguiente diagrama muestra el caso.
Desde el DAG, después de que se liberó el nodo número uno, los nodos principales del número dos al seis se pueden liberar en paralelo. En esas versiones candidatas, solo el nodo número tres depende de otros nodos. Si estos nodos se liberan en secuencia aleatoria y hay tres nodos de Jenkins para realizar el trabajo de liberación, es posible que el nodo número tres sea el último en liberarse. En este escenario, los otros dos nodos de Jenkins tienen que esperar a que se libere el nodo número tres, ya que desde DAG no hay otros nodos disponibles para liberar hasta que se libere el número tres. Por lo tanto, el nodo número tres es el nodo clave y debe ajustarse con mayor prioridad que los nodos del dos al seis. Después de que el número tres se libere primero, los nodos del siete al 10 se pueden agregar a la cola de prioridad como candidatos de liberación. Todos los nodos de Jenkins funcionarán a plena capacidad en lugar de estar inactivos a la espera de los candidatos de lanzamiento.
Por lo tanto, la configuración de prioridad seguirá este principio: en los nodos que se pueden liberar en paralelo, el nodo con más nodos principales tendrá mayor prioridad y se liberará primero.
Después de que todas las bibliotecas se establezcan en la cola de lanzamiento por prioridad, el servicio central puede aprovechar Jenkins para realizar el lanzamiento.
Optimizar la concurrencia con Jenkins
Modo de empuje
Una forma fácil de aprovechar Jenkins para realizar la publicación es a través del servicio central, que selecciona los nodos (bibliotecas) con la misma prioridad de la cola de publicación y luego activa un trabajo de Jenkins para cada nodo para publicación.
Se le puede llamar ‘modo push’. Si hay más de 100 bibliotecas con la misma prioridad, para maximizar la capacidad paralela, activará/empujará casi la misma cantidad de trabajos de Jenkins desde varios servidores de Jenkins para su lanzamiento. El siguiente diagrama muestra esta arquitectura.
La arquitectura tiene dos problemas potenciales.
- El sistema de lanzamiento depende de muchos nodos Jenkins en vivo antes de cada ronda de lanzamiento. En el proceso de lanzamiento, todos los nodos de Jenkins deben estar bien monitoreados sobre el estado del lanzamiento. Es propenso a errores y será un gran esfuerzo para el mantenimiento y la resolución de problemas de cada nodo de Jenkins para problemas de red/rendimiento.
- Cada versión de la biblioteca activará los trabajos de Jenkins programados correspondientes de forma asíncrona. Puede llevar más tiempo esperar la ejecución del trabajo que realizar el trabajo de liberación. Teniendo en cuenta la gran cantidad de bibliotecas en la fase de lanzamiento, el proceso de lanzamiento tardará mucho tiempo (varios días) en completarse.
- Las dependencias de Maven deben descargarse en cada nodo de Jenkins de forma repetitiva y no pueden compartirse entre diferentes nodos.
Entonces, para acelerar el proceso de lanzamiento y hacerlo más liviano y estable, se ha descubierto el modo de extracción.
Modo de extracción
Dado que Jenkins admite bien Groovy, es fácil usar Groovy para implementar algunas funciones avanzadas en el lado de Jenkins. Cada trabajo de Jenkins funciona como una canalización con un script Groovy. Una vez que comienza el lanzamiento (la cola de lanzamiento se ha llenado por prioridad), los nodos de Jenkins deben estar en el ciclo de extracción de la biblioteca candidata llamando al servicio central y liberándolo, luego informando los resultados y tirando del siguiente hasta que se liberen todas las bibliotecas. Así que la arquitectura final se muestra a continuación.
Los beneficios de esta arquitectura son obvios.
- Se maximizará la utilización de los recursos del nodo único de Jenkins. El nodo único de Jenkins funciona constantemente, evita la pérdida de tiempo para la programación de trabajos de Jenkins y todas las dependencias descargadas que residen en el mismo nodo se pueden compartir entre diferentes bibliotecas.
- No es necesario reservar una gran cantidad de nodos de Jenkins porque solo un nodo con 20 trabajos de Jenkins puede manejar todo el lanzamiento. Es fácil de configurar y mantener.
Ahora, el modo de extracción solo tarda unas dos horas en completar más de 3000 versiones de la biblioteca, lo que es una mejora significativa dado que el modo de inserción tarda de 2 a 3 días en completarse.
Con los beneficios y la mejora del rendimiento anteriores, el sistema de lanzamiento utiliza el modo de extracción para administrar los nodos de Jenkins para manejar el lanzamiento de todas las bibliotecas.
Resumen
La arquitectura distribuida liviana proporciona una solución exitosa para las miles de bibliotecas lanzadas en eBay, que ya beneficia la migración de bibliotecas heredadas.
El servicio central funciona con una pequeña cantidad de nodos de Jenkins en modo pull que proporciona una solución rápida, escalable, estable y mantenible. Además, la arquitectura distribuida no se limita a la liberación de tareas. Es una arquitectura genérica y se puede aplicar fácilmente a casos en los que se asignan muchas subtareas a varios trabajadores para ejecutar y resumir los resultados una vez que se completan todas.
A continuación se presentan dos casos aplicables que son muy comunes en el trabajo diario.
- Casos de prueba de integración distribuida en ejecución, generaron resultados resumidos una vez que todas las pruebas se ejecutaron por completo.
- Recopilación/análisis de datos de diferentes canales simultáneamente y generación de informes.
Con esta arquitectura, es fácil configurar el servicio central y los trabajadores (nodos de Jenkins) para manejarlos con alta eficiencia.
