Hallo, Habr. Derzeit ist bei OTUS eine neue Gruppe für den Kurs eröffnet. Im Vorfeld des Kursstarts möchte ich mit Ihnen meinen Artikel teilen.
Einführung
Die Wahl des Architektur-Stils ist eine der grundlegenden technischen Entscheidungen beim Aufbau eines Informationssystems. In dieser Artikelreihe möchte ich die beliebtesten Architektur-Stile für Anwendungen untersuchen und die Frage beantworten, wann welcher Architektur-Stil am vorteilhaftesten ist. Während der Darstellung werde ich versuchen, eine logische Kette zu entwickeln, die die Evolution der Architektur-Stile von Monolithen zu Mikroservices erklärt.
Ein wenig Geschichte
Wenn Sie die Entwickler fragen: „Warum sind Mikrodienste notwendig?“, werden Sie die unterschiedlichsten Antworten erhalten. Sie werden hören, dass Mikrodienste die Skalierbarkeit verbessern, das Verständnis des Codes erleichtern, die Fehlertoleranz erhöhen, und manchmal wird sogar gesagt, dass sie den Code „reinigen“ können. Lassen Sie uns zur Geschichte zurückkehren, um zu verstehen, welches Ziel mit dem Auftauchen von Mikrodiensten verfolgt wurde.
Kurz gesagt, unser heutiges Verständnis von Mikrodiensten ist wie folgt entstanden: 2011 bemerkte James Lewis, dass viele Unternehmen ein neues Muster namens „Micro-App“ entwickelten, das SOA hinsichtlich der Bereitstellungsgeschwindigkeit von Diensten optimierte. Später, im Jahr 2012, wurde das Muster beim Architekturgipfel in Mikrodienst umbenannt. Damit war das ursprüngliche Ziel der Einführung von Mikrodiensten die Verbesserung des berühmten time to market.
Der Hype um Mikrodienste begann im Jahr 2015. Laut einigen Studien ließ sich keine Konferenz finden, die ohne einen Vortrag über Mikrodienste auskam. Darüber hinaus waren einige Konferenzen ausschließlich den Mikrodiensten gewidmet. Heute beginnen viele Projekte mit diesem Architekturstil, und wenn ein Projekt große Mengen an Legacy-Code enthält, erfolgt mit Sicherheit eine aktive Migration zu Mikrodiensten.
Trotz all dem gibt es bisher nur relativ wenige Entwickler, die den Begriff "Mikrodienst" definieren können. Aber darüber werden wir später sprechen...
Monolith
Der Architekturstil, der dem Mikrodienst-Stil gegenübergestellt wird, ist der Monolith (oder "alles in einem"). Es ist wahrscheinlich unnötig, zu erklären, was ein Monolith ist, daher werde ich gleich die Nachteile dieses Architekturstils aufzählen, die die weitere Entwicklung von Architekturstilen angestoßen haben: Größe, Kopplung, Bereitstellung, Skalierbarkeit, Zuverlässigkeit und Trägheit. Unten schlage ich vor, sich mit jedem der Nachteile einzeln vertraut zu machen.
Größe
Ein Monolith ist sehr umfangreich und kommuniziert in der Regel mit einer sehr großen Datenbank. Die Anwendung wird so umfangreich, dass sie prinzipiell von einem einzelnen Entwickler kaum zu verstehen ist. Nur diejenigen, die viel Zeit mit diesem Code verbracht haben, können gut mit einem Monolithen arbeiten, während Neulinge viel Zeit damit verbringen werden, den Monolithen zu verstehen, ohne dass sicher ist, ob sie es schaffen. Normalerweise gibt es beim Arbeiten mit einem Monolithen immer einen „quasi Senior“, der den Monolithen mehr oder weniger gut kennt und Neulinge über ein bis eineinhalb Jahre hinweg korrigiert. Es ist natürlich, dass dieser quasi Senior ein einzelner kritischer Punkt ist, und sein Weggang kann zum Untergang des Monolithen führen.
Kopplung
Ein Monolith stellt einen „großen Klumpen Schlamm“ (big ball of mud) dar, Änderungen in einem Bereich können unvorhersehbare Konsequenzen haben. Wenn man an einer Stelle Änderungen vornimmt, kann man an einer anderen Stelle den Monolithen beschädigen (das typische „habe mir das Ohr gekratzt, und *@ ist abgebrochen“). Dies liegt daran, dass die Komponenten im Monolithen sehr komplexe und vor allem undurchsichtige Beziehungen zueinander haben.
Deployment
Das Deployment eines Monolithen ist aufgrund der komplexen Wechselwirkungen zwischen seinen Komponenten ein langwieriger Prozess mit einem bestimmten Ritus. Dieser Ritus ist oft nicht endgültig standardisiert und wird "von Mund zu Mund" weitergegeben.
Skalierbarkeit
Die Module des Monolithen können konfliktierende Ressourcenbedürfnisse haben, was es notwendig macht, einen Kompromiss in Bezug auf die Hardware zu finden. Stellen Sie sich vor, Ihr Monolith besteht aus den Services A und B. Service A ist anspruchsvoll in Bezug auf die Festplattengröße, während Service B mehr RAM benötigt. In diesem Fall muss entweder der Server, auf dem der Monolith installiert wird, die Anforderungen beider Services erfüllen, oder man muss manuell einen der Services deaktivieren.
Ein weiteres Beispiel (klassischer): Service A ist viel beliebter als Service B, daher möchten Sie 100 Exemplare von Service A und nur 10 von Service B bereitstellen. Wieder gibt es zwei Optionen: entweder installieren wir 100 vollwertige Monolithen oder müssen bei einigen von ihnen manuell die Services B deaktivieren.
Zuverlässigkeit
Da alle Dienste zusammengefasst sind, fallen alle Dienste gleichzeitig aus, wenn das Monolith fehlschlägt. Tatsächlich ist das vielleicht nicht so schlimm, denn es wird zumindest keine Teilausfälle in einem verteilten System geben. Andererseits könnten Sie jedoch aufgrund eines Fehlers in einer Funktionalität, die nur 0,001 % der Nutzer verwenden, alle Nutzer Ihres Systems verlieren.
Trägheit
Aufgrund der Größe des Monolithen ist es schwierig, auf neue Technologien umzusteigen. Infolgedessen wird die Beibehaltung des so genannten Senior-Entwicklers zu einer eigenen Herausforderung. Der zu Beginn des Projekts gewählte Technologiestack kann zu einem Block werden, der die Entwicklung des Produkts behindert.
Fazit
Beim nächsten Mal werden wir darüber sprechen, wie Menschen versucht haben, die genannten Probleme zu lösen, indem sie zu Komponenten und SOA übergegangen sind.
Weiterlesen:
Quelle: habr.com
