Microservices und Datenspeicherung

Ich überlege, eine monolithische REST-API auf eine Microservice-Architektur umzustellen, und bin etwas verwirrt über die Datenspeicherung. Aus meiner Sicht wären einige der Vorteile von Microservices:

• Horizontal skalierbar - Ich kann mehrere redundante Kopien eines Mikrodienstes ausführen, um die Last und / oder den Ausfall eines Servers zu bewältigen.
• Locker gekoppelt - Ich kann interne Implementierungen von Mikrodiensten ändern, ohne die anderen ändern zu müssen, und ich kann sie unabhängig voneinander bereitstellen und ändern usw.

Mein Problem ist die Datenspeicherung. Aus meiner Sicht gibt es mehrere Möglichkeiten:

1. Ein einziger Datenbankdienst, der von allen Microservices gemeinsam genutzt wird - dies scheint den Vorteil einer losen Kopplung vollständig auszuschließen.
2. Eine lokal installierte Datenbankinstanz auf jedem Mikroservice - Ich kann dies nicht horizontal skalieren, daher denke ich nicht, dass dies eine Option wäre.
3. Jeder Mikrodienst verfügt über einen eigenen Datenbankdienst. Dies scheint am vielversprechendsten zu sein, da die Vorteile der losen Kopplung und der horizontalen Skalierung erhalten bleiben (Verwendung redundanter Datenbankkopien und / oder Splittung über mehrere).

Für mich scheint die dritte Option die einzige Option zu sein, aber für mich ist sie unglaublich schwer und eine überentwickelte Lösung. Wenn ich es richtig verstehe, müsste ich für eine einfache Anwendung mit 4-5 Mikrodiensten 16-20 Server ausführen - zwei tatsächliche Mikrodienstinstanzen pro Mikrodienst (im Falle eines Serverausfalls und für die Bereitstellung ohne Ausfallzeit) und zwei Datenbank-Service-Instanzen pro Microservice (bei Serverausfall etc ...).

Dies scheint, ganz offen gesagt, etwas lächerlich. 16-20 Server für die Ausführung einer einfachen API, wenn man bedenkt, dass ein realistisches Projekt wahrscheinlich mehr als 4-5 Dienste haben wird? Gibt es ein grundlegendes Konzept, das mir fehlt und das dies erklären wird?

Einige Dinge, die bei der Beantwortung helfen können:

• Ich bin der einzige Entwickler für dieses Projekt und werde es auf absehbare Zeit sein.
• Ich verwende Node.js und MongoDB, aber ich würde mich für sprachunabhängige Antworten interessieren - eine Antwort könnte sogar sein, dass ich nur die falschen Technologien verwende!

Von den drei Optionen sind die erste (eine einzelne, gemeinsam genutzte Datenbank) und die dritte (ein "Datenbankdienst") am häufigsten.

Die erste heißt Integrationsdatenbank . Dies wird im Allgemeinen nicht als eine gute Lösung in einer Microservice-Architektur angesehen. Es fügt eine Kopplung zu Ihren Diensten hinzu. Außerdem ist es für einen Dienst sehr einfach, die anderen Dienste einfach zu umgehen und direkt in eine Datenbank abzufragen. Sie können jede Art von Datenintegrität oder -überprüfung verlieren, die von der Anwendungsebene bereitgestellt wird, die nicht auf Datenbankebene erzwungen wird.

Ihre dritte Idee heißt Anwendungsdatenbank . Und Sie haben Recht - Sie können die lose Kopplung auf API-Ebene zwischen Diensten erzwingen und Dienste auf Datenbankebene einfacher skalieren. Dies erleichtert auch das Ersetzen der zugrunde liegenden Datenbanktechnologie durch eine für jeden Dienst geeignete Technologie, ebenso wie Sie die Technologie oder andere Implementierungsdetails für jeden Dienst ändern können. Sehr flexibel.

Ich würde jedoch eine Zwischenlösung vorschlagen.

Anstatt für jeden Mikroservice einen Datenbankservice einzurichten, sollten Sie für jeden Service ein Schema einrichten. Wenn Sie mehrere Datenbanktechnologien verwenden, müssen Sie möglicherweise etwas anders aufteilen. Die Idee wäre jedoch, die Anzahl der von Ihnen ausgeführten Datenbankserver zu minimieren, aber es ist sehr einfach, einen Dienst in einen eigenen Datenbankserver aufzuteilen, wenn und wenn es nötig wird. Solange Sie nur einer Datenbank erlauben, auf ihr eigenes Schema zuzugreifen, haben Sie die Vorteile einer Anwendungsdatenbank, jedoch ohne den für jede Anwendung oder jeden Dienst vorhandenen Aufwand an Datenbankservern.

