Hallo, Habr. Die Anmeldung für einen neuen Kurszweig ist ab sofort bei OTUS möglich . Am Vorabend des Kursbeginns möchte ich meinen Originalartikel mit Ihnen teilen.
Einführung
Die Wahl des Architekturstils ist eine der grundlegenden technischen Entscheidungen beim Aufbau eines Informationssystems. In dieser Artikelserie schlage ich vor, die beliebtesten Architekturstile für Bauanwendungen zu analysieren und die Frage zu beantworten, wann welcher Architekturstil am besten geeignet ist. Im Prozess der Präsentation werde ich versuchen, eine logische Kette zu zeichnen, die die Entwicklung von Architekturstilen von Monolithen zu Microservices erklärt.
Ein wenig Geschichte
Wenn Sie versuchen, Entwickler zu fragen: „Warum brauchen wir Microservices?“, erhalten Sie unterschiedliche Antworten. Sie werden hören, dass Microservices die Skalierbarkeit verbessern, den Code verständlicher machen und die Fehlertoleranz verbessern, und manchmal werden Sie hören, dass sie es Ihnen ermöglichen, „Ihren Code zu bereinigen“. Schauen wir uns die Geschichte an, um den Zweck hinter der Entstehung von Microservices zu verstehen.
Kurz gesagt, Microservices nach unserem aktuellen Verständnis sind wie folgt entstanden: Im Jahr 2011 machte James Lewis bei der Analyse der Arbeit verschiedener Unternehmen auf die Entstehung eines neuen „Micro-App“-Musters aufmerksam, das SOA im Hinblick auf die Beschleunigung der Bereitstellung von optimierte Dienstleistungen. Etwas später, im Jahr 2012, wurde das Muster auf einem Architekturgipfel in Microservice umbenannt. Daher bestand das ursprüngliche Ziel der Einführung von Microservices darin, das Berüchtigte zu verbessern Zeit bis zur Markt.
Microservices waren im Jahr 2015 auf der Hype-Welle. Einigen Studien zufolge kam keine einzige Konferenz ohne einen Bericht zum Thema Microservices zu Ende. Darüber hinaus waren einige Konferenzen ausschließlich Microservices gewidmet. Heutzutage verwenden viele Projekte diesen Architekturstil, und wenn das Projekt Unmengen von Legacy-Code enthält, wird die Migration zu Microservices wahrscheinlich aktiv durchgeführt.
Trotz alledem kann immer noch eine relativ kleine Anzahl von Entwicklern das Konzept des „Microservice“ definieren. Aber darüber reden wir etwas später...
Monolith
Der Architekturstil, der im Gegensatz zu Microservices steht, ist der Monolith (oder All-in-One). Es macht wahrscheinlich keinen Sinn zu sagen, was ein Monolith ist, deshalb liste ich gleich die Nachteile dieses Architekturstils auf, der die Weiterentwicklung von Architekturstilen initiierte: Größe, Konnektivität, Bereitstellung, Skalierbarkeit, Zuverlässigkeit und Steifigkeit. Im Folgenden schlage ich vor, jeden der Mängel einzeln zu betrachten.
Größe
Der Monolith ist sehr groß. Und es 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 mit der Arbeit an diesem Code verbracht haben, können gut mit dem Monolithen arbeiten, während Anfänger viel Zeit damit verbringen werden, den Monolithen herauszufinden, und es keine Garantie dafür gibt, 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 innerhalb von anderthalb Jahren die Hände anderer neuer Entwickler schlägt. Natürlich ist ein solcher bedingter Senior ein Single Point of Failure, und sein Weggang kann zum Tod des Monolithen führen.
Verbundenheit
Der 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 beschädigen (dasselbe „Sie haben sich am Ohr gekratzt, *@ ist abgefallen“). Dies liegt daran, dass die Komponenten im Monolithen sehr komplexe und vor allem nicht offensichtliche Zusammenhänge aufweisen.
Einsatz
Der Einsatz eines Monolithen ist aufgrund der komplexen Beziehungen zwischen seinen Komponenten ein langer Prozess mit einem eigenen Ritual. Ein solches Ritual ist meist nicht vollständig standardisiert und wird „mündlich“ weitergegeben.
Skalierbarkeit
Monolith-Module können widersprüchliche Ressourcenanforderungen haben, sodass Kompromisse bei der Hardware eingegangen werden müssen. Stellen Sie sich vor, Sie verfügen über einen Monolithen, der aus den Diensten A und B besteht. Dienst A stellt hohe Anforderungen an die Größe der Festplatte und Dienst B stellt hohe Anforderungen an den Arbeitsspeicher. In diesem Fall muss entweder die Maschine, auf der der Monolith installiert ist, die Anforderungen beider Dienste unterstützen, oder Sie müssen einen der Dienste manuell und künstlich deaktivieren.
Ein weiteres (klassischeres) Beispiel: Dienst A ist viel beliebter als Dienst B, daher möchten Sie, dass es 100 Dienste A und 10 Dienste B gibt. Wieder zwei Optionen: Entweder wir setzen 100 vollwertige Monolithen ein oder dann einige Dienste B müssen manuell deaktiviert werden.
Zuverlässigkeit
Da alle Dienste zusammen angeordnet sind, fallen alle Dienste gleichzeitig, wenn der Monolith fällt. Tatsächlich ist das vielleicht nicht so schlimm, zumindest wird es in einem verteilten System keine Teilausfälle geben, aber andererseits kann es aufgrund eines Fehlers in der Funktionalität, die von 0.001 % der Benutzer genutzt wird, dazu kommen, dass alle Benutzer verloren gehen Ihres Systems.
Trägheit
Aufgrund der Größe des Monolithen ist es schwierig, auf neue Technologien umzusteigen. Daher ist es eine separate Aufgabe, denselben Senior zu halten. Der zu Beginn eines Projekts gewählte Technologie-Stack kann zu einem Block werden, der die Entwicklung des Produkts behindert.
Abschluss
Das nächste Mal werden wir darüber sprechen, wie Menschen versucht haben, diese Probleme durch die Umstellung auf Komponenten und SOA zu lösen.
Weiterlesen:
Source: habr.com