Por qué usar AMQP/ZeroMQ/RabbitMQ
messaging (6)
en lugar de escribir tu propia biblioteca.
Estamos trabajando en un proyecto que será un grupo de servidores que se divide a sí mismo, si una sección se vuelve demasiado pesada, el administrador la dividirá y la colocará en otra máquina como un proceso separado. También alertaría a todos los clientes conectados que esto afecta para conectarse al nuevo servidor.
Tengo curiosidad sobre el uso de ZeroMQ para la comunicación entre servidores y entre procesos. Mi compañero preferiría rodar el suyo. Estoy buscando a la comunidad para responder esta pregunta.
Soy un programador bastante novato y acabo de aprender sobre colas de mensajes. Como busqué en Google y leí, parece que todos están usando colas de mensajes para todo tipo de cosas, pero ¿por qué? ¿Qué los hace mejores que escribir tu propia biblioteca? ¿Por qué son tan comunes y por qué hay tantos?
¿Qué los hace mejores que escribir tu propia biblioteca?
Al implementar la primera versión de su aplicación, probablemente nada: sus necesidades están bien definidas y desarrollará un sistema de mensajería que se ajuste a sus necesidades: lista de características pequeña, código fuente pequeño, etc.
Esas herramientas son muy útiles después de la primera versión, cuando en realidad tiene que extender su aplicación y agregarle más funciones. Déjame darte algunos casos de uso:
- su aplicación tendrá que hablar con una máquina endian grande (sparc / powerpc) de una pequeña máquina endian (x86, intel / amd). Su sistema de mensajería tenía alguna suposición de pedido endian: ir y arreglarlo
- diseñó su aplicación para que no sea un sistema de mensajería / protocolo binario y ahora es muy lenta porque pasa la mayor parte de su tiempo analizando (el número de mensajes aumentó y el análisis se convirtió en un cuello de botella): adáptelo para que pueda transportar archivos binarios / codificación fija
al principio tenías 3 máquinas dentro de una lan, sin demoras notables, todo llega a cada máquina. aparece su cliente / jefe / jefe del demonio de pelo puntiagudo y le dice que instalará la aplicación en WAN que no administra, y luego comienza a tener fallas de conexión, mala latencia, etc., necesita almacenar el mensaje y volver a intentar enviarlo más adelante: vuelva al código y conecte estas cosas (y disfrute)
los mensajes enviados necesitan respuestas, pero no todos: envía algunos parámetros y espera una hoja de cálculo como resultado en lugar de solo enviar y confirmar, volver al código y conectar esto (y disfrutar).
- algunos mensajes son críticos y su recepción / envío necesita una copia de seguridad / persistencia / adecuada. Porque preguntas ? fines de auditoría
Y muchos otros casos de uso que olvidé ...
Puede implementarlo usted mismo, pero no dedique mucho tiempo a hacerlo: probablemente lo reemplace más adelante de todos modos.
¿Qué los hace mejores que escribir tu propia biblioteca?
Los sistemas de colas de mensajes son transaccionales, que es conceptualmente fácil de usar como cliente, pero difíciles de manejar como implementadores, especialmente considerando las colas persistentes. Puede pensar que puede salirse con la suya escribiendo una biblioteca de mensajería rápida, pero sin transacciones y persistencia, no tendría todos los beneficios de un sistema de mensajería.
La persistencia en este contexto significa que el middleware de mensajería mantiene los mensajes no administrados en el almacenamiento permanente (en el disco) en caso de que el servidor se caiga; después de un reinicio, los mensajes pueden manejarse y no es necesario retransmitir (el remitente ni siquiera sabe que hubo un problema). Transaccional significa que puede leer mensajes de diferentes colas y escribir mensajes en diferentes colas de forma transaccional, lo que significa que todas las lecturas y escrituras tienen éxito o (si una o más fallan) ninguna tiene éxito. Esto no es muy diferente de la transaccionalidad conocida al interactuar con bases de datos y tiene los mismos beneficios (simplifica el manejo de errores; sin transacciones, debería asegurarse de que cada lectura / escritura individual tenga éxito, y si una o más fallan, usted tiene para revertir aquellos cambios que tuvieron éxito).
¡Si tiene un poco de tiempo, pruébelo y despliegue su propia implementación! El aprendizaje de este ejercicio lo convencerá de la sabiduría de usar una biblioteca ya probada.
Antes de escribir su propia biblioteca, lea la Guía 0MQ aquí: http://zguide.zeromq.org/page:all
Lo más probable es que decida instalar RabbitMQ, de lo contrario, hará que su biblioteca se encuentre en la cima de ZeroMQ, ya que ya han hecho todas las partes difíciles.
Es muy parecido a preguntar: ¿por qué usar una base de datos cuando puedes escribir la tuya?
La respuesta es que usar una herramienta que ha existido por un tiempo y que se entiende bien en muchos casos de uso diferentes, rinde más y más a medida que pasa el tiempo y según evolucionan sus requisitos. Esto es especialmente cierto si hay más de un desarrollador involucrado en un proyecto. ¿Desea convertirse en personal de soporte para un sistema de colas si cambia a un nuevo proyecto? Usar una herramienta evita que eso suceda. Se convierte en el problema de otra persona.
Caso en punto: persistencia. Escribir una herramienta para almacenar un mensaje en el disco es fácil. Escribir un persistor que se escala y funciona bien y de manera estable, en muchos casos de uso diferentes, y es manejable, y de bajo costo para mantener, es difícil. Si quieres ver a alguien quejándose de lo difícil que es, mira esto: http://www.lshift.net/blog/2009/12/07/rabbitmq-at-the-skills-matter-functional-programming-exchange
De todos modos, espero que esto ayude. Por supuesto, escriba su propia herramienta. Muchas personas lo han hecho. Lo que resuelva tu problema, es bueno.
Estoy considerando usar ZeroMQ yo mismo, por lo tanto, me encontré con esta pregunta.
Supongamos por el momento que tiene la capacidad de implementar un sistema de cola de mensajes que cumpla con todos sus requisitos. ¿Por qué debería adoptar ZeroMQ (u otra biblioteca de terceros) sobre el enfoque de "rodar por su cuenta"? Simple - costo.
Supongamos por un momento que ZeroMQ ya cumple con todos sus requisitos. Todo lo que necesita hacerse es integrarlo en su construcción, leer un poco de doco y luego comenzar a usarlo. Eso tiene que ser mucho menos esfuerzo que hacer tu propio. Además, la carga de mantenimiento se ha trasladado a otra empresa. Como ZeroMQ es gratuito, es como si acabaras de hacer crecer tu equipo de desarrollo para incluir (parte del) equipo de ZeroMQ.
Si ejecutó un negocio de desarrollo de software, entonces creo que equilibraría el costo / riesgo de usar bibliotecas de terceros para no hacer rodar el suyo, y en este caso, usar ZeroMQ ganaría sin problemas.
Quizás usted (o más bien, su compañero) sufra, como muchos desarrolladores, por el síndrome de "No inventado aquí" . Si es así, ajuste su actitud y vuelva a evaluar el uso de ZeroMQ. Personalmente, prefiero los beneficios de la actitud de Proudly Found Elsewhere. Espero poder estar orgulloso de encontrar ZeroMQ ... el tiempo dirá.
EDITAR: Me encontré con este video de los desarrolladores de ZeroMQ que explica por qué debería usar ZeroMQ.