Als Einzelentwickler würde ich jedoch zu diesem Zeitpunkt die gesamte Vorstellung von Microservices in Frage stellen - Martin Fowler schreibt über den Monolith First und den Microservice Premium , Simon Brown über modulare Monolithen und DHH über den Majestic Monolith. Ich bin mir nicht sicher, wie gut Ihr Monolith organisiert ist, aber überarbeiten und organisieren Sie es. Identifizieren Sie Komponenten und machen Sie saubere Trennungen zwischen ihnen, um Teile einfach zu einem Service zu extrahieren. Gleiches gilt für Ihre Datenbankstruktur. Konzentrieren Sie sich auf eine gute, saubere, komponentenbasierte Architektur, die das Refactoring in Services unterstützen kann. Microservices bedeuten für einen einzelnen Entwickler einen hohen Aufwand für den Aufbau und die Unterstützung des Betriebs. Wenn Sie jedoch tatsächlich einen Teil des Systems skalieren müssen, können Sie mithilfe Ihrer Überwachungs- und Berichtssysteme die Engpässe identifizieren, auf einen Service extrahieren und nach Bedarf skalieren.

Jeder Mikrodienst verfügt über einen eigenen Datenbankdienst. Dies scheint am vielversprechendsten zu sein, da die Vorteile der losen Kopplung und der horizontalen Skalierung erhalten bleiben (Verwendung redundanter Datenbankkopien und / oder Splittung über mehrere).

Zustimmen. Die dritte Option ist die natürliche Wahl für Mikrodienste. Wenn der Mikrodienst wirklich unabhängig sein soll (und nicht Teil eines verteilten Monolithen ist ), ist es normal, dass er jeweils über eine Datenbank verfügt.

[...] zwei tatsächliche Microservice-Instanzen pro Microservice (bei Serverausfall und zur Bereitstellung ohne Ausfallzeit) und zwei Datenbankservice-Instanzen pro Microservice (bei Serverausfall usw.).

Sie haben Recht mit der Anzahl der ausgeführten Mikrodienste, wenn Sie einen Lastenausgleich wünschen. Wenn Sie 4 Mikrodienste planen, müssen Sie mindestens 2 Instanzen jedes Mikrodienstes vorbereiten (insgesamt 8), wie Sie bereits erläutert haben.

Aber zwei Datenbanken pro Mikrodienst? Das ist wirklich fraglich. Ich kenne die Details des Geschäftsproblems, mit dem sich Ihre Mikrodienste befassen werden, nicht, aber die Datenbankredundanz ist für die meisten Produkte / Projekte recht hoch. Ich empfehle, mit einer einzigen Datenbank mit einem guten Backup zu beginnen und (zumindest anfangs) die Komplexität Ihrer Infrastruktur zu minimieren.

Dies scheint, ganz offen gesagt, etwas lächerlich. 16-20 Server für die Ausführung einer einfachen API, wenn man bedenkt, dass ein realistisches Projekt wahrscheinlich mehr als 4-5 Dienste haben wird? Gibt es ein grundlegendes Konzept, das mir fehlt und das dies erklären wird?

Für eine einfache API stimmen diese Zahlen nicht überein. Achten Sie darauf, wenn Sie nicht in eine der "Microservice First" -Fallen fallen .

Microservices sind eine Form von serviceorientierter Architektur, vielleicht im Extremfall. Ihr allgemeiner Zweck besteht darin, die Kopplung zu verringern und eine unabhängige Entwicklung und Bereitstellung zu ermöglichen.

In architektonischer Hinsicht ist Microservices ein Begriff, der beispielsweise auf einer logischen Ebene gilt. Die Microservices sind logisch voneinander getrennt. Aus dieser Sicht sollten Mikrodienstleistungen jeweils eigene und für eine eigene Lagerung sorgen, die von der Lagerung anderer Mikrodienstleistungen entkoppelt sein sollte. Für Microservices ist diese Speicherunabhängigkeit der Schlüssel zu ihrem Ziel der Modularität und der losen Kopplung.

