Monolithische vs. Microservices-Architektur für .NET

Dieser Artikel ist eine Einführung in die Entwicklung und Verwaltung von Microservices-basierten Anwendungen. Er beschreibt Entwurfs- und Implementierungsansätze mithilfe von .NET Core und Docker-Containern. Dieser Artikel richtet sich an .NET-Entwickler und Lösungsarchitekten, die eine Entscheidung über ihre Anwendungsarchitektur treffen müssen und mit der Microservices-basierten Architektur nicht vertraut sind. In diesem Artikel erfahren Sie mehr über die Vorteile der Implementierung einer Microservices-basierten Architektur im Vergleich zur Entwicklung einer monolithischen Anwendung sowie über Ansätze zur Lösung der Hauptprobleme, die bei diesem Ansatz auftreten können.

Das Microservices-Designmuster fördert die Entwicklung komplexer Anwendungen als eine Reihe kleiner unabhängiger Teile (Services), die auf Geschäftsanforderungen reagieren. Jeder Microservice ist für eine spezifische Funktion des Systems verantwortlich.

Anstatt einer monolithischen Anwendung können Microservices an verschiedenen Orten gehostet werden, und Entwickler können wichtige Änderungen in Echtzeit durchführen, ohne das gesamte System zu stoppen.

Warum Microservices anstelle einer monolithischen Architektur?

Lange Zeit haben die Kosten, der Zeitaufwand und die Komplexität der Bereitstellung neuer Hardware die Anwendungsentwicklung eindeutig beeinflusst. Da Anwendungen statisch dimensioniert und für spezifische Hardware ausgelegt wurden, bestand die Antwort auf steigende Lasten, die die Hardware einer Anwendung überlasteten, einfach darin, „hochzuskalieren“ oder die Hardware der Anwendung aufzurüsten, um Kapazitäten hinzuzufügen und eine Neukonfiguration des Rechenzentrums und Software-Refactoring zu vermeiden.

Das monolithische Anwendungsmodell war begrenzt und ineffizient. Jede Änderung an der Anwendung konnte viel Zeit kosten und einen Fehler an beliebiger Stelle im gesamten System verursachen. In diesem Fall müssen Entwickler einen riesigen Codebestand debuggen, um herauszufinden, was schiefgelaufen ist. Jede neu gelieferte Funktion kann vorübergehend alles zerstören.

Unternehmen versuchen immer häufiger, einige Probleme zu lösen, wenn sie große Unternehmensanwendungen nutzen, um ihren eigenen Bedürfnissen gerecht zu werden:

• Kosten senken
• Bereitstellungsprozess weniger schmerzhaft gestalten
• DevOps verbessern

Diese Probleme können durch die Verwendung einer Microservices-Architektur in Verbindung mit Containern gelöst werden. Docker-Containerisierung wird zum Standard in der Anwendungsbereitstellung. Die Vorteile der Containerisierung sind eine flexible, leichte, sichere, skalierbare und portable Architektur. Mit Hilfe von Kubernetes können Sie Ihre Container einfach bereitstellen und hosten, containerisierte Workloads und Dienste verwalten.

In diesem Fall, wenn Sie eine stark ausgelastete Anwendung haben, müssen Sie nicht die gesamte Anwendung skalieren, wie es bei der Verwendung einer monolithischen Architektur der Fall wäre. Sie können nur einige Microservices skalieren, die die höchste Last haben, und Ihre Leistung mit minimalem Ressourcenverbrauch verbessern.

Vor- und Nachteile der Microservices-Architektur

Die Microservices-Architektur ist ein Ansatz zum Aufbau einer Serveranwendung als eine Reihe kleiner Dienste. Jeder Dienst sollte in einem eigenen Prozess laufen und mit anderen Diensten über Protokolle wie HTTP/HTTPS, WebSockets usw. kommunizieren. Jeder Teil dieser Struktur (also Dienst) sollte als autonomes Einheit entwickelt werden, die unabhängig bereitgestellt werden kann. Jeder Microservice sollte sein eigenes zugehöriges Domänendatenmodell und Domänenlogik besitzen und kann auf unterschiedlichen Datenspeichertechnologien basieren. Übrigens kann er in verschiedenen Programmiersprachen geschrieben sein.

Der Hauptpunkt bei der Entwicklung von Microservices besteht darin, lose gekoppelte Dienste zu erstellen, um die Möglichkeit der unabhängigen Bereitstellung, Skalierung und Entwicklung jedes Dienstes in der Anwendung zu bieten. Wenn wir über die Größe von Microservices sprechen, sollten wir versuchen, sie so klein wie möglich zu machen, aber sie mit einem Minimum an direkten Abhängigkeiten von anderen Microservices zu belassen. Dies bietet langfristige Agilität, Skalierbarkeit und bessere Wartbarkeit in der Zukunft.

