php - productos - Cómo gestionar/equilibrar trabajos semi persistentes en instancias de servicio

dollar city productos (3)

Deberías echar un vistazo a Gearman .

Se compone de un client que asigna los trabajos, uno o más workers que recogerán y ejecutarán los trabajos y un server que mantendrá la lista de funciones (servicios) y trabajos pendientes. Se volverá a asignar los trabajos si un trabajador muere.

Veo un patrón común para los servicios que intentamos desarrollar y me pregunto si hay herramientas / bibliotecas que ayuden aquí. Si bien los trabajos predeterminados, tal como se analizan en la literatura de microservicios, son de la naturaleza SOLICITUD -> RESPUESTA, nuestros trabajos son más o menos asignaciones de tareas semipermanentes.

Ejemplos de tales tareas

Escuche en la cola de mensajes los datos de origen X e Y, correlacione los datos que vienen y almacénelos en Z.
Mantenga un búfer en memoria que calcule un promedio de los últimos 15 minutos de datos cada vez que ingrese una nueva entrada de datos.

Actualmente nuestros servicios están escritos en PHP. Debido a la sobrecarga percibida de los procesos de PHP y las conexiones a la cola de mensajes, nos gustaría que un solo proceso de servicio maneje múltiples de esos trabajos simultáneamente.

Un gráfico que esperamos ilustró la configuración que tenemos en nuestra cabeza:

Los trabajadores de servicios están actualmente desmitificados en scripts PHP.
Para el Registro de Servicios estamos buscando a Zookeeper.

Mientras que Zookeeper (y Curator) hacen balanceo de carga, no encontré nada alrededor de la distribución de trabajos permanentes (que son actualizables, removibles y deben ser reasignados cuando un trabajador muere)

Responsabilidades propuestas de un administrador de trabajo

Sabe sobre trabajos
Conoce los servicios que pueden hacer estos trabajos.
Puede asignar trabajos a servicios
Puede enviar actualizaciones de trabajo a los servicios.
Puede reasignar trabajos si un trabajador muere

¿Existen bibliotecas / herramientas que puedan abordar estos problemas y, por lo tanto, pueden funcionar como el Administrador de trabajos? ¿O es este todo un gran patrón anti y deberíamos hacerlo de otra manera?

RabbitMq es una cola de mensajes simple con la que es bastante fácil ponerse en marcha.

Sus trabajadores suenan como (api-menos) servicios en sí mismos. Por lo tanto, sus requerimientos pueden ser reformulados como:

Conoce los servicios desplegados.
Conoce los nodos que pueden alojar sus servicios.
Puede desplegar servicios a nodos.
Puede [enviar actualizaciones de trabajos a los servicios] = volver a implementar servicios / invocar algunas API en los servicios implementados
Puede volver a desplegar el servicio si el servicio o el nodo muere

Mire a Docker para implementar, ejecutar y administrar procesos aislados en el host.