Chorégraphie vs orchestration : conception de flux de travail distribués dans des microservices

Dans une architecture monolithique, l’exécution d’une transaction commerciale complexe, telle que l’exécution d’une commande de commerce électronique, est simple. Toutes les données résident dans une seule base de données relationnelle, ce qui permet aux développeurs d’encapsuler plusieurs écritures de base de données concernant l’inventaire, les paiements et l’expédition dans une seule transaction ACID. Si une erreur se produit à un moment donné, un ROLLBACK SQL restaure instantanément la cohérence du système.

Cependant, les systèmes cloud natifs modernes adoptent une architecture de microservices, dans laquelle chaque service est propriétaire de ses données et expose des limites d’API distinctes. Dans ce paradigme distribué, une seule opération commerciale de bout en bout s’étend sur plusieurs microservices et moteurs de bases de données indépendants.

Étant donné que les protocoles de validation en deux phases (2PC) sont lents, bloquants et fragiles sur les réseaux cloud, les systèmes distribués doivent coordonner les flux de travail de manière asynchrone tout en conservant une cohérence éventuelle.

Cela amène les architectes logiciels à une décision de conception fondamentale : Devriez-vous utiliser la chorégraphie ou l’orchestration pour gérer les flux de travail de microservices distribués ?

Dans ce guide complet, nous décomposerons les deux modèles architecturaux, explorerons les analogies du monde réel, analyserons les compromis architecturaux, détaillerons les implémentations du code de production dans Go et Java, et établirons un cadre pour sélectionner le modèle approprié pour votre infrastructure.

Analogie du monde réel : Flash Mob contre Symphony Orchestra

Pour construire un modèle mental intuitif pour les deux modèles, réfléchissez à la manière dont les groupes d’interprètes humains coordonnent leurs actions :

L’analogie chorégraphique : un réseau de danseurs Flash Mob

Imaginez un groupe de danseurs de rue professionnels exécutant une routine flash mob. Il n’y a aucun instructeur debout sur scène pointant du doigt les danseurs pour commander leur prochain mouvement. Au lieu de cela, chaque danseur écoute la piste musicale centrale et réagit de manière dynamique aux mouvements du danseur à côté de lui.

• Lorsque le danseur A termine un saut, le danseur B reconnaît ce signal visuel et commence à tourner.
• Lorsque le danseur B a fini de tourner, le danseur C avance.
• Caractéristique clé : Décentralisé, réactif et autonome. Chaque participant comprend sa propre responsabilité sans direction centrale.

L’analogie de l’orchestration : un orchestre symphonique

Imaginez maintenant un orchestre symphonique classique de 70 musiciens. Les violonistes, percussionnistes et violoncellistes ne se laissent pas guider par le fait de se regarder les mains à travers la scène. Au lieu de cela, tout le monde regarde directement le Conducteur.

• Le chef d’orchestre signale aux violons quand jouer des cordes douces.
• Le chef d’orchestre montre la batterie pour signaler une frappe de percussion.
• Si un musicien manque un tempo, le chef d’orchestre coordonne l’ajustement du tempo ou signale une pause.
• Caractéristique clé : centralisé, explicite et piloté par des commandes. Un seul leader dirige tous les participants.

1. Architecture chorégraphique : décentralisée et événementielle

Dans Choreography, les microservices distribués communiquent de manière réactive sans coordinateur principal central. Les services publient des événements de domaine sur un courtier de messages asynchrone (tel qu’Apache Kafka, RabbitMQ ou AWS EventBridge) chaque fois que leur état interne change. Les microservices en aval s’abonnent à des sujets d’événements pertinents et décident indépendamment des actions à entreprendre ensuite.

Flux de commerce électronique sous chorégraphie

Envisagez un processus de paiement de commerce électronique utilisant une chorégraphie :

1. Service de commande : reçoit une demande de paiement HTTP POST, écrit la commande en attente dans sa base de données et émet un événement de domaine OrderCreated vers le bus d’événements Kafka.
2. Service de paiement : Abonnez-vous au sujet OrderCreated. Dès réception de l’événement, il débite la carte de crédit du client et émet un événement PaymentProcessed.
3. Service d’inventaire : abonnement à la rubrique PaymentProcessed. Il réserve les articles de l’entrepôt et émet un événement InventoryReserved.
4. Service d’expédition : abonnement au sujet InventoryReserved. Il génère une étiquette d’expédition et émet un événement OrderShipped.
5. Service de notification : s’abonne à OrderShipped et envoie un e-mail de suivi au client.

