Hallo, Habr. Momentan ist die Anmeldung fĂŒr einen neuen Kurs bei OTUS offen. Vor dem Start des Kurses möchte ich mit Ihnen meinen eigenen Artikel teilen.
EinfĂŒhrung
Die Wahl des Architekturstils ist eine der grundlegenden technischen Entscheidungen beim Aufbau eines Informationssystems. In dieser Artikelreihe möchte ich die beliebtesten Architekturstile fĂŒr die Entwicklung von Anwendungen untersuchen und die Frage beantworten, wann welcher Architekturstil am bevorzugt wird. Im Laufe der ErlĂ€uterungen werde ich versuchen, eine logische Kette zu ziehen, die die Entwicklung der Architekturstile von Monolithen zu Microservices 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 CodeverstĂ€ndnis erleichtern, die Ausfallsicherheit erhöhen und manchmal auch, dass sie âden Code bereinigenâ. Lassen Sie uns einen RĂŒckblick auf die Geschichte werfen, um zu verstehen, welches Ziel mit der EinfĂŒhrung von Mikrodiensten verfolgt wurde.
Kurz gesagt, in unserem aktuellen VerstĂ€ndnis entstanden Mikrodienste folgendermaĂen: 2011 beobachtete James Lewis bei der Analyse der Arbeiten verschiedener Unternehmen das Auftauchen eines neuen Musters âmicro-appâ, welches SOA hinsichtlich der Beschleunigung der Bereitstellung von Diensten optimierte. Einige Zeit spĂ€ter, im Jahr 2012, wurde das Muster auf einem Architektur-Gipfel in Mikrodienst umbenannt. Damit war das ursprĂŒngliche Ziel der EinfĂŒhrung von Mikrodiensten die Verbesserung des berĂŒchtigten time to market.
Auf der âHype-Welleâ waren Mikrodienste im Jahr 2015. Laut einigen Studien fand auf keiner Konferenz ein Vortrag ĂŒber Mikrodienste statt. DarĂŒber hinaus waren einige Konferenzen ausschlieĂlich Mikrodiensten gewidmet. Heute beginnen viele Projekte mit der Anwendung dieses architektonischen Stils, und wenn ein Projekt tonnenweise Legacy-Code enthĂ€lt, wird definitiv aktiv an einer Migration zu Mikrodiensten gearbeitet.
Trotz alledem sind noch immer relativ wenige Entwickler in der Lage, das Konzept âMikrodienstâ zu definieren. Aber darĂŒber werden wir spĂ€ter sprechen...
Monolith
Der architektonische Stil, der dem Mikrodienst gegenĂŒbersteht, ist der Monolith (oder âalles in einemâ). Es macht wahrscheinlich keinen Sinn, zu erklĂ€ren, was ein Monolith ist, deshalb werde ich sofort die Nachteile dieses architektonischen Stils auflisten, die die weitere Entwicklung architektonischer Stile initiiert haben: GröĂe, Kopplung, Bereitstellung, Skalierbarkeit, ZuverlĂ€ssigkeit und TrĂ€gheit. Im Folgenden lade ich Sie ein, sich mit jedem der Nachteile einzeln vertraut zu machen.
GröĂe
Der Monolith ist sehr groĂ. Er kommuniziert normalerweise mit einer sehr groĂen Datenbank. Die Anwendung wird so groĂ, dass sie von einem einzelnen Entwickler im Prinzip nicht mehr verstanden werden kann. Nur diejenigen, die viel Zeit mit diesem Code verbracht haben, können gut mit dem Monolithen arbeiten, wĂ€hrend Neueinsteiger viel Zeit mit dem Versuch verbringen, den Monolithen zu verstehen, ohne sicher zu sein, dass sie es letztendlich schaffen. In der Regel gibt es beim Arbeiten mit dem Monolithen immer einen gewissen "bedingten" Senior, der den Monolithen mehr oder weniger gut kennt und andere neue Entwickler im Laufe eines Jahres bis eineinhalb Jahre in Schach hĂ€lt. NatĂŒrlich ist ein solcher bedingter Senior ein einzelner Ausfallpunkt, und sein Weggang kann den Monolithen zum Scheitern bringen.
Kopplung
Der Monolith stellt eine "groĂe Schlammschicht" (big ball of mud) dar, deren Ănderungen zu unvorhersehbaren Folgen fĂŒhren können. Wenn man an einem Ort Ănderungen vornimmt, kann der Monolith an einem anderen beschĂ€digt werden (das bekannte "ich habe das Ohr gekratzt, und das Ganze ist abgerissen"). Dies liegt daran, dass die Komponenten im Monolithen sehr komplexe und vor allem nicht offenkundige Wechselbeziehungen haben.
Bereitstellung
Die Bereitstellung des Monolithen aufgrund der komplexen Wechselbeziehungen zwischen seinen Komponenten ist ein langwieriger Prozess mit seinem eigenen Ritus. Dieser Ritus ist normalerweise nicht vollstÀndig standardisiert und wird "von Mund zu Mund" weitergegeben.
Skalierbarkeit
Die Module des Monolithen können widersprĂŒchliche Anforderungen an Ressourcen haben, weshalb es notwendig ist, einen Kompromiss aus der Perspektive der Hardware zu finden. Stellen Sie sich vor, Ihr Monolith besteht aus den Diensten A und B. Dienst A hat hohe Anforderungen an die FestplattengröĂe, wĂ€hrend Dienst B hohe Anforderungen an den Arbeitsspeicher stellt. In diesem Fall muss entweder der Rechner, auf dem der Monolith installiert wird, die Anforderungen beider Dienste erfĂŒllen, oder man muss manuell einen der Dienste deaktivieren.
Ein weiteres Beispiel (klassischer): Dienst A ist viel beliebter als Dienst B, weshalb Sie möchten, dass es 100 Dienste A und 10 Dienste B gibt. Wiederum gibt es zwei Varianten: Entweder wir setzen 100 voll funktionsfĂ€hige Monolithen auf, oder wir mĂŒssen auf einigen von ihnen manuell die Dienste B deaktivieren.
ZuverlÀssigkeit
Da alle Dienste zusammengefasst sind, fallen mit dem Monolithen auch alle Dienste gleichzeitig aus. In Wirklichkeit ist das vielleicht gar nicht so schlimm; zumindest werden keine partiellen AusfĂ€lle im verteilten System auftreten. Auf der anderen Seite kann jedoch ein Fehler in der FunktionalitĂ€t, die 0,001 % der Benutzer nutzen, dazu fĂŒhren, dass Sie alle Benutzer Ihres Systems verlieren.
Starrheit
Aufgrund der GröĂe des Monolithen ist es schwierig, auf neue Technologien umzusteigen. Folglich ergibt sich die separate Aufgabe, den besagten hypothetischen Senior-Entwickler zu halten. Der zu Beginn des Projekts gewĂ€hlte Technologiestack kann sich als Block erweisen, der die Produktentwicklung behindert.
Fazit
Beim nĂ€chsten Mal werden wir darĂŒber sprechen, wie die Menschen versucht haben, die benannten Probleme zu lösen, indem sie auf Komponenten und SOA umgestiegen sind.
Weiterlesen:
Quelle: habr.com
