Microservices vs Monolithic Architecture [geschlossen]

Ich habe etwas über Microservices gelesen und bin ein bisschen fasziniert. Scheint, als wäre es ein interessantes Konzept. Aber ich frage mich, welche Vor- und Nachteile die Verwendung von Mikrodiensten gegenüber der monolithischen Architektur hat und umgekehrt.

Wenn Microservices besser geeignet sind und wo es besser zur monolithischen Architektur passt.

Während ich in der Microservices-Welt noch relativ neu bin, werde ich versuchen, Ihre Frage so vollständig wie möglich zu beantworten.

Wenn Sie die Microservices-Architektur verwenden, haben Sie eine stärkere Entkopplung und Trennung von Bedenken. Da Sie Ihre Bewerbung buchstäblich aufteilen.

Dies führt dazu, dass Ihre Codebasis einfacher zu verwalten ist (jede Anwendung ist unabhängig von den anderen Anwendungen, um am Laufen zu bleiben). Deshalb , wenn Sie dieses Recht tun , wird es in Zukunft leichter an neue Funktionen hinzufügen , um Ihre Anwendung. Während es bei einer monolithischen Architektur sehr schwierig werden kann, wenn Ihre Anwendung groß ist (und Sie können davon ausgehen, dass dies zu einem bestimmten Zeitpunkt der Fall sein wird).

Das Bereitstellen der Anwendung ist auch einfacher , da Sie die unabhängigen Mikrodienste separat erstellen und auf separaten Servern bereitstellen. Dies bedeutet, dass Sie jederzeit Dienste erstellen und bereitstellen können, ohne den Rest Ihrer Anwendung neu erstellen zu müssen.

Da die verschiedenen Dienste klein sind und separat bereitgestellt werden, ist es offensichtlich einfacher, sie zu skalieren , mit dem Vorteil, dass Sie bestimmte Dienste Ihrer Anwendung skalieren können (mit einem Monolithic skalieren Sie das gesamte "Ding", selbst wenn es nur ein bestimmter Teil innerhalb der ist Anwendung, die eine übermäßige Belastung erhält).

Für Anwendungen, die nicht zu groß werden sollen, um in Zukunft verwaltet zu werden. Es ist besser, die monolithische Architektur beizubehalten. Da die Microservices-Architektur einige ernsthafte Schwierigkeiten aufweist. Ich erklärte, dass es einfacher ist, Microservices bereitzustellen, aber dies gilt nur im Vergleich zu großen Monolithen. Mit Microservices haben Sie die zusätzliche Komplexität, die Dienste auf verschiedene Server an verschiedenen Standorten zu verteilen, und Sie müssen einen Weg finden, um all dies zu verwalten. Das Erstellen von Microservices hilft Ihnen auf lange Sicht, wenn Ihre Anwendung groß wird. Bei kleineren Anwendungen ist es jedoch einfacher, monolithisch zu bleiben.

Dies ist eine sehr wichtige Frage, da einige Leute von der ganzen Aufregung um Microservices angezogen werden und es Kompromisse gibt, die berücksichtigt werden müssen. Was sind also die Vorteile und Herausforderungen von Microservices (im Vergleich zum monolithischen Modell)?

Leistungen

• Bereitstellbarkeit : Mehr Flexibilität bei der Einführung neuer Versionen eines Dienstes aufgrund kürzerer Build-, Test- und Bereitstellungszyklen. Flexibilität bei der Verwendung dienstspezifischer Sicherheits-, Replikations-, Persistenz- und Überwachungskonfigurationen.
• Zuverlässigkeit : Ein Microservice-Fehler betrifft nur diesen Microservice und seine Verbraucher, während im monolithischen Modell ein Service-Fehler den gesamten Monolithen zum Erliegen bringen kann.
• Verfügbarkeit : Die Einführung einer neuen Version eines Mikrodienstes erfordert nur geringe Ausfallzeiten, während die Einführung einer neuen Version eines Dienstes im Monolithen einen normalerweise langsameren Neustart des gesamten Monolithen erfordert.
• Skalierbarkeit : Jeder Microservice kann mithilfe von Pools, Clustern und Grids unabhängig skaliert werden. Aufgrund der Bereitstellungseigenschaften passt Microservices hervorragend zur Elastizität der Cloud.
• Änderbarkeit : Mehr Flexibilität bei der Verwendung neuer Frameworks, Bibliotheken, Datenquellen und anderer Ressourcen. Außerdem sind Microservices lose gekoppelte, modulare Komponenten, die nur über ihre Verträge zugänglich sind und daher weniger dazu neigen, sich in einen großen Schlammball zu verwandeln.
• Management : Die Anwendung Entwicklungsaufwand wird in Teams aufgeteilt , die unabhängig voneinander kleiner und Arbeit sind.
• Designautonomie : Das Team hat die Freiheit, unterschiedliche Technologien, Frameworks und Muster zum Entwerfen und Implementieren jedes Microservices einzusetzen und kann jeden Microservice unabhängig ändern und erneut bereitstellen

Herausforderungen

• Deployability : es weit mehr Einsatz - Einheiten sind, so gibt es mehr komplexe Aufträge, Skripte, Transferbereiche und Konfigurationsdateien für die Bereitstellung zu überwachen. (Aus diesem Grund sind kontinuierliche Lieferung und DevOps für Microservice-Projekte äußerst wünschenswert.)
• Leistung : Dienste müssen mit größerer Wahrscheinlichkeit über das Netzwerk kommunizieren, während Dienste innerhalb des Monolithen von Ortsgesprächen profitieren können. (Aus diesem Grund sollte das Design "gesprächige" Microservices vermeiden.)
• Änderbarkeit : Vertragsänderungen wirken sich eher auf Verbraucher aus, die an anderer Stelle eingesetzt werden, während sich Verbraucher im monolithischen Modell eher innerhalb des Monolithen befinden und im Gleichschritt mit dem Dienst eingeführt werden. Mechanismen zur Verbesserung der Autonomie, wie etwa eventuelle Konsistenz und asynchrone Aufrufe, erhöhen die Komplexität von Mikrodiensten.
• Testbarkeit : Integrationstests sind schwieriger einzurichten und auszuführen, da sie unterschiedliche Microservices in unterschiedlichen Laufzeitumgebungen umfassen können.
• Verwaltung : Der Aufwand für die Verwaltung von Vorgängen steigt, da mehr Laufzeitkomponenten, Protokolldateien und Punkt-zu-Punkt-Interaktionen überwacht werden müssen.
• Speichernutzung : In jedem Microservice-Bundle werden häufig mehrere Klassen und Bibliotheken repliziert, und der gesamte Speicherbedarf nimmt zu.
• Laufzeitautonomie : Im Monolithen ist die gesamte Geschäftslogik zusammengefasst. Bei Microservices ist die Logik auf Microservices verteilt. Wenn alles andere gleich ist, ist es wahrscheinlicher, dass ein Mikrodienst mit anderen Mikrodiensten über das Netzwerk interagiert - diese Interaktion verringert die Autonomie. Wenn die Interaktion zwischen Mikrodiensten das Ändern von Daten beinhaltet, beeinträchtigt die Notwendigkeit einer Transaktionsgrenze die Autonomie weiter. Die gute Nachricht ist, dass wir zur Vermeidung von Problemen mit der Laufzeitautonomie Techniken wie eventuelle Konsistenz, ereignisgesteuerte Architektur, CQRS, Cache (Datenreplikation) und das Ausrichten von Microservices an DDD-gebundenen Kontexten einsetzen können. Diese Techniken sind Microservices nicht eigen, wurden aber von praktisch jedem Autor vorgeschlagen, den ich gelesen habe.

Sobald wir diese Kompromisse verstanden haben , müssen wir noch eines wissen, um die andere Frage zu beantworten: Was ist besser, Microservices oder Monolith? Wir müssen die nicht funktionalen Anforderungen (Qualitätsattributanforderungen) der Anwendung kennen. Wenn Sie beispielsweise verstanden haben, wie wichtig Leistung und Skalierbarkeit sind, können Sie die Kompromisse abwägen und eine fundierte Entwurfsentscheidung treffen.

@ Luxo ist genau richtig. Ich möchte nur eine kleine Variation anbieten und die organisatorische Perspektive davon herbeiführen. Microservices ermöglichen nicht nur die Entkopplung der Anwendungen, sondern können auch auf organisatorischer Ebene hilfreich sein. Die Organisation könnte sich beispielsweise in mehrere Teams aufteilen, von denen jedes auf einer Reihe von Mikrodiensten entwickelt werden kann, die das Team möglicherweise bereitstellt.

In größeren Geschäften wie Amazon haben Sie beispielsweise möglicherweise ein Personalisierungsteam, ein E-Commerce-Team, ein Infrastrukturdienstteam usw. Wenn Sie in Microservices einsteigen möchten, ist Amazon ein sehr gutes Beispiel dafür. Jeff Bezos machte es zu einem Mandat für Teams, mit den Diensten eines anderen Teams zu kommunizieren, wenn sie Zugriff auf eine gemeinsam genutzte Funktionalität benötigen. Sehen Sie hier für eine kurze Beschreibung.

Darüber hinaus hatten Ingenieure von Etsy und Netflix zu Zeiten von Microservices gegen Monolith auf Twitter eine kleine Debatte. Die Debatte ist etwas weniger technisch, kann aber auch einige Einblicke bieten.