Wie gehen Sie in einer Microservices-Architektur mit zusammengesetzten Anfragen um, die geringfügige Daten verarbeiten und andere Dienste aufrufen müssen?

Question

Zum Beispiel, sobald der Benutzer den Zahlungsschritt in unserem Workflow erreicht, müssen viele verschiedene Dienste aufgerufen werden (wie z. B. Zahlung, E-Mail-Generierung, Inhaltserzeugung). Sollte der Front-End diesen Service bearbeiten oder sollte er für diese Art von Anfrage ausgelegt sein? Wenn ja, wie sollte dieser Dienst so gestaltet sein, dass er Kompositanfragen bearbeiten kann, ohne speziell zu kodieren, woraus diese Anfragen bestehen?

Answer 1

Sie suchen nach etwas in Richtung BPEL, um Ihre Geschäftslogik zu abstrahieren. Sofern Sie dies nicht ausdrücklich externalisieren müssen, empfehle ich Ihnen dringend, dies nicht zu tun. Es ist viel schwieriger zu testen und fügt Ihrem Service eine erhebliche Komplexität hinzu.

Das gesagt, möchten Sie wahrscheinlich Ihre anderen Dienste mit einer Fassade umhüllen, so dass Sie von den Details der Anrufe isoliert sind. Dadurch kann Ihre Logik testbar sein und diese Service-Implementierungen können sich unabhängig vom Rest Ihrer Anwendung ändern.

Answer 2

Es hängt wirklich davon ab, worauf Sie sich beziehen.

Composite-UI

In der Benutzeroberfläche Sie ein Composite-ui bauen sollte. Ein (Mikro-) Dienst sollte für eine vertikale statt für eine horizontale Schicht verantwortlich sein. Zum Beispiel sollten Business-Layer oder Daten-Layer durch Branchen wie Finanzen, Vertrieb usw. ersetzt werden, und innerhalb dieser können Sie noch kleinere Komponenten erstellen. Diese Komponenten sind technisch für ein Geschäftsproblem verantwortlich, vom Speicher bis zur Benutzeroberfläche. Ich benutze meistens ein Framework wie AngularJS, wo ein Teil einer Benutzeroberfläche einige Daten anfordert und verschiedene Dienste die Daten hinzufügen können. Zum Beispiel eine Liste empfohlener Bücher in Amazon. Sie beginnen mit der URL, die auf eine einzelne Produkt-ID verweist. Sie erhalten Buchinformationen von ServiceA, Preis von ServiceB, Versandkosten von ServiceC, Rabatte von ServiceD usw. Es gibt auch eine Liste empfohlener Bücher. Die Liste enthält mehrere Produkt-IDs von ServiceB (zum Beispiel) und diese führen zu mehreren erneuten Anfragen an ServiceA für Buchinformationen, wie zum Beispiel Name & Bild-URL.

Jetzt kann eine Rechnung gleich sein, oder eine E-Mail. Erstellen Sie es, als wäre es eine zusammengesetzte UI.

Integration

Wenn Sie möchten, um Daten abzurufen an ein externes System, zum Beispiel, gibt es keine Benutzeroberfläche in der Lage sein zu kommunizieren. Es gehört nicht zu Finanzen oder Umsatz oder was auch immer. Erstellen Sie eine neue Grenze, einen beschränkten Kontext, zum Beispiel IT/Ops. Ihre Verantwortung liegt beispielsweise in der Integration mit Dritten. Es besitzt dieses Problem.

Es kann dann mehrere Schnittstellen definieren, wie IProvideBookInformation und IProvideBookPrice. Die IProvideBookInformation kann eine Methode wie BookInfo ProvideBook(Guid id) haben, wobei BookInfo ein DTO ist, das ebenfalls diesem IT/Operations-Dienst gehört.

Dann sind Sales und Finance verantwortlich für die Implementierung dieser Schnittstelle. Sie sind also von dieser Schnittstelle abhängig. Stellen Sie das dann so wie Sie möchten, in .NET World könnten Sie beispielsweise NuGet verwenden. Nach der Bereitstellung dieses IT/Operations-Dienstes stellen Sie auch die Komponenten von anderen Diensten bereit, die diese Schnittstellen implementieren. Es ist vergleichbar mit dem Beispiel einer Composite UI, bei der eine Website mit mehreren anderen Komponenten bereitgestellt wird, die die Daten für die Benutzeroberfläche bereitstellen. Aber jetzt ist es ein Backend-Integrationsdienst, anstatt etwas mit einer Benutzerschnittstelle. Der IT/Operations-Dienst hat keine direkten Abhängigkeiten von der Implementierung.Wenn es jedoch Implementierungen des Dienstes benötigt, lädt es alle Komponenten, die es finden kann, und sucht nach Implementierungen seiner erforderlichen Schnittstelle. Sobald die Implementierung gefunden wurde, wird sie ausgeführt und erhält Daten zurück. Die Komponenten könnten direkt in die Datenbank gehen, was einfach ist und wir alle mögen es einfach. Es kann aber auch Daten über eine REST-API anfordern oder was immer Ihnen am besten gefällt. Sie sammelt alle Daten auf diese Weise über die Schnittstellen, deren Eigentümer sie sind, aber die von anderen Diensten bereitgestellten Implementierungen. Sobald alle Daten gesammelt sind, ruft es die dritte Partei an und tut, was immer es tun soll.

Answer 3

Ich denke, dass Microservices Warteschlangen verwenden müssen, um mit dem einen oder anderen zu kommunizieren.

Das Frontend kann den Aufruf generieren, aber das Backend muss die Logik speichern, für die Warteschlangen benachrichtigt werden müssen, sobald eine Aktion stattgefunden hat.

ich denke, dass RabbitMq ein großartiges Werkzeug für diese Art von Design ist. Zum Beispiel:

• Benutzerpass Stufe 1 an der Kasse
  • Senden - userid, E-Mail-Queue
  • send to emailqueue_standby - userid, Queue emailcontent_standby Artikeln
  • Senden - userid, paymentdata zu paymentchecking Queue
• Benutzer vollständige Stufe 2 an der Kasse
  • verbrauchen msg von emailqueue_standby Queue -> Code aktiviert, die E-Mail-
  • verbrauchen msg von paymentchecking Queue senden -> aktiviert Code, um die Zahlungsdaten überprüfen -> post Antwort auf approve_payment_data -> Wert user_id, deal_id
  • msg von approve_payment_data verbrauchen Queue -> wenn der Benutzer der Zahlung weiterhin zugelassen, sonst auf der Bühne stoppen zurück 1.

so kann diese Strömung ermöglicht es Ihnen, viele Stufen auf einmal, ohne Code blockiert und auch ermöglichen, verteilen die Last zwischen dem zu aktualisieren Backend-Server.