Einführung
Die Wahl eines Architekturstils ist eine der grundlegenden technischen Lösungen beim Aufbau eines Informationssystems. In dieser Artikelserie schlage ich vor, die beliebtesten Architekturstile für Gebäudeanwendungen zu analysieren und die Frage zu beantworten, wann der Architekturstil am meisten bevorzugt wird. Dabei werde ich versuchen, eine logische Kette zu zeichnen, die die Entwicklung von Architekturstilen von Monolithen bis zu Mikrodiensten erklärt.
Ein bisschen Geschichte
Wenn Sie versuchen, Entwicklern eine Frage zu stellen: „Warum brauchen wir Microservices?“, Erhalten Sie verschiedene Antworten. Sie werden hören, dass Microservices die Skalierung verbessern, Ihren Code verständlicher machen, die Fehlertoleranz verbessern und manchmal hören, dass Sie damit den Code "bereinigen" können. Kehren wir zur Geschichte zurück, um zu verstehen, was der Zweck der Entstehung von Mikrodiensten war.
Kurz gesagt, Microservices haben sich nach unserem derzeitigen Verständnis wie folgt entwickelt: Im Jahr 2011 machte James Lewis bei der Analyse der Arbeit verschiedener Unternehmen auf die Entstehung eines neuen Musters "Mikro-App" aufmerksam, das die SOA im Hinblick auf die Beschleunigung der Servicebereitstellung optimierte. Wenig später, 2012, auf dem Architekturgipfel, wurde das Muster in Microservice umbenannt. Das ursprüngliche Ziel der Einführung von Microservices war daher die Verkürzung der berüchtigten Markteinführungszeit .
Microservices waren 2015 auf der "Hype-Welle". Nach einigen Studien war keine Konferenz ohne einen Vortrag zum Thema Microservices abgeschlossen. Darüber hinaus waren einige Konferenzen ausschließlich Microservices gewidmet. Heutzutage verwenden viele Projekte diesen Architekturstil. Wenn das Projekt Tonnen von Legacy-Code enthält, wird höchstwahrscheinlich die Migration zu Microservices aktiv durchgeführt.
Trotz alledem gibt es immer noch einige Entwickler, die das Konzept des "Microservice" definieren können. Aber wir werden etwas später darüber sprechen ...
Monolith
Der architektonische Stil im Vergleich zum Mikroservice ist Monolith (oder All-in-One). Es ist wahrscheinlich nicht sinnvoll zu sagen, was ein Monolith ist, daher werde ich sofort die Mängel dieses Architekturstils auflisten, die die Weiterentwicklung der Architekturstile eingeleitet haben: Größe, Kohärenz, Bereitstellung, Skalierbarkeit, Zuverlässigkeit und Trägheit. Im Folgenden schlage ich vor, jeden der Nachteile einzeln kennenzulernen.
Die Größe
Der Monolith ist sehr groß. Und er kommuniziert normalerweise mit einer sehr großen Datenbank. Die Anwendung wird zu groß, als dass ein Entwickler sie überhaupt verstehen könnte. Nur diejenigen, die viel Zeit hinter diesem Code verbracht haben, können gut mit einem Monolithen arbeiten, während Anfänger viel Zeit damit verbringen werden, den Monolithen herauszufinden und nicht die Tatsache, dass sie es herausfinden werden. Normalerweise gibt es bei der Arbeit mit einem Monolithen immer einen „bedingten“ Senior, der den Monolithen mehr oder weniger gut kennt und andere neue Entwickler anderthalb Jahre lang schlägt. Natürlich ist ein solcher bedingter Senior ein einziger Fehlerpunkt, und sein Abgang kann zum Tod des Monolithen führen.
Verbundenheit
Ein Monolith ist ein "großer Schlammball", dessen Veränderungen zu unvorhersehbaren Folgen führen können. Wenn Sie an einer Stelle Änderungen vornehmen, können Sie den Monolithen an einer anderen Stelle beschädigen (genau das gleiche "kratzte mein Ohr, * @ fiel ab"). Dies liegt an der Tatsache, dass die Komponenten im Monolithen sehr komplexe und vor allem nicht offensichtliche Beziehungen aufweisen.
Einsatz
Der Einsatz eines Monolithen ist aufgrund der komplexen Beziehungen zwischen seinen Komponenten ein langer Prozess mit einem eigenen Ritual. Dieses Ritual ist normalerweise nicht vollständig standardisiert und wird "mündlich" weitergegeben.
Skalierbarkeit
Monolith-Module können widersprüchliche Ressourcenanforderungen haben, was einen Kompromiss in Bezug auf die Hardware erforderlich macht. Stellen Sie sich vor, Ihr Monolith besteht aus den Diensten A und B. Dienst A stellt hohe Anforderungen an die Festplattengröße, während Dienst B den Arbeitsspeicher beansprucht. In diesem Fall muss entweder der Computer, auf dem der Monolith installiert ist, die Anforderungen beider Dienste erfüllen, oder Sie müssen einen der Dienste manuell von Hand deaktivieren.
Ein weiteres Beispiel (klassischer): Dienst A ist viel beliebter als Dienst B, daher möchten Sie, dass Dienste A 100 und Dienste B 10 sind. Auch hier gibt es zwei Möglichkeiten: entweder 100 vollwertige Monolithen bereitstellen oder einige dann müssen Dienste B von Hand deaktiviert werden.
Verlässlichkeit
Da alle Dienste zusammen sind, fallen alle Dienste auf einmal, wenn der Monolith fällt. In der Tat ist dies vielleicht nicht so schlimm, zumindest gibt es keine teilweisen Fehler in einem verteilten System, aber andererseits können Sie aufgrund eines Fehlers in der Funktionalität, die 0,001% der Benutzer verwenden, alle Benutzer Ihres Systems verlieren.
Trägheit
Aufgrund der Größe des Monolithen ist es schwierig, auf neue Technologien umzusteigen. Infolgedessen ist die Beibehaltung dieses bedingten Senioren eine separate Aufgabe. Der zu Beginn des Projekts gewählte technologische Stapel kann zu einem Block werden, der die Entwicklung des Produkts behindert.
Fazit
Das nächste Mal werden wir darüber sprechen, wie Menschen versucht haben, diese Probleme zu lösen, indem sie zu Komponenten und SOA übergegangen sind.
Weiterlesen: