Buscando claridad en Event Hubs vs Topics en Azure Service Bus
azureservicebus azure-eventhub (3)
He estado aprendiendo sobre Event Hubs y solo quiero obtener confirmación o corrección desde mi perspectiva en Event Hubs. Estoy acostumbrado a aprovechar los reintentos, los mensajes tóxicos, al menos una entrega, etc., para las soluciones normales de mensajería empresarial, que me ofrecen las colas y los temas del servicio de bus de Azure. Parece que Event Hubs está destinado a proporcionar una herramienta diferente para muy alta escala en la que tiene que renunciar a un poco de las características más "empresariales" para una escala mucho más alta.
¿Estoy pensando en esto correctamente? ¿Hay detalles adicionales que necesito considerar también? Me doy cuenta de que podría haber una superposición funcional con Event Hubs y Topics, pero solo quiero aclarar cómo pensar en utilizar Event Hubs.
¡¡Correcto!!
La diferencia fundamental entre EventHubs y Topics es - TOPICS ofrece semántica por mensaje - pero, EventHubs - ofrece Stream Semantics - no debe esperar ninguna característica / semántica per-message con EventHubs.
¡Cualquier nivel medio que proporcione funciones per-message viene con la processing overhead (the tax) !
Por ejemplo: por mensaje Detección duplicada, confirmación de recepción por mensaje (los temas tienen un mensaje. Completo para recibir el mensaje recibido) - son todas las características del tema. EventHubs reduce el conjunto de características para proporcionar una mejor solución de baja latencia / alto rendimiento.
Para visualizar características como entrega al menos una vez (de por mensaje no está disponible en EventHubs) es traducirla a la semántica de flujo: leer hasta un punto en una eventual partición de eventoHub y punto de control y dejar que la aplicación que está consumiendo esos eventos maneje el at-least-once .
Hace un tiempo, escribí una publicación sobre este tema con el apoyo de Dan en el equipo de Service Bus. Espero que esto te aclare
http://microsoftintegration.guru/2015/03/03/azure-event-hubs-vs-azure-messaging/
Bus de servicio ( mensajería )
Para los mensajes, se trata de una aplicación que le dice a una o más aplicaciones HACER ALGO o DARME ALGO.
Centro de eventos ( Eventing )
La alternativa es que en eventing las aplicaciones dicen que ALGO HA SUCEDIDO.
Si tiene la opción, es casi siempre más fácil escribir un sistema basado en un sistema de mensajería de pubsub completo donde puede marcar eventos únicos como consumidos, reintentar mensajes y prácticamente cualquier otra característica maravillosa. Si ya ha aceptado particionar su canal de mensajes (que Azure Service Bus Topics parece ser compatible), entonces, en principio, podría escalar un sistema de mensajería más completo en la medida que lo requiera. El problema es a qué costo?
Un tema de Azure Service Bus tiene un costo a gran escala de aproximadamente $ 0.20 por millón de mensajes, Amazon SQS (algo similar) muestra $ 0.50 por millón . Si lo aloja usted mismo, probablemente necesite configurar muchos servidores RabbitMQ o incluso varios clústeres a medida que participe.
Azure Event Hub cuesta $ 0.028 por millón más una cantidad por unidad de rendimiento, lo same para Amazon Kinesis. Apache Kafka ha sido benchmarked a 2 millones por segundo en 3 máquinas
Con un promedio de 20,000 eventos por segundo, la diferencia entre algunos Azure Topics y Azure Event Hub está en el rango de un salario de desarrollador de tiempo completo. Con 2 millones por segundo sostenido (que requiere contactar MS), la diferencia se acerca a $ 1M / mes.
Básicamente utilice los sistemas de seguimiento de flujo / registro de flujo particionado cuando no necesita todas las funciones útiles de un sistema de mensajería completo, o cuando no las necesita para pagar la prima de ~ 10X. (O no puede usarlos porque no puede escalar el sistema de mensajería adecuado lo suficiente sin esfuerzos heroicos).