Microservices, ehrlich gezeichnet

Nicht "welche Dienste gibt es" - das leistet eine Liste, und die Liste steht meist in den Repository-Namen. Die Frage lautet: lässt sich irgendeiner davon für sich deployen? Alles, was man sich von Microservices erhofft - unabhängige Releases, unabhängige Skalierung, ein Team, das ohne Abstimmungstermin liefern kann - folgt daraus, dass die Antwort ja ist, und keine andere Eigenschaft der Zeichnung zählt, wenn sie nein ist.

Ein Komponentendiagramm beantwortet sie, sofern Sie das Richtige zeichnen. Jeder deploybare Dienst ist eine Komponente; jeder veröffentlichte Vertrag eine Schnittstelle; jedes Ereignis ein «signal». Decken Sie dann einen Dienst mit der Hand ab: wenn das Verbleibende seinen Ersatz vollständig spezifiziert, kann dieser Dienst nach eigenem Zeitplan released werden.

In der Abbildung oben hängt das Gateway von IOrders ab - einem synchronen Vertrag, denn das Gateway kann dem Nutzer ohne Bestellung nicht antworten. Shipping und Billing zeigen auf OrderPlaced, ein Signal, das der Order service sendet und auf das er nicht wartet.

Beide unterschiedlich zu zeichnen ist der ganze Wert des Bildes. Die synchronen Kanten sind, wo Verfügbarkeit sich zusammensetzt: ist der Order service unten, gibt das Gateway einen Fehler zurück. Die Ereigniskanten sind, wo sie es nicht tut: ist Shipping unten, verzögert sich ein Paket und sonst nichts. Ein Diagramm, das beides als schlichte Pfeile zeichnet, hat den Unterschied getilgt, der entscheidet, wie das System ausfällt.

Das ist ein verteilter Monolith, und es ist die häufigste Form in der Produktion. Nichts daran ist illegal, nichts schlecht benannt, und es besteht jeden Review, weil es aussieht wie jedes andere Microservice-Diagramm. Was es sagt, wenn man die Pfeile statt der Kästen liest, ist, dass die vier Dienste zusammen deployt, zusammen getestet und zusammen oben sein müssen - das Team hat also jede Last der Verteilung auf sich genommen und jede Einschränkung eines Monolithen behalten.

Das Anzeichen ist zählbar: die Zahl synchroner Sprünge auf einer Anfrage. Einer ist in Ordnung. Zwei sind meist in Ordnung. Drei oder mehr, und die Verfügbarkeit des Ganzen ist das Produkt der Teile - vier Dienste mit je 99,9 % ergeben zusammen etwa 99,6 %, also drei Stunden im Monat, in denen niemand etwas bestellen kann.

Die Abhilfen sind auf derselben Zeichnung sichtbar. Lassen Sie Orders ein Ereignis publizieren und Pricing und Inventory darauf reagieren. Oder führen Sie zwei der Kästen zusammen, was eine legitime Antwort ist, die selten vorgeschlagen wird. Oder cachen Sie, was Pricing braucht, damit der Sprung nicht mehr im Anfragepfad liegt. Alle drei sind Änderungen an diesem Diagramm, und deshalb sind die zwanzig Minuten, es vor dem Bauen zu zeichnen, gut angelegt.

Die Notation behandelt der Leitfaden zum Komponentendiagramm, und fünf weitere Anordnungen - darunter der Zweiwege-Zyklus, den dieser Artikel nicht wiederholt - stehen in den Beispielen für Komponentendiagramme.