Autoalojamiento

Dentro del motor de ejecución de n8n: cómo funciona realmente el planificador de flujos de trabajo

Un análisis técnico del modelo de ejecución interno de n8n, que cubre sus objetos de ejecución serializables, la lógica de planificación y la arquitectura de colas para automatización autoalojada.

Ilustración de datos fluyendo a través de nodos de flujo de trabajo en un servidor
Ilustración creada para este artículo

Traducido automáticamente del original en inglés.

n8n ha ganado una gran tracción como alternativa autoalojada a las plataformas comerciales de automatización, pero sus mecánicas internas siguen siendo opacas para muchos usuarios. Un reciente análisis técnico revela que la plataforma se basa en un único objeto de ejecución serializable y un bucle determinista, en lugar de una gestión compleja de hilos. Comprender esta arquitectura ayuda a los ingenieros a depurar flujos de trabajo y escalar implementaciones de manera efectiva.

Qué ocurrió

El artículo ofrece una inmersión profunda en el núcleo del motor de n8n, examinando específicamente la clase WorkflowExecute escrita en TypeScript. Explica que cuando un usuario activa un flujo de trabajo, el sistema no genera hilos individuales para cada nodo. En su lugar, construye un objeto de estado integral llamado IRunExecutionData. Este objeto contiene todo el contexto de la ejecución, incluyendo la pila de nodos pendientes de ejecutar, un mapa para gestionar uniones de múltiples entradas y los resultados históricos de los pasos completados.

Este objeto de estado está diseñado para ser portable. Se mueve desde la interfaz del editor al servidor y potencialmente hacia una cola Redis para procesos de trabajadores (workers). El motor procesa este objeto en un bucle, extrayendo nodos de la pila de ejecución, ejecutándolos, registrando su salida y encolando cualquier dependencia posterior. Este enfoque lineal simplifica el modelo mental para los desarrolladores, eliminando la necesidad de razonar sobre pools de hilos ocultos o condiciones de carrera asincrónicas dentro del propio grafo.

Detalles clave

  • Estado Serializado: El objeto IRunExecutionData transporta todo el estado de tiempo de ejecución, permitiendo que las ejecuciones se pausen, reanuden o se muevan entre procesos sin perder contexto.
  • Configuración del Orden de Ejecución: Los usuarios pueden elegir entre v0 (amplitud primero) y v1 (profundidad primero), lo cual cambia si el motor prioriza completar todos los hermanos en un nivel o perseguir una sola rama hasta su finalización.
  • Mapa de Espera para Uniones: Los nodos con múltiples entradas no se ejecutan hasta que todos los datos upstream requeridos estén disponibles. Los datos parciales se almacenan en un mapa de espera hasta que cada ranura necesaria esté llena.
  • Terminación de Ramas: Si un nodo devuelve datos vacíos, la rama posterior se detiene a menos que se establezca la bandera alwaysOutputData, que fuerza al motor a fabricar un ítem vacío para mantener vivo el flujo.
  • Arquitectura en Modo Cola: En entornos de producción, el proceso principal maneja la UI y los webhooks, mientras que los workers sin estado extraen trabajos de Redis, ejecutan el mismo bucle del motor y escriben los resultados en PostgreSQL.
  • Licencia Fair-Code: n8n utiliza la Sustainable Use License, que permite el uso comercial interno gratuito y la modificación, pero prohíbe la reventa como producto SaaS alojado competidor.

Contexto

Para entender el diseño de n8n, es útil distinguir entre el recorrido de grafos y la programación de tareas. Muchas herramientas visuales de automatización abstraen el orden de las operaciones, lo que lleva a comportamientos impredecibles cuando las ramas se fusionan o dividen. n8n expone esta lógica a través de sus configuraciones de orden de ejecución. La ejecución amplitud primero asegura que todas las tareas paralelas a una profundidad dada se completen antes de avanzar más profundamente, lo cual es útil para el procesamiento por lotes. La ejecución profundidad primero sigue un camino completamente antes de retroceder, lo que puede reducir el uso de memoria en cadenas largas.

El concepto de "fair-code" también es central para la adopción de n8n. A diferencia de las licencias puramente open-source, fair-code permite a las empresas usar y modificar el software libremente para sus propias operaciones internas. Sin embargo, restringe a las entidades de ofrecer el software como un servicio gestionado a terceros. Este modelo apoya una vibrante comunidad de autoalojadores mientras protege los intereses comerciales de los mantenedores principales.

Por qué importa

Para equipos que gestionan su propia infraestructura, la previsibilidad es más valiosa que la velocidad bruta. Saber que n8n usa un bucle de un solo hilo para cada ejecución significa que la depuración es determinista. Si un flujo de trabajo falla, el objeto de estado captura exactamente qué pasó en cada paso. Los ingenieros pueden inspeccionar el runData para ver la entrada y salida de cada nodo, facilitando identificar dónde fallaron las transformaciones de datos. Esta visibilidad suele faltar en alternativas SaaS de caja negra.

La escalabilidad es otro factor crítico. Dado que el estado de ejecución es serializable, n8n puede escalar horizontalmente usando el modo cola. El servidor de aplicación principal permanece ligero, manejando solo solicitudes API e ingesta de webhooks, mientras que los procesos de worker dedicados realizan el trabajo pesado de la ejecución de flujos de trabajo. Esta separación permite a los equipos DevOps ajustar recursos basándose en la profundidad de la cola en lugar de adivinar cuánta CPU necesita el proceso principal. También evita que el tráfico intenso de webhooks bloquee la interfaz de usuario.

Qué puedes hacer

  • Auditar el Orden de Ejecución: Revisa tus flujos de trabajo complejos y alterna entre órdenes de ejecución v0 y v1 para ver si el rendimiento o la lógica mejoran para casos de uso específicos.
  • Manejar Ramas Vacías: Establece explícitamente alwaysOutputData: true en nodos donde las acciones posteriores deben ocurrir incluso si el paso anterior no produce resultados.
  • Monitorear la Profundidad de la Cola: Si usas el modo cola, configura alertas para la longitud de la cola Redis para escalar pods de worker automáticamente usando Kubernetes HPA o KEDA.
  • Inspeccionar Datos de Ejecución: Usa el visor de ejecución integrado para examinar el linaje pairedItem al depurar errores de mapeo de datos en uniones complejas.
  • Verificar Cumplimiento de Licencia: Asegúrate de que tu uso se alinea con la Sustainable Use License, especialmente si estás construyendo automatizaciones personalizadas para clientes externos.
  • Probar Resiliencia de Webhooks: Simula eventos de webhook de alto volumen para verificar que tus procesadores de webhook dedicados no están bloqueando el hilo principal de la UI.

Más noticias

Todas las noticias