Utilisation de Kafka comme magasin d'événements (CQRS). Bonne idée?
Bien que j'ai déjà rencontré Kafka auparavant, je viens tout juste de me rendre compte que Kafka peut peut-être être utilisé comme (base de) un CQRS , - magasin d'événements .
Un des points principaux que Kafka soutient:
- Capturer/stocker des événements, tous les HA bien sûr.
- Architecture de pub/sub
- Possibilité de rejouer le journal des événements, ce qui permet aux nouveaux abonnés de s'inscrire après coup au système.
Certes, je ne suis pas à 100% au courant de la recherche de CQRS/Event, mais cela semble assez proche de ce que devrait être un EventStore. Ce qui est drôle, c’est que je ne trouve vraiment pas grand chose à propos de Kafka utilisé comme magasin d’événements, alors peut-être dois-je rater quelque chose.
Donc, il manque quelque chose de Kafka pour que ce soit un bon EventStore? Cela fonctionnerait-il? En utilisant la production? Intéressé par un aperçu, des liens, etc.
En gros, l'état du système est sauvegardé en fonction des transactions/événements que le système a reçus, au lieu de simplement sauvegarder l'état/instantané actuel du système, comme c'est habituellement le cas. (Pensez-y comme un grand livre dans la comptabilité: toutes les transactions s'additionnent finalement à l'état final). Cela permet toutes sortes de choses cool, mais il suffit de lire les liens fournis.
Kafka est censé être un système de messagerie présentant de nombreuses similitudes avec un magasin d’événements, mais 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 sur deux jours, les deux jours suivant la publication du message, il est disponible pour la consommation, après quoi il sera supprimé pour libérer de l'espace. Les performances de Kafka sont en réalité constantes en ce qui concerne la taille des données, de sorte que la conservation d'une grande quantité de données ne pose pas de problème.
Ainsi, les messages peuvent potentiellement être conservés indéfiniment, mais on s’attend à ce qu’ils soient supprimés. Cela ne signifie pas que vous ne pouvez pas utiliser cela comme magasin d'événements, mais il peut être préférable d'utiliser autre chose. Jetez un oeil à EventStore pour une alternative.
MISE À JOUR
L'approvisionnement en événements est un style de conception d'application dans lequel les changements d'état sont consignés en tant que séquence d'enregistrements ordonnée dans le temps. La prise en charge par Kafka de très grandes données de journal stockées en fait un excellent backend pour une application construite dans ce style.
MISE À JOUR 2
Le nombre de sujets obligatoires est l'un des problèmes liés à l'utilisation de Kafka pour la recherche d'événements. Généralement, lors de l’approvisionnement en événements, il existe un flux (sujet) d’événements par entité (utilisateur, produit, etc.). De cette façon, l'état actuel d'une entité peut être reconstitué en réappliquant tous les événements du flux. Chaque rubrique Kafka comprend une ou plusieurs partitions et chaque partition est stockée sous la forme d'un répertoire sur le système de fichiers. ZooKeeper exercera également une pression lorsque le nombre de znodes augmentera.
Je suis l'un des auteurs originaux de Kafka. Kafka fonctionnera très bien comme journal pour la détermination des événements. Il est tolérant aux pannes, s'adapte à des tailles de données énormes et possède un modèle de partitionnement intégré.
Nous l'utilisons pour plusieurs cas d'utilisation de ce formulaire sur LinkedIn. Par exemple, notre système de traitement de flux open source, Apache Samza, est livré avec support intégré pour la génération d’événements.
Je pense que vous n'entendez pas beaucoup parler de l'utilisation de Kafka pour le sourcing d'événements principalement parce que la terminologie relative à la sourcing d'événements ne semble pas être très répandue dans l'espace Web grand public où Kafka est le plus populaire. .
J'ai écrit un peu sur ce style de Kafka usage ici .
Je reviens toujours à ce QA. Et comme je n’ai pas trouvé les réponses existantes assez nuancées, j’ajoute celle-ci.
TL; DR. Oui ou non, en fonction de l'utilisation de votre source d'événements.
À ma connaissance, il existe deux types principaux de systèmes basés sur des événements.
Processeurs d'événements en aval = Oui
Dans ce type de système, les événements se produisent dans le monde réel et sont enregistrés comme des faits. Tels qu'un système d'entrepôt pour garder une trace des palettes de produits. Il n'y a fondamentalement pas d'événements contradictoires. Tout est déjà arrivé, même si c'était faux. (Par exemple, la palette 123456 a été embarquée sur le camion A, mais a été programmée pour le camion B.) Plus tard, les faits sont vérifiés pour rechercher des exceptions via des mécanismes de rapport. Kafka semble bien adapté à ce type d'application de traitement d'événements en aval.
Dans ce contexte, on comprend pourquoi Kafka les gens le préconisent en tant que solution Event Sourcing. Parce qu'il ressemble beaucoup à la façon dont il est déjà utilisé, par exemple, dans les flux de clics. Cependant, les utilisateurs du terme Event Sourcing (par opposition à Stream Processing) font probablement référence à la deuxième utilisation ...
Source de vérité contrôlée par l'application = Non
Ce type d’application déclare ses propres événements à la suite de demandes des utilisateurs transitant par la logique métier. Kafka ne fonctionne pas bien dans ce cas pour deux raisons principales.
Manque d'isolation d'entité
Ce scénario nécessite la possibilité de charger le flux d'événements pour une entité spécifique. La raison commune en est de créer un modèle d'écriture transitoire que la logique métier doit utiliser pour traiter la demande. Faire cela n'est pas pratique à Kafka. L'utilisation de sujet par entité peut permettre cela, sauf qu'il s'agit d'un point de départ lorsqu'il peut y avoir des milliers, voire des millions, d'entités. Cela est dû aux limites techniques de Kafka/Zookeeper.
L'une des principales raisons d'utiliser un modèle d'écriture transitoire de cette manière est de rendre les modifications de la logique métier peu coûteuses et faciles à déployer.
L'utilisation de rubrique par type est recommandée à la place pour Kafka, mais cela nécessiterait le chargement d'événements pour chaque entité de ce type uniquement pour obtenir les événements d'une seule entité. . Puisque vous ne pouvez pas dire par position de journal quels événements appartiennent à quelle entité. Même en utilisant Snapshots pour démarrer à partir d'une position de journal connue, il peut s'agir d'un nombre important d'événements à traiter.
Absence de détection de conflit
Deuxièmement, les utilisateurs peuvent créer des conditions de concurrence en raison de demandes simultanées adressées à la même entité. Il peut ne pas être souhaitable de sauvegarder des événements conflictuels et de les résoudre après coup. Il est donc important de pouvoir prévenir les conflits. Pour échelonner le chargement des demandes, il est courant d'utiliser des services sans état tout en évitant les conflits d'écriture à l'aide d'écritures conditionnelles (n'écrivez que si le dernier événement a été #x). Alias. Concurrence optimiste. Kafka ne prend pas en charge la concurrence optimiste. Même s’il le soutenait au niveau du sujet, il faudrait que ce soit au niveau de l’entité pour être efficace. Pour utiliser Kafka et prévenir les conflits, vous devez utiliser un graveur avec état et sérialisé au niveau de l'application. C'est une exigence/restriction architecturale importante.
Mise à jour par commentaire
Le commentaire a été supprimé, mais la question était quelque chose comme: qu'est-ce que les gens utilisent pour le stockage d'événements alors?
Il semble que la plupart des utilisateurs déploient leur propre implémentation de stockage d'événements sur une base de données existante. Pour les scénarios non distribués, comme les serveurs internes ou les produits autonomes, il est bien documenté comment créer un magasin d'événements basé sur SQL. Et il existe des bibliothèques disponibles sur différentes bases de données. Il existe également EventStore , qui est construit à cet effet.
Dans les scénarios distribués, j'ai déjà vu plusieurs implémentations. Jet le projet Panther utilise Azure CosmosDB , avec la fonctionnalité Modifier le flux pour notifier les écouteurs. Une autre implémentation similaire dont j'ai entendu parler sur AWS utilise DynamoDB avec sa fonctionnalité Streams pour notifier les écouteurs. La clé de partition devrait probablement être l'identifiant de flux pour une meilleure distribution des données (afin de réduire la quantité de sur-provisionnement). Cependant, une relecture complète des flux dans Dynamo est coûteuse (en lecture et en coût). Donc, cette impl a également été configuré pour Dynamo Streams pour vider les événements vers S3. Lorsqu'un nouvel auditeur se connecte ou qu'un auditeur existant souhaite une relecture complète, il lit en premier lieu S3.
Mon projet actuel est un scénario multi-locataire, et j'ai misé sur Postgres. Quelque chose comme Citus semble approprié pour l’évolutivité, le partitionnement par client + flux.
Kafka est toujours très utile dans les scénarios distribués. Exposer les événements de chaque service à d'autres services est un problème non trivial. Un magasin d’événements n’est généralement pas construit pour cela, mais c’est précisément ce que fait bienKafka. Chaque service a sa propre source de vérité interne (qu'il s'agisse de stockage d'événements ou autre), mais écoute Kafka pour savoir ce qui se passe "à l'extérieur". Le service peut également publier des événements sur Kafka afin d'informer "l'extérieur" des choses intéressantes qu'il a effectuées.
Vous pouvez utiliser Kafka comme magasin d'événements, mais je ne le recommande pas, bien que cela puisse sembler être un bon choix:
- Kafka garantit seulement au moins une fois la livraison et il y a des doublons dans le magasin d'événements qui ne peuvent pas être supprimés. Mise à jour: Vous pouvez lire ici pourquoi il est si difficile de travailler avec Kafka et quelques informations récentes sur la manière de parvenir enfin à ce comportement: - https://www.confluent.io/blog/exactly-once-semantics-are-possible-heres-how-Apache-kafka-does-it/
- En raison de son immuabilité, il n’ya aucun moyen de manipuler le magasin d’événements lorsque l’application évolue et que les événements doivent être transformés (il existe bien sûr des méthodes telles que la conversion ascendante, mais ...). Une fois peut-être dire que vous n'avez jamais besoin de transformer des événements, mais ce n'est pas une hypothèse correcte, il peut arriver que vous sauvegardiez l'original, mais que vous les mettiez à niveau vers les dernières versions. C'est une exigence valide dans les architectures pilotées par les événements.
- Aucun endroit pour conserver des instantanés d'entités/agrégats et la relecture deviendra de plus en plus lent. La création d'instantanés est indispensable pour le magasin d'événements dans une perspective à long terme.
- Étant donné que les partitions Kafka sont distribuées, leur gestion et leur sauvegarde sont difficiles à comparer avec les bases de données. Les bases de données sont simplement plus simples :-)
Donc, avant de faire votre choix, vous réfléchissez à deux fois. Le magasin d’événements combinant les interfaces de couche d’application (surveillance et gestion), le magasin SQL/NoSQL et Kafka en tant que courtier est un meilleur choix que de laisser Kafka gérer les deux rôles afin de créer une solution complète complète.
Le magasin d’événements est un service complexe qui nécessite plus que ce que Kafka peut offrir si vous êtes sérieux dans l’application de l’approvisionnement en événements, de CQRS, de Sagas et d’autres modèles d’architecture axée sur les événements, tout en maintenant des performances élevées.
N'hésitez pas à contester ma réponse! Vous n'aimerez peut-être pas ce que je dis à propos de votre courtier préféré, qui offre de nombreuses fonctionnalités qui se chevauchent, mais qui reste Kafka n'était pas conçu comme un magasin d'événements, mais plutôt comme un courtier et un tampon hautes performances en même temps pour gérer les scénarios de producteurs rapides par rapport aux scénarios de consommateurs lents, par exemple.
Consultez le framework open source eventuate.io microservices pour en savoir plus sur les problèmes potentiels: http://eventuate.io/
Mise à jour au 8 février 2018
Je n'incorpore pas les nouvelles informations issues des commentaires, mais je suis d'accord sur certains de ces aspects. Cette mise à jour concerne davantage certaines recommandations relatives à la plate-forme microservice événementielle. Si vous êtes sérieux au sujet de la conception robuste du microservice et des performances les plus élevées possibles en général, je vous donnerai quelques conseils qui pourraient vous intéresser.
- N'utilisez pas le printemps - il est génial (je l'utilise beaucoup moi-même), mais il est lourd et lent en même temps. Et ce n’est pas du tout une plate-forme de microservice. C'est "juste" un cadre pour vous aider à en mettre en place un (beaucoup de travail derrière cela ..). D'autres cadres ne sont "que" légers REST ou JPA ou des cadres orientés différemment. Je recommande probablement la meilleure plate-forme complète de microservices à code source libre et open source disponible, qui revient à la pure Java racines: https://github.com/networknt
Si vous vous interrogez sur les performances, vous pouvez vous comparer à la suite de tests existante. https://github.com/networknt/microservices-framework-benchmark
N'utilisez pas du tout Kafka :-)) C'est une blague à moitié. Je veux dire, bien que Kafka soit génial, il s’agit d’un autre système axé sur les courtiers. Je pense que l'avenir est dans les systèmes de messagerie sans courtier. Vous pourriez être surpris mais il y a plus rapide que Kafka systèmes :-), bien sûr, vous devez descendre au niveau inférieur. Regardez la chronique.
Pour le magasin d'événements, je recommande l'extension postgresql supérieure appelée TimescaleDB, qui se concentre sur le traitement de données de séries temporelles hautes performances (les événements sont des séries temporelles) en grand volume. Bien sûr, CQRS, les sources d’approvisionnement en événements (fonctions de relecture, etc.) sont intégrées au framework light4j, qui utilise Postgres comme stockage faible.
Pour la messagerie, essayez de regarder Chronicle Queue, Map, Engine, Network. Je veux dire se débarrasser de cette solution centrée sur le courtier à l'ancienne et utiliser un système de micro-messagerie (intégré). Chronicle Queue est en réalité encore plus rapide que Kafka. Mais je conviens que ce n’est pas une solution tout-en-un et que vous devez faire du développement, sinon vous achetez la version Enterprise (payante). En fin de compte, l’effort de construire à partir de Chronicle votre propre couche de messagerie sera payé en supprimant la charge liée au maintien du cluster Kafka.
Oui, vous pouvez utiliser Kafka comme magasin d'événements. Cela fonctionne assez bien, en particulier avec l'introduction de Kafka Streams , qui fournit un moyen natif de Kafka de traiter vos événements en accumulés indiquer que vous pouvez interroger .
En ce qui concerne:
Possibilité de rejouer le journal des événements, ce qui permet aux nouveaux abonnés de s'inscrire après coup au système.
Cela peut être délicat. J'ai couvert cela en détail ici: https://stackoverflow.com/a/48482974/74197
Oui, Kafka fonctionne bien dans le modèle d’approvisionnement en événements, spécialement CQRS. Toutefois, vous devez prendre des précautions lors de la définition des TTL pour les sujets et garder toujours à l’esprit que kafka n’a pas été conçu pour ce modèle, mais nous pouvons le faire. très bien l'utiliser.