Avantages de la chorégraphie

• Haute autonomie et couplage lâche : les services ne connaissent pas l’existence de gestionnaires en aval. Le service de commande sait seulement qu’une commande a été créée ; peu importe qui consomme ces informations.
• Évolutivité et rapidité indépendantes : les équipes peuvent créer, déployer et faire évoluer des microservices de manière indépendante. L’ajout d’une nouvelle fonctionnalité (par exemple, un service Analytics qui suit les ventes) nécessite de s’abonner aux événements existants sans modifier le code en amont.
• Pas de point de défaillance unique (SPOF) : étant donné qu’il n’y a pas de coordinateur central de flux de travail, la défaillance d’un service indépendant ne fait pas tomber l’ensemble du moteur d’exécution.
• Hautes performances et débit : le streaming pub/sub piloté par événements gère un volume d’événements massif de manière asynchrone sans latence de blocage HTTP/gRPC synchrone.

Inconvénients de la chorégraphie

• Logique de flux de travail implicite : aucun emplacement de code unique ne définit le processus métier de bout en bout. Comprendre l’ensemble du flux de travail nécessite de rassembler des gestionnaires d’événements sur plusieurs bases de code.
• Risque de dépendance cyclique : si les microservices publient et s’abonnent à des sujets qui se chevauchent sans une conception minutieuse des sujets, des boucles d’événements infinies peuvent faire planter les files d’attente de messages du système.
• Observabilité complexe et traçage distribué : le suivi d’une transaction de commande unique sur 10 sujets d’événement nécessite une infrastructure de traçage distribuée robuste (par exemple, OpenTelemetry, Jaeger, W3C Trace Context).
• Gestion des erreurs et compensations difficiles : Si le service d’inventaire échoue après la réussite du paiement, le service d’inventaire doit émettre un événement InventoryFailed. Le Service de Paiement doit être à l’écoute de cet événement et déclencher manuellement une indemnisation de remboursement.

2. Architecture d’orchestration : centralisée et pilotée par des commandes

Dans Orchestration, un service de coordinateur dédié (le Saga Orchestrator) dirige explicitement la séquence d’exécution. L’orchestrateur détient la machine à états de workflow, envoie des demandes de commandes (via gRPC, HTTP REST ou des files d’attente de commandes dédiées) aux microservices de travail, attend les réponses et détermine l’étape d’exécution suivante.

Flux de commerce électronique sous orchestration

1. Order Service / Saga Orchestrator : reçoit la demande de paiement et instancie une instance de workflow OrderSagaCoordinator dans l’état ORDER_PENDING.
2. Étape 1 (commande de paiement) : l’orchestrateur appelle PaymentService.ExecutePayment(). Le service de paiement traite le paiement et renvoie SUCCESS.
3. Étape 2 (commande d’inventaire) : l’orchestrateur reçoit SUCCESS et appelle InventoryService.ReserveStock(). Le service d’inventaire réserve le stock et renvoie SUCCESS.
4. Étape 3 (commande d’expédition) : l’orchestrateur appelle ShippingService.CreateShipment(). Le service d’expédition renvoie les détails de suivi.
5. Étape 4 (achèvement) : l’orchestrateur met à jour le statut de la commande dans son magasin d’état sur ORDER_COMPLETED.

Si InventoryService.ReserveStock() échoue au cours de l’étape 2, Orchestrator exécute les commandes de restauration de manière séquentielle :

• Appelle PaymentService.RefundPayment() pour annuler l’étape 1.
• Met à jour l’état de Saga vers ORDER_CANCELLED.

Avantages de l’orchestration

• Visibilité explicite et centralisée du flux de travail : l’ensemble du processus métier est clairement visible dans une définition de machine à état unique ou dans un DSL de flux de travail (par exemple, définition de flux de travail temporel).
• Gestion simplifiée des échecs : si une étape échoue, l’orchestrateur appelle directement des transactions compensatoires pour toutes les étapes précédemment terminées sans s’appuyer sur des chaînes d’événements indirectes.
• Empêche les dépendances cycliques : les services de travail communiquent dans les deux sens avec Orchestrator plutôt que de s’appeler directement.
• Tests et audits plus faciles : vous pouvez tester les transitions d’état du flux de travail de manière déterministe en vous moquant des réponses du service dans les tests unitaires.

