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.
Erstellen Sie Hilfsdienste, die im Auftrag von Consumerdiensten oder -anwendungen Netzwerkanforderungen senden. Ein Ambassador-Dienst kann als ein Out-of-Process-Proxy betrachtet werden, der sich beim Kunden befindet.
Dieses Muster kann nützlich sein, um allgemeine Clientkonnektivitätsaufgaben wie Überwachung, Protokollierung, Routing, Sicherheit (z. B. TLS) und Resilienzmuster auf sprachunabhängige Weise zu entladen. Es wird häufig mit älteren Anwendungen oder anderen Anwendungen verwendet, die schwer zu ändern sind, um ihre Netzwerkfunktionen zu erweitern. Es kann auch ein spezialisiertes Team aktivieren, um diese Features zu implementieren.
Kontext und Problem
Robuste cloudbasierte Anwendungen erfordern Features wie Schaltkreisbruch, Routing, Metering und Überwachung sowie die Möglichkeit, netzwerkbezogene Konfigurationsupdates vorzunehmen. Es kann schwierig oder unmöglich sein, ältere Anwendungen oder vorhandene Codebibliotheken zu aktualisieren, um diese Features hinzuzufügen, da der Code nicht mehr verwaltet wird oder vom Entwicklungsteam nicht einfach geändert werden kann.
Netzwerkanrufe erfordern möglicherweise auch eine erhebliche Konfiguration für Verbindung, Authentifizierung und Autorisierung. Wenn diese Aufrufe für mehrere Anwendungen verwendet werden, die mit mehreren Sprachen und Frameworks erstellt werden, müssen die Aufrufe für jede dieser Instanzen konfiguriert werden. Darüber hinaus müssen Netzwerk- und Sicherheitsfunktionen möglicherweise von einem zentralen Team innerhalb Ihrer Organisation verwaltet werden. Mit einer großen Codebasis kann es riskant sein, dass dieses Team Anwendungscode aktualisiert, mit dem sie nicht vertraut sind.
Lösung
Fügen Sie Clientframeworks und Bibliotheken in einen externen Prozess ein, der als Proxy zwischen Ihrer Anwendung und externen Diensten fungiert. Stellen Sie den Proxy in derselben Hostumgebung wie Ihre Anwendung bereit, um die Kontrolle über Routing, Resilienz, Sicherheitsfeatures zu ermöglichen und hostbezogene Zugriffsbeschränkungen zu vermeiden. Sie können auch das Botschaftermuster verwenden, um die Instrumentierung zu standardisieren und zu erweitern. Der Proxy kann Leistungsmetriken wie Latenz oder Ressourcennutzung überwachen, und diese Überwachung erfolgt in derselben Hostumgebung wie die Anwendung.
Funktionen, die an den Ambassador ausgelagert werden, können unabhängig von der Anwendung verwaltet werden. Sie können den Botschafter aktualisieren und ändern, ohne die älteren Funktionen der Anwendung zu stören. Außerdem können separate, spezialisierte Teams Sicherheits-, Netzwerk- oder Authentifizierungsfeatures implementieren und verwalten, die an den Botschafter verschoben wurden.
Ambassador-Dienste können als Sidecar bereitgestellt werden, um den Lebenszyklus einer konsumierenden Anwendung oder eines Dienstes zu begleiten. Wenn ein Botschafter auch von mehreren separaten Prozessen auf einem gemeinsamen Host geteilt wird, kann er als Daemon oder Windows-Dienst bereitgestellt werden. Wenn der verbrauchende Dienst containerisiert wird, sollte der Botschafter als separater Container auf demselben Host erstellt werden, wobei die entsprechenden Links für die Kommunikation konfiguriert sind.
Probleme und Überlegungen
Berücksichtigen Sie die folgenden Punkte, wenn Sie sich für die Implementierung dieses Musters entscheiden:
- Der Proxy erhöht den Latenzaufwand. Überlegen Sie, ob eine Clientbibliothek, die direkt von der Anwendung aufgerufen wird, ein besserer Ansatz ist.
- Berücksichtigen Sie die möglichen Auswirkungen der Einbeziehung generalisierter Features in den Proxy. Beispielsweise könnte der Botschafter Wiederholungen verarbeiten, jedoch könnte das eventuell unsicher sein, es sei denn, alle Operationen sind idempotent.
- Erwägen Sie einen Mechanismus, mit dem der Client Kontext an den Proxy und zurück an den Client übergeben kann. Fügen Sie z. B. HTTP-Anforderungsheader ein, um die Wiederholung zu deaktivieren, oder geben Sie die maximale Anzahl von Wiederholungsversuche an.
- Überlegen Sie, wie Sie den Proxy packen und bereitstellen.
- Überlegen Sie, ob Sie eine einzelne freigegebene Instanz für alle Clients oder eine Instanz für jeden Client verwenden möchten.
Wann dieses Muster verwendet werden soll
Verwenden Sie dieses Muster in folgenden Fällen:
- Sie müssen einen allgemeinen Satz von Clientkonnektivitätsfeatures für mehrere Sprachen oder Frameworks erstellen.
- Sie müssen die übergreifenden Kundenkonnektivitätsprobleme an Infrastrukturentwickler oder andere spezialisiertere Teams delegieren.
- Müssen Cloud- oder Clusterkonnektivitätsanforderungen in einer älteren Anwendung oder einer Anwendung unterstützen, die schwer zu ändern ist.
- Sie müssen Protokolle oder Verbindungsmuster unterstützen, die nicht einfach von API-Gateways, Dienstgittern oder Standard-Eingangs-/Ausgangssteuerelementen behandelt werden.
Dieses Muster ist möglicherweise nicht geeignet, wenn:
- Wenn die Latenz der Netzwerkanforderung wichtig ist. Ein Proxy führt zu einem gewissen Aufwand, obwohl minimal, und in einigen Fällen kann sich dies auf die Anwendung auswirken.
- Wenn Client-Konnektivitätsfunktionen von einer einzigen Programmiersprache genutzt werden. In diesem Fall könnte eine bessere Option eine Clientbibliothek sein, die als Paket an die Entwicklungsteams verteilt wird.
- Wenn Konnektivitätsfeatures nicht generalisiert werden können und eine tiefere Integration in die Clientanwendung erfordern.
- Wenn Ihre Anwendungsplattform vorgefertigte Lösungen wie ein Dienstgitter unterstützt, um mTLS, Datenverkehrsverwaltung und Richtlinienfunktionen zu verarbeiten. Verwenden Sie sie in diesem Fall, anstatt eine benutzerdefinierte Botschafterlösung zu erstellen.
Workloadentwurf
Ein Architekt sollte bewerten, wie das Botschaftermuster im Design ihrer Arbeitsauslastung verwendet werden kann, um die ziele und Prinzipien zu erfüllen, die in den Azure Well-Architected Framework-Säulen behandelt werden. Beispiel:
| 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. | Der durch dieses Muster erleichterte Vermittlungspunkt für die Netzwerkkommunikation bietet die Möglichkeit, Zuverlässigkeitsmuster zur Netzwerkkommunikation hinzuzufügen, z. B. Wiederholung oder Pufferung. - RE:07 Selbsterhaltung |
| Sicherheitsdesignentscheidungen tragen dazu bei, die Vertraulichkeit, Integrität und Verfügbarkeit der Daten und Systeme Ihrer Workload sicherzustellen. | Dieses Muster bietet die Möglichkeit, die Sicherheit in der Netzwerkkommunikation zu erweitern, die nicht direkt vom Client behandelt werden konnte. - SE:06 Netzwerksteuerungen - SE:07-Verschlüsselung |
Berücksichtigen Sie wie bei jeder Designentscheidung alle Kompromisse im Hinblick auf die Ziele der anderen Säulen, die mit diesem Muster eingeführt werden könnten.
Beispiel
Das folgende Diagramm zeigt eine Anwendung, die eine Anforderung an einen Remotedienst über einen Ambassador-Proxy stellt. Der Botschafter bietet Routing, Schaltkreisbruch und Protokollierung. Er ruft den Remotedienst auf und gibt dann die Antwort an die Clientanwendung zurück:
In einer containerisierten Umgebung würde dieser Botschafter als Sidecar-Container neben dem Anwendungscontainer ausgeführt. In nicht containerisierten Umgebungen würde sie als lokaler Prozess oder Windows-Dienst auf demselben Host implementiert.