Comment Camunda Stocke l’État des Workflows (Zeebe simplifié)
🖼️ Vue d’ensemble de l’architecture Zeebe
✍️ Introduction
Si vous venez de Camunda 7 (basé sur base de données), comprendre comment Camunda 8 (Zeebe) stocke l’état des workflows est essentiel.
Contrairement à Camunda 7 :
- ❌ Pas de base de données centrale
- ✅ Utilisation d’une architecture distribuée basée sur les événements
👉 Résultat :
- ⚡ Haute performance
- 🔁 Tolérance aux pannes
- 🚀 Scalabilité horizontale
🧩 1. Concept clé : Event Sourcing
Dans Zeebe :
L’état du workflow = suite d’événements (event stream)
Chaque action devient un événement :
- Démarrage du processus
- Activation d’une tâche
- Mise à jour des variables
- Fin d’une tâche
👉 Tous ces événements sont stockés dans un log append-only
🖼️ Concept de flux d’événements
⚙️ 2. Comment l’état est stocké concrètement
🧱 Étapes simplifiées
- Le client envoie une requête (via Gateway)
- La Gateway redirige vers un Broker
- Le Broker écrit un événement :
PROCESS_INSTANCE_CREATED
TASK_ACTIVATED
VARIABLE_UPDATED
- L’événement est :
- Stocké dans un log
- Répliqué sur d’autres brokers
- L’état est reconstruit à partir de ces événements
🧠 Important
👉 L’état n’est pas stocké directement
❌ Exemple classique :
status = COMPLETED
✅ Zeebe :
EVENT 1 → started
EVENT 2 → task completed
EVENT 3 → workflow finished
🧩 3. Brokers et Partitions
Zeebe est distribué :
- Plusieurs Brokers
- Chaque broker contient des partitions
- Chaque partition a :
- Leader
- Followers (réplication)
👉 Avantages :
- Haute disponibilité
- Aucune perte de données
- Scalabilité
🔄 4. Reconstruction de l’état (Replay)
Si un broker tombe :
- Redémarrage
- Lecture du log
- Reconstruction de l’état
👉 On appelle cela le replay
📌 Pas besoin de recovery DB complexe
⚡ 5. Comparaison avec Camunda 7
| Critère | Camunda 7 | Camunda 8 (Zeebe) |
|---|---|---|
| Stockage | Base de données | Event log |
| Scalabilité | Verticale | Horizontale |
| État | Persisté | Reconstruit |
| Performance | Moyenne | Élevée |
🧠 6. Composants internes
🔹 Gateway
- Point d’entrée
- Routage des requêtes
🔹 Broker
- Stocke les événements
- Exécute les workflows
🔹 Exporters
- Envoient les données vers :
- Elasticsearch
- Monitoring
🔹 Clients
- Appellent les APIs
- Implémentent la logique métier
🖼️ Flux complet
🚀 7. Exemple réel
Processus de commande
- Commande créée → événement
- Paiement → événement
- Paiement validé → événement
- Livraison → événement
👉 Le workflow = suite d’événements
💡 Points clés
- ✅ Zeebe utilise event sourcing
- ✅ Pas de dépendance forte à une base de données
- ✅ État reconstruit dynamiquement
- ✅ Architecture distribuée
- ✅ Idéal pour microservices
📚 Articles recommandés
👉 Camunda + Database Design (History tables, optimisation, scaling)
👉 Securing Workflows in Camunda 8 (Auth, rôles)
👉 Java + Spring Security (Authentication & Authorization)
💼 Besoin d’aide ?
💼 Besoin d’aide avec Hibernate, JPA ou vos systèmes backend?
J’aide les équipes à concevoir des applications performantes et résoudre des problèmes en production.
Services:
- Implémentation Hibernate & JPA
- Optimisation des performances
- Conception base de données
- Architecture backend entreprise
🔗 https://shikhanirankari.blogspot.com/p/professional-services.html
📩 Email: ishikhanirankari@gmail.com | info@realtechnologiesindia.com
🌐 https://realtechnologiesindia.com
✔ Disponible pour des consultations rapides
✔ Réponse sous 24h
🎥 Learn IT with Shikha on YouTube
Prefer learning through videos? Watch practical tutorials on Kafka, Camunda, Alfresco, Java, Spring Boot, Microservices and Enterprise Architecture.▶ Subscribe to Learn IT with Shikha on YouTube
Comments
Post a Comment