Antwoord.

Het minimaliseren van de koppeling (loose coupling) tussen microservices is een van de belangrijkste principes van moderne architectuur. Dit wordt bereikt door asynchrone interactie (via een berichtenwachtrij of gebeurtenisbus), het vermijden van directe synchrone HTTP-aanroepen zonder noodzaak en het definireren van expliciete API-contracten.

Een populaire methode is het gebruik van message brokers (RabbitMQ, Kafka, NATS), waarbij microservices gebeurtenissen over hun status publiceren en abonnenten hierop reageren.

Voorbeeld van het publiceren en verwerken van een gebeurtenis in Kafka met 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())
  // verwerking van de bestelling
}})

Belangrijke kenmerken:

• Microservices communiceren via een geformaliseerde API of tussenpersoon (wachtrij, bus)
• Elke service heeft zijn eigen database (Database per Service) om blokkades en concurrentie te vermijden
• Nieuwe services kunnen on-the-fly worden aangesloten zonder bestaande services te wijzigen

Vragen met een addertje onder het gras.

Vraag: Mag je een gemeenschappelijke database gebruiken voor meerdere microservices als het één groot project is?

Nee, dit schendt het onafhankelijkheidsprincipe, leidt tot tight coupling, verslechtert de schaalbaarheid en onderhoudbaarheid. Er moeten aparte databases of schema's worden gebruikt.

Vraag: Is synchrone HTTP-interactie tussen services een aanvaardbare praktijk bij het schalen van een systeem?

Synchrone HTTP-aanroepen schalen slecht en kunnen een bottleneck worden. Asynchrone mechanismen worden aanbevolen en alleen in het geval van absolute noodzaak moet je naar synchrone oproepen teruggrijpen.

Vraag: Is het mogelijk om een microservice alleen te schalen op het aantal instanties, zonder de architectuur van het systeem te wijzigen?

Nee, alleen het verhogen van het aantal instanties lost de problemen van koppeling of knelpunten in de architectuur niet op. Er is een analyse van knelpunten nodig, evenals de implementatie van wachtrijen, caching en het splitsen van verantwoordelijkheden van services.