¿El apio es apropiado para usar con muchos sistemas pequeños y distribuidos?

Question

Estoy escribiendo un software que administrará algunos cientos de small systems en "el campo" a través de una conexión intermitente 3G (o similar).

La base doméstica necesitará enviar trabajos a los sistemas en el campo (por ejemplo, "informar sobre su estado", "actualizar su software", etc.), y los sistemas en el campo deberán enviar trabajos a la servidor (por ejemplo, "se ha detectado una falla", "aquí hay algunos datos", etc.).

He pasado algún tiempo buscando en Celery y parece ser un ajuste perfecto: celeryd funcionando a base podría recoger puestos de trabajo para los sistemas en el campo, un celeryd que se ejecuta en los sistemas de campo podría recoger puestos de trabajo para el servidor, y estos trabajos podrían intercambiarse a medida que los clientes estén disponibles.

¿Por lo tanto, apio es una buena opción para este problema? Específicamente:

• La mayoría de las tareas será dirigido a un trabajador individual (por ejemplo, “enviar el trabajo‘’get_status a‘system51’”) - ¿será esto un problema?
• ¿Maneja correctamente las condiciones adversas de la red (como, por ejemplo, la muerte de las conexiones)?
• ¿Qué funcionalidad solo está disponible si RabbitMQ se está utilizando como back-end? (Prefiero no ejecutar RabbitMQ en los sistemas de campo)
• ¿Hay alguna otra razón por la que Aplery podría dificultar mi vida si la uso como la describí?

Gracias!

(sería válida para sugerir que el apio es una exageración, pero hay otras razones que haría mi vida más fácil, así que me gustaría tener en cuenta que)

Answer 1

La mayoría de las tareas será dirigida a un trabajador individual (por ejemplo, “enviar el trabajo ‘get_status’a‘system51’”) - será esto un problema?

No, en absoluto. Simplemente cree una cola para cada trabajador, p.decir cada nodo escucha a una cola de round robin llamada default y cada nodo tiene su propia cola llamado así por su nombre de nodo:

(a)$ celeryd -n a.example.com -Q default,a.example.com 
(b)$ celeryd -n b.example.com -Q default,b.example.com 
(c)$ celeryd -n c.example.com -Q default,c.example.com 

Enrutamiento una tarea directamente a un nodo es simple:

$ get_status.apply_async(args, kwargs, queue="a.example.com") 

o configuración mediante un Router:

# Always route "app.get_status" to "a.example.com" 
CELERY_ROUTES = {"app.get_status": {"queue": "a.example.com"}} 

lo hace con gracia manejar adverso condiciones de la red (como, por ejemplo, conexiones que faltan)?

El trabajador se recupera con gracia de los fallos de conexión del intermediario. (al menos desde RabbitMQ, no estoy seguro acerca de todos los otros backends, pero esto es fácil de probar y solucionar (sólo tiene que añadir las excepciones relativas a una lista)

Para el cliente siempre se puede a intentar enviar la tarea si la conexión está inactiva, o puede configurar HA con RabbitMQ:? http://www.rabbitmq.com/pacemaker.html

¿Qué funcionalidad sólo está disponible si RabbitMQ está siendo utilizado como un backend (prefiero no correr RabbitMQ en los sistemas de campo)

Comandos de control remoto, y solo se admiten intercambios "directos" (no "tema" o "fanout"). Pero esto será compatible con Kombu (http://github.com/ask/kombu).

Reconsideraría seriamente el uso de RabbitMQ. ¿Por qué crees que no es una buena opción? En mi humilde opinión No buscaría en otro lugar un sistema como este (excepto tal vez ZeroMQ si el sistema es transitorio y no necesita persistencia de mensaje).

¿Hay alguna otra razón por la que Aplery pueda hacerme la vida difícil si lo uso como he descrito?

No se me ocurre nada de lo que describes arriba. Dado que el modelo de concurrencia es multiproceso, requiere algo de memoria (estoy trabajando para agregar compatibilidad con grupos de subprocesos y grupos de eventos, lo que puede ayudar en algunos casos).

sería válida para sugerir que el apio es una exageración, pero hay otras razones que haría mi vida más fácil, por lo que me gustaría considerarlo)

En ese caso, piensas que usas la palabra overkill ligeramente. Realmente depende de la cantidad de código y las pruebas que necesita para escribir sin él. Creo que es mejor mejorar una solución general ya existente, y en teoría suena como debería funcionar para su aplicación.

Answer 2

que probablemente establecer una (Django) servicio web para aceptar solicitudes. El servicio web podría hacer el trabajo de validar las solicitudes y desviar las solicitudes incorrectas. Entonces el apio solo puede hacer el trabajo.

Esto requeriría que los dispositivos remotos sondeen el servicio web para ver si se realizaron los trabajos. Eso puede o no ser apropiado, dependiendo de lo que estés haciendo exactamente.