Aus architektonischer Sicht gilt die horizontale Skalierung auf einer niedrigeren Ebene, näher an der Implementierung, beispielsweise auf einer physischen Ebene. Auf dieser Ebene implementieren wir einen Mikrodienst und können diesen einzelnen Mikrodienst intern in eine zustandslose Komponente zerlegen, die horizontal skalierbar ist, und eine zustandsbehaftete Komponente, die von allen zustandslosen Komponenten gemeinsam genutzt wird.  Aber verwechseln wir nicht nur den zustandslosen Teil mit dem Microservice selbst.

Wenn wir also über die einzelnen Mikrodienste sprechen, sprechen wir auf der logischen Ebene über APIs und getrennte Verantwortlichkeiten sowie getrennte Entwicklungs- / Bereitstellungszyklen. Und wenn wir über horizontale Skalierung sprechen, sprechen wir auf physikalischer Ebene über die Implementierung eines (einzelnen) Mikrodienstes und dessen Zerlegung in zustandslose und zustandsbehaftete Komponenten.

Bei der Implementierung mehrerer Microservices haben wir die Wahl, die Datenbanktechnologie für die statusbehafteten Komponenten wiederzuverwenden:

• separate Datenbank pro Microservice
• gemeinsame Datenbank mit:
  • separates / privates Schema pro Microservice
  • separate / private Tische pro Microservice

Sehen Sie hier mehr .

Ein einziger Datenbankdienst, der von allen Microservices gemeinsam genutzt wird - dies scheint den Vorteil einer losen Kopplung vollständig auszuschließen.

Einverstanden, wenn Sie Tabellenzeilen und -spalten gemeinsam nutzen wollen, wäre das nicht wirklich Microservices.

Wenn wir - in unseren Denkprozessen - den logischen Begriff der Mikrodienste von dem physikalischeren Begriff der zustandsbehafteten und zustandslosen Komponenten eines Mikrodienstes entkoppeln können, fällt es uns möglicherweise leichter, die lose Kopplung zu erreichen, die Mikrodienste bieten, während die Effizienz eines gemeinsam genutzten Dienstes erhalten bleibt Datenbanken.

Im Allgemeinen wird eine ganze Menge über Microservices und Stateful Persistence geschrieben, siehe auch hier .

Nun, ich habe alle Beiträge in diesem Thread durchgelesen und kann Ihnen sagen, dass ich mit der Frage verwirrt bin: Es mischt Microservice (MS) mit Diensten mit Datenzugriffsdienst (DB-Dienst) mit Datenbanken und Servern ...

Wenn MS eine unabhängige (implementierbare) Komponente ist, die eine der einfachsten Aufgaben zustandslos löst, welche Datenbank benötigt sie? Wenn eine komplexere Aufgabe gelöst werden muss, für die mehr als eine einfachste Teilaufgabe (MS?) Gemeinsam gelöst werden muss, handelt es sich dann immer noch um eine MS? In SOA wird es als Orchestrierungsdienst bezeichnet. Es implementiert "process" und koordiniert den MS-Aufruf. Daher muss es seinen Status beibehalten (alle Orchestrierungen / Organisatoren / Komponisten / etc. Sind statusbehaftet) und benötigt einen persönlichen Datenspeicher: Niemand darf den Status des Orchestrators beeinträchtigen.

Wir sprechen jedoch nicht über Datenbanken, sondern über Database Access MS / Service, und das ist eine ganz andere Sache. Eine MS benötigt möglicherweise einige Daten, die in der Firma gesammelt wurden (nicht in der Anwendung, in der sie arbeitet), und kann keine andere MS über ihre API / Schnittstelle nach den Daten fragen. Dies ist das häufigste und realistischste Szenario. Und eine andere MS aus derselben oder einer anderen Anwendung benötigt diese Daten möglicherweise oder ändert sie sogar. Ja, sie konkurrieren um die Daten, wie es immer war, bevor MS auftauchte.

Warum brechen wir die 'Tür' auf, die bekannt und offen ist? Was ist in dieser Hinsicht der Unterschied zwischen einer MS und einem regulären selbstbeständigen Objekt? Warum brauchen wir eine individuelle Datenbank für MS, wenn sie (aus Gründen der Flexibilität und der Kompositionsfähigkeit) trotzdem ihren Datenzugriffsdienst (DAS) in Anspruch nehmen muss? Vergessen Sie nicht, dass DAS die MS mit einer Geschäftsaufgabe vor dem Bewusstsein für die physische Konnektivität mit der Datenbank schützt. Diese lose Kopplung und Flexibilität sollte die MS bewahren, um frei an mehreren Anwendungen ohne Datenbankanker teilnehmen zu können.