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

9

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?

Thufir
quelle
4
Abstimmung zum Schließen. Es ist unklar, was Sie fragen und warum Sie es fragen. Die Microservice-Architektur ist nur eine andere Architektur. Nicht mehr, nicht weniger.
Davidk01
1
Vielleicht finden Sie diesen Artikel auch lohnenswert: devweek.com/blog/microservices-the-good-the-bad-and-the-ugly
davidk01
1
Ich bevorzuge "Jetzt haben sie Hunderte kleiner Faux-Services, und statt eines Monolithen müssen sie sich Sorgen machen, was passiert, wenn jemand den Vertrag für einen dieser Services ändern möchte. Ein Wollknäuel mit einem anderen Namen. Stattdessen Wenn sie sich fragen, ob der Code kompiliert wird, wenn sie Änderungen vornehmen, fragen sie sich, ob er in der Praxis ausgeführt wird. " - Microservices für mürrische Nackenbärte Haftungsausschluss: Nein, ich bin kein Nackenbart, es ist nur ein humorvoller Artikel.
Thufir
"Anstatt sich zu fragen, ob der Code kompiliert wird ... fragen sie sich, ob er ausgeführt wird ..." Tatsächlich ist dies überhaupt kein Problem. Ganz einfach, wenn ein Entwickler einen Vertrag ändert, ohne alle Beteiligten zu benachrichtigen, sollte dieser Entwickler sehr hart geschlagen werden. Buchstäblich. Wenn wir einen befristeten Vertrag verwenden, stellen Sie sich dann vor, Ihr Mobilfunkanbieter ändert die Vertragsbedingungen, ohne Sie zu fragen / zu informieren? Aus diesem Grund handelt es sich um einen Vertrag - alle Beteiligten müssen Vertragsänderungen kennen / vereinbaren, und wenn diese Änderung eintritt (unter der Annahme eines ordnungsgemäßen Entwicklungsflusses), sollten alle getestet werden und reibungslos funktionieren.
Alexey Kamenskiy
1
@Thufir Wie bereits gesagt, ist MS nur ein weiterer Ansatz, der Vor- und Nachteile hat. Ich habe tatsächlich mit diesem Ansatz (noch bevor ich hörte, dass er einen speziellen Namen hat) an mehreren Projekten gearbeitet. Als Randnotiz - es ist kein Wasserfall, es ist das, was Sie daraus machen. Da ich für ein Projekt gearbeitet habe, bei dem (im Team) ein Teil des mobilen Betriebssystems entwickelt wurde, ist dieser Ansatz der einzige Weg, da das Betriebssystem nicht als gemacht werden kann, da giant blobes Schnittstellen haben muss, sodass jeder Teil, der vom Kernel ausgeht, eine Art MS ist, und als erstes vorher Jedes Team, das mit dem Schreiben von Code begann, sollte sich auf die Spezifikationen v0.0.1 einigen.
Alexey Kamenskiy

Antworten:

2

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.

Konstantin Tarashchanskiy
quelle
"Die MS kann weggeworfen und von Grund auf neu geschrieben werden, solange die API erhalten bleibt." - nichts Neues da, aber ok. Wie vergleichen sich all diese MS in Bezug auf die Leistung am anderen Ende des Spektrums mit einer monolithischen App / einem monolithischen App / System? In Bezug auf die Verteilung klingt es so , und bitte korrigieren Sie mich, wenn es falsch ist, dass es einen potenziellen Leistungsgewinn gibt, wenn n MS auf einer einzelnen Maschine installiert werden ... virtualisiert auf einem Mainframe? Es ist fast so, als ob es umso einfacher wird, MSs vertikal zu skalieren, je mehr Sie sie horizontal skalieren ...? Bonuspunkte für das
Nichtlesen
1
Wie bei jeder Indirektionsebene erzielen Sie im Vergleich zu einem großen Schlammball einen Leistungseinbruch. Im Fall von MS ist dies besonders teuer, da Sie bei jedem Anruf eine Netzwerkrundfahrt durchführen. Durch die Verwendung von Virtualisierung oder Containern wird diese Hin- und Rückfahrt erheblich verkürzt, da der Anruf die Maschine nie verlässt. Dies bedeutet auch, dass Sie mit geringeren Hardwarekosten mehr Isolation erlangen (ein außer Kontrolle geratener Dienst kann seine Kollegen nicht verletzen).
Konstantin Tarashchanskiy
5

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.

Ixrec
quelle
1
"Wenn diese drei Aufgaben alle in einem großen Blob miteinander verbunden sind ..." Ich habe nur eine Java-Perspektive, aber ich würde "Nein" sagen, schlechte Idee, tu das nicht. Machen Sie eine Bibliothek, API # 1, API # 2, usw., Ihren genauen Punkt zu erreichen „..task C nie Sorgen über Änderungen an A haben sollte“ , weil C ein Kunde von B ist nur und nicht von A überhaupt . In dieser Hinsicht sehe ich das überhaupt nicht als neu an, entschuldigen Sie. Ich weiß, dass die Frage, die ich gestellt habe, verschwommen war. Es ist eine unscharfe Frage, weil ich unscharf bin, worum es geht. Jede einzelne Antwort war für mich nützlich, schon allein um meinen Wortschatz zu verbessern.
Thufir
1
@Thufir Wenn die Bibliotheken alle dynamisch verknüpft sind und die Aufgaben alle auf genau demselben Rechnersatz ausgeführt werden, haben Sie Recht, dies würde in der Tat einen separaten Rollout ermöglichen. Mit Microservices können Sie jedoch auch diese Annahmen fallen lassen, wenn Sie mit der Entkopplung so weit gehen möchten. Es ist völlig vernünftig, dies nicht zu tun.
Ixrec
CORBA ist (war) eine verteilte Technologie, die verteilte Architekturen zu einer Zeit (Ende 1990) ermöglichte, als es noch keine weit verbreiteten Namen gab, um sie zu definieren. Es stand Ihnen frei, grobkörnige oder feinkörnige CORBA-basierte Systeme zu implementieren, die später als SOA oder Microservices bezeichnet wurden. CORBA hat nicht überlebt, aber wir machen es wieder, nur mit einer anderen Technologie. Das Problem war jedoch nicht die Technologie. Also ja, wir schließen den Kreis. Ich hoffe, wir haben dabei etwas gelernt.
Xtian
4

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).

Telastyn
quelle
Ok, ich kann den Vorteil sehen. Es gibt eine niedrige Eintrittsbarriere, die sich jedoch vergrößern kann . Ich nehme an, was mich für eine Schleife wirft, ist, wenn Sie horizontal n MS skalieren, es scheint nur ... sehr ... retro? Etwas. Ich kann nicht sagen, warum es einfach falsch scheint .
Thufir
Die Anwendungsskalierung ist ein Problem, für das nicht unbedingt Microservices erforderlich sind: Sie können die Leistung einer VM in AWS (auch bei Bedarf) sehr einfach erhöhen oder in einer herkömmlichen Architektur weitere VMs hinter einem Load Balancer hinzufügen.
Xtian
@xtian - sicher, aber Sie skalieren oft die falschen Dinge und geben so mehr Geld aus, als Sie brauchen. Die Idee hinter Microservices ist, dass Sie einfach skalieren, was Sie brauchen (CPU, Speicher, Festplatte, Durchsatz, GPU)
Telastyn