Der Aufbau einer fein granulierten Microservices-basierten Architektur ermöglicht Continuous Integration (CI) und Continuous Delivery (CD) Praktiken. Dies bietet die Möglichkeit, neue Funktionen leicht in bereits in Produktion befindliche Anwendungen zu integrieren. Sie können einen der Microservices vollständig ändern, um neue Funktionalität zu implementieren oder diesen Dienst sogar zerstören, und es wird nicht das gesamte System, das Sie aufgebaut haben, beeinträchtigen.

Schließlich können Sie Unit-Tests zu jedem Microservice hinzufügen, was die Möglichkeit bietet, Probleme oder Fehler in Ihrem System leicht zu erkennen, bevor sie in die Produktion gelangen. In diesem Fall müssen Sie nicht die gesamte Anwendung überprüfen, sondern nur einen kleinen Teil des Codes debuggen – den aktuellen Microservice.

Eine erfolgreich erstellte voll funktionsfähige Microservices-Anwendung und die Bereitstellung auf einer spezifischen Plattform zur Verwaltung von Microservices bedeutet, dass Sie einige Vorteile haben werden, wie Kosteneffizienz, Skalierbarkeit und 24/7-Verfügbarkeit. Die Aufrechterhaltung der Gesundheit der Microservices kann erreicht werden, indem Instanzen auf gesunde VMs oder Server durch die Plattform verschoben werden. Wenn also die Software oder Hardware, auf der sie laufen, ausfällt oder für Upgrades neu gestartet werden muss, verschiebt das System sie automatisch an einen sicheren Ort, an dem diese Microservices erfolgreich weiterarbeiten können. Übrigens können Microservices auf die gleiche Weise skaliert werden, indem der Dienst einfach auf eine neue virtuelle Maschine kopiert und eine weitere Instanz gestartet wird.

Plattformen, die zur Bereitstellung und Verwaltung Ihrer Microservices verwendet werden können:

• Kubernetes
• Mesosphere DCOS
• Docker Swarm und Docker Compose
• OpenShift
• Pivotal Cloud Foundry
• Service Fabric

Alle diese Plattformen können erfolgreich verwendet werden, um Ihre Anwendung auf der Azure-Infrastruktur ohne Probleme oder spezielle Workarounds auszuführen. Einfaches Verwalten, Skalieren, Bereitstellen und Entwickeln von Microservices ist keine Revolution in der Anwendungsentwicklung?

Probleme und Lösungen für verteiltes Datenmanagement

1. Wie man die Grenzen jedes Microservices definiert

Das erste Problem, das Sie bei der Erstellung einer Microservices-Architektur begegnen, besteht darin, die Grenzen der Microservices zu definieren. Jeder Dienst sollte autonom sein und dennoch ein Teil des gesamten Systems bleiben. Sie sollten alle Vorteile der Microservices-Infrastruktur beibehalten können.

Sie müssen sich auf die logischen Domänenmodelle und die zugehörigen Daten konzentrieren. Versuchen Sie, die entkoppelten Dateninseln und verschiedene Kontexte innerhalb derselben Anwendung zu identifizieren. Diese Kontexte sollten separat verwaltet und definiert werden.

2. Wie man Abfragen erstellt, die Daten aus mehreren Microservices abrufen

Das Problem besteht darin, dass Sie direkte Client-Referenzierungen zu verschiedenen Diensten vermeiden möchten. Besonders dann, wenn die Client-Anwendung verschiedene Microservices-APIs aufrufen muss, um eine Aufgabe auszuführen. Zum Beispiel, wenn Sie eine Benutzerrolle (Security-Service) und die Bestellhistorie (Orders-Service) abrufen müssen. Mehrere Anfragen zu senden, um eine Aktion auszuführen, kann eine wirklich schlechte Lösung sein.

Die beliebtesten Methoden, um dieses Problem zu vermeiden, sind:

• Erstellen eines API-Gateways, um alle Client-Anfragen zu empfangen und die Anfragen an andere Dienste zu verteilen. Selbst wenn einer Ihrer Microservices Daten von einem anderen Microservice abrufen muss, können Sie eine Anfrage an den Gateway-Microservice senden. Diese Anfrage wird an den richtigen Empfänger weitergeleitet.
• CQRS mit Abfrage/Lese-Tabellen. Diese Lösung besteht darin, Daten aus mehreren Microservices mithilfe des Materialized View-Musters zu aggregieren. In diesem Fall erstellen Sie einfach eine schreibgeschützte Tabelle mit den Daten, die von verschiedenen Microservices verwaltet werden. Diese Tabelle hat ein Format, das vom Client empfangen werden sollte.

