xkafka — comment utiliser Kafka plus simplement en Go

• xkafka est une bibliothèque open source qui permet d’utiliser Kafka aussi simplement qu’un service HTTP dans un environnement Go
• Avec confluent-kafka-go, il fallait jusque-là des boucles de traitement complexes et beaucoup de code boilerplate, alors que xkafka permet de se concentrer sur la logique métier grâce à une structure Handler, Middleware, Message
• La publication et la consommation de messages se gèrent de façon intuitive, comme des requêtes/réponses HTTP, et une grande partie de la complexité de Kafka — gestion des offsets, configuration de la concurrence, gestion des erreurs, etc. — est masquée
• L’outil prend simplement en charge divers modèles requis en production, comme le traitement Streaming/Batch, le traitement séquentiel/asynchrone ou les garanties At-most-once/At-least-once
• Des besoins courants en conditions réelles, comme la gestion hiérarchique des erreurs et les retries/logging/metrics basés sur des middlewares, peuvent être appliqués facilement

---

Kafka façon HTTP

• xkafka est une bibliothèque qui abstrait Kafka en Go comme un service HTTP
  • Message est similaire à une requête HTTP et inclut topic, partition, offset, clé, valeur, en-têtes, callback, etc.
  • Handler traite la logique métier, comme un handler HTTP
  • Middleware permet d’appliquer des fonctions annexes comme le logging, les métriques ou les retries séparément de la logique métier

Publication de messages (Publishing Messages)

• On crée un Producer avec xkafka.NewProducer, puis on construit un objet message avant de le publier avec la fonction Publish
• La publication asynchrone (AsyncPublish) et l’enregistrement de callbacks sont possibles, ce qui facilite les traitements hautes performances ou événementiels asynchrones
• La transmission des messages est gérée dans une goroutine en arrière-plan, et l’état de livraison peut être suivi via les callbacks

Consommation de messages (Consuming Messages)

• Lors de la création du Consumer, on indique la fonction Handler ainsi que le topic, les brokers et les paramètres
• Il est possible d’ajouter des middlewares avec consumer.Use()
• La consommation démarre avec consumer.Run(ctx)

Streaming vs. Batch

• Streaming : chaque message est traité immédiatement à l’arrivée, un par un. Adapté à des volumes plus faibles, à l’économie mémoire ou à des garanties de traitement plus strictes
• Batch : les messages sont regroupés par nombre ou par fenêtre de temps avant traitement. Adapté aux systèmes à haut débit ou pour alléger la charge sur les composants aval

Séquentiel ou asynchrone

• Par défaut, le traitement est séquentiel (Sequential) — le message suivant n’est lu qu’une fois le précédent terminé
• Avec xkafka.Concurrency(N), le mode asynchrone (Async) permet de traiter en parallèle N messages (ou batches)

Gestion des offsets

• Dans le fonctionnement par défaut de Kafka, l’offset avance dès la livraison du message, ce qui peut entraîner une perte de messages en cas d’incident
• xkafka configure enable.auto.offset.store=false afin de ne stocker l’offset qu’une fois le traitement du message (ou du batch) terminé
• Cela permet d’obtenir des garanties de traitement via Kafka sans avoir à gérer l’état des messages dans une base de données ou une file distincte

• Garantie At-Most-Once

  • Par défaut, l’offset est commit en arrière-plan selon le paramètre Kafka enable.auto.commit=true
  • Avec xkafka.ManualCommit(true) et un traitement séquentiel, l’offset est commit avant la lecture de chaque message/batch, ce qui garantit le At-most-once

• Garantie At-Least-Once

  • En combinant xkafka.ManualCommit(true) avec la concurrence (N>1), les offsets peuvent être commit de façon synchrone et ordonnée même en traitement parallèle
  • Il devient ainsi simple d’appliquer un modèle garantissant le At-least-once

Gestion des erreurs

• Niveau Handler

  • Le Handler peut gérer les erreurs applicatives et, par exemple, envoyer les messages vers une Dead Letter Queue
  • Contrôle explicite via msg.AckSuccess() en cas de succès, msg.AckSkip() pour ignorer, msg.AckFail(err) en cas d’échec

• Niveau Middleware

  • Les middlewares permettent de réutiliser une logique commune, comme les retries ou le logging d’erreurs, sur plusieurs Handlers
  • Il est facile d’appliquer différentes politiques de retry ou méthodes de traitement selon le type d’erreur

• Niveau global

  • Les erreurs du broker Kafka ou de la bibliothèque sont traitées de manière centralisée via l’option obligatoire xkafka.ErrorHandler
  • Si ce handler retourne une erreur non nulle, le Consumer ou le Producer interrompt son fonctionnement

Conclusion

• xkafka transforme l’expérience complexe d’Apache Kafka en une structure de serveur HTTP familière pour les développeurs Go
• Il réduit le code boilerplate inutile et fournit un environnement où l’on peut se concentrer uniquement sur la logique métier
• Le code est bien plus concis et intuitif qu’avec confluent-kafka-go
• On peut démarrer immédiatement avec la documentation officielle et les exemples

[penza1]

Hum, il me semblait qu’en golang,
sarama était davantage privilégié..
Les clients Kafka sont en fait plus complexes qu’on ne le pense, surtout en cas de panne du broker ou d’exception,
alors couvrir tous les cas..