Apache Kafka est une plateforme de diffusion distribuée hautement évolutive, souvent utilisée pour distribuer des messages ou des événements au sein d’un système basé sur les microservices. Ces événements font parfois partie d’un processus métier avec des tâches réparties sur plusieurs microservices. Un moteur de workflow peut être utilisé pour gérer des processus métier complexes, mais pour correspondre à Kafka, il doit respecter la même évolutivité que celle fournie par Kafka. Zeebe est un moteur de workflow actuellement développé et conçu pour répondre à ces exigences d’évolutivité. Lors d’une réunion conjointe à Amsterdam, Kai Waehner a décrit les fonctionnalités de Kafka et son intégration dans une architecture pilotée par les événements(EDA). Bernd Rücker a décrit les moteurs de workflow, Zeebe et son utilisation avec Kafka.
Pour Waehner, évangéliste en technologie chez Confluent, l’une des raisons pour lesquelles Kafka est si souvent utilisé aujourd’hui, est que de plus en plus d’applications, microservices, applications mobiles et appareils IoT sont intégrés, ce qui fournit beaucoup plus de données. Nous devons traiter plus de messages qu’auparavant et à une vitesse accrue, souvent avec des cas d’utilisation en temps réel. Nous avons commencé il y a de nombreuses années à construire des intégrations point à point, mais cela ne s’adapte pas très bien et est difficile à maintenir. Il y a environ 10 ans, nous avons commencé à utiliser un Bus de Service d’Entreprise (ESB) pour l’intégration. Aujourd’hui, l’ESB est remplacé par une plateforme de diffusion de messages comme Kafka à laquelle toutes les applications sont connectées.
EDA n’est pas une nouvelle idée; le concept existe depuis au moins 10 à 20 ans. La nouveauté réside dans la manière dont nous pouvons traiter les données. Au lieu de stocker des données dans une base de données lue et traitée par un autre service, les données sont maintenant transmises et traitées en continu. Un différenciateur important pour une plateforme de diffusion en continu d’événements est qu’elle n’utilise pas de stockage statique comme une base de données SQL ou NoSQL; à la place, les événements ou les autres messages sont stockés. Cela affecte la manière dont vous construisez les applications. Les événements sont désormais publiés et sont ensuite consommés par d’autres applications.
Waehner souligne que Kafka repose sur trois concepts; messagerie, stockage et traitement de données. C’est un courtier en messagerie comme beaucoup d’autres courtiers, c’est un système de stockage dans lequel les données peuvent être stockées aussi longtemps que vous le souhaitez, et enfin, il peut traiter des données. Les deux fonctionnalités importantes que Kafka partage avec les bases de données sont les suivantes :
- Ordre strict des messages, ce qui est très important dans de nombreux cas d’utilisation
- Persistance; tous les messages sont stockés sur le disque, ce qui signifie qu’il peut planter sans perdre de données
Un autre élément clé de Kafka est qu’il est distribué par conception et conçu pour les pannes. Les concepts principaux incluent la réplication, la tolérance aux pannes, le partitionnement et la mise à l’échelle élastique.
Selon l’expérience de Waehner, de nombreux développeurs considèrent Kafka uniquement comme une plateforme de messagerie et soulignent donc que deux composants supplémentaires qui sont inclus :
- Kafka Connect, an integration framework on top of core Kafka; examples of connectors include many databases and messaging systems
- Kafka Streams for stream processing, which for Waehner is the easiest way to process data
- Kafka Connect, une infrastructure d’intégration au-dessus du noyau Kafka; des exemples de connecteurs incluent de nombreuses bases de données et systèmes de messagerie
- Kafka Streams pour le traitement de flux, ce qui, pour Waehner, constitue le moyen le plus simple pour le traitement des données
Waehner conclut en notant qu’il s’aperçoit de plus en plus que Kafka est utilisé lors de la création d’applications métier principale - Kafka exploite le business. L’analyse du business est toujours importante, mais ce n’est qu’une petite partie. Une autre tendance qu’il constate est que la plupart de ses clients sont hybrides. Ils construisent de nouveaux systèmes dans le cloud mais ont toujours des systèmes sur site, et ils ont tous besoin de communiquer.
Bernd Rücker
Rücker, cofondateur et promoteur du développement chez Camunda, constate une nette tendance à l’utilisation des microservices au cours des dernières années parmi ses clients. Il a également noté une tendance selon laquelle certains clients ont commencé à utiliser une approche événementielle et l’utilisent maintenant pour tout.
À l’aide du pattern event notification, les systèmes sont construits avec des microservices responsables de différentes parties du métier. Les services publient des événements pour informer les autres services de ce qui se passe. Pour accomplir une fonction métier, plusieurs services peuvent être impliqués, en envoyant des événements les uns aux autres. Rücker appelle ces chaînes d’événements de "peer-to-peer" et constate le problème qu’il est peut être difficile d’obtenir une image du flux global du point de vue métier. Il cite un article de Martin Fowler dans lequel il souligne que, si le modèle de notification d’événement peut être utile, il ajoute également un risque de perte de vue du flux à grande échelle.
Une approche permettant de retrouver une vue du flux d’événements consiste à utiliser le monitoring et le traçage. Dans un article sur InfoQ, Rücker décrit des exemples montrant comment procéder. Le tracking des processus est sa préférence, car en modélisant le workflow et en utilisant un moteur de workflow écoutant tous les événements, il est possible de vérifier que chaque flux fonctionne correctement du point de vue métier et d’obtenir des notifications en cas d’échec.
Rücker note que le tracking des processus est facile à appliquer car il n’est pas nécessaire de changer quoi que ce soit; attachez simplement le moteur de workflow à l’infrastructure Kafka. Cela peut également être une première étape pour agir face aux défaillances potentielles, par exemple en ajoutant des délais et des avertissements lorsqu’un processus prend trop de temps. Il fait référence à une présentation de Vodafone sur la manière dont ils ont remplacé un middleware existant, d’abord en utilisant le tracking, puis en remplaçant pas à pas chaque tâche par une orchestration.
Un problème potentiel avec une chaîne d’événements "peer-to-peer" survient lorsque le workflow doit être modifié. Cela peut nécessiter que plusieurs services changent leurs abonnements aux événements. Cela nécessite également une coordination entre les équipes et le déploiement des services, ainsi que la prise en compte des workflow en cours et les événements actifs dans le système. Pour garantir le respect des processus de gestion, Rücker préfère extraire la responsabilité de bout en bout au sein d’un seul service. Un avantage est que vous aurez un service responsable de quelque chose de très important pour l’entreprise et un point unique où vous contrôlerez la séquence des tâches. Cela donne également la possibilité de commencer à utiliser des commandes pour contrôler le workflow. Les commandes sont une orchestration - vous dites à quelqu’un de faire quelque chose - mais Rücker souligne que l’orchestration est une partie interne d’un microservice et non un mécanisme d’infrastructure central utilisé par chaque service. Il souligne également qu’avec un service responsable d’un workflow, vous pouvez également vérifier l’état des commandes en cours, le nombre de commandes exécutées, etc.
Camunda travaille actuellement sur Zeebe, un moteur de workflow évolutif horizontalement pour les microservices, qui le rend compatible avec les cas d'utilisation à faible temps de latence et à haut débit combiné à Kafka. Il est toujours dans l'état de "developer preview", mais ils ont des clients pilotes qui exécutent de 100 à 200 000 instances de workflow. Selon Rücker, une version prête pour la production sera prévue pour juillet 2019.
Les diapositives de Wahner et de Rücker des présentations sont disponibles.
Dans une interview avec InfoQ, Rücker a déclaré qu’il trouvait cela un peu étrange que l’exécution d’une commande, ce qui est très important pour une entreprise, ne soit pas traitée dans le domaine principal, mais doit être effectuée en surveillant les événements pour tenter de détecter si un ordre est coincé quelque part. Pour lui, un service d’exécution des commandes doit être concerné par les commandes exécutées et ne pas simplement publier un événement indiquant qu’une commande a été créée et espérer que d’autres services s’assurent que le paiement est traité et que les marchandises sont livrées au client.
Nous parlons couramment de flux d’événements, mais Rücker pense que nous devrions plutôt parler de flux d’enregistrements ou de messages et souligne que le terme utilisé dans l’API Kafka est un enregistrement et non un événement. Pour lui, Kafka peut être utilisé pour différents types de messages, tels que des événements et des commandes. Il fait référence au livre phare Enterprise Integration Patterns, écrit par Gregor Hohpe et Bobby Woolf, dans lequel les messages comme Command, Document et Event sont décrits.