Microservices Architecture in Ruby: A Practical Setup Guide

Der Einsatz von Microservice-Architekturen wird vor allem aufgrund ihrer Skalierbarkeit, größeren Flexibilität und Fehlerisolierung immer beliebter. Es ist nicht notwendig, Ihr Projekt auf einer monolithischen Architektur zu starten; Sie können eine skalierbarere Lösung nutzen, bei der die Dienste unabhängig voneinander arbeiten, aber dennoch miteinander kommunizieren.

Hier führen wir Sie anhand von konkreten Praxisbeispielen und hilfreichen Empfehlungen durch den Prozess der Ruby-Einrichtung.

Erste Schritte mit Microservices

Beim klassischen Client-Server-Ansatz basiert das Backend in der Regel auf einem monolithischen System, das den gesamten Datenzugriff und die Domänenlogik umfasst. Die Interaktion mit dem Backend erfolgt über die API-Schicht. Bei einer Microservices-Architektur ist das System in kleinere Dienste unterteilt, wobei jeder Teil über eigene Ressourcen und einen eigenen Bereich verfügt. Darüber hinaus lassen sich alle diese Dienste unabhängig voneinander skalieren.

Die Dienste sind über die Broker-Architektur miteinander verbunden und interagieren über diese. Der gesamte Prozess funktioniert wie folgt: Die Nachrichten werden über die Dienste an den Broker gesendet und anschließend an das gewünschte Ziel weitergeleitet. Das bedeutet, dass Dienste nicht direkt miteinander verbunden sein sollten, sondern lediglich wissen müssen, wie sie mit dem Broker interagieren. Ein solcher Ansatz ist äußerst vorteilhaft für die Isolation der Dienste und die Sicherheit im Allgemeinen.

Einblicke in die Interaktion und den Nachrichtenaustausch  

Zur Ermöglichung der Interaktion mit dem Broker wird die asynchrone Schicht genutzt. Die Interaktion ähnelt in gewisser Weise HTTP. Sie funktioniert wie folgt: Dienste senden die Anfrage über den Broker und erhalten anschließend die Antwort.

Ein solcher Ansatz bedeutet, dass sich jeder Dienst ausschließlich auf bestimmte einzelne Aufgaben konzentriert. Das System ist so praktisch organisiert, dass Dienste nur mit dem Broker interagieren, Operationen jedoch von anderen Teilen innerhalb dieses Systems genutzt werden können.

Entwicklung von Microservices mit Ruby    

Nehmen wir zum Beispiel eine Architektur mit einem Broker und einigen Ruby-Diensten. Um den Prozess ordnungsgemäß zu starten, richten Sie zunächst den Broker ein, nachdem Sie überprüft haben, dass er korrekt funktioniert. Sie können Ruby-Mikroservices hinzufügen.

Wenn von einem konkreten Service-Projekt die Rede ist, umfasst dieses in der Regel die folgenden Teile:

• Eine Konfiguration, die Protokollierungsstufen, Datenbankeinstellungen und die Broker-Adresse enthält.
• Initialisierer, die für die Ermittlung von Abhängigkeiten zuständig sind.
• Datenübertragungsobjekte (DTOs) und Datenzugriffsobjekte (DAOs).
• Repositorien, die Zugriffsvorgänge auf Daten steuern.
• Mapper sind für die Konvertierung zwischen DAO und DTO erforderlich.
• Dienstklassen, die für die Orchestrierung der Repositorien und die Implementierung der Geschäftsendpunkte benötigt werden.

Erstellen eines einfachen „Person“-Dienstes

Sehen wir uns nun ein Beispiel für den „Person“-Dienst an. Der erste Schritt betrifft die Konfiguration der Datenbankverbindung und die Definition der Personentabelle. Das DAO-Modell wird für die Darstellung der Datensätze in der Tabelle benötigt, und das DTO dient zur Darstellung der externen Payload-Struktur.

Anschließend wird ein Mapper für die Konvertierung zwischen DTO und DAO verwendet. Alle diese Komponenten werden durch das Repository zusammengeführt, um Operationen auf höherer Ebene zu gewährleisten. Der letzte Schritt besteht in der Verwendung der Service-Klasse, um alles zusammenzuführen und eine strukturierte Antwort zu liefern.

Mit der get-Methode ist es beispielsweise möglich, Informationen zu allen Benutzern abzurufen. Falls keine dieser Informationen empfangen wird, wird der Standardfehler 404 generiert. Sind solche Informationen verfügbar, werden sie in ein DTO konvertiert und an den Client zurückgegeben. Anschließend wird der Service an den Broker gebunden, die Routen werden zugeordnet, und es wird sichergestellt, dass eingehende Anfragen an den richtigen Handler weitergeleitet werden.

Zum Testen der Endpunkte sind lediglich kleine Skripte erforderlich. Durch den Einsatz einfacher Fehlerbehandlungslogik wird das allgemeine Verhalten zwischen allen Prozessen wesentlich besser testbar und vorhersehbarer.

Verwendung der Repository-Muster

Dienste in der beschriebenen Architektur kommunizieren nicht direkt mit den Datenbankmodellen. Sie basieren hauptsächlich auf Repositories, die wiederum auf dem Prinzip von Mappern, DTOs und DAOs beruhen. Ein solcher Ansatz bietet einige spezifische Vorteile:

• Da alle Datenzugriffe in Repositories zentralisiert sind, wirkt sich dies positiv auf die Abfragelogik und die Speicherung aus.
• Das Hauptfunktionsprinzip basiert auf der Nachrichtenverarbeitung und der Geschäftslogik.
• Garantie eines stabilen Vertrags durch DTOs.

Mikroservices funktionieren hauptsächlich nach dem Prinzip der strikten Trennung, wobei jeder Service seine eigene individuelle Struktur und Speicherstrategie hat. Die Kombination aus strikt definierten Mustern und einem brokerbasierten Messaging-Design macht diesen Ansatz wesentlich wartungsfreundlicher und flexibler.