Haben wir den Kreis mit Microservices geschlossen, zurück zu sehr alten Ansätzen?

Wie können sich Microservices in Bezug auf Softwarearchitektur und -design gegen Middleware "stapeln" (Wortspiel beabsichtigt)? Ich komme aus Java, und wenn Sie sich von REST als API entfernen und verschiedene Ebenen und Verbindungsparameter abstrahieren, zumindest in Java, schließt sich fast der Kreis zu einigen sehr alten Ideen . Wir sind zur Virtualisierung zurückgekehrt ... wobei die JVM bereits virtuell ist.

Auf agnostische Weise können Sie, und ich würde die Vorteile argumentieren, eine RESTful-API für CORBA abstrahieren. Oder, auf eine Java-zentrierte Art und Weise, JMS oder MDB.

Früher war EJB eine große Sache in Java, dann wurde es als ein bisschen wie ein Cluster-Effekt erkannt, aber jetzt sind wir wieder am Anfang?

Oder bieten Microservices etwas an, was CORBA oder noch besser MDB fehlt? Wenn ich (FowDR) Martin Fowler lese, der Microservices erklärt, erscheint es mir als gute Lösung für ein schlechtes Problem, wenn Sie so wollen. Oder besser gesagt, ein geschlossener Ansatz, der ein Maß an Komplexität einführt, das das Problem nur herumschubst. Wenn die Dienste wirklich klein und zahlreich sind, hat jeder einen Dollar Kosten für den Betrieb und die Wartung.

Wenn ein Mikrodienst unter vielen seine API ändert, bricht außerdem alles ab, was von diesem Dienst abhängt. Dabei spielt es keine scheinen lose gekoppelt, es scheint das Gegenteil von dem agilen. Oder missbrauche ich diese Worte?

Natürlich gibt es eine unbestimmte Anzahl von Möglichkeiten zwischen diesen Extremen.

Hai gegen Gorilla ... los! (Für die Pedantiker soll das ironisch sein und ist überhaupt nicht meine Absicht. Die Frage soll zum Nennwert genommen werden. Wenn die Frage verbessert werden kann, tun Sie dies bitte oder kommentieren Sie und ich werde es beheben. )

Stellen Sie sich eine Vielzahl von Mikrodiensten vor, die im Docker auf einem Computer ausgeführt werden und miteinander sprechen ... Wahnsinn. Schwer zu warten oder zu verwalten und so gut wie unmöglich, jemals etwas zu ändern, da jede Änderung kaskadiert und unvorhersehbare Fehler verursacht. Wie ist es irgendwie besser, dass diese Dienste auf verschiedene Maschinen verteilt sind? Und wenn sie verteilt sind, dann haben sicherlich einige sehr, sehr alte Schultechniken zumindest bis zu einem gewissen Grad verteiltes Rechnen gelöst.

Warum ist horizontale Skalierung so weit verbreitet oder zumindest wünschenswert?

TL; DR. Ich hatte das Vergnügen, viel Kool-Aid mit Microserver-Geschmack zu trinken, damit ich ein wenig über die Gründe sprechen kann, die dahinter stehen.

Vorteile:

• Services wissen, dass ihre Abhängigkeiten stabil sind und Zeit zum Backen hatten
• Ermöglichen Sie fortlaufende Bereitstellungen neuer Versionen
• Ermöglichen Sie das Zurücksetzen von Komponenten, ohne höhere Ebenen zu beeinträchtigen.

Nachteile:

• Sie können die neuen und glänzenden Funktionen Ihrer Abhängigkeiten nicht verwenden.
• Sie können die API-Abwärtskompatibilität niemals unterbrechen (oder zumindest nicht für viele Entwicklungszyklen).

Ich denke, Sie verstehen grundlegend falsch, wie eine Microservice-Architektur funktionieren soll. Die Art und Weise, wie es ausgeführt werden soll, ist, dass jeder Mikrodienst (von nun an als MS bezeichnet) eine starre API hat, auf die sich alle seine Kunden einigen. Die MS darf alle gewünschten Änderungen vornehmen, solange die API erhalten bleibt. Die MS kann weggeworfen und von Grund auf neu geschrieben werden, solange die API erhalten bleibt.

Um die lose Kopplung zu unterstützen, hängt jede MS von der Version n-1 ihrer Abhängigkeiten ab. Dadurch ist die aktuelle Version des Dienstes weniger stabil und etwas riskanter. Es erlaubt auch Versionen, in Wellen herauszukommen. Zuerst wird 1 Server aktualisiert, dann die Hälfte und schließlich der Rest. Wenn in der aktuellen Version jemals schwerwiegende Probleme auftreten, kann die MS ohne Funktionsverlust in anderen Ebenen auf eine frühere Version zurückgesetzt werden.

Wenn die API geändert werden muss, muss sie abwärtskompatibel geändert werden.

Bei jeder Softwareentwicklungstechnik, die wir jemals erfunden haben, ging es darum, die Komplexität irgendwie zu managen. Ein großer Teil von ihnen befasste sich mit Abstraktion, Einkapselung und loser Kopplung. Microservices sind eine weitere Möglichkeit, diese Dinge zu tun, weshalb sie wahrscheinlich vielen älteren Techniken auf einem hohen theoretischen Niveau ähneln, aber das macht sie nicht weniger nützlich oder relevant.

In Bezug auf die lose Kopplung denke ich, dass Sie das Ziel ein wenig missverstanden haben. Wenn Aufgabe A Aufgabe B aufrufen muss, gibt es keine Möglichkeit, A und B zu 100% zu entkoppeln. Das wird niemals passieren. Sie können sicherstellen, dass sich Aufgabe C, wenn Aufgabe B Aufgabe C aufruft, niemals um Änderungen an A kümmern muss. Wenn diese drei Aufgaben alle in einem großen Blob miteinander verbunden sind und Strukturen aneinander übergeben, gibt es eine erhebliche Chance, dass sie sich alle ändern müssen, wenn einer von ihnen dies tut. Wenn es sich bei allen drei um Microservices handelt, ist im Grunde genommen garantiert, dass eine Änderung von A nur die Aktualisierung von B erzwingt (es sei denn, es handelt sich um eine so große Änderung der Kernfunktionalität von A, dass Sie es wahrscheinlich zu einem brandneuen Service hätten machen sollen). Dies gilt insbesondere dann, wenn alle Microservice-Updates abwärtskompatibel durchgeführt werden, wie es sein sollte.

In Bezug auf den agilen Kommentar kann ich Ihnen aus persönlicher Erfahrung sagen, dass unser Microservice-y-Code mit Agile weitaus besser funktioniert als unser Code "In einen großen Blob verknüpft". In letzterem Fall muss jemand, wenn er einen Fehler in einer Funktion auf niedriger Ebene behebt, der gesamten Forschungs- und Entwicklungsabteilung buchstäblich eine E-Mail mit der Aufschrift "Bitte verknüpfen Sie Ihre Aufgaben erneut, sonst stürzen alle am Freitag ab" senden. Wir bekommen jede Woche ein paar davon . Wenn sein Code in einem Microservice wäre, würden wir alle automatisch von dem Fix profitieren, sobald er eine neue Version bereitstellt.

Ich verstehe den Kommentar zu COBRA und MDB nicht vollständig, da es sich anscheinend nicht um Softwarearchitekturen handelt, sondern um Komponenten einer solchen. Nach meinem Verständnis sind dies potenzielle Möglichkeiten, die Messaging-Protokolle Ihrer Microservices zu definieren und / oder diese Microservices zu implementieren, und nicht an und für sich Alternativen zu Microservices.

Wie ist es irgendwie besser, dass diese Dienste auf verschiedene Maschinen verteilt sind?

Wegen der Wolke.

Schon gelacht? Im Ernst - für viele Unternehmen sind die größten Kosten für Software nicht mehr die Software. Es sind die Bandbreite, die Hardware, die CDN-Kosten usw. Jetzt, da jeder ein mobiles Gerät hat, gibt es nur noch so viel mehr Verkehr. Und das wird nur noch schlimmer, wenn Ihr Toaster über eine eigene Internetverbindung verfügt.

Unternehmen versuchen daher, diese Kosten zu verwalten. Insbesondere versuchen sie, das Geschäftsproblem zu lösen: "Wenn dieses Problem auftritt, wie kann ich Millionen von Menschen bedienen, die meine Software erhalten / verwenden - ohne vorher dafür zu bezahlen, dass die Server Millionen von Menschen bedienen, die meine Software erhalten / verwenden." ? ".

Warum ist horizontale Skalierung so weit verbreitet oder zumindest wünschenswert?

Weil es dieses (riesige und zunehmende) Geschäftsproblem beantwortet.

Wenn Sie ein Dutzend Benutzer haben, können Sie alle Dienste auf eine Box werfen. Dies ist gut, da Sie nur für eine Box bezahlen möchten. Außerdem möchten Sie nicht für Änderungen an der App bezahlen, um die verschiedenen Dienste aufzuteilen, wenn Ihr Unternehmen skaliert. Heutzutage haben Sie keine Zeit dafür, bevor die Menge der Kunden Ihre Server sowieso in Brand setzt.

Es ist auch gut, weil es Ihnen ermöglicht, Serverzuordnungen zu jonglieren, so dass Sie:

1. Verwenden Sie die meisten Server, die Sie haben, und lassen Sie wenig "verschwenden".
2. Messen Sie die Leistung einzelner Elemente Ihrer Software.
3. Reduzieren Sie die durch Releases verursachte Bereitstellungs- / Ausfallzeit.

Eine sehr detaillierte Bereitstellung macht diese beiden Dinge einfacher / besser (zusätzlich zu einer besseren Trennung von Bedenken).