Utilisation de Kafka comme Eventstore (CQRS). Bonne idée ?

Question

Bien que j'aie déjà entendu parler de Kafka, j'ai récemment réalisé que Kafka pourrait peut-être être utilisé comme base d'un CQRS, eventstore.

l'un des principaux points que Kafka prend en charge:

• Capturer/stocker des événements, le tout en haute disponibilité bien sûr.
• Architecture pub/sub
• Possibilité de rejouer le journal des événements, ce qui permet aux nouveaux abonnés de s'inscrire au système après coup.

J'avoue que je ne suis pas totalement familiarisé avec CQRS / Event sourcing, mais cela semble assez proche de ce qu'un magasin d'événements devrait être. La chose amusante est que je ne trouve pas beaucoup d'informations sur l'utilisation de Kafka comme magasin d'événements, donc peut-être que je passe à côté de quelque chose.

Alors, qu'est-ce qui manque à Kafka pour être un bon magasin d'événements? Ça marcherait? En production? Intéressé par des idées, des liens, etc.

Fondamentalement, l'état du système est enregistré en fonction des transactions/événements que le système a déjà reçus, au lieu de simplement enregistrer l'état/snapshot actuel du système, ce qui est généralement fait. (Pensez à un livre comptable général en comptabilité: toutes les transactions s'additionnent finalement à l'état final) Cela permet toutes sortes de choses intéressantes, mais lisez simplement les liens fournis.

Answer 1

Je suis l'un des auteurs originaux de Kafka. Kafka fonctionnera très bien en tant que journal pour la mise en oeuvre d'événements. Il est tolérant aux pannes, peut s'adapter à des volumes de données énormes et dispose d'un modèle de partitionnement intégré.

Nous l'utilisons pour plusieurs cas d'utilisation de ce type chez LinkedIn. Par exemple, notre système de traitement de flux open source, Apache Samza, est livré avec un support intégré pour la mise en oeuvre d'événements.

Je pense que l'on entend peu parler de l'utilisation de Kafka pour la mise en oeuvre d'événements principalement parce que la terminologie de mise en oeuvre d'événements ne semble pas très répandue dans l'espace web grand public où Kafka est le plus populaire.

J'ai écrit un peu sur ce style d'utilisation de Kafka ici.

Answer 2

Kafka est censé être un système de messagerie qui présente de nombreuses similitudes avec un magasin d'événements cependant pour citer leur introduction :

Le cluster Kafka conserve tous les messages publiés, qu'ils aient été consommés ou non, pendant une période configurable. Par exemple, si la rétention est définie pour deux jours, alors pendant les deux jours suivant la publication d'un message, il est disponible pour la consommation, après quoi il sera supprimé pour libérer de l'espace. Les performances de Kafka sont effectivement constantes par rapport à la taille des données, il n'est donc pas un problème de conserver beaucoup de données.

Alors que les messages peuvent potentiellement être conservés indéfiniment, l'attente est qu'ils seront supprimés. Cela ne signifie pas que vous ne pouvez pas utiliser cela comme un magasin d'événements, mais il peut être préférable d'utiliser autre chose. Jetez un œil à EventStoreDB pour une alternative.

MISE À JOUR

Documentation Kafka:

La journalisation d'événements est un style de conception d'application où les modifications d'état sont enregistrées sous forme de séquence de dossiers ordonnée dans le temps. Le support de Kafka pour les données de log stockées très volumineuses en fait une excellente solution de stockage pour une application construite dans ce style.

MISE À JOUR 2

Un souci avec l'utilisation de Kafka pour la journalisation d'événements est le nombre de sujets requis. Typiquement dans la journalisation d'événements, il existe un flux (sujet) d'événements par entité (comme utilisateur, produit, etc.). De cette manière, l'état actuel d'une entité peut être reconstitué en réappliquant tous les événements dans le flux. Chaque sujet Kafka se compose d'une ou plusieurs partitions et chaque partition est stockée sous forme de répertoire sur le système de fichiers. Il y aura également une pression de la part de ZooKeeper à mesure que le nombre de znodes augmente.

Answer 3

Vous pouvez utiliser Kafka comme magasin d'événements, mais je ne recommande pas de le faire, bien que cela puisse sembler être un bon choix :

