it-swarm.com.de

Möglichkeiten, DTO über Microservices hinweg zu teilen?

Mein Szenario ist wie folgt.

Ich entwerfe ein System, mit dem Daten von verschiedenen Sensortypen empfangen und konvertiert und dann beibehalten werden können, um später von verschiedenen Front-End- und Analysediensten verwendet zu werden.

Ich versuche, jeden Dienst so unabhängig wie möglich zu gestalten, aber ich habe einige Probleme. Das Team hat sich für ein DTO entschieden, das wir verwenden möchten. Die nach außen gerichteten Dienste (Sensordatenempfänger) empfangen die Daten auf ihre eigene Weise, konvertieren sie dann in ein JSON-Objekt (das DTO) und senden sie an den Nachrichtenbroker. Verbraucher der Nachrichten wissen dann genau, wie sie die Sensordatennachrichten lesen sollen.

Das Problem ist, dass ich dasselbe DTO in einigen verschiedenen Diensten verwende. Ein Update muss an mehreren Stellen implementiert werden. Natürlich haben wir es so gestaltet, dass ein paar zusätzliche oder fehlende Felder im DTO hier und da kein großes Problem sind, bis die Dienste aktualisiert wurden, aber es nervt mich immer noch und gibt mir das Gefühl, ich zu sein einen Fehler machen. Es könnte leicht zu Kopfschmerzen werden.

Mache ich das System falsch? Wenn nicht, wie können Sie dies umgehen oder zumindest meine Sorgen lindern?

33

Mein Rat? Teilen Sie diese DTOs nicht mit den Anwendungen in einer Bibliothek. Oder mach das jetzt zumindest nicht.

Ich weiß, scheint sehr kontraintuitiv. Sie duplizieren Code, richtig? Dies ist jedoch keine Geschäftsregel, sodass Sie flexibler sein können.

Der Dienst, der das DTO sendet, muss in seinem Nachrichtenvertrag starr sein, wie eine Rest-API. Der Dienst kann das DTO nicht so ändern, dass die anderen Dienste, die bereits die Informationen aus dem DTO verbrauchen, beschädigt werden.

Wenn ein neues Feld für DTO hinzugefügt wird, aktualisieren Sie die anderen Dienste, die dieses DTO verwenden , nur, wenn sie das neue Feld benötigen. Ansonsten vergiss es. Wenn Sie JSON als Inhaltstyp verwenden, haben Sie die Flexibilität, neue Attribute zu erstellen und zu senden, ohne den Code der Dienste zu unterbrechen, die diese neuen Felder in seinen tatsächlichen DTO-Versionen nicht zuordnen.

Aber wenn Sie diese Situation wirklich stört, können Sie die Dreierregel befolgen:

Bei der Wiederverwendung gibt es zwei "Dreierregeln": (a) Es ist dreimal so schwierig, wiederverwendbare Komponenten wie Einwegkomponenten zu erstellen, und (b) eine wiederverwendbare Komponente sollte in drei verschiedenen Anwendungen ausprobiert werden, bevor sie allgemein genug ist in eine Wiederverwendungsbibliothek aufnehmen.

Versuchen Sie also, etwas länger zu warten, bevor Sie dieses DTO für die Dienste freigeben.

40
Dherik

Wenn es um Microservices geht, sollten auch Services Entwicklungslebenszyklen unabhängig sein.* *

Unterschiedliche SLDC- und unterschiedliche Entwicklerteams

in einem echten MS-System könnten mehrere Teams an der Entwicklung des Ökosystems beteiligt sein, von denen jedes für einen oder mehrere Dienste verantwortlich ist. Diese Teams befinden sich möglicherweise in verschiedenen Büros, Städten, Ländern, Plänen ... Vielleicht kennen sie sich nicht einmal, was den Austausch von Wissen oder Code sehr schwierig macht (wenn möglich). Dies kann jedoch sehr praktisch sein, da gemeinsam genutzter Code auch eine Art Argumentation für das Teilen impliziert. Wichtig ist, dass alles, was für ein bestimmtes Team sinnvoll ist, nicht für ein anderes Team erstellt werden muss. Zum Beispiel kann es angesichts des DTO Kunde Je nach dem im Dienst befindlichen Dienst unterschiedlich sein, da Kunden von jedem Dienst unterschiedlich interpretiert (oder gesehen) werden.

Unterschiedliche Bedürfnisse, unterschiedliche Technologien

Mit isolierten SLDCs können Teams auch den Stapel auswählen, der ihren Anforderungen am besten entspricht. Das Auferlegen von DTOs, die in einer bestimmten Technologie implementiert sind, schränkt die Auswahlfähigkeit der Teams ein.

DTOs sind weder Geschäftsregeln noch Dienstleistungsverträge

Was sind DTOs wirklich? Einfache Objekte mit keinem anderen Ziel als dem Verschieben von Daten von einer Seite zur anderen. Taschen mit Gettern und Setzern. Es ist nicht die Art von "Wissen", die es wert ist, wiederverwendet zu werden, insgesamt, weil es überhaupt kein Wissen gibt. Ihre Volatilität macht sie auch zu schlechten Kandidaten für die Kopplung.

Im Gegensatz zu dem, was Dherik angegeben hat, muss es möglich sein, dass ein Dienst seine DTOs ändert, ohne dass andere Dienste gleichzeitig geändert werden müssen. Dienste sollten tolerante Leser, tolerante Schreiber und fehlertolerante sein. Andernfalls verursachen sie eine Kopplung, die die Dienstarchitektur nicht sinnvoll macht. Noch einmal, und im Gegensatz zu Dheriks Antwort, ist es wahrscheinlich, dass während der Zerlegung der Dienste etwas schief gelaufen ist, wenn drei Dienste genau dieselben DTOs benötigen.

Unterschiedliches Geschäft, unterschiedliche Interpretationen

Zwar könnte (und wird) es Querschnittskonzepte zwischen den Diensten geben, dies bedeutet jedoch nicht, dass wir ein kanonisches Modell auferlegen müssen, um alle Dienste zu zwingen, sie auf dieselbe Weise zu interpretieren.

Fallstudie

Angenommen, unser Unternehmen hat drei Abteilungen: Kundendienst, Vertrieb und Versand. Angenommen, jede dieser Versionen gibt einen oder mehrere Dienste frei.

Der Kundendienst implementiert aufgrund seiner Domain-Sprache Dienste rund um das Kundenkonzept, wobei Kunden Personen sind . Zum Beispiel werden Kunden modelliert als Name, Nachname, Alter, Geschlecht, E-Mail, Telefon usw.

Sagen Sie nun, Sales und Shipping modellieren ihre Dienste auch entsprechend ihrer jeweiligen Domain-Sprache. In diesen Sprachen erscheint auch das Konzept Kunde, jedoch mit einem subtilen Unterschied. Für sie sind Kunden nicht (unbedingt) Personen. Für Verkäufe sind Kunden eine Belegnummer a Kreditkarte und eine Rechnungsadresse =, für Versand a vollständiger Name und a Lieferadresse auch.

Wenn wir Sales und Shipping zwingen, das kanonische Datenmodell von Customer Service zu übernehmen, zwingen wir sie, sich damit zu befassen unnötige Daten, die zu unnötiger Komplexität führen können, wenn die gesamte Darstellung beibehalten und die Daten Kunde mit Kundendienst synchronisiert werden müssen.

Verwandte Links


* * Hier liegen die Stärken dieser Architektur

12
Laiv

Ich versuche, jeden Service so unabhängig wie möglich zu gestalten

Sie sollten events veröffentlichen. Ereignisse sind bestimmte Arten von Nachrichten, die eine solide Tatsache über etwas darstellen, das zu einem bestimmten Zeitpunkt passiert ist.

Jeder Dienst sollte eine sehr genau definierte Verantwortung haben und die Verantwortung haben, die mit dieser Verantwortung verbundenen Ereignisse zu veröffentlichen.

Darüber hinaus möchten Sie, dass Ihre Ereignisse geschäftliche Ereignisse darstellen, keine technischen Ereignisse. Z.B. ziehe OrderCancelled Ereignis einem OrderUpdated mit status: "CANCELLED" vor.

Auf diese Weise muss ein Dienst, wenn er auf eine stornierte Bestellung reagieren muss, nur eine bestimmte Art von Nachricht abhören, die nur für dieses Ereignis relevante Daten enthält. Z.B. Ein OrderCancelled benötigt wahrscheinlich nur einen order_id. Welcher Service, der darauf reagieren muss, hat bereits alles, was er über die Bestellung wissen muss, in seinem eigenen Datenspeicher gespeichert.

Wenn der Service jedoch nur OrderUpdated Ereignisse zum Abhören hatte, musste er den Ereignisfluss interpretieren, und es war nun abhängig vom Lieferauftrag, um korrekt abzuschließen, wenn ein Auftrag storniert wurde.

In Ihrem Fall kann es jedoch sinnvoll sein, einen Dienst zu haben, die Ereignisse abzuhören und einen neuen Strom von "Geschäftsereignissen" zu veröffentlichen, z. TemperatureThresholdExceeded, TemperatureStabilised.

Und seien Sie vorsichtig, wenn Sie zu viele Microservices erstellen. Microservices können eine großartige Möglichkeit sein, Komplexität zu kapseln. Wenn Sie jedoch keine geeigneten Servicegrenzen entdecken, liegt Ihre Komplexität in der Service-Integration. Und das ist ein Albtraum.

Es ist besser, zu wenige, zu große Dienste zu haben, als zu viele, zu kleine Dienste.

8
Pete