Inconvénients de l’orchestration

• Risque de centralisation excessive (« God Service ») : si les développeurs intègrent la logique métier du domaine dans Orchestrator, les microservices de travail risquent de se transformer en « services CRUD stupides », recréant un noyau monolithique.
• Couplage API plus étroit : l’orchestrateur doit être explicitement conscient des contrats API et des points de terminaison de tous les microservices participants.
• Gout d’étranglement potentiel en matière d’évolutivité : l’orchestrateur central gère la persistance de l’état pour chaque transaction active. Les systèmes à haut débit nécessitent des backends de moteur d’état évolutifs horizontalement.

3. Comparaison architecturale complète

Pour évaluer côte à côte la chorégraphie et l’orchestration, considérez leurs principales caractéristiques opérationnelles :

4. L’approche hybride : Macro Chorégraphie + Micro Orchestration

L’architecture d’entreprise moderne impose rarement un choix tout ou rien. Au lieu de cela, les principales équipes d’ingénierie utilisent une architecture hybride :

• Niveau macro (chorégraphie) : les contextes délimités de haut niveau (par exemple, contexte délimité par les ventes, contexte délimité par la chaîne d’approvisionnement, support client) communiquent à l’aide de la chorégraphie basée sur les événements via Kafka ou NATS.
• Niveau micro (orchestration) : dans un contexte limité spécifique (par exemple, dans le contexte limité de paiement gérant les tentatives multi-passerelles, la validation des fraudes et les écritures du grand livre), un Orchestrateur local coordonne l’exécution fine du service.

                  [EVENT BROKER: KAFKA]
             /              |              \
   (OrderCreated)     (PaymentSuccess)   (StockReserved)
           /                |                \
  [Order Domain]   [Payment Domain]   [Inventory Domain]
         |                  |                 |
  (Local Saga        (Local Saga       (Local Saga
  Orchestrator)      Orchestrator)     Orchestrator)

Ce modèle hybride permet un couplage lâche de la chorégraphie au-delà des frontières de domaine tout en conservant la visibilité de l’état de l’orchestration au sein des équipes de service individuelles.

5. Exemples de codes de production

Voyons comment implémenter les deux modèles dans des environnements de production à l’aide de Go et Java (Spring Boot).

Implémentation Go : Consommateur d’événements de chorégraphie vs Saga Orchestrator

1. Chorégraphie en Go (Kafka Event Consumer)

Dans Chorégraphie, le service d’inventaire écoute de manière réactive PaymentProcessedEvent de Kafka :

package main

import (
	"context"
	"encoding/json"
	"fmt"
	"log"

	"github.com/segmentio/kafka-go"
)

type PaymentProcessedEvent struct {
	OrderID string  `json:"order_id"`
	Amount  float64 `json:"amount"`
	Status  string  `json:"status"`
}

type InventoryReservedEvent struct {
	OrderID string `json:"order_id"`
	Status  string `json:"status"`
}

func main() {
	reader := kafka.NewReader(kafka.ReaderConfig{
		Brokers: []string{"localhost:9092"},
		Topic:   "payment-events",
		GroupID: "inventory-service-group",
	})
	defer reader.Close()

	writer := kafka.NewWriter(kafka.WriterConfig{
		Brokers: []string{"localhost:9092"},
		Topic:   "inventory-events",
	})
	defer writer.Close()

	fmt.Println("Inventory Service listening for payment events...")

	for {
		msg, err := reader.ReadMessage(context.Background())
		if err != nil {
			log.Fatalf("Error reading message: %v", err)
		}

		var event PaymentProcessedEvent
		if err := json.Unmarshal(msg.Value, &event); err != nil {
			log.Printf("Invalid message payload: %v", err)
			continue
		}

		if event.Status == "SUCCESS" {
			log.Printf("[Choreography] Reserved stock for Order: %s", event.OrderID)
			
			// Publish downstream domain event reactively
			resEvent := InventoryReservedEvent{
				OrderID: event.OrderID,
				Status:  "RESERVED",
			}
			payload, _ := json.Marshal(resEvent)
			
			err = writer.WriteMessages(context.Background(), kafka.Message{
				Key:   []byte(event.OrderID),
				Value: payload,
			})
			if err != nil {
				log.Printf("Failed to publish inventory event: %v", err)
			}
		}
	}
}

2. Orchestration en Go (coordinateur central de la machine d’état)

Dans Orchestration, une machine à états explicite exécute les étapes et gère les compensations :

package main

import (
	"context"
	"errors"
	"fmt"
	"log"
)

type OrderSagaOrchestrator struct {
	paymentClient *PaymentClient
	stockClient   *StockClient
}

func NewOrderSagaOrchestrator(p *PaymentClient, s *StockClient) *OrderSagaOrchestrator {
	return &OrderSagaOrchestrator{paymentClient: p, stockClient: s}
}

func (o *OrderSagaOrchestrator) ExecuteSaga(ctx context.Context, orderID string, amount float64) error {
	log.Printf("[Orchestrator] Starting Saga execution for Order ID: %s", orderID)

	// Step 1: Charge Payment
	if err := o.paymentClient.Charge(ctx, orderID, amount); err != nil {
		log.Printf("[Orchestrator] Payment failed for Order %s: %v", orderID, err)
		return err
	}
	log.Printf("[Orchestrator] Step 1 Complete: Payment Charged")

	// Step 2: Reserve Inventory
	if err := o.stockClient.Reserve(ctx, orderID); err != nil {
		log.Printf("[Orchestrator] Inventory reservation failed: %v. Initiating Compensation...", err)
		
		// Compensation Step: Refund Payment
		if refundErr := o.paymentClient.Refund(ctx, orderID, amount); refundErr != nil {
			log.Printf("[CRITICAL] Compensation failed! Manual intervention required for Order %s", orderID)
		}
		return errors.New("saga aborted: inventory unavailable")
	}

	log.Printf("[Orchestrator] Saga Completed Successfully for Order ID: %s", orderID)
	return nil
}

type PaymentClient struct{}
func (p *PaymentClient) Charge(ctx context.Context, id string, amt float64) error { return nil }
func (p *PaymentClient) Refund(ctx context.Context, id string, amt float64) error { return nil }

type StockClient struct{}
func (s *StockClient) Reserve(ctx context.Context, id string) error { return errors.New("out of stock") }

func main() {
	saga := NewOrderSagaOrchestrator(&PaymentClient{}, &StockClient{})
	_ = saga.ExecuteSaga(context.Background(), "ORD-9982", 149.99)
}

Implémentation Java (Spring Boot)

1. Chorégraphie en Java (Spring Cloud Stream / Kafka Listener)

package com.ghaznix.microservices.choreography;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import java.util.function.Function;

public record PaymentProcessedEvent(String orderId, String status, double amount) {}
public record InventoryReservedEvent(String orderId, String status) {}

@Configuration
public class InventoryChoreographyProcessor {

    @Bean
    public Function<PaymentProcessedEvent, InventoryReservedEvent> processPaymentEvent() {
        return paymentEvent -> {
            System.out.println("[Choreography Java] Processing payment event for order: " + paymentEvent.orderId());

            if ("SUCCESS".equals(paymentEvent.status())) {
                // Reserve stock in database...
                System.out.println("[Choreography Java] Reserved inventory for: " + paymentEvent.orderId());
                return new InventoryReservedEvent(paymentEvent.orderId(), "SUCCESS");
            } else {
                return new InventoryReservedEvent(paymentEvent.orderId(), "FAILED");
            }
        };
    }
}

2. Orchestration en Java (Coordinateur d’état déclaratif)

package com.ghaznix.microservices.orchestration;

import org.springframework.stereotype.Service;

@Service
public class OrderSagaOrchestratorService {

    private final PaymentServiceClient paymentClient;
    private final InventoryServiceClient inventoryClient;
    private final ShippingServiceClient shippingClient;

    public OrderSagaOrchestratorService(PaymentServiceClient p, InventoryServiceClient i, ShippingServiceClient s) {
        this.paymentClient = p;
        this.inventoryClient = i;
        this.shippingClient = s;
    }

    public boolean processCheckoutSaga(String orderId, double totalAmount) {
        System.out.println("[Orchestrator Java] Initiating Saga Workflow for Order: " + orderId);

        // Step 1: Execute Payment
        boolean paymentSuccess = paymentClient.processPayment(orderId, totalAmount);
        if (!paymentSuccess) {
            System.err.println("[Orchestrator Java] Step 1 Failed: Aborting Saga.");
            return false;
        }

        // Step 2: Reserve Inventory
        boolean inventorySuccess = inventoryClient.reserveStock(orderId);
        if (!inventorySuccess) {
            System.err.println("[Orchestrator Java] Step 2 Failed: Triggering Compensation.");
            paymentClient.refundPayment(orderId, totalAmount);
            return false;
        }

        // Step 3: Trigger Shipping
        boolean shippingSuccess = shippingClient.createShipment(orderId);
        if (!shippingSuccess) {
            System.err.println("[Orchestrator Java] Step 3 Failed: Compensating Step 2 & Step 1.");
            inventoryClient.releaseStock(orderId);
            paymentClient.refundPayment(orderId, totalAmount);
            return false;
        }

        System.out.println("[Orchestrator Java] Saga Executed Successfully.");
        return true;
    }
}

6. Paysage de l’outillage industriel populaire

Selon l’orientation architecturale que vous choisissez, l’écosystème open source et cloud propose des moteurs d’infrastructure dédiés :

Écosystème chorégraphique

• Diffusion de messages : Apache Kafka, Apache Pulsar, RabbitMQ, NATS JetStream.
• Routeurs d’événements cloud : AWS EventBridge, Azure Event Grid, Google Cloud Eventarc.
• Registres de schémas : Registre de schémas Confluent (pour la gouvernance Avro/Protobuf).

Écosystème d’orchestration

• Moteurs de code de workflow : Temporal.io (moteur d’exécution durable Go/Java/TypeScript), Cadence.
• Coordonnateurs gérés dans le cloud : AWS Step Functions, Azure Logic Apps, GCP Workflows.
• BPMN et moteurs d’entreprise : Camunda 8 (Zeebe), Netflix Conductor.

7. Matrice de décision : Comment choisir ?

Lorsque vous décidez entre la chorégraphie et l’orchestration pour votre plate-forme de microservices, utilisez cette matrice de règles de décision :

                              [Start: System Architecture Assessment]
                                                |
                              Is the workflow complex with >4 steps 
                              or strict business auditing rules?
                                           /         \
                                     (YES)             (NO)
                                     /                   \
               [Choose: Saga Orchestration]    Does the system require 
               (e.g., Temporal / Camunda)      ultra-high event streaming velocity?
                                                   /              \
                                             (YES)                  (NO)
                                             /                        \
                            [Choose: Event Choreography]      [Choose: Simple Choreography]
                            (e.g., Apache Kafka / NATS)       (e.g., RabbitMQ Pub/Sub)

Choisissez Chorégraphie si :

1. Votre flux de travail se compose de 2 à 4 étapes simples et linéaires.
2. Un débit de streaming d’événements élevé et une latence de livraison inférieure à la milliseconde sont des priorités absolues.
3. Votre équipe d’ingénierie est organisée en équipes de domaines autonomes qui créent et déploient des services de manière indépendante.
4. Vous possédez déjà des outils robustes de traçage distribué et d’APM (OpenTelemetry, Datadog).

Choisissez Orchestration si :

1. Vos processus métier impliquent des transitions d’état complexes, une logique conditionnelle multi-branches ou des retards temporels (par exemple, « Attendez 3 jours pour l’approbation du client »).
2. Vos exigences en matière de conformité et d’audit exigent un journal centralisé de l’état exact de chaque transaction.
3. Vous avez besoin d’annulations de compensation robustes et automatisées pour les étapes ayant échoué sans écrire de logique de chaînage d’événements personnalisée.
4. Vous gérez les transactions financières de l’entreprise (par exemple, opérations bancaires, traitement des réclamations d’assurance).

Conclusion

Ni la chorégraphie ni l’orchestration ne sont universellement supérieures. Choréographie maximise le couplage lâche, le débit des événements et l’autonomie des services au détriment de la visibilité implicite des flux de travail et du traçage distribué complexe. Orchestration offre une gestion explicite des états, une auditabilité centralisée et une reprise déterministe après panne au détriment d’un couplage API plus étroit et d’une gestion de l’infrastructure de l’orchestrateur.

En comprenant les points forts des deux modèles et en tirant parti de la chorégraphie de macros hybrides avec micro orchestration le cas échéant, vous pouvez créer des architectures de microservices résilientes et évolutives qui gèrent avec élégance les transactions distribuées dans les environnements cloud.