Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
API-Kompositionsmuster
Dieses Muster verwendet einen API-Composer oder Aggregator, um eine Abfrage zu implementieren, indem einzelne Microservices aufgerufen werden, die Eigentümer der Daten sind. Anschließend werden die Ergebnisse kombiniert, indem ein In-Memory-Join durchgeführt wird.
Das folgende Diagramm veranschaulicht, wie dieses Muster implementiert wird.
Das Diagramm zeigt den folgenden Workflow:
-
Ein API-Gateway bedient die "/customer"-API, die über einen "Orders"-Microservice verfügt, der Kundenaufträge in einer Aurora-Datenbank verfolgt.
-
Der Microservice „Support“ verfolgt Probleme mit dem Kundensupport und speichert sie in einer Amazon- OpenSearch Service-Datenbank.
-
Der Microservice „CustomerDetails“ verwaltet Kundenattribute (z. B. Adresse, Telefonnummer oder Zahlungsdetails) in einer DynamoDB-Tabelle.
-
Die „GetCustomer“-Lambda-Funktion führt die APIs für diese Microservices aus und führt einen speicherinternen Join für die Daten durch, bevor sie an den Anforderer zurückgegeben werden. Dies hilft, Kundeninformationen in einem Netzwerkaufruf an die benutzerorientierte API einfach abzurufen, und hält die Schnittstelle sehr einfach.
Das API-Kompositionsmuster bietet die einfachste Möglichkeit, Daten aus mehreren Microservices zu sammeln. Die Verwendung des API-Kompositionsmusters hat jedoch die folgenden Nachteile:
-
Es eignet sich möglicherweise nicht für komplexe Abfragen und große Datensätze, die In-Memory-Joins erfordern.
-
Ihr Gesamtsystem ist weniger verfügbar, wenn Sie die Anzahl der Microservices erhöhen, die mit dem API-Composer verbunden sind.
-
Erhöhte Datenbankanforderungen erzeugen mehr Netzwerkverkehr, was Ihre Betriebskosten erhöht.
