Microservice, Serviceregistrierung, API-Gateway und Datenaustausch

Ich lese gerade eine ganze Reihe von Artikeln über Microservices-Architektur, aber es scheint, als würden sie die Dinge auf die einfachste Art und Weise behandeln, ohne näher auf Erklärungen einzugehen.

Um dir meine Fragen zu erklären, zeige ich dir meine aktuelle kleine Architektur:

Also, hier ist was ich verwenden möchte. Bevor ich etwas technisch mache, brauche ich mehr theoretische Informationen.

Beschreibung meiner Domain

ch habe einige mobile und browserbasierte Kunden, die in der Lage sind, sich mit einer Anwendung zu verbinden, ihre Benutzerinformationen abzurufen und Rechnungsinformationen zu den von ihnen gekauften Produkten abzurufe

In einer monolithischen Anwendung würde ich diese Architektur verwenden: - Präsentationsebene mit Mobile / Angular-Ember - Business-Ebene mit einer REST-API mit NGINX davor - DAL mit einer Standard-MySQL-Datenbank - Skalierbarkeit würde nur auf X angewendet. Achs

Ich möchte in diesem Fall eine Microservice-Architektur verwenden, weil sie "domänenskalierbar" und wirklich flexibel ist (und natürlich ein bisschen mehr darüber zu lernen).

Im Schema ist in jedem Dienst die einzige HTTP-URL enthalten, die von der betreffenden API verfügbar gemacht wird.

Frage

ein Senden Sie im (1) -Fluss "mobil" eine http-Anfrage anhttp: //myDomain.or/aut.

Meiner Meinung nach kann das APIGateway eine Standard-Service-Registry (Eureka, ZooKeeper oder etwas anderes) fragen, ob ein AuthSrv verfügbar ist, und seine Netzwerkadresse abrufen. Dann kann das ApiGateway den AuthSrv anfordern und auf den Server antworten

Ist das ein guter Weg, um es zum Laufen zu bringen? Gibt es nicht ein Latenzproblem beim Umgang mit X-Maschinen, um auf Daten zuzugreifen?

b / Das Flussmittel (2) konsultiert das Dienstregister. Wie kann die Dienstregistrierung verstehen, dass alle Anforderungen für / auth, auch für untergeordnete URLs wie / auth / other (sofern verfügbar), mit diesem Dienst unter der Adresse ip: port verknüpft sind?

c / Der Fluss (3) zeigt an, dass in der Dienstregistrierung ein AuthSrv verfügbar ist. Die (3 bis) zeigen den anderen: kein AuthSrv ist verfügbar. In einer kleinen Anwendung können wir zugeben, dass wir manchmal die Verfügbarkeit verlieren, aber in einem großen System, in dem Hunderte von Diensten miteinander verbunden sind, wie können wir mit Dienstmängeln umgehen?

d / In einem anderen Beitrag habe ich gefragt, wie Rechnungsinformationen gespeichert werden sollen, da sie sich auf einen Benutzer, einen anderen Dienst und eine andere Datenbank beziehen.

n einer Standardarchitektur hätte ich:

{
   billingInformations:{...},
   billingUser:ObjectId("userId")
}

n einer Microservice-Architektur wird empfohlen, Folgendes zu verwende

{
    billingInformations:{...},
    billingUser:"/user/12365" // URL corresponding the the user Resource in the other service
}

Ist dies der beste Weg, um mit "Service Data Sharing" umzugehen und die Dienste nicht zu koppeln?

e / Wann sollte ich in diesem speziellen Fall das AMQP-Protokoll anstelle des HTTP-Protokolls bevorzugen?

Danke für den Fortschritt