• Kafka garantit seulement une livraison au moins une fois et il y a des doublons dans le magasin d'événements qui ne peuvent pas être supprimés. Mise à jour : Ici vous pouvez lire pourquoi c'est si difficile avec Kafka et quelques dernières nouvelles sur comment atteindre enfin ce comportement : https://www.confluent.io/blog/exactly-once-semantics-are-possible-heres-how-apache-kafka-does-it/
• En raison de l'immuabilité, il n'y a pas moyen de manipuler le magasin d'événements lorsque l'application évolue et que les événements ont besoin d'être transformés (bien sûr, il y a des méthodes comme l'upcasting, mais...). On pourrait dire que vous n'avez jamais besoin de transformer les événements, mais cela n'est pas une hypothèse correcte, il pourrait y avoir des situations où vous effectuez une sauvegarde des originaux, mais vous les mettez à niveau vers les dernières versions. C'est une exigence valide dans les architectures orientées événements.
• Aucun endroit pour persister les instantanés des entités/agrégats et la relecture va devenir de plus en plus lente. Créer des instantanés est une fonctionnalité incontournable pour le magasin d'événements à long terme.
• Comme les partitions de Kafka sont distribuées et qu'elles sont difficiles à gérer et à sauvegarder par rapport aux bases de données. Les bases de données sont tout simplement plus simples :-)

Donc, avant de faire votre choix, réfléchissez à deux fois. Le magasin d'événements comme combinaison de interfaces de couche d'application (surveillance et gestion), de stockage SQL/NoSQL et de Kafka en tant que courtier est un meilleur choix que de laisser Kafka gérer les deux rôles pour créer une solution complète et fonctionnelle.

Le magasin d'événements est un service complexe qui nécessite plus que ce que Kafka peut offrir si vous êtes sérieux au sujet de l'application de la source d'événements, CQRS, Sagas et autres schémas dans une architecture orientée événements et maintenir de hautes performances.

N'hésitez pas à remettre ma réponse en question ! Vous pourriez ne pas aimer ce que je dis à propos de votre courtier préféré avec de nombreuses fonctionnalités en chevauchement, mais tout de même, Kafka n'a pas été conçu comme un magasin d'événements, mais plutôt comme un courtier haute performance et tampon en même temps pour gérer les scénarios de producteurs rapides versus consommateurs lents, par exemple.

Veuillez consulter le framework open source de microservices eventuate.io pour découvrir d'autres problèmes potentiels : http://eventuate.io/

Mise à jour du 8 février 2018

Je n'incorpore pas de nouvelles informations des commentaires, mais je suis d'accord sur certains de ces aspects. Cette mise à jour concerne davantage des recommandations pour une plateforme d'événements microservices. Si vous êtes sérieux au sujet de la conception robuste des microservices et des performances les plus élevées possibles en général, je vous donnerai quelques indications qui pourraient vous intéresser.

1. N'utilisez pas Spring - c'est génial (je l'utilise moi-même beaucoup), mais c'est lourd et lent en même temps. Et ce n'est pas du tout une plateforme de microservices. C'est "juste" un framework pour vous aider à en implémenter un (beaucoup de travail derrière cela..). D'autres frameworks sont "juste" des frameworks REST légers ou JPA ou d'autres frameworks à orientation différente. Je recommande probablement la meilleure plateforme de microservices open-source complète disponible qui revient aux racines du Java pur : https://github.com/networknt

Si vous vous interrogez sur les performances, vous pouvez vous comparer vous-même avec la suite de benchmarks existante. https://github.com/networknt/microservices-framework-benchmark

2. N'utilisez pas du tout Kafka :-)) C'est à moitié une blague. Je veux dire que même si Kafka est génial, c'est un autre système centré sur le courtage. Je pense que l'avenir est dans les systèmes de messagerie sans courtage. Vous pourriez être surpris, mais il y a des systèmes plus rapides que Kafka :-), bien sûr vous devez descendre au niveau inférieur. Regardez Chronicle.

3. Pour le magasin d'événements, je recommande une extension supérieure de Postgresql appelée TimescaleDB, qui se concentre sur le traitement haute performance des données de séries chronologiques (les événements sont des séries chronologiques) en grande quantité. Bien sûr, CQRS, la source d'événements (rejeu, etc. fonctionnalités) sont intégrées dans le framework light4j par défaut qui utilise Postgres comme stockage bas.

4. Pour la messagerie, essayez de regarder Chronicle Queue, Map, Engine, Network. Je veux dire, débarrassez-vous de ces vieilles solutions centrées sur le courtage et passez à un système de micro-messagerie (embarqué). Chronicle Queue est en fait encore plus rapide que Kafka. Mais je suis d'accord que ce n'est pas une solution tout-en-un et vous devez faire un peu de développement sinon vous allez acheter la version Entreprise (payante). En fin de compte, l'effort de construire à partir de Chronicle votre propre couche de messagerie sera compensé par l'élimination de la charge de maintenance du cluster Kafka.

Answer 4

Je pense que vous devriez regarder le framework Axon ainsi que leur support pour Kafka

Answer 5

Oui, Kafka fonctionne bien dans le modèle de l'approvisionnement en événements, en particulier CQRS, cependant, vous devez faire attention en définissant les TTL pour les sujets et gardez toujours à l'esprit que Kafka n'a pas été conçu pour ce modèle, cependant, nous pouvons très bien l'utiliser.