À la recherche de clarté sur Event Hubs vs Topics dans Azure Service Bus
J'ai appris sur les hubs d'événements et je veux juste obtenir une confirmation ou une correction de mon point de vue sur les hubs d'événements? J'ai l'habitude de tirer parti des nouvelles tentatives, d'empoisonner les messages, au moins une fois la livraison, etc. pour les solutions de messagerie d'entreprise normales, que me fournissent les files d'attente et les sujets d'Azure Service Bus. Il semble que Event Hubs soit destiné à fournir un outil différent à très grande échelle où vous devez abandonner un peu des fonctionnalités plus "d'entreprise" pour une échelle beaucoup plus élevée.
Suis-je en train de penser correctement à cela? Y a-t-il des détails supplémentaires dont je dois également tenir compte? Je me rends compte qu'il pourrait y avoir un certain chevauchement fonctionnel avec les concentrateurs d'événements et les sujets, mais je cherche juste à obtenir une certaine clarté sur la façon de penser à utiliser les concentrateurs d'événements.
Si vous avez le choix, il est presque toujours plus facile d'écrire un système basé sur un système de messagerie pubsub d'entreprise complet où vous pouvez marquer des événements uniques comme ayant été consommés, réessayer les messages et à peu près toutes les autres fonctionnalités merveilleuses. Si vous avez déjà accepté de partitionner votre canal de messagerie (que les rubriques Azure Service Bus semblent prendre en charge), vous pouvez en principe faire évoluer un système de messagerie plus complet au degré requis. La question est à quel prix?
Un sujet Azure Service Bus a un coût à grande échelle d'environ ,20 $ par million messages, Amazon SQS (quelque peu similaire) répertorie ,50 $ par million . Si vous l'hébergez vous-même, vous devrez probablement configurer de nombreux serveurs RabbitMQ ou même plusieurs clusters lors de la partition.
Azure Event Hub coûte ,028 USD par million plus un montant par unité de débit, même pour Amazon Kinesis. Apache Kafka a été comparé à 2 millions par seconde sur 3 machines
Par exemple, 20 000 événements par seconde ont soutenu la différence entre certains sujets Azure et Azure Event Hub est de l'ordre du salaire d'un développeur à temps plein. À 2 millions par seconde soutenue (ce qui nécessite de contacter MS), la différence s'approche de 1 M $/mois.
Utilisez essentiellement les systèmes de suivi de flux/journal/décalage partitionné lorsque vous n'avez pas besoin de toutes les fonctionnalités utiles d'un système de messagerie complet, ou lorsque vous n'en avez pas suffisamment besoin pour payer la prime ~ 10X. (Ou ne pouvez pas les utiliser parce que vous ne pouvez pas faire évoluer suffisamment le système de messagerie approprié sans efforts héroïques).
j'ai écrit un article il y a un moment sur ce sujet avec le soutien de Dan de l'équipe Service Bus. J'espère que cela devrait clarifier pour vous
http://microsoftintegration.guru/2015/03/03/Azure-event-hubs-vs-Azure-messaging/
Bus de service ( Messagerie )
Pour la messagerie , il s'agit d'une application demandant à une ou plusieurs applications de FAIRE QUELQUE CHOSE ou DE ME DONNER QUELQUE CHOSE.
Event Hub ( Eventing )
L'alternative est que dans l'événement les applications disent QUELQUE CHOSE EST ARRIVÉE.
Correct!!
La différence fondamentale entre les EventHubs et les Topics est - les TOPICS proposent la sémantique par message - tandis que les EventHubs - proposent la sémantique des flux - implique, il ne faut pas s'attendre à une fonctionnalité/sémantique per-message avec EventHubs.
Tout niveau intermédiaire fournissant des fonctionnalités per-message Est fourni avec la fonction processing overhead (the tax) !!
Par exemple: Détection de doublons par message, confirmation de réception par message (les sujets ont un message. EventHubs restreint l'ensemble des fonctionnalités pour fournir une meilleure solution à faible latence/haut débit.
Pour visualiser des fonctionnalités comme la livraison au moins une fois (de par msg n'est pas disponible dans EventHubs), c'est la traduire en sémantique de flux - Lire jusqu'à un point dans une partition et un point de contrôle EventHub donnés et laisser votre application qui consomme ces événements gérer la Livraison at-least-once.