Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Aggregieren Sie mithilfe eines Gateways mehrere einzelne Anforderungen in einer einzigen Anforderung. Dieses Muster ist nützlich, wenn ein Client mehrere Aufrufe an verschiedene Back-End-Systeme durchführen muss, um einen Vorgang auszuführen.
Kontext und Problem
Um eine einzelne Aufgabe auszuführen, muss ein Client möglicherweise mehrere Aufrufe an verschiedene Back-End-Dienste durchführen. Eine Anwendung, die zur Ausführung einer Aufgabe auf viele Dienste angewiesen ist, muss für jede Anforderung Ressourcen aufwenden. Wenn der Anwendung neue Features oder Dienste hinzugefügt werden, werden zusätzliche Anforderungen benötigt, wodurch die Ressourcenanforderungen und Netzwerkaufrufe weiter erhöht werden. Diese Chattigkeit zwischen einem Client und einem Back-End kann sich negativ auf die Leistung und skalierung der Anwendung auswirken. Microservices-Architekturen haben dieses Problem häufiger gemacht, da Anwendungen, die um viele kleinere Dienste erstellt wurden, eine höhere Anzahl von dienstübergreifenden Aufrufen aufweisen.
Im folgenden Diagramm sendet der Client Anforderungen an jeden Dienst (nummeriert 1, 2 und 3). Jeder Dienst verarbeitet die Anforderung und gibt eine Antwort auf die Anwendung zurück (nummeriert 4, 5 und 6). Das Senden einzelner Anforderungen auf diese Weise über ein Mobilfunknetz mit hoher Latenz ist ineffizient und kann zu Verbindungsverlusten oder unvollständigen Antworten führen. Jede Anforderung kann parallel ausgeführt werden. Die Anwendung muss jedoch weiterhin Daten für jede Anforderung für separate Verbindungen senden, warten und verarbeiten, wodurch die Wahrscheinlichkeit eines Fehlers erhöht wird.
Lösung
Verwenden Sie ein Gateway, um die Anzahl der Interaktionen zwischen Client und Diensten zu reduzieren. Das Gateway empfängt Clientanforderungen, sendet Anforderungen an die verschiedenen Back-End-Systeme und aggregiert die Ergebnisse, bevor es sie an den Client zurücksendet.
Dieses Muster kann die Anzahl der Anforderungen verringern, die die Anwendung an Back-End-Diensten sendet, und die Anwendungsleistung über Netzwerke mit hoher Latenz verbessern.
Im folgenden Diagramm sendet die Anwendung eine Anforderung an das Gateway (1). Die Anforderung enthält ein Paket mit zusätzlichen Anforderungen. Das Gateway dekompiliert diese Anforderungen und verarbeitet jede Anforderung, indem sie an den relevanten Dienst (2) gesendet wird. Jeder Dienst gibt eine Antwort an das Gateway zurück (3). Das Gateway fasst die Antworten der einzelnen Dienste zusammen und sendet die Antwort an die Anwendung (4). Die Anwendung erstellt eine einzige Anforderung und erhält nur eine einzige Antwort vom Gateway.
Probleme und Überlegungen
Berücksichtigen Sie die folgenden Punkte, wenn Sie sich für die Implementierung dieses Musters entscheiden:
Das Gateway sollte keine Dienstkopplung über die Back-End-Dienste hinweg einführen.
Das Gateway sollte sich in der Nähe der Back-End-Dienste befinden, um die Latenz so weit wie möglich zu reduzieren.
Der Gatewaydienst kann einen einzelnen Fehlerpunkt (SPoF) einführen. Stellen Sie sicher, dass das Gateway ordnungsgemäß für die Verfügbarkeitsanforderungen Ihrer Anwendung ausgelegt ist.
Möglicherweise führt das Gateway zu einem Engpass. Stellen Sie sicher, dass das Gateway über eine angemessene Leistung verfügt, um die aktuelle Last zu verarbeiten, und kann skaliert werden, um Ihr erwartetes Wachstum zu erfüllen.
Führen Sie Lasttests gegen das Gateway durch, um sicherzustellen, dass Sie keine kaskadierenden Ausfälle bei Diensten verursachen.
Implementieren Sie ein robustes Design mithilfe von Techniken wie Bulkheads, Schaltkreisbruch, Wiederholungsversuche und Timeouts.
Wenn ein oder mehrere Dienstaufrufe zu lang dauern, kann es akzeptabel sein, ein Timeout durchzuführen und einen Teilsatz von Daten zurückzugeben. Berücksichtigen Sie, wie sich Ihre Anwendung in diesem Szenario verhält.
Verwenden Sie asynchrone Eingabe und Ausgabe (E/A), um sicherzustellen, dass eine Verzögerung am Back-End keine Leistungsprobleme in der Anwendung verursacht.
Implementieren Sie die verteilte Ablaufverfolgung mithilfe von Korrelations-IDs, um jeden einzelnen Anruf nachzuverfolgen.
Überwachen Sie Anforderungsmetriken und Antwortgrößen.
Betrachten Sie die Rückgabe von zwischengespeicherten Daten als Failoverstrategie, um Ausfälle zu behandeln.
Anstatt Aggregation in das Gateway zu integrieren, sollten Sie einen Aggregationsdienst hinter dem Gateway platzieren. Die Anforderungsaggregation hat wahrscheinlich unterschiedliche Ressourcenanforderungen als andere Dienste im Gateway und wirkt sich möglicherweise auf die Routing- und Offloadfunktion des Gateways aus.
Wann dieses Muster verwenden
Verwenden Sie dieses Muster in folgenden Fällen:
Ein Client muss mit mehreren Back-End-Diensten kommunizieren, um einen Vorgang auszuführen.
Der Client verwendet möglicherweise Netzwerke mit erheblicher Latenz, z. B. Mobilfunknetzwerken.
Dieses Muster ist möglicherweise nicht geeignet, wenn:
Sie möchten die Anzahl der Aufrufe zwischen einem Client und einem einzelnen Dienst für mehrere Vorgänge reduzieren. In diesem Szenario ist das Hinzufügen eines Batchvorgangs zum Dienst möglicherweise besser geeignet.
Der Client oder die Anwendung befindet sich in der Nähe der Back-End-Dienste und die Latenz ist kein wichtiger Faktor.
Arbeitslastgestaltung
Bewerten Sie, wie das Gatewayaggregation-Muster beim Entwurf einer Workload verwendet werden kann, um die in den Azure Well-Architected Framework-Säulen behandelten Ziele und Prinzipien zu berücksichtigen. Die folgende Tabelle enthält Anleitungen dazu, wie dieses Muster die Ziele jeder Säule unterstützt.
| Säule | So unterstützt dieses Muster die Säulenziele |
|---|---|
| Zuverlässigkeitsentwurfsentscheidungen helfen Ihrer Arbeitsauslastung, ausfallsicher zu werden und sicherzustellen, dass sie nach auftreten eines Fehlers wieder in einen voll funktionsfähigen Zustand versetzt wird. | Mit dieser Topologie können Sie die vorübergehende Fehlerbehandlung von einer verteilten Implementierung über Clients in eine zentralisierte Implementierung verschieben. - Empfehlungen für die Behandlung vorübergehender Fehler |
| Sicherheitsdesignentscheidungen tragen dazu bei, die Vertraulichkeit, Integrität und Verfügbarkeit der Daten und Systeme Ihrer Workload sicherzustellen. | Diese Topologie reduziert häufig die Anzahl der Touchpoints, die ein Client mit einem System hat, wodurch der öffentliche Oberflächenbereich und die Authentifizierungspunkte reduziert werden. Die zusammengefassten Backends können gegenüber Clients vollständig netzwerkisoliert bleiben. - SE:04 Segmentierung - SE:08 Ressourcenhärtung |
| Operational Excellence hilft, Arbeitsauslastungsqualität durch standardisierte Prozesse und Teamzusammenhalt zu liefern. | Dieses Muster ermöglicht es Back-End-Logik, unabhängig von Clients zu entwickeln. Diese Entkopplung bietet Ihnen die Flexibilität, die verketteten Dienstimplementierungen oder sogar Datenquellen zu ändern, ohne dass Clienttouchpoints geändert werden müssen. - OE:04 Tools und Prozesse |
| Performance Efficiency hilft Ihrem Workload durch Optimierungen bei Skalierung, Daten und Code, die Anforderungen effizient zu erfüllen . | Dieses Design kann zu einer geringeren Latenz führen als ein Design, bei dem der Client mehrere Verbindungen aufbaut. Zwischenspeichern in Aggregationsimplementierungen minimiert Aufrufe an Back-End-Systeme. - PE:03 Dienste auswählen - PE:08 Datenleistung |
Wenn dieses Muster Kompromisse innerhalb einer Säule einführt, sollten Sie sie gegen die Ziele der anderen Säulen berücksichtigen.
Example
Erwägen Sie eine mikroservicesbasierte Anwendung, die eine Bestellzusammenfassung für einen Kunden bietet. Wenn ein Benutzer eine Bestellseite öffnet, muss die Anwendung Daten aus mehreren Back-End-Diensten abrufen, z. B. einen Auftragsservice, einen Versanddienst und einen Kundendienst.
In einer Microservices-Architektur werden diese Dienste unabhängig implementiert und bereitgestellt. Ohne Aggregation muss der Client jeden Dienst direkt aufrufen, was die Latenz und Komplexität erhöht.
Um dieses Problem zu beheben, verwendet die Anwendung Azure API Management als Gatewayaggregationsschicht. Der Client sendet eine einzelne Anforderung an einen API-Verwaltungsvorgang, der als Sammelvorgang für Bestellinformationen fungiert. Die API-Verwaltung ruft dann die unterstützenden Back-End-APIs auf und gibt eine einheitliche Antwort an den Client zurück.
Sie können diese einfache Komposition implementieren, indem Sie die Api Management-Anforderungsrichtlinie verwenden, um Daten aus mehreren Diensten abzurufen und eine kombinierte Antwort zu erstellen. In diesem Beispiel werden die Back-End-Dienste in einer Azure Container Apps Umgebung ausgeführt, und Sie stellen jeden Back-End-Dienst als Container-App bereit, die vom direkten Clientzugriff ausgeblendet bleibt.
Laden Sie eine Visio-Datei dieser Architektur herunter.
Der Anforderungsfluss folgt den folgenden Schritten:
Der Client sendet eine Anfrage an einen Endpunkt für die Bestellübersicht, der über API Management verfügbar gemacht wird.
Die API-Verwaltung wendet eine Richtlinie an, die die Auftrags-, Versand- und Kundenprofildaten aus den Back-End-Diensten sammelt.
API-Management fasst die Antworten des Back-Ends zu einer einzelnen Nutzlast mit der Bestellzusammenfassung zusammen.
Die API-Verwaltung gibt die aggregierte Antwort auf den Client zurück.
Durch die Einführung dieser Aggregationsebene reduziert die Lösung Client-zu-Service-Roundtrips und vereinfacht Clientinteraktionen. Diese Ebene übernimmt die Aufgabe, nicht reagierende Back-End-Dienste robust zu behandeln und zu verhindern, dass sich Ausfälle auf die gesamte aggregierte Antwort ausweiten. Sichern Sie Ihre API-Verwaltungsrichtlinien durch anforderungsbezogene Timeouts, bedingte Fehlerbehandlung und Circuit Breakers ab.
Wenn bei einem der Back-End-Aufrufe eine Zeitüberschreitung auftritt oder ein Fehler zurückgegeben wird, kann API Management das Verhalten anwenden, das am besten zum Vorgang passt. Beispielsweise kann eine teilweise Antwort zurückgegeben werden, wenn fehlende Daten akzeptabel sind, oder die gesamte Anforderung schlägt fehl, wenn vollständige und konsistente Bestelldaten erforderlich sind. Treffen Sie diese Entscheidung im Richtlinienentwurf explizit, damit Clients ein vorhersehbares Verhalten erleben.
Dieser Ansatz funktioniert gut, wenn das Gateway eine leichtgewichtige Komposition, Strukturierung und Zusammenstellung von Antworten durchführt. Wenn für die Aggregation benutzerdefinierte Domänenlogik, komplexe Transformationen oder eine längere Orchestrierung erforderlich sind, platzieren Sie diese Funktionalität in einem dedizierten benutzerdefinierten Dienst hinter dem Gateway.
Sammeln Sie zur Überwachung Telemetrie über den vollständigen Anforderungspfad, damit Sie das API-Verwaltungsverhalten mit der Back-End-Latenz korrelieren können. Diese Sichtbarkeit ist in einem Gatewayaggregationsmuster wichtig, da ein einzelner Clientvorgang von mehreren Back-End-Aufrufen abhängt, und Fehler oder langsame Antworten in einer Abhängigkeit können sich auf das endgültige aggregierte Ergebnis auswirken. Verwenden Sie Azure Monitor als zentrale Observability-Plattform. Sammeln Sie API-Verwaltungsprotokolle und Metriken für den Gateway- und Richtlinienausführungspfad, und ermöglichen Sie die Überwachung für Container-Apps , um Anwendungsprotokolle und Metriken aus den Back-End-Container-Apps zu erfassen. Leiten Sie api-Verwaltung und Back-End-Telemetrie an einen Log Analytics-Arbeitsbereich für einheitliche Abfragen, Warnungen und Problembehandlung weiter. Mit dieser Telemetrie können Sie Timeoutmuster erkennen, ermitteln, welche Back-End-Abhängigkeit eine teilweise oder fehlgeschlagene Antwort verursacht hat, und Warnungen für erhöhte Latenz oder Fehlerraten erstellen.
Nächste Schritte
- Verwenden externer Dienste aus dem API-Verwaltungsdienst
- Richtlinie zum Senden von Anforderungen
- Dokumentation zu Container Apps