3. Wie man die Kommunikation über Microservice-Grenzen hinweg gestaltet

Ein weiteres Problem, das Sie lösen müssen, ist die Kommunikation. Ein beliebter Ansatz ist die Verwendung von HTTP-basierten Microservices, was vollkommen akzeptabel ist. Es ist eine gute Idee, diese Lösung zur Interaktion mit dem API-Gateway oder verschiedenen Microservices zu verwenden. Es besteht jedoch ein Risiko, da Sie eine übermäßig lange Kette von HTTP-Aufrufen erstellen können, die Ihre Microservices-basierte Anwendung in etwas Monolithisches verwandeln und alle Ihre Vorteile verlieren können.

Warum API-Gateways besser sind als direkte Kommunikation mit Microservices

Bei der Entwicklung einer Anwendung können Sie nichts vorhersehen. Sie sollten eine Architektur aufbauen, die leicht skaliert, verbessert oder geändert werden kann. Wenn Sie direkte Anfragen von Clients an Ihre Microservices haben, kann jede Aktualisierung Ihrer Microservice-Antwort Fehler verursachen. Clients müssten aktualisiert werden, um verschiedene Endpunkte zu verwenden oder Antworten in verschiedenen Formaten zu empfangen. Wenn Sie ein API-Gateway verwenden, werden Änderungen an den Microservices Ihre Clients in keiner Weise beeinflussen. Sie müssen lediglich die Gateway-Einstellungen ändern, um neue Endpunkte zu verwenden oder eine neue Antwort zu erhalten. Oder sogar die neuen Antworten in das Format ändern, das die Clients zuvor verwendet haben.

Schließlich können bei der direkten Kommunikation folgende Probleme auftreten:

• Kopplung. Die Client-Anwendungen müssen wissen, wo und wie sie die benötigten Daten abrufen können. Sie müssen direkte Links zu den Diensten haben, die die notwendigen Informationen bereitstellen können.
• Zu viele Rundreisen. Wenn Sie verschiedene Microservices aufrufen müssen, um eine Aktion auszuführen, können mehrere Netzwerk-Rundreisen und erhebliche Latenzen auftreten. Dies kann zu Leistungsproblemen führen.
• Sicherheitsprobleme. Bei direkter Kommunikation müssen Sie Ihre Microservices der Welt öffnen, um den Clients die Möglichkeit zu geben, Ihre Anwendung zu nutzen. Bei Verwendung eines API-Gateways können Sie Ihre Microservices nur vom Gateway-Microservice aus erreichbar machen. Dies ist eine sicherere Methode.
• Querschnittliche Anliegen. Jeder Ihrer Microservices, der direkte Kommunikation mit einem Client hat, muss eine Logik zur Überprüfung der Autorisierung, der Benutzerrollen und Berechtigungen usw. haben. Dies kann zu Leistungsproblemen führen. Bei Verwendung eines Gateways sollte diese Berechtigungsprüfung nur im Gateway-Microservice stattfinden.

Zusammenfassung

Die Auswahl der richtigen Architektur für eine Anwendung ist eine der wertvollsten Entscheidungen, um qualitativ hochwertige, leistungsstarke und optimierte Lösungen zu erstellen. Es gibt viele Risikofaktoren, die Sie berücksichtigen müssen.

Die Lösung hängt von der Größe Ihrer Anwendung ab. Die monolithische Anwendungsarchitektur kann eine gute Idee für kleine und leichte Anwendungen sein. Sie ist jedoch nicht ideal für komplexe oder sich entwickelnde Anwendungen. Es ist viel einfacher, eine monolithische Architektur zu Beginn der Anwendungsentwicklung zu erstellen. Aber in Zukunft, bei Erweiterung der Funktionalität und Fortsetzung der Entwicklung, werden Sie mehr Probleme haben und mehr Geld ausgeben. Wenn Sie Ihre Anwendung skalieren müssen, sollten Sie im Falle einer monolithischen Architektur die gesamte große Instanz Ihrer App skalieren. Bei einer Microservices-basierten Architektur können Sie nur einige wenige Microservices skalieren und Kosten sparen.

Also was bevorzugen, Microservices oder Monolithisch? Die Antwort ist ganz einfach – wenn Sie eine kleine oder leichte Anwendung haben, können Sie die monolithische Architektur verwenden, um Ihr System wirklich schnell aufzubauen. Aber wenn Sie etwas Großes schaffen wollen, sollten Sie die Microservices-basierte Architektur bevorzugen.