Hallo Habr!
Wir beginnen mit der Übersetzung von Chris Richardsons Buch
Microservices Patterns. Mit Beispielen in Java . Es ist ein halbes Jahr vor der Premiere auf Russisch vergangen, aber wir möchten Ihnen eine Art Trailer anbieten - eine leicht gekürzte Rezension dieses Buches von Ben Nadel, der die MEAP-Version gelesen hat. Die Rezension zitiert aktiv den Text der Kindle-Version von Richardson.
Willkommen bei Katze!
Ich habe Chris Richardson kennengelernt, als ich seine Online-Ressource
Microservices.io kennengelernt habe. Wo es, um ehrlich zu sein, eine erstaunliche Menge an Informationen gibt - die ich auf einen späteren Zeitpunkt verschoben habe, weil ich zu diesem Zeitpunkt nicht wusste, wie ich damit umgehen sollte, insbesondere angesichts der Tatsache, dass ich praktisch keine Geschäfte mit Microservices hatte. Ich lese gerne mehr. Als ich erfuhr, dass Chris das Buch
Microservices Patterns: With Examples In Java des Autors veröffentlichte, war ich einfach begeistert. So sehr, dass er nicht auf ihren Ausgang warten konnte. Also habe ich Mannings "frühe Version" (MEAP) erworben und gelesen. Letzte Woche habe ich genau das getan, was ich in diesem Buch studiert habe, und ich denke, dass dies eine faszinierende, pragmatische und ganzheitliche Studie des Microservice-Ansatzes für die Entwicklung ist.
Das gesamte Buch ist in Form der Geschichte von Mary - CTO (CTO) von Food To Go, Inc (FTGO) aufgebaut. Das Unternehmen möchte das Geschäft ausbauen, indem es das Refactoring seiner alten monolithischen Anwendung startet und sie in eine Microservice-Architektur umwandelt. Mary übernimmt dieses Projekt, weil die Entwicklungsgeschwindigkeit abgenommen hat und die Chefs sich immer mehr darüber ärgern, dass die Programmierer unter der Leitung von Mary keine neuen Funktionen in einer qualitativ hochwertigen Form produzieren können.
Marys Hauptproblem ist natürlich die sogenannte "monolithische Hölle" in Richardsons Terminologie. Während der Monolith eine große und wachsende Anwendung ist, konzentriert sich Richardson auf einen eher subtilen Aspekt der FTGO-Migration, so dass es bequemer ist, alle Konzepte aufzudecken und zu vermitteln. Gleichzeitig ist der Inhalt des Buches unglaublich gut verdaulich. Die meisten Architekturüberlegungen sind normalerweise entweder zu stark vereinfacht oder zu kompliziert. Richardson gelang es jedoch, einen Mittelweg zu finden, indem er ein Domänenmodell konstruierte, das (fast) in den Kopf passt, aber gleichzeitig komplex genug ist, um interessante dienstübergreifende Aufgabenströme zu veranschaulichen.
Ich hatte mich von Anfang an darauf gefreut, dass Richardson in jedem Detail pragmatisch war. Kein einziger Aspekt des Buches wird als „Silberkugel“ oder „einzige Lösung“ dargestellt. Überall sehen wir eine kalkulierte Auswahl, eine Reihe klar definierter Kompromisse. Zum Beispiel bringt der Autor sogar die Idee von Microservices in diesem Sinne vor: Microservice-Architektur sollte immer vermieden werden, außer in Fällen, in denen dies unbedingt erforderlich ist:
Eine weitere Herausforderung im Zusammenhang mit der Verwendung der Microservice-Architektur besteht darin, zu entscheiden, zu welchem Zeitpunkt im Anwendungslebenszyklus diese Architektur verwendet werden soll. Bei der Entwicklung der ersten Version einer Anwendung treten häufig immer noch keine Probleme auf, die durch eine solche Architektur gelöst werden. Darüber hinaus wird die Verwendung einer ausgewogenen verteilten Architektur die Entwicklung nur verlangsamen. Ein solches Dilemma kann bei Startups auftreten, bei denen die wichtigste Herausforderung in der Regel in der raschen Entwicklung eines Geschäftsmodells und seiner eigenen Anwendung liegt. Bei Verwendung der Microservice-Architektur ist es viel schwieriger, schnelle Iterationen zu organisieren. Die Startup-Entwicklung sollte auf jeden Fall mit einer monolithischen Anwendung beginnen. (Kindle-Version, Adresse 416)
Richardson betrachtet Microservices auch in einer ganzheitlichen Perspektive und diskutiert die Dynamik des Teams als einen völlig unabhängigen Kreis von Problemen, der auf dem technologischen Teil aufbaut. Natürlich betrachtet er Themen wie
Conways Gesetz und "
Conways Umkehrmanöver", aber gleichzeitig geht er auch auf die Tatsache ein, dass Programmierer emotionale Pathos-Charaktere sind, mit denen Sie die Idee von Microservices "verkaufen" sollten:
Wenn Sie zum Microservice-Paradigma übergehen, müssen Sie Ihre Architektur, Ihre Organisation und Ihre Entwicklungsprozesse ändern. Am Ende ändert sich jedoch das Arbeitsumfeld, die Bedingungen, unter denen Menschen arbeiten, und die Menschen sind, wie bereits erwähnt, emotional. Wenn menschliche Emotionen ignoriert werden, kann die Einführung von Mikrodiensten in einer Organisation zu einem steilen Weg werden. (Kindle-Version, Adresse 718)
Die vom Autor beschriebenen Strategien betreffen das gesamte Unternehmen und betreffen Manager und Führungskräfte, die es möglicherweise nicht wagen, ein umfangreiches Refactoring zu starten, indem sie wertvolle Ressourcen daraus ziehen und Personen, die aktiv neue Funktionen entwickeln könnten:
Ein wesentlicher Vorteil des schrittweisen Refactorings in Richtung Microservice-Architektur besteht darin, dass sich eine solche Strategie sofort auszahlt. Dies ist überhaupt nicht der Fall, wenn ein Code „überarbeitet“ wird, der erst dann Vorteile bringt, wenn er vollständig abgeschlossen ist ...
Ein weiteres Plus der Situation, in der der Wert des Übergangs frühzeitig erworben wird, besteht darin, dass wir Unternehmensunterstützung gewinnen können, um die Migration sicherzustellen. Eine solche fortlaufende Unterstützung ist von entscheidender Bedeutung, denn je aktiver das Refactoring ist, desto weniger Zeit können Sie für die Entwicklung von Funktionen aufwenden. In einigen Organisationen ist es schwierig, technische Schulden loszuwerden, da sich frühere Versuche als zu ehrgeizig herausstellen konnten und nicht die gewünschten Vorteile brachten. Infolgedessen zögert das Unternehmen, weiterhin in „Aufräumarbeiten“ zu investieren. Durch die schrittweise Vorgehensweise beim Refactoring bei Microservices kann ein Team sehr oft wertvolle Ergebnisse vorweisen. (Kindle-Versionsadresse 10769)
Aus technologischer Sicht in dem Buch „Microservices. Entwicklungs- und Refactoring-Muster “untersuchten eine breite Palette von Themen: von hexagonalen Architekturen über Tests und kontinuierliche Integration bis hin zu Messaging-Mustern und der Erstellung beobachtbarer Systeme. Eine solche Berichterstattung impliziert, dass einige Themen im Buch ausführlicher behandelt werden als andere. Richardson schafft es jedoch wieder perfekt, alles in Einklang zu bringen und so viele Details anzugeben, dass man das Thema vernünftigerweise diskutieren kann, ohne den Leser zu entmutigen.
Tatsächlich ist der Inhalt des Buches so organisiert, dass Sie selbst auswählen können, mit welchen Themen Sie sich befassen möchten. In jedem Kapitel wird vor einem detaillierten Eintauchen in das Thema eine Liste von TL; DR gegeben, in der alle Vor- und Nachteile kurz aufgeführt sind. So schaffen Sie es, die wichtigsten Punkte des Kapitels zu erfassen, ohne jedes Wort durchzulesen.
Ehrlich gesagt habe ich gerade zwei Kapitel zum Testen von Microservices und ein Kapitel zum Bereitstellen von Microservices durchgeblättert. Ich bin sicher, dass der Autor diese Themen perfekt ausgearbeitet hat, aber es schien mir, dass es einfach mehr Informationen gab, als ich verdauen konnte. Der Einsatz ist für mich keine dringende tägliche Aufgabe. Er schrieb mehrere Tests in seinem Leben.
Daher wollte ich in meinem unklaren Höhlenbewusstsein genügend Platz lassen, um das Material aus allen anderen Kapiteln dort abzulegen: über themenorientiertes Design (DDD), Interprozesskommunikation und Datensynchronisation.
In einem der Abschnitte, die mich besonders beeindruckt haben, wird erläutert, welcher Service Anfragen eines bestimmten Typs bearbeiten soll: Finden Sie geeignete Restaurants in der Nähe des aktuellen Standorts des Benutzers:
Es kann jedoch schwierig sein, selbst solche Anforderungen zu implementieren, die in Bezug auf einen bestimmten Dienst lokal sind. Dies ist aus mehreren Gründen möglich. Erstens, weil es (wie unten beschrieben) manchmal unangemessen ist, eine Anforderung in dem Dienst zu implementieren, dem die Daten gehören. Ein weiterer Grund ist, dass die Servicedatenbank (oder das Datenmodell) die Anforderung manchmal nicht effizient unterstützen kann (Kindle-Version, Adresse 5659).
... Wenn in der FTGO-Anwendung Informationen zu Restaurants in einer [anderen] Datenbank gespeichert sind, ist die Implementierung der Abfrage findAvailableRestaurant() viel komplizierter. Eine Replik der Restaurantdaten sollte in einer Form gespeichert werden, die Geodatenabfragen unterstützt. Eine Anwendung könnte beispielsweise die Geospatial Indexing Library für DynamoDB verwenden, in der die Tabelle als Geospatial Index verwendet wird. Alternative: Die Anwendung kann eine Replik von Restaurantdaten in einer völlig anderen Art von Datenbank speichern. Eine ähnliche Situation tritt auf, wenn wir Textabfragen mit einer Datenbank für die Textsuche verwenden. (Kindle-Version, Adresse 5675)
... In diesem Fall ist es ratsam (zumindest auf den ersten Blick), dass die Anforderungsoperation von genau dem Dienst implementiert wird, dem die Daten gehören. Neben dem Dateneigentum müssen jedoch noch andere Faktoren berücksichtigt werden.
Es ist auch notwendig, die Notwendigkeit einer Aufgabentrennung zu berücksichtigen und eine Überlastung der Dienste mit zu vielen Funktionen zu vermeiden. Die Hauptverantwortung des Teams, das den Restaurantservice entwickelt, besteht beispielsweise darin, den Restaurantmanagern bei der Arbeit des Unternehmens zu helfen. Diese Aufgabe gehört überhaupt nicht zum Plan, eine kritische Anfrage für die Arbeit mit großen Datenmengen umzusetzen. Wenn das Entwicklungsteam für den findAvailableRestaurants() verantwortlich wäre, hätte es darüber hinaus ständig Angst, solche Änderungen einzuführen, die Verbraucher daran hindern könnten, Bestellungen findAvailableRestaurants() . (Kindle-Version, Adresse 5675)
Hier explodierte mein Gehirn ein wenig, weil ich zum ersten Mal einen Dienst sah, dessen einzige Funktion darin bestand, die Daten eines anderen Dienstes zu optimieren, um eine bestimmte Aufgabe auszuführen. Richardson weist jedoch darauf hin, dass dies nur eine allgemeinere Abstraktion der Idee ist, die der Volltextsuche zugrunde liegt, beispielsweise in Apache Lucene (dieses Tool bietet eine Volltextindizierung über einem anderen Data Warehouse).
Ich vermute - oder besser gesagt, ich möchte hoffen -, dass der Leser nach einer solchen Aufteilung der Zuständigkeiten eine neue Grenze zwischen den Diensten ziehen wird. Er wird nicht nur über „Dateneigentum“ nachdenken, sondern auch „Geschäftsmöglichkeiten“ berücksichtigen - das ist ein Faktor von echtem Wert, damit die Datenbank nicht nur der Ort zu sein scheint, an dem der Staat gespeichert ist.
Ein weiterer Aspekt, der in dieser Diskussion hervorgehoben wird, ist die absolute Bedeutung der Datensynchronisation und -replikation sowie des asynchronen Messaging in der Microservice-Architektur. Dieses Thema zieht sich durch das gesamte Richardson-Buch mit einem roten Faden, unabhängig davon, worüber sie sprechen: die Erstellung eines Mikrodienstes von Grund auf oder die schrittweise Umgestaltung eines Monolithen in Mikrodienste (ein separates Kapitel ist diesem Thema gewidmet). Er macht sehr deutlich, dass Synchronisation die Rückgratkraft ist, die es wirklich ermöglicht, viele Dinge zu realisieren.
Ich könnte viele interessante Dinge erwähnen. Was ist zum Beispiel die Tatsache wert, dass Richardson richtig über Authentifizierung und Autorisierung in einem verteilten System spricht? Ich denke, dieses Thema wurde, gelinde gesagt, noch nicht vollständig untersucht. Der Autor erklärt das themenorientierte Design am leichtesten zugänglich. Er zeigt auch, dass selbst sehr einfache Klassen Verhalten haben können.
Seit über einem Jahr versuche ich, die Architektur verteilter Systeme und Mikroservice-Muster richtig zu verstehen (was besonders schwierig ist, da meine tägliche Arbeit mit der Wartung des Monolithen verbunden ist). Viele der Texte, die ich zu diesen Themen lese, sind entweder zu oberflächlich oder zu eng und gleichzeitig ausführlich. Das Buch "Microservices. Entwicklungs- und Refactoring-Muster “ist in der Tat der Mittelweg zwischen diesen beiden Extremen.
Ich kann dieses Buch jedem (unserem Kühnen)
empfehlen, der versucht (einschließlich bisher erfolglos), von einer monolithischen Architektur zu einem verteilten System zu wechseln.