Alle reden jetzt über Microservices. Fast jedes Meeting, jede Konferenz und jedes Meeting ist nicht vollständig ohne eine Geschichte darüber, was Microservices sind und wie gut sie sind, wie sie die Komplexität des Projekts reduzieren usw.
Die Hauptbotschaft all dieser Berichte - Microservices helfen dabei, sich von der übermäßigen Komplexität und Komplexität des Projekts zu lösen. Aber für mich kann man die Komplexität überhaupt nicht loswerden, man kann das Projekt nicht neu gestalten, so dass alles auf einmal einfach wird. Die Schwierigkeit wird von einem Bereich in einen anderen verschoben.
Zum Beispiel: Es gab einen sehr komplizierten verwickelten Monolithen, wir haben ihn in mehrere Dienste aufgeteilt, jeder von ihnen sieht gut aus, jeder kann den Code herausfinden, aber was passiert mit der Umgebung? Die Komplexität wächst: Dies sind verteilte Transaktionen, die protokolliert werden müssen, um zu verstehen, dass dies eine Transaktion ist. CI / CD und Lieferung werden für jeden Service hinzugefügt. Das Interaktionsschema wird nicht trivial.
Die kontroversesten Thesen oder Aussagen, die ich in den Berichten gehört habe und mit denen ich argumentieren möchte:
Die Teilnahme an einem monolithischen Projekt ist für neue Teammitglieder teurer . Aus irgendeinem Grund ist es üblich, die Kosten für den Beitritt zu einem Projekt danach zu bewerten, wie schnell ein neuer Entwickler mit der Ausführung von Aufgaben beginnt. Ja, er wird es in einem kleinen Dienst sehr schnell herausfinden und die Aufgabe sehr schnell erledigen (insbesondere gemäß der Spezifikation „was sie geschrieben haben, dann habe ich getan“).
Aber was ist mit den anderen Teammitgliedern?
Der neue Tester wird sich mit dem Integrationsmodell befassen. Das Testen eines Dienstes ist gut, aber zusätzlich zum Testen eines Servicevertrags müssen Sie einen Geschäftsprozess überprüfen, der mehrere Dienste betrifft.
Zunächst kann sich der neue Analyst sogar den Kopf brechen, bis er alle Feinheiten interner Herausforderungen verstanden hat.
Mit Microservices können Sie häufiger veröffentlichen . Microservices lassen sich schneller verfeinern, da sie in mehrere parallele Aufgaben unterteilt sind, die parallel entwickelt und getestet werden. Es bleibt nur die Überprüfung der Integration (ohne Berücksichtigung der Zeit für die Analyse).
Sie können dies auch mit einem Monolithen tun, alles hängt von der Zerlegung der Aufgabe ab. Am Anfang wird es meistens eine Aufgabe geben - allgemeine Funktionen zu erstellen (die allgemeine Datenbank zu korrigieren oder die Benutzeroberfläche zu ändern), und dann werden alle ihre Unteraufgaben sehen und sie zum Testen geben.
Die Release-Zeit für Features, für die das Unternehmen bezahlt, ist dieselbe. Die Funktion wird nur geschlossen, wenn alle Komponenten freigegeben sind. Microservices können 99% der Aufgaben lösen, aber bis das letzte Feature geschlossen ist, werden sie nicht in den Kampf entlassen.
Worüber reden sie sonst noch nicht
Die Schwierigkeit wächst
Bei der Verwendung von Microservices ist die
Infrastruktur kompliziert . Dies liegt an der Tatsache, dass Sie die Arbeit nicht einer Anwendung, sondern vieler Dienste unterstützen müssen. Es ist notwendig, die Leistung aller Dienste zu überwachen, die Abhängigkeiten der Dienste nach Version gut zu verstehen, CI / CD-Pläne für die Zusammenstellung von Diensten und die Bereitstellung sowie Mechanismen für die Reaktion auf Dienstausfälle zu haben, damit nicht alles andere ausfällt.
Es scheinen einfache Dinge zu sein, und in einem Monolithen müssen wir dasselbe tun. Nur im Monolithen arbeiten wir an einer Anwendung, und mit zunehmender Anzahl von Diensten wächst die Komplexität, was die Unterstützung höherer Fähigkeiten erfordert.
Microservices erhöhen die Komplexität - neue Bibliotheken, neue Funktionen zur Unterstützung verteilter Transaktionen, zur Behandlung von Fehlern anderer Dienste, zum Senden wiederholter Anforderungen und zum Zurücksetzen von Transaktionen. Zum größten Teil werden diese Mechanismen üblich sein, und die meisten Entwickler werden nicht in den Mut geraten, sondern sie nur verwenden.
Möglicherweise sind jedoch Fehler enthalten, die behoben werden müssen. Wenn wir die Reparatur problemlos durchführen können, wird es einige Zeit dauern, bis die Änderungen an 200-300 Diensten eingeführt und Steuerungen entwickelt werden. Und wenn Sie die Dienste mit der aktualisierten Bibliothek neu erstellen oder sogar die Anrufe wiederholen müssen (sie haben es so behoben, haben es nicht vorgesehen), wird all dies keinen Spaß machen.
Monolith - kein großer Schlammball
Wie beginnen normalerweise Geschichten über die schöne Welt der Mikrodienste? „Wir hatten einen Monolithen, es war ein fester Schlammklumpen, in dem alles verwirrend und unverständlich ist“, und sie werden ein schreckliches Bild zeigen. Und der Monolith ist bereits zu etwas Erschreckendem geworden: "Sie werden schlecht arbeiten, Ihr Projekt wird sich in einen Monolithen verwandeln."
Aber NEIN.Ein Monolith kann (und sollte) klar, strukturiert, mit „gutem“ Code und Dokumentation sein, genau wie ein Microservice-Projekt zu einem noch größeren Schmutzklumpen werden kann, wenn Sie sich nicht an Entwicklungsprozessen beteiligen und die Qualität der Entwicklung nicht überwachen.
Also, was zu verwenden?
Gute Frage, die nur Sie beantworten können. Weil nur Sie wissen, welche geschäftlichen Probleme Sie entscheiden, wie das Projekt aussehen wird. Es gibt keine Silberkugel, es gibt keine ideale Architektur, die verwendet werden kann, und es wird immer „Glück“ geben.
Befolgen Sie im Monolithen und in Microservices die Dokumentation und halten Sie sie auf dem neuesten Stand. Mit Dokumentation ist besser als ohne.
Erstellen Sie einen Entwicklungsprozess, in dem die Qualität des Codes nur zunimmt (Überprüfungen, Komponententests). Aber über Qualität kann man ein ganzes Buch schreiben, dies ist ein Thema für ein separates großes Gespräch.
Bei einfachem und verständlichem Code geht es nicht um Microservices, der Code sollte a priori so sein.
Bei der Testautomatisierung geht es auch um die Codequalität.
Automatisieren Sie alles, was Sie automatisieren können - CI / CD. Es gibt wahrscheinlich einen Technologie-Stack, der sehr schwer in CI / CD zu ziehen ist, aber 99% der Baugruppen / Lieferungen können automatisiert werden.