it-swarm.com.de

Kommunikation zwischen zwei Microservices

Ich erstelle ein Projekt mit Microservices-Architektur. Und ich habe zwei Microservices erstellt.

Eine davon ist für Produktentität, die andere für Rechnungsentität. Sie haben ihre eigenen Endpunkte und sind mit dem Gateway verbunden (ich verwende Jhipster Microservice-Architektur). 

Die bill-ms sollte auf die Liste der Produkte zugreifen. Ich frage mich, wie ich zwischen diesen beiden MS kommunizieren kann. Ich habe drei Ansätze im Kopf:

  1. Senden Sie eine Anfrage von bill-ms an die Warteschlange - wie rabbitMQ, um diese Produkte mit diesen IDs von product-ms zu erhalten (ich weiß nicht, was hier ein Engpass ist)

  2. Senden Sie eine Anfrage an das Gateway für den Produktservice und erhalten Sie das Produkt von dort (ich bin wegen der Datengröße zwischen den beiden besorgt, und auf diese Weise berühre ich die Datenbank nicht direkt, daher bin ich immer auf das Gateway angewiesen.)

  3. Ich kann die Repositories, Services und Entities in bill-ms duplizieren (es ist eine hässliche Methode, und ich denke, es verstößt gegen die Regeln der ms-Architektur und die Wartung ist sehr schwierig).

Wenn Sie andere Ansätze haben, freue ich mich, dass Sie sie mir mitteilen.

Bearbeiten

  1. Jetzt weiß ich, was der Engpass ist: Sagen Sie, dass es 3 Instanzen von bill-ms gibt und wie entscheidet rabbitMQ, welche Instanz zu antworten ist? oder wie soll ich Ribbon sagen " gebt mir die kostenlose Instanz von bill-ms, um die Anforderung von rabbitMQ " zum Lastausgleich zu abonnieren.
35
SerhatTR

Ich bin mir nicht sicher, ob meine Antwort richtig ist. Ich lerne noch selbst .. Aber ich kann Ihnen sagen, wie ich meine Mikroservices-Versuche implementiert habe. 

Zuerst begann ich mit HTTP kommunikationsbasierten Microservices mit diesem Blog . Das funktioniert gut, aber das Problem ist, dass Sie Abhängigkeiten zwischen Ihren Diensten erstellen. Dienst A muss einen Dienst B kennen und muss direkt (über die Dienstermittlung usw.) aufrufen. Dies ist es, was Sie generell bei der Entwicklung von Microservices zu vermeiden versuchen.

Ein anderer Ansatz, mit dem ich in letzter Zeit angefangen habe, ist die Verwendung eines message bus. Es ist tatsächlich die dritte Option, die Sie in Ihrer Frage berührt haben.

Ich habe einen Dienst A, der Personen speichert (nur ein Beispiel). Was der Dienst tut, wenn er eine neue Person erstellt, ist: Er sendet eine event an einen RabbitMQ-Bus: personCreatedEvent. Wenn es andere Dienste gibt, die an solchen Ereignissen interessiert sind, können sie subscribe für sie. Diese interessierten Dienste speichern die relevanten Informationen, an denen sie interessiert sind, in ihren eigenen Datenspeichern.

Bei diesem letzten Ansatz besteht keine wirkliche Abhängigkeit zwischen Ihren Diensten, da diese nicht direkt miteinander kommunizieren. Dienst A kennt Dienst B nicht, da B nur Ereignisse an RabbitMQ an den gewünschten Dienst an diese Ereignisse sendet und umgekehrt.

Natürlich haben Sie zwischen den Datenspeichern über den Dienst Duplikationen. Dies kann jedoch auch rentabel sein, z. Dienst B muss nicht dasselbe Schema oder denselben Datenspeichermechanismus wie Dienst A verwenden. Er speichert die relevanten Informationen nur so, wie es für diesen Dienst am besten ist.

32
Kaj

Haben Sie angesehen http://stytex.de/blog/2016/03/25/jhipster3-microservice-tutorial/ Teil 2: Abschnitt zur Kommunikation zwischen den Diensten. Es führt Sie durch ein bestimmtes Beispiel, wie es erreicht wird 

2
jvence

Lassen Sie mich versuchen, einige weitere Details zu diesem Szenario hinzuzufügen, um hervorzuheben, was im Zusammenhang mit Product und Biiling möglicherweise als Ereignis eingestuft wird oder nicht. Das Billing-MS muss nur dann mit Product-Ms sprechen, wenn eine Bestellung aufgegeben wird. Die Bestellung einer Bestellung würde hauptsächlich für eine separate MS sein, sagen wir zum Beispiel eine Order-MS. Wenn eine Bestellung erstellt oder aufgegeben wird, enthält sie Informationen zu Produkten als Werbebuchungen.

Das Anlegen einer Bestellung kann als Ereignis betrachtet werden. Wenn ein Auftragserstellungsereignis auftritt, kann es in eine Warteschlange für den Abrechnungsdienst verschoben werden. Die Warteschlange sollte als Arbeitswarteschlange in RabbitMQ implementiert werden. Auf diese Weise können mehrere Instanzen der Billing-MS dieselbe Warteschlange abonnieren, diese wird jedoch nur von einem einzigen Mitarbeiter verarbeitet. RIBBON spielt keine Rolle bei der Registrierung eines Dienstes als Worker bei RabbitMQ. Jede Instanz registriert sich in einer Warteschlange, und RabbitMQ entscheidet RoundRobin, welche Instanz des Abrechnungsdienstes dieses Ereignis verarbeiten soll.

Das Abrufen von Details zu Produkten in einer Bestellung für die Rechnungssteller sollte eine über das Menüband verteilte Last-zu-Dienst-Anruflast sein (wenn dies der Fall ist). Produktdetails zu erhalten, ist nicht wirklich ein Ereignis, das Aufgeben einer Bestellung ist daher der Unterschied. 

Gateway sollte auch zum Offenlegen Ihrer Edge-Dienste verwendet werden. Für Service-to-Service-Anrufe wäre ein Sprung über den Gateway-Dienst nicht ideal.

0
sg4j

Eine Option ist das Senden einer Anfrage zur Abrechnung mit dem registrierten Namen in der Eureka-Registrierdatenbank.

0
freemanpolys