Was sind die wichtigen Überlegungen beim Wechsel von der monolithischen zur Microservices-Architektur in .NET? [geschlossen]

Wir denken darüber nach, unsere monolithischen Monster schrittweise in auf Mikrodiensten basierende Architektur zu zerlegen. Wir haben 5 Teams, jedes Team besteht aus 2-3 C # -Entwicklern, mindestens 1 Datenbankentwickler und 2 QS-Ingenieuren. Neben dem enormen Kultur- und Paradigmenwechsel von einer monolithischen Architektur zu Microservices gibt es auch technische Herausforderungen. Ich möchte die Community um Weisheit und Rat bitten, damit wir nicht dieselben Fehler machen.

Gibt es gute Branchenbeispiele, bei denen .NET-basierte Mikrodienste erfolgreich in einem Produktionssystem eingesetzt wurden? Was war die Strategie für Folgendes?

• Org : Wie haben Sie die .NET-Lösungen / -Projekte organisiert?
• Entwicklungsplanung : Wie haben Sie die Arbeit in Bezug auf die Entwicklungsplanung auf Teams aufgeteilt? Was war die Gesamtstrategie, um sicherzustellen, dass die Einhaltung von Verträgen über Microservices hinweg zwischen Teams ausgehandelt wurde?
• Lastausgleich / Routing / API-Gateway : Welche Strategie wurde für Lastausgleich, Redundanz und Skalierung verfolgt? Haben Sie sich gerade für eine vollständige asynchrone Architektur entschieden und eine Warteschlange für die Microservice-Kommunikation verwendet, oder haben Sie Peer-to-Peer über ein Load Balancer / API-Gateway durchgeführt? Und warum?
• Testautomatisierung : Wie haben Sie mit der Testautomatisierung umgegangen? Dies zusammen mit der kontinuierlichen Integration scheint für die Microservices-Architektur absolut notwendig zu sein. Wie bist du vorgegangen?
• Bereitstellung : Wie stellen Sie bereit? Eine VM / Microservice oder ein Container / Microservice oder etwas ganz anderes? Wie haben Sie mit der Tatsache umgegangen, dass Sie jetzt über zehn Datenbanken verfügen, wenn nicht mehr, wenn man bedenkt, dass jeder Microservice seinen Datenspeicher haben würde, was hat das mit Ihrer Infrastruktur gemacht und wie haben Ihre Datenbankadministratoren damit umgegangen?
• Infrastruktur : Wie wurde Ihre Infrastruktur mit dieser Architektur skaliert? War es super gesprächig und du musstest es fein abstimmen oder hat das Netzwerk es ohne Probleme gehandhabt? Sind selbst gehostet oder in der Cloud?
• Überwachung : Was ist Ihre Überwachungsstrategie? Wie behalten Sie zehn, wenn nicht Hunderte von Mikrodiensten im Auge? Ist es hauptsächlich durch Protokollierung und zentrale Überwachung?

Ich habe an einer Reihe von Microservice-Projekten gearbeitet. Unweigerlich haben Unternehmen den Weg eingeschlagen, weil ihr großer DB-Ansatz nicht weiter skaliert werden kann. Hier sind meine Erfahrungen / Empfehlungen.

Org. Eine Lösung pro Microservice. Nuget-Pakete für gemeinsam genutzte Bibliotheken

Entwicklung. Größere Teams 5-6 entwickeln jeweils einen Funktionsbereich. Refactor in einen Schnittstellendienst. Ersetzen Sie den In-Memory-Dienst durch einen Client für den Microservice.

Testen. Integrationstests unter Verwendung realer Eingabe- / Ausgabedaten. Sie möchten in der Lage sein, sie gegen jede laufende Instanz auszulösen, um zu überprüfen, ob sie aktiv und korrekt sind, lokale Instanzen, Test- / Uat-Umgebungen und Speicherinstanzen für Komponententests. Stellen Sie sicher, dass Sie die Version der Instanz über eine Healthcheck-Oberfläche oder ähnliches testen können

Skalierung. Warteschlangenbasiert ist am besten geeignet, da mehrstufige verteilte Prozesse verarbeitet werden können. Rabbit MQ, Zero MQ, MSMQ usw. REST-Services mit Lastenausgleich eignen sich jedoch gut für Anrufe im RPC-Stil und können ein einfacher Ausgangspunkt sein.

Einsatz. Tintenfisch. db projekte, selbst erstellen no-sql.dbs wie mongo. Obwohl ich denke, dass Sie den falschen Weg gehen, wenn Sie mehrere dbs haben. Verwenden Sie stattdessen umfangreiche Nachrichten, die die Daten enthalten, die Sie für den Prozess benötigen, und einige größere Datenbanken für die Datenspeicherung, die hinter ihren eigenen APIs versteckt sind.

Keine Datenbankadministratoren! Wenn Sie einen DBA haben, der SQL schreibt, machen Sie es falsch.

Infrastruktur. Keine Probleme. Aus einer Warteschlange lesen. Prozess machen. In eine Warteschlange schreiben. Sie können mit mehr als einer Instanz pro Box davonkommen, selbst auf Cloud-Mikroinstanzen für kleine oder selten aufgerufene Dienste

Überwachung. Health-Check-Schnittstellen für alle Dienste, die regelmäßig von Überwachungssoftware und auf der großen Tafel aufgerufen werden.

Das automatische Failover und die automatische Wiederherstellung sind wichtig. Instanzen sollten bei Bedarf hochgefahren und zustandslos sein, damit ein Absturz den Dienst nicht offline hält.

Das Hauptproblem besteht darin, dass nicht so viele Dienste ausfallen, sondern dass Mikrodienste sie in dieser Hinsicht robust machen. So gehen Sie mit Nachrichten um, die nicht verarbeitet werden können / wurden.

Verwenden Sie logstash oder ähnliches, um den Nachrichtenfluss zu verfolgen und herauszufinden, wo und was die Probleme sind. Stellen Sie sicher, dass Sie fehlgeschlagene Nachrichten erneut ausführen können, damit ein fester Prozess dort fortgesetzt werden kann, wo er aufgehört hat.

Schlussbemerkung. Version alles, DLLs, Nugets, Daten, Schnittstellen. Wenn mehrere Instanzen mehrerer Dienste und historische Nachrichten im Umlauf sind, kann dies eine Hauptursache für Probleme sein.

In den letzten 2 Jahren haben wir einen Monolithen in Microservices aufgeteilt. Hier sind einige der Dinge, die wir tun

Organisation : Jeder Dienst ist eine Lösung für sich, keine gemeinsamen Projekte mit einem anderen Dienst. Am Ende waren die Verträge eine separate Lösung für sich, bei der jede Version ein .nuget-Paket ist.

Entwicklung : Jedes Team arbeitete an einem Teil der Anwendung. Für jeden neuen Dienst haben wir mit der Vertragserstellung begonnen und dann den Dienst getrennt, aber ihn weiterhin als Teil der Hauptanwendung / -lösung beibehalten (also noch keine HTTP-Aufrufe). Und in einem zukünftigen Schritt würden wir diesen Service völlig auseinander nehmen.

Routing : Alle unsere Services befinden sich hinter einem Load Balancer und jeder Service wird auf einigen VMs bereitgestellt. Wir teilen die gleiche VM für mehrere Dienste. Die Verwendung einer VM pro Dienst schien mir eine Verschwendung von Ressourcen zu sein, da die Dienste klein sind, während eine Windows-VM etwa 2 GB benötigt, um einwandfrei zu funktionieren. Einige Dienste, die nicht mit der Benutzerinteraktion zusammenhängen (z. B. das Senden von E-Mails / Benachrichtigungen), arbeiten mit Warteschlangen.

Testen : Anfangs dachten wir, dass das Testen des Dienstes und das Testen der Vertragskompatibilität zwischen verschiedenen Versionen der Clients und des Dienstes mit Pact.Net ausreichen würde. Wir hatten jedoch Probleme, als keine neue Version eines Dienstes bereitgestellt wurde und wir mit der vorherigen gearbeitet haben. Alle Tests bestanden, aber die gesamte Plattform funktionierte nicht einwandfrei. Deshalb haben wir einige hochrangige (Integrations-) Tests für die Hauptflüsse hinzugefügt.

Bereitstellung : Die gesamte Plattform ist auf einigen VMs installiert. Wir verwenden eine Kombination aus TFS für die Erstellung, AWS S3 für Artefakte und Ansible für die Erstellung, Bereitstellung und Konfiguration von VMs. Ansible spielt hier eine große Rolle, ist agentenlos und verwendet Powershell-Remoting für die Verbindung mit Windows. Wir haben die XML-Transformation von web.config eingestellt und sind zu Ansible-Vorlagen gewechselt, damit wir alle Konfigurationen in Ansible-Dateien haben können. Und das Gute daran ist, dass es im Vergleich zu Octopus kostenlos und Open Source ist. Für neue Versionen werden völlig neue VMs verwendet. Wir aktualisieren Dienste nur, wenn wir Fixes bereitstellen müssen.

Skalierung : Bei einer solchen Bereitstellung können Sie nur die VMs und nicht den Dienst selbst skalieren. Überwachen Sie also Ihre Leistung (CPU, RAM), die Anzahl der Anfragen, die Sie erhalten, oder sogar zeitbasiert (wie am Wochenende gibt es weniger Verkehr), wenn Sie neue VMs starten und stoppen

Überwachung : Wir sind in AWS und haben CloudWatch für Zeitreihenwarnungen, aber wir planen, zu Grafana und Prometheus zu gehen (ein Schritt näher für Docker, jetzt mit Server 2016). Bei der Protokollierung verwenden wir Graylog (das ElastiSearch dahinter verwendet). Es war leicht , es zu übernehmen, denn wir verwenden wurden Log4Net mit Datei Appender vor und es gibt eine appender besonders für Graylog. Sie können viele Warnungen darauf aufbauen. Wir haben festgestellt, dass es sich tatsächlich um einen kontinuierlichen Prozess handelt.