Mikroservices: Was sie sind, warum sie benötigt werden und wann man sie einführen sollte.

Ich wollte schon lange einen Artikel über mikroskopische Architektur schreiben, aber ich wurde die ganze Zeit von zwei Punkten gestoppt – je tiefer ich in das Thema eintauchte, desto mehr schien mir, dass das, was ich weiß, offensichtlich ist, und das, was ich nicht weiß, muss noch weiter erforscht werden. Auf der anderen Seite denke ich, dass es schon genügend Diskussionsstoff für ein breites Publikum gibt. Daher sind alternative Meinungen willkommen.

Das Conway-Gesetz und die Verbindung zwischen Geschäft, Organisation und Informationssystem

Ich erlaube mir erneut zu zitieren:

„Jede Organisation, die ein System (im weitesten Sinne) entwirft, wird ein Design erhalten, dessen Struktur die Struktur der Teams in dieser Organisation widerspiegelt“
– Melvyn Conway, 1967

Meiner Meinung nach bezieht sich dieses Gesetz eher auf die Zweckmäßigkeit der Geschäftsorganisation als direkt auf das Informationssystem. Ich erkläre es am Beispiel. Angenommen, wir haben eine relativ stabile Geschäftsmöglichkeit mit einem Lebenszyklus, der lang genug ist, um es sinnvoll zu machen, ein Unternehmen zu gründen (das ist kein Schreibfehler, der Begriff gefällt mir sehr, den ich abgekupfert habe). Es versteht sich von selbst, dass das unterstützende System dieses Geschäfts organisatorisch und prozessual zu diesem Geschäft passen wird.

Geschäftsorientierung von Informationssystemen

Ich erkläre es am Beispiel. Angenommen, es gibt eine Geschäftsmöglichkeit zur Organisation eines Geschäfts für den Pizzaverkauf. In der Version V1 (nennen wir sie vor-informatisch) stellte das Unternehmen eine Pizzeria, eine Kasse und einen Lieferdienst dar. Diese Version war in einem Umfeld mit niedriger Veränderlichkeit sehr langlebig. Dann kam die Version 2 – fortschrittlicher und fähig, ein Informationssystem als Grundlage für das Geschäft mit monolithischer Architektur zu nutzen. Und hier entsteht meines Erachtens eine einfach furchtbare Ungerechtigkeit gegenüber den Monolithen – angeblich entspricht die monolithische Architektur nicht dem Domänenmodell des Geschäfts.. Wenn dem so wäre, könnte das System überhaupt nicht funktionieren - was im Widerspruch zu demselben Gesetz von Conway und dem gesunden Menschenverstand steht. Nein, die monolithische Architektur entspricht völlig dem Geschäftsmodell in dieser Phase der Geschäftsentwicklung - ich meine natürlich die Phase, in der das System bereits erstellt und in Betrieb genommen wurde. Es ist ein völlig bemerkenswerter Fakt, dass unabhängig vom architektonischen Ansatz sowohl die Service-orientierte Architektur Version 3 als auch die Mikroservice-Architektur Version N gleich gut funktionieren werden. Wo liegt der Haken?

Alles fließt, alles verändert sich oder sind Mikroservices ein Mittel im Kampf gegen die Komplexität?

Bevor wir fortfahren, lassen Sie uns einige Missverständnisse über Mikroservice-Architektur betrachten.

Befürworter des mikroservicebasierten Ansatzes sagen oft, dass die Zerlegung eines Monolithen in Mikroservices den Entwicklungsansatz vereinfacht, indem die Codebasis der einzelnen Dienste verkleinert wird. Meiner Meinung nach ist diese Aussage völliger Unsinn. Ernsthaft, scheint die offensichtliche Interaktion innerhalb eines Monolithen und homogener Code kompliziert zu sein? Wenn das wirklich der Fall wäre, würden alle Projekte von Anfang an als Mikroservices aufgebaut werden, während die Praxis zeigt, dass die Migration vom Monolithen zu Mikroservices wesentlich verbreiteter ist. Die Komplexität verschwindet nicht, sie wandert einfach von einzelnen Modulen zu Schnittstellen (ob es sich um Datenbusse, RPC, APIs oder andere Protokolle handelt) und zu orchestrierenden Systemen. Und das ist kompliziert!

Der Vorteil der Verwendung eines heterogenen Stacks ist ebenfalls fraglich. Ich werde nicht bestreiten, dass dies auch möglich ist, aber in der Realität kommt es selten vor (Um der Sache vorzugreifen - es sollte der Fall sein - aber eher als Konsequenz denn als Vorteil).

Der Lebenszyklus eines Produkts und der Lebenszyklus eines Dienstes

Schauen Sie sich das Diagramm oben noch einmal an. Ich habe den verkürzten Lebenszyklus einer einzelnen Geschäftsversion nicht ohne Grund hervorgehoben - unter den modernen Bedingungen ist es gerade die Beschleunigung des Übergangs des Geschäfts zwischen Versionen, die entscheidend für seinen Erfolg ist. Der Erfolg eines Produkts wird durch die Geschwindigkeit bestimmt, mit der Geschäfts-Hypothesen darin überprüft werden.. Und hier liegt meiner Meinung nach der Schlüsselvorteil der Mikroservice-Architektur. Aber lassen Sie uns der Reihe nach vorgehen.

Lass uns zur nächsten Stufe der Evolution von Informationssystemen übergehen – zur serviceorientierten Architektur SOA. Also, zu einem bestimmten Zeitpunkt haben wir in unserem Produkt langfristige Dienste – langfristig in dem Sinne, dass beim Übergang zwischen den Produktversionen die Chance besteht, dass der Lebenszyklus des Dienstes länger ist als der Lebenszyklus der nächsten Produktversion. Es wäre logisch, sie überhaupt nicht zu verändern – uns ist insbesondere die Geschwindigkeit des Übergangs zur nächsten Version wichtig. Aber leider sind wir gezwungen, ständig Änderungen an den Diensten vorzunehmen – und hier ist alles möglich, sowohl DevOps-Praktiken als auch Containerisierung und andere Dinge – alles, was einem in den Sinn kommt. Aber das sind immer noch keine Mikrodienste!

Mikrodienste als Mittel zur Bewältigung von Komplexität... Konfigurationsmanagement

Und hier können wir endlich zur entscheidenden Rolle von Mikrodiensten übergehen – es ist ein Ansatz, der das Konfigurationsmanagement des Produkts vereinfacht. Genauer gesagt, die Funktion jedes Mikrodienstes beschreibt genau die Geschäftsfunction innerhalb des Produkts gemäß dem Domainmodell – und das sind bereits Dinge, die nicht in der kurzlebigen Version leben, sondern in der langfristigen Geschäftsmöglichkeit. Der Übergang zur nächsten Produktversion geschieht buchstäblich unbemerkt – man ändert/hinzugefügt einen Mikrodienst oder vielleicht nur das Schema ihrer Interaktion und befindet sich plötzlich schon in der Zukunft, während man die weinenden Konkurrenten hinter sich lässt, die weiterhin zwischen den Versionen ihrer Monolithen hüpfen. Stellen Sie sich nun vor, dass es ausreichend viele Mikrodienste mit vordefinierten Schnittstellen und Geschäftsmöglichkeiten gibt. Und Sie kommen und bauen die Struktur Ihres Produkts aus fertigen Mikrodiensten – einfach indem Sie beispielsweise ein Diagramm zeichnen. Herzlichen Glückwunsch – Sie haben eine Plattform geschaffen – und jetzt können Sie sich Ihr Geschäft zusammenklicken. Träume, Träume.

Das DBMS Tarantool ist ein attraktives, zukunftsträchtiges Produkt zur Erstellung von hochbelasteten Anwendungen.

• Die Systemarchitektur sollte durch den Lebenszyklus ihrer Komponenten definiert werden. Wenn eine Komponente innerhalb einer Produktversion lebt, macht es keinen Sinn, die Komplexität des Systems zu erhöhen, indem man den mikrodienstlichen Ansatz anwendet.
• Die mikrodienstliche Architektur sollte auf dem Domainmodell basieren – aus dem Grund, dass die Geschäftsmöglichkeit das am längsten lebende Gebiet ist.
• Lieferpraktiken (DevOps-Praktiken) und Orchestrierung sind für die Mikrodienstarchitektur von entscheidender Bedeutung, da eine höhere Änderungsrate der Komponenten erhöhte Anforderungen an die Geschwindigkeit und Qualität der Lieferung stellt.

Quelle: habr.com