Antwort.

Die Minimierung der Loose Coupling zwischen Mikrodiensten ist eines der Hauptprinzipien moderner Architektur. Dies wird durch asynchrone Interaktion (über Nachrichtenwarteschlangen oder Event-Bussen), den Verzicht auf direkte synchrone HTTP-Aufrufe ohne Notwendigkeit und die Bereitstellung klarer API-Verträge erreicht.

Eine beliebte Methode ist die Verwendung von Nachrichten-Brokern (RabbitMQ, Kafka, NATS), bei denen Mikrodienste Ereignisse über ihren Status veröffentlichen und Abonnenten auf sie reagieren.

Beispiel für die Veröffentlichung und Verarbeitung eines Ereignisses in Kafka mit 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())
  // Bestellung bearbeiten
}})

Schlüsselfeatures:

Mikrodienste kommunizieren über einen formalisierten API oder einen Vermittler (Warteschlange, Bus)
Jeder Dienst hat seine eigene Datenbank (Database per Service), um Blockierungen und Konkurrenz zu vermeiden
Es ist möglich, neue Dienste während des Betriebs hinzuzufügen, ohne bestehende zu ändern

Trickfragen.

Frage: Kann man eine gemeinsame Datenbank für mehrere Mikrodienste verwenden, wenn es sich um ein großes Projekt handelt?

Nein, das verletzt das Prinzip der Unabhängigkeit, führt zu Tight Coupling, verschlechtert die Skalierbarkeit und Wartbarkeit. Es sollten separate Datenbanken oder Schemata verwendet werden.

Frage: Ist die synchrone HTTP-Interaktion zwischen Diensten eine zulässige Praxis beim Skalieren eines Systems?

Synchrone HTTP-Anfragen skalieren schlecht und können zum Bottleneck werden. Es wird empfohlen, asynchrone Mechanismen zu verwenden und nur in absolut notwendigen Fällen auf synchrone Aufrufe zurückzugreifen.

Frage: Kann man einen Mikrodienst nur durch die Anzahl seiner Instanzen skalieren, ohne die Architektur des Systems zu ändern?

Nein, eine einfache Erhöhung der Anzahl der Instanzen löst nicht die Probleme der Kopplung oder Engpässe in der Architektur. Eine Analyse der Bottlenecks, die Implementierung von Warteschlangen, Caching und die Trennung der Zuständigkeiten der Dienste sind erforderlich.

Wie organisiert man die Interaktion zwischen Mikrodiensten richtig, um die Loose Coupling zu minimieren und die Skalierbarkeit zu maximieren?

Antwort.

Trickfragen.