message queue - que - ¿En qué dominios es útil el middleware orientado a mensajes como AMQP?
rabbitmq vs kafka (4)
Buenas respuestas y discusión aquí. Nuestro equipo de consultoría tiene dos soluciones preferidas de "mensajería": RabittMQ y NXTera, un middleware RPC de alta velocidad, la versión contemporánea de Entera mencionada anteriormente. Mis socios y yo hemos desarrollado varias soluciones usando RabittMQ, es la mejor herramienta disponible en ese espacio en este momento. Además, casualmente trabajo para la compañía que fabrica NXTera / Entera.
Por experiencia, puedo decir claramente que ambos productos cumplen con la necesidad de confiabilidad y bajo mantenimiento, como se discutió anteriormente. Hay situaciones en las que un servicio de mensajería, como RabittMQ, es la opción correcta, donde se requieren Publicar y suscribirse, entrega certificada, Queuing o store-and-forward.
En otros casos, las RPC (llamadas a procedimientos remotos) son las mejores y más rápidas soluciones para el procesamiento transaccional y distribuido para aplicaciones empresariales o basadas en la nube. Cuando es correcto usar un RPC, pero SOAP / .NET (sí, estas son implementaciones RPC) son demasiado lentos, caros o complejos, un middleware RPC de alta velocidad como NXTera / Entera es la elección correcta para nosotros.
Existe una superposición de casos de uso entre el middleware de RPC y el middleware orientado a mensajes, y en los casos en que puede utilizarlos correctamente. Pero ambas son opciones fuertes y confiables.
Las grandes empresas con las que trabajo utilizan tanto RPC como MoM de forma paralela. En lo que respecta a las empresas de Internet, Google (Protocol Buffers) y Facebook (Thrift) muestran que los RPC tienen un rol para jugar en la web moderna y en el desarrollo basado en la nube.
¿Qué problema resuelve MOM (Middleware orientado a mensajes)? Escalabilidad? ¿Integración?
¿En qué dominio se usan normalmente y en qué dominios normalmente no se usan?
Por ejemplo, digamos, ¿usa Google esta solución para su motor de búsqueda principal o para alimentar a GMail?
¿Qué hay de los grandes sitios web como Walmart, eBay, FedEx (prácticamente una tienda de Java) y buy.com (prácticamente una tienda de MS)? ¿MOM resuelve una necesidad allí?
¿Tiene algún sentido cuando estás escribiendo una aplicación Webapp donde controlas el lado del servidor y tienes un entorno homogéneo (digamos decenas de instancias de Amazon EC2 que ejecutan todas las JVM de Linux + Java) y donde los clientes son, bueno, navegadores web?
¿Tiene sentido para las aplicaciones de escritorio que necesitan comunicarse con un servidor?
¿O es ''solo'' para cosas de grandes empresas en las que normalmente tienes una mezcla feliz de innumerables sistemas diferentes que necesitan comunicarse de una forma u otra?
Estoy un poco confundido acerca de para qué son útiles y creo que con un ejemplo de dónde son apropiados y dónde no son apropiados, podría entender mejor su uso.
Esta es una gran pregunta.
Los principales usos de la mensajería son: escalado, trabajo de descarga, integración, monitoreo, manejo de eventos, enrutamiento, redes, push, movilidad, almacenamiento en búfer, colas, compartir tareas, alertas, administración, registro, lote, entrega de datos, pubsub, multidifusión, auditoría , programación, ... y más. Básicamente: cualquier cosa donde necesite datos pero no quiera hacer una solicitud de base de datos. (El almacenamiento en caché es otra historia más larga).
Otra forma de ver esto es observar que muchas aplicaciones solían construirse al asumir que los usuarios (personas) realizarían acciones que se cumplirían ejecutando una transacción en una base de datos (incluyendo lecturas, escrituras). Pero hoy, muchas acciones no son iniciadas por el usuario. En cambio, son iniciados por la aplicación. Por ejemplo, "dime cuándo el libro que quiero comprar está en existencia". La mejor manera de resolver esta clase de problemas es con algún tipo de mensaje. Ya sea que lo llames middleware o web push o aderezo en tiempo real no importa. Es todo mensajería.
Cuando habilita aplicaciones para iniciar o reaccionar ante eventos, entonces es mucho más fácil escalar porque su arquitectura puede basarse en componentes poco compactos. También es mucho más fácil integrar esos componentes si su mensaje se basa en una herramienta estable, escalable y útil, preferiblemente utilizando API y protocolos estándar abiertos.
Espero que esto ayude. Tratamos de mantener una lista de enlaces útiles sobre mensajes here
Por favor, póngase en contacto con preguntas y comentarios sobre cualquiera de estos, somos muy fáciles de encontrar.
Para abordar sus preguntas específicas:
¿En qué dominio se usan normalmente y en qué dominios normalmente no se usan?
Al igual que las bases de datos, los sistemas de mensajería aparecen en todas partes.
Por ejemplo, digamos, ¿usa Google esta solución para su motor de búsqueda principal o para alimentar a GMail?
Google usa mucha tecnología local, pero muchas de sus contribuciones de código abierto y casos de uso conocidos sugieren que la mensajería es (o debería ser) central en algunos de los principales servicios.
¿Qué hay de los grandes sitios web como Walmart, eBay, FedEx (prácticamente una tienda de Java) y buy.com (prácticamente una tienda de MS)? ¿MOM resuelve una necesidad allí?
Mucho.
Un ejemplo de caso de uso es escalar las solicitudes de páginas web. Cuando el usuario realiza una solicitud web, el servidor web la coloca en una cola para el procesamiento en segundo plano. Esto significa que el servidor web puede seguir trabajando mientras se procesa la solicitud. También significa que el servidor web no necesita saber cómo se maneja la solicitud, por lo que el mantenimiento del sistema, la actualización y la reversión son mucho más simples porque las partes principales están ''desacopladas''.
Entonces, de todos modos, la solicitud web es procesada por un servicio final, o posiblemente por muchos servicios, por ejemplo, ''buscar títulos de libros'', ''dibujar carrito de compras'', ''obtener publicidad'', ''verificar cuenta de usuario'' ... Finalmente todo los resultados se colocan en otra cola, listos para que el servidor web los recoja y responda al usuario. Normalmente, el sistema incluirá un tiempo de espera de alrededor de 100 ms, por lo que cualquier solicitud atrasada simplemente se descarta. El usuario ve todo lo que se procesó en el intervalo de tiempo. Esta es una razón por la cual algunos grandes sitios de comercio electrónico tienen páginas que parecen cargarse en etapas.
Hay muchos más casos de uso ...
¿Tiene algún sentido cuando estás escribiendo una aplicación Webapp donde controlas el lado del servidor y tienes un entorno homogéneo (digamos decenas de instancias de Amazon EC2 que ejecutan todas las JVM de Linux + Java) y donde los clientes son, bueno, navegadores web?
Seguro. Si tiene una cantidad desconocida o ilimitada de usuarios, instancias del lado del servidor y latencias de la aplicación, entonces tiene sentido utilizar la mensajería, incluso si solo es un sustrato escalable para RPC sin bloqueo.
¿Tiene sentido para las aplicaciones de escritorio que necesitan comunicarse con un servidor?
En muchos casos Un caso muy común es cuando el servidor envía eventos a la aplicación de escritorio, por ejemplo, evento del juego, tweets, precios de las finanzas, alertas del sistema ...
¿O es ''solo'' para cosas de grandes empresas en las que normalmente tienes una mezcla feliz de innumerables sistemas diferentes que necesitan comunicarse de una forma u otra?
Definitivamente no solo para los casos de ''integración heredada'', sino que también son importantes. En RabbitMQ, los mayores clientes que tenemos en términos de escala pura o volumen de mensajes son los proveedores de la nube y los grandes proveedores de aplicaciones web.
Responderé a una sola respuesta, por experiencia previa: eche un vistazo a este middle-ware que aquí emplean las grandes empresas; Middleware tiene un único propósito: unir los sistemas desconectados (escritos en diferentes idiomas) para que funcionen juntos. pueden interactuar entre sí y agilizar el proceso comercial. Entera, como lo he experimentado, crea una capa intermedia en la que el cuadro Unix utiliza procesos escritos en C, interactúa con el sistema mainframe (DB2, COBOL) a través de un front-end escrito en PowerBuilder (¡no estoy nombrando a la compañía!).
Según la descripción que he dado, Entera es un software intermedio que aloja varias cosas: integración fluida del flujo de datos independientemente del formato endian, capacidad para que diferentes idiomas hablen con el intermediario de software intermedio (un intermediario es un CORBA o DCE como proceso, que se ajusta a ''The Open Group'' que escucha en un puerto particular) y es especificado por un IDL que hace que un proceso parezca ser local, si usted entiende la terminología utilizada en Remoting bajo el Marco de .NET de Microsoft, ¡no estás lejos de la marca! El middleware genera stubs que están vinculados en tiempo de compilación y gestiona la creación del proceso, alojándolo de un puerto, multi-threading en tiempo de ejecución, y también, los front-ends modernos (como .NET, Java , PowerBuilder incluso el inefable VB6 ... ok ... VB.NET para los puristas que existen) puede interactuar abriendo una conexión al puerto especificado en una dirección IP particular, y usando los stubs generados, puede interactuar directamente con él.
Obviamente, a partir de lo descrito se puede ver cómo los sistemas legados pueden tener una nueva vida inspirada en él y, por lo tanto, la escalabilidad del proceso, la principal desventaja de esto es el factor de costo que puede llegar a miles de dólares. Las grandes empresas que utilizan mainframes como sus sistemas de procesamiento back-end para facturación / facturación, que generan grandes ingresos, obviamente pueden permitirse un producto tan costoso, para ellos parecería tirar centavos en un charco de agua ... debido al uso de middleware que prolonga el proceso comercial y le da nueva vida, puede extender el negocio en un buen número de años hacia el futuro sin preocuparse por la etiqueta ''legacy'' que se le atribuye.
A propósito, lo llevé a cabo como parte de mi tesis para mi BSc. en Sistemas de Información que cubrieron este front-end comercial. Hubo una versión de código abierto del FreeDCE disponible en sourceforge llamada FreeDCE , pero los esfuerzos de desarrollo se han reducido o suspendido.
Edit: @cocotwo: Eso es exactamente lo que hace middle-ware como dijiste es una herramienta de fontanería ... middle-ware orientado a mensajes realmente no se escucha de AFAIK porque me imagino que los procesos (funciones) deberían llamarse como si fueran localmente visibles dentro del dominio de aplicación del front-end para facilitar la interacción.
El uso de mensajes puede tener sus ventajas sobre las llamadas RPC porque los mensajes están en cola en un área segura en caso de que se produzca una desconexión de la red; puede haber algo de caché de datos dentro de ese aspecto para permitir que el front-end continúe independientemente ... sería útil en las instancias de ''actualizar un estado de un número de factura / factura particular'' - una escritura de datos de una vía al back-end vía middleware.
Ok, las grandes compañías tendrían una infraestructura de sistemas avanzada en la que los técnicos están constantemente trabajando para garantizar una entrega fluida del flujo de datos, de modo que tendría que tenerse en cuenta. La compañía con la que trabajé tenía un contrato de IBM Global Support para cumplir con el fin para garantizar un tiempo de actividad máximo del 99% con 6 nueve después del punto decimal ... con sistemas de intercambio en caliente / clústeres balanceados / duplicación en posición ...
Mientras que con RPC, si ocurre la desconexión, el front-end debería reiniciarse o tendría que manejar el evento de desconexión. Realmente depende si el middle-ware de puesta en cola de mensajes maneja cada mensaje en tiempo real y devuelve los resultados al front-end de inmediato ...
Aquí es donde cada (middleware de Message Queuing y RPC related) tiene sus fortalezas y debilidades ... y también el factor de mitigación de costos como soporte, tiempo de actividad máximo, esfuerzos de desarrollo y capacitación, eso es algo importante aquí como middle- ware son realmente propietarios (a pesar de seguir el diseño / estándares de ''The Open Group'') y complejos de configurar y pegar todo junto mediante scripts.