{"id":79498,"date":"2020-04-27T19:42:07","date_gmt":"2020-04-27T17:42:07","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat"},"modified":"2020-04-27T19:42:07","modified_gmt":"2020-04-27T17:42:07","slug":"mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat","title":{"rendered":"Mikroservices: Was sie sind, warum sie ben\u00f6tigt werden und wann man sie einf\u00fchren sollte.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ich wollte schon lange einen Artikel \u00fcber mikroskopische Architektur schreiben, aber ich wurde die ganze Zeit von zwei Punkten gestoppt \u2013 je tiefer ich in das Thema eintauchte, desto mehr schien mir, dass das, was ich wei\u00df, offensichtlich ist, und das, was ich nicht wei\u00df, muss noch weiter erforscht werden. Auf der anderen Seite denke ich, dass es schon gen\u00fcgend Diskussionsstoff f\u00fcr ein breites Publikum gibt. Daher sind alternative Meinungen willkommen.
\n<\/a><\/noindex><\/p>\n

Das Conway-Gesetz und die Verbindung zwischen Gesch\u00e4ft, Organisation und Informationssystem<\/h2>\n

\nIch erlaube mir erneut zu zitieren:<\/p>\n

\u201eJede Organisation, die ein System (im weitesten Sinne) entwirft, wird ein Design erhalten, dessen Struktur die Struktur der Teams in dieser Organisation widerspiegelt\u201c
\n\u2013 Melvyn Conway, 1967\n<\/p><\/blockquote>\n

Meiner Meinung nach bezieht sich dieses Gesetz eher auf die Zweckm\u00e4\u00dfigkeit der Gesch\u00e4ftsorganisation als direkt auf das Informationssystem. Ich erkl\u00e4re es am Beispiel. Angenommen, wir haben eine relativ stabile Gesch\u00e4ftsm\u00f6glichkeit mit einem Lebenszyklus, der lang genug ist, um es sinnvoll zu machen, ein Unternehmen zu gr\u00fcnden (das ist kein Schreibfehler, der Begriff gef\u00e4llt mir sehr, den ich abgekupfert habe). Es versteht sich von selbst, dass das unterst\u00fctzende System dieses Gesch\u00e4fts organisatorisch und prozessual zu diesem Gesch\u00e4ft passen wird.<\/p>\n

Gesch\u00e4ftsorientierung von Informationssystemen<\/h2>\n

\n\"Mikroservices:
\n
\nIch erkl\u00e4re es am Beispiel. Angenommen, es gibt eine Gesch\u00e4ftsm\u00f6glichkeit zur Organisation eines Gesch\u00e4fts f\u00fcr 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\u00e4nderlichkeit sehr langlebig. Dann kam die Version 2 \u2013 fortschrittlicher und f\u00e4hig, ein Informationssystem als Grundlage f\u00fcr das Gesch\u00e4ft mit monolithischer Architektur zu nutzen. Und hier entsteht meines Erachtens eine einfach furchtbare Ungerechtigkeit gegen\u00fcber den Monolithen \u2013 angeblich entspricht die monolithische Architektur nicht dem Dom\u00e4nenmodell des Gesch\u00e4fts.<\/b>. Wenn dem so w\u00e4re, k\u00f6nnte das System \u00fcberhaupt nicht funktionieren - was im Widerspruch zu demselben Gesetz von Conway und dem gesunden Menschenverstand steht. Nein, die monolithische Architektur entspricht v\u00f6llig dem Gesch\u00e4ftsmodell in dieser Phase der Gesch\u00e4ftsentwicklung - ich meine nat\u00fcrlich die Phase, in der das System bereits erstellt und in Betrieb genommen wurde. Es ist ein v\u00f6llig bemerkenswerter Fakt, dass unabh\u00e4ngig 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?<\/p>\n

Alles flie\u00dft, alles ver\u00e4ndert sich oder sind Mikroservices ein Mittel im Kampf gegen die Komplexit\u00e4t?<\/h2>\n

\n Bevor wir fortfahren, lassen Sie uns einige Missverst\u00e4ndnisse \u00fcber Mikroservice-Architektur betrachten.<\/p>\n

Bef\u00fcrworter 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\u00f6lliger Unsinn. Ernsthaft, scheint die offensichtliche Interaktion innerhalb eines Monolithen und homogener Code kompliziert zu sein? Wenn das wirklich der Fall w\u00e4re, w\u00fcrden alle Projekte von Anfang an als Mikroservices aufgebaut werden, w\u00e4hrend die Praxis zeigt, dass die Migration vom Monolithen zu Mikroservices wesentlich verbreiteter ist. Die Komplexit\u00e4t 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! <\/p>\n

Der Vorteil der Verwendung eines heterogenen Stacks ist ebenfalls fraglich. Ich werde nicht bestreiten, dass dies auch m\u00f6glich ist, aber in der Realit\u00e4t kommt es selten vor (Um der Sache vorzugreifen - es sollte der Fall sein - aber eher als Konsequenz denn als Vorteil).<\/p>\n

Der Lebenszyklus eines Produkts und der Lebenszyklus eines Dienstes<\/h2>\n

\nSchauen Sie sich das Diagramm oben noch einmal an. Ich habe den verk\u00fcrzten Lebenszyklus einer einzelnen Gesch\u00e4ftsversion nicht ohne Grund hervorgehoben - unter den modernen Bedingungen ist es gerade die Beschleunigung des \u00dcbergangs des Gesch\u00e4fts zwischen Versionen, die entscheidend f\u00fcr seinen Erfolg ist. Der Erfolg eines Produkts wird durch die Geschwindigkeit bestimmt, mit der Gesch\u00e4fts-Hypothesen darin \u00fcberpr\u00fcft werden.<\/b>. Und hier liegt meiner Meinung nach der Schl\u00fcsselvorteil der Mikroservice-Architektur. Aber lassen Sie uns der Reihe nach vorgehen. <\/p>\n

Lass uns zur n\u00e4chsten Stufe der Evolution von Informationssystemen \u00fcbergehen \u2013 zur serviceorientierten Architektur SOA. Also, zu einem bestimmten Zeitpunkt haben wir in unserem Produkt langfristige Dienste<\/b> \u2013 langfristig in dem Sinne, dass beim \u00dcbergang zwischen den Produktversionen die Chance besteht, dass der Lebenszyklus des Dienstes l\u00e4nger ist als der Lebenszyklus der n\u00e4chsten Produktversion. Es w\u00e4re logisch, sie \u00fcberhaupt nicht zu ver\u00e4ndern \u2013 uns ist insbesondere die Geschwindigkeit des \u00dcbergangs zur n\u00e4chsten Version wichtig<\/b>. Aber leider sind wir gezwungen, st\u00e4ndig \u00c4nderungen an den Diensten vorzunehmen \u2013 und hier ist alles m\u00f6glich, sowohl DevOps-Praktiken als auch Containerisierung und andere Dinge \u2013 alles, was einem in den Sinn kommt. Aber das sind immer noch keine Mikrodienste! <\/p>\n

Mikrodienste als Mittel zur Bew\u00e4ltigung von Komplexit\u00e4t... Konfigurationsmanagement<\/h2>\n

\n Und hier k\u00f6nnen wir endlich zur entscheidenden Rolle von Mikrodiensten \u00fcbergehen \u2013 es ist ein Ansatz, der das Konfigurationsmanagement des Produkts vereinfacht. Genauer gesagt, die Funktion jedes Mikrodienstes beschreibt genau die Gesch\u00e4ftsfunction innerhalb des Produkts gem\u00e4\u00df dem Domainmodell \u2013 und das sind bereits Dinge, die nicht in der kurzlebigen Version leben, sondern in der langfristigen Gesch\u00e4ftsm\u00f6glichkeit. Der \u00dcbergang zur n\u00e4chsten Produktversion geschieht buchst\u00e4blich unbemerkt \u2013 man \u00e4ndert\/hinzugef\u00fcgt einen Mikrodienst oder vielleicht nur das Schema ihrer Interaktion und befindet sich pl\u00f6tzlich schon in der Zukunft, w\u00e4hrend man die weinenden Konkurrenten hinter sich l\u00e4sst, die weiterhin zwischen den Versionen ihrer Monolithen h\u00fcpfen. Stellen Sie sich nun vor, dass es ausreichend viele Mikrodienste mit vordefinierten Schnittstellen und Gesch\u00e4ftsm\u00f6glichkeiten gibt. Und Sie kommen und bauen die Struktur Ihres Produkts aus fertigen Mikrodiensten \u2013 einfach indem Sie beispielsweise ein Diagramm zeichnen. Herzlichen Gl\u00fcckwunsch \u2013 Sie haben eine Plattform geschaffen \u2013 und jetzt k\u00f6nnen Sie sich Ihr Gesch\u00e4ft zusammenklicken. Tr\u00e4ume, Tr\u00e4ume. <\/p>\n

Das DBMS Tarantool ist ein attraktives, zukunftstr\u00e4chtiges Produkt zur Erstellung von hochbelasteten Anwendungen.<\/h2>\n

<\/p>\n