1. Synchrone Kommunikation

Synchronisierte Kommunikation beinhaltet eine Echtzeitinteraktion, bei der ein Dienst eine Anfrage an einen anderen sendet und seinen Betrieb anhält, bis eine Antwort empfangen wird. REST-APIs und gRPC sind gängige Protokolle, die diese Art der Kommunikation erleichtern.

1.1 RESTful-API

Eine RESTful API (Representational State Transfer) ist eine der gebräuchlichsten Methoden für die Kommunikation von Diensten untereinander in einem Microservices-System. REST nutzt HTTP/HTTPS- und JSON- oder XML-Formate für den Datenaustausch.

Typischerweise interagieren Dienste miteinander, indem sie direkt die API eines anderen Dienstes aufrufen.

Beispielanfrage und -antwort:

GET /users/12345 HTTP/1.1
Host: api.userservice.com
Accept: application/json
Authorization: Bearer your-access-token

{
  "userId": "12345",
  "name": "Michel J",
  "email": "[email protected]",
  "address": "Mountain View, Santa Clara, California"
}

Quellcode-Beispiel

import org.springframework.web.client.RestTemplate;
import org.springframework.http.ResponseEntity;

public class OrderService {

    private final RestTemplate restTemplate = new RestTemplate();
    private final String userServiceUrl = "https://api.userservice.com/users/";

    public User getUserById(String userId) {
        String url = userServiceUrl   userId;
        ResponseEntity response = restTemplate.getForEntity(url, User.class);
        return response.getBody();
    }
}

Vorteile:

Einfache Bereitstellung und Integration mit verschiedenen Sprachen und Tools.

Kann problemlos Test- und Überwachungstools verwenden.

Nachteile:

Aufgrund seiner synchronen Natur möglicherweise nicht effizient für Hochgeschwindigkeitsanforderungen.

Es kann zu Schwierigkeiten bei der Bewältigung von Netzwerkfehlern oder Verbindungsabbrüchen kommen.

1,2 gRPC

gRPC steht für Google Remote Procedure Call und ist ein leistungsstarkes, universelles Open-Source-RPC-Framework. Es nutzt HTTP/2 für eine effiziente Datenübertragung und stützt sich typischerweise auf Protokollpuffer, einen sprachneutralen, plattformneutralen, erweiterbaren Mechanismus zur Serialisierung strukturierter Daten, um die Struktur der gesendeten und empfangenen Daten zu definieren.

Beispiel, Definition von Protokollpuffern

syntax = "proto3";

package userservice;

// Define message User
message User {
    string userId = 1;
    string name = 2;
    string email = 3;
    string address = 4;
}

// Define service UserService
service UserService {
    rpc GetUserById (UserIdRequest) returns (User);
}

// Define message UserIdRequest
message UserIdRequest {
    string userId = 1;
}

Für den Benutzerverwaltungsdienst sollten Sie einen gRPC-Server implementieren, der der in der .proto-Datei bereitgestellten Dienstdefinition entspricht. Dazu gehört die Erstellung der notwendigen serverseitigen Logik, um eingehende gRPC-Anfragen zu verarbeiten und entsprechende Antworten zu generieren.

import io.grpc.stub.StreamObserver;
import userservice.User;
import userservice.UserIdRequest;
import userservice.UserServiceGrpc;

public class UserServiceImpl extends UserServiceGrpc.UserServiceImplBase {

    @Override
    public void getUserById(UserIdRequest request, StreamObserver responseObserver) {
        // Assuming you have a database to retrieve user information.
        User user = User.newBuilder()
                .setUserId(request.getUserId())
                .setName("Michel J")
                .setEmail("[email protected]")
                .setAddress("Mountain View, Santa Clara, California")
                .build();

        responseObserver.onNext(user);
        responseObserver.onCompleted();
    }
}

import io.grpc.Server;
import io.grpc.ServerBuilder;

public class UserServer {
    public static void main(String[] args) throws Exception {
        Server server = ServerBuilder.forPort(9090)
                .addService(new UserServiceImpl())
                .build()
                .start();

        System.out.println("Server started on port 9090");
        server.awaitTermination();
    }
}

Vorteile:

Hohe Leistung und Bandbreiteneffizienz durch die Verwendung von HTTP/2 und Protokollpuffern.

Unterstützt mehrere Programmiersprachen und verfügt über eine gute Skalierbarkeit.

Nachteile:

Erfordert eine Übersetzungsschicht, wenn Dienste gRPC nicht unterstützen.

Die Bereitstellung und Verwaltung kann komplexer sein.

2. Asynchrone Kommunikation

Asynchrone Kommunikation bezieht sich auf den Prozess, bei dem ein Dienst eine Anfrage an einen anderen Dienst sendet, ohne seinen eigenen Vorgang zu blockieren und auf eine Antwort zu warten. Dies wird üblicherweise durch Nachrichtenwarteschlangen oder Publish/Subscribe-Systeme erreicht.

1. Nachrichtenwarteschlangen

Nachrichtenwarteschlangensysteme wie RabbitMQ und Apache ActiveMQ erleichtern die asynchrone Kommunikation zwischen Diensten.

Vorteile:

Verbesserte Skalierbarkeit und Fehlertoleranz: Das System kann erhöhte Arbeitslasten besser bewältigen und ist weniger anfällig für Ausfälle.

Reduzierte Belastung der Dienste: Durch die Entkopplung des Sendens und Empfangens von Anforderungen können sich die Hauptdienste auf die Verarbeitung von Aufgaben konzentrieren, ohne durch ständige Anforderungen überlastet zu werden.

Nachteile:

Erfordert möglicherweise zusätzlichen Verwaltungs- und Wartungsaufwand: Warteschlangenbasierte Systeme können komplexer sein und mehr Ressourcen für den Betrieb erfordern.

Schwierigkeiten bei der Bestellabwicklung und der Sicherstellung der Nachrichtenzustellung: Es kann eine technische Herausforderung sein, sicherzustellen, dass Anfragen in der richtigen Reihenfolge verarbeitet werden und keine Nachrichten verloren gehen.

2.2. Pub/Sub-System

Ein Pub/Sub-System (Publish/Subscribe) wie Apache Kafka oder Google Pub/Sub ermöglicht es Diensten, Nachrichten zu veröffentlichen und Themen zu abonnieren.

Vorteile:

Unterstützt große Datenströme mit hohem Durchsatz.

Reduziert Abhängigkeiten zwischen Diensten.

Nachteile:

Erfordert eine komplexere Ebene zur Verwaltung und Überwachung von Themen und Nachrichten.

Es kann schwierig sein, Ordnungs- und Zuverlässigkeitsprobleme bei Nachrichten zu lösen.“

Bei Interesse können Sie meine bisherigen Artikel zum Pub/Sub-Thema lesen.

Warteschlange für unzustellbare Nachrichten in einem Message Broker Teil 1

Warteschlange für unzustellbare Nachrichten in einem Message Broker Teil 2

Konsistenz- und Zuverlässigkeitsbedenken innerhalb des Message Broker-Systems

3. Ereignisgesteuerte Kommunikation

Ereignisgesteuerte Kommunikation liegt vor, wenn ein Dienst ein Ereignis ausgibt und andere Dienste auf der Grundlage dieser Ereignisse reagieren oder Maßnahmen ergreifen.

3.1. Synchrone Ereignisse

Synchronisierte Ereignisse treten auf, wenn ein Dienst ein Ereignis ausgibt und auf eine Antwort von anderen Diensten wartet.

Vorteile:

Einfache Steuerung und Überwachung des Ereignisverarbeitungsprozesses.

Nachteile:

Kann zu Engpässen führen, wenn die antwortenden Dienste langsam sind oder Fehler auftreten

3.2. Asynchrone Ereignisse

Asynchrone Ereignisse treten auf, wenn ein Dienst ein Ereignis ausgibt und nicht auf eine sofortige Antwort warten muss.

Vorteile:

Reduziert Wartezeiten und verbessert die Skalierbarkeit.

Hilft den Diensten, unabhängiger zu arbeiten und verringert gegenseitige Abhängigkeiten.

Nachteile:

Erfordert zusätzliche Mechanismen, um sicherzustellen, dass Ereignisse korrekt und rechtzeitig verarbeitet werden.

Schwierigkeiten bei der Sicherstellung der Ordnung und beim Umgang mit doppelten Ereignissen.

4. Fazit

Die Wahl der Kommunikationsmethode zwischen Diensten in einem Microservices-System hängt von Faktoren wie Leistungsanforderungen, Zuverlässigkeit und Systemkomplexität ab. Jede Methode hat ihre eigenen Vor- und Nachteile. Wenn Sie diese Methoden verstehen, können Sie ein effizienteres und flexibleres Microservices-System aufbauen. Berücksichtigen Sie sorgfältig die Anforderungen Ihres Systems, um die am besten geeignete Kommunikationsmethode auszuwählen.