none
Inter Microservice Kommunikation RRS feed

  • Frage

  • Hallo zusammen,

    ich habe gerade angefangen mich mit Microservice Architekturen zu beschäftigen und komme gedanklich irgendwie nicht weiter. Ich habe verstanden, dass jeder Service, unabhängig von event sourcing etc, seine eigene DB/Persistierung haben soll. Services sollen gemäß DDD am Bounded Context geschnitten werden. Die direkte synchrone (REST) Kommunikation zwischen Services gilt als Anti Pattern.

    Sollten Daten eines anderen Service benötigt werden, sollten diese relevanten Daten in die DB des nutzenden Services (eventual consistency als ok vorausgesetzt). Es gibt sogenannte Integration- und Domain Events. Ein Customer mit vielen Attributen ist z.B. im Order Service der "Buyer" mit weit weniger Attributen. Stammdaten also soweit ok. 

    Aber wie gehe ich mit Bewegungsdaten um?

    Einmal angenommen, es sollen Bestellungen verarbeitet werden. Während der Bestellung soll überprüft werden, ob der jeweilige Kunde überhaupt bezugsberechtigt für einen Artikel ist. Das würde also heißen, dass im OrderService ein Buyer mit den jeweiligen Bezugsberechtigungen existiert. Wenn ein neuer Customer im CustomerService angelegt wird, feuert dieser ein Event mit den jeweiligen Daten, der OrderService verarbeitet das Event und legt die Daten inkl. Bezugsberechtigungen in seiner DB ab.

    Weiterhin angenommen, dass der OrderService als Antwort auf die Bestellung die erwartete Lieferzeit zurückmelden soll. Etwas vereinfachend würde ich sagen, dass hier z.B. Lagerbestände berücksichtigt werden müssen. Sollen die dann auch immer vom WarehouseService in den OrderService gesynced werden? Außerdem müssen Transportwege und Fahrzeugverfügbarkeiten berücksichtigt werden, die eigentlich dem TransportationService gehören. Sollen die dann auch gesynced werden?

    Selbst wenn ich nach der Auftragserstellung einen Event auslöse, der dann vom TransportationService zwecks Lieferung verarbeitet werden soll, benötigt der TranportationService die Daten bezüglich der Lagerbestände bzw den Warehousservice für das Picking. 

    Das wird doch dann eine Riesen OrderService DB. Ich glaube, ich bin hier gedanklich irgendwo falsch abgebogen. Vielleicht liege ich hier falsch, aber es sieht für mich so aus, also ob es problematisch ist, Ergebnisse am Ende einer "Microservices Kette" an den User zurückzuliefern. Sollte über eine Website bestellt werden, geht das ja vielleicht noch mit SignalR o.ä. aber bei einer RestSchnittstelle und einem FatClient am anderen Ende, der von einer anderen Firma entwickelt wird?

    Danke für Eure Hilfe.

    Gruß

    Harald

    Dienstag, 19. März 2019 13:27