Je souhaite créer une architecture CQRS et Event Sourcing qui soit très bon marché, très flexible et très simple.
Je veux m'assurer que les événements ne manquent jamais au moins d'atteindre l'éditeur / magasin d'événements, jamais, jamais, car c'est là que se trouve l'entreprise.
Maintenant, j'ai plusieurs options en tête:
<₹Azure
Avec azur, je ne sais pas quoi utiliser.
<↑ Quelle est la fiabilité de ces solutions sans serveur Azure?
< gagnantCustom
Pour cela, je pense utiliser RabbitMQ, le problème est le coût d'une machine virtuelle pour l'exécuter.
Que suggère votre expérience?
Et les autres alternatives? (par exemple: apache-kafka )?
3 Réponses :
Pourquoi ne pas lancer Event Store? Créé par Greg Young lui-même. Hébergez là où vous en avez besoin.
Je suis un utilisateur java, j'utilise hornetq (aka artemis que je n'utilise pas) une alternative à rabbitmq depuis le plus longtemps; le seul problème est qu'il ne prend pas en charge la réplication, mais fait le travail en matière de gestion d'événements. Pour votre scénario personnalisé, rabbitmq est un bon choix, mais essayez de l'exécuter sur une instance océanique numérique à faible coût. Si vous recherchez la simplicité et la flexibilité, vous n'avez que 2 choix, construisez le vôtre ou renoncez à la simplicité et choisissez Apache Kafka avec toutes ses complexités mais vous donnera de la flexibilité. Encore une fois, vous pouvez également créer un magasin d'événements avec mongodb. https://www.mongodb.com/blog/post/event- sourcing-avec-mongodb
En ce qui concerne la construction de votre propre magasin d'événements: c'est vraiment un mauvais conseil. Les magasins d'événements ont des exigences suffisamment complexes pour rendre la création de votre propre tâche assez difficile, et beaucoup de gens ne semblent pas en être conscients lorsqu'ils sont initiés à l'approvisionnement d'événements,
Aussi (étant donné que cela est suggéré régulièrement) et juste au cas où, n'utilisez pas kafka comme magasin d'événements, car il manque de contrôles de concurrence à l'écriture, ce qui vous fait potentiellement vous retrouver avec des données erronées.
Je vous entends cependant cela dépend vraiment du cas d'utilisation. Vous n'avez pas besoin de choisir un cadre complet juste pour faire du sourcing d'événements mineurs. Si vous le faites à grande échelle, je comprendrais vraiment la nécessité d'aller dans cette direction, mais pour le sourcing d'événements mineurs, créez une application simple de sourcing d'événements et utilisez-la entre-temps.
@SavvasKleanthous Encore une chose, regardez les 8 lignes de code de Greg Youngs et youtube.com/ regarder? v = 9a1PqwFrMP0 & ab_channel = NDCConferences . Vous pouvez toujours créer le vôtre, il n'y a pas de manière standard de le faire, juste un tas de principes que vous devez comprendre.
Je connais très bien les entretiens de Greg et Mat, et je les connais tous les deux personnellement. L'écriture de code pour réhydrater l'état à partir d'événements est un type de problème TRÈS différent de celui de la création d'un magasin d'événements. Regardez ici: github.com/ylorph/RandomThoughts/blob/master /…
Vos exigences sont trop vagues pour faire le choix optimal. Vous devez considérer beaucoup de choses, l'un d'entre eux serait, par exemple, le nombre d'événements pour un agrégat, le nombre d'agrégats (notez que cela doit être statistique). Celles-ci sont importantes principalement car si vous autorisez des dizaines de milliers d'événements pour chaque agrégat, vous aurez besoin d'un instantané, ce qui ajoute une complexité dont vous n'avez peut-être pas besoin.
Mais pour les cas d'utilisation réguliers, vous pouvez simplement utiliser une base de données relationnelle comme Postgres comme magasin d'événements (linéarisables). Il dispose également d'une fonctionnalité d'écoute / notification qui ne nécessite pas non plus de bus de messages et votre application pourrait être écrite de manière réactive.