Réponse.

La minimisation du couplage (loose coupling) entre les microservices est l'un des principaux principes de l'architecture moderne. Cela est réalisé par une interaction asynchrone (via une file de messages ou un bus d'événements), l'abandon des appels HTTP synchrones directs sans nécessité et la définition de contrats API explicites.

Une méthode populaire consiste à utiliser des courtiers de messages (RabbitMQ, Kafka, NATS), où les microservices publient des événements sur leur état et les abonnés réagissent à ces événements.

Exemple de publication et de traitement d'événements dans Kafka avec Node.js:

// producer.js
const { Kafka } = require('kafkajs')
const kafka = new Kafka({ clientId: 'order-service', brokers: ['kafka01:9092'] })
const producer = kafka.producer()
await producer.connect()
await producer.send({ topic: 'orders', messages: [ { value: JSON.stringify({orderId: 123}) } ] })
await producer.disconnect()

// consumer.js
const consumer = kafka.consumer({ groupId: 'payment-group' })
await consumer.connect()
await consumer.subscribe({ topic: 'orders', fromBeginning: true })
await consumer.run({ eachMessage: async ({ topic, partition, message }) => {
  const order = JSON.parse(message.value.toString())
  // traitement de la commande
}})

Caractéristiques clés:

• Les microservices communiquent via une API formalisée ou un intermédiaire (file, bus)
• Chaque service a sa propre base de données (Database per Service) pour éviter les verrous et la concurrence
• Il est possible d'ajouter de nouveaux services à la volée sans modifier les existants

Questions pièges.

Question: Peut-on utiliser une base de données commune pour plusieurs microservices si c'est un grand projet ?

Non, cela viole le principe d'indépendance et conduit à un couplage étroit (tight coupling), ce qui nuit à l'évolutivité et à la maintenabilité. Il faut utiliser des bases de données ou des schémas séparés.

Question: L'interaction HTTP synchrone entre les services est-elle une pratique acceptable lors de l'évolutivité du système ?

Les requêtes HTTP synchrones sont mal évolutives et peuvent devenir des goulets d'étranglement (bottleneck). Il est recommandé d'utiliser des mécanismes asynchrones et de recourir à des appels synchrones uniquement en cas de nécessité absolue.

Question: Peut-on évoluer un microservice uniquement en termes de nombre de ses instances, sans modifier l'architecture du système ?

Non, une simple augmentation du nombre d'instances ne résout pas les problèmes de couplage ou de goulets d'étranglement dans l'architecture. Une analyse des goulets d'étranglement est nécessaire, ainsi que la mise en place de files d'attente, de mise en cache et de séparation des responsabilités des services.