Anmerkung
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.
GILT FÜR: Alle API Management-Ebenen
Dieser Artikel enthält Informationen zu den Rollen und Features der Gatewaykomponente von API Management und vergleicht die bereitstellbaren Gateways.
Verwandte Informationen:
Eine Übersicht über API Management-Szenarien, -Komponenten und -Konzepte finden Sie unter Informationen zu API Management.
Weitere Informationen zu den API Management-Dienstebenen und -features finden Sie unter:
Rolle des Gateways
Das Gateway von API Management (auch Datenebene oder Runtime genannt) ist die Dienstkomponente, die als Proxy für API-Anforderungen fungiert sowie Richtlinien anwendet und Telemetriedaten sammelt.
Das Gateway übernimmt insbesondere folgende Aufgaben:
- Es fungiert als Fassade für Back-End-Dienste, indem es API-Aufrufe akzeptiert und an geeignete Back-Ends weiterleitet.
- Überprüft API-Schlüssel und andere Anmeldeinformationen wie JWTs und Zertifikate, die bei Anfragen mitgesendet werden.
- Es erzwingt Nutzungskontingente und Ratenbegrenzungen.
- Es transformiert optional Anforderungen und Antworten gemäß der Angabe in Richtlinienanweisungen.
- Bei entsprechender Konfiguration speichert es Antworten zwischen, um die Antwortlatenz zu verbessern und Back-End-Dienste zu entlasten.
- Es gibt Protokolle, Metriken und Ablaufverfolgungen für die Überwachung, Berichterstellung und Problembehandlung aus.
Note
Alle Anforderungen an das API Management-Gateway, einschließlich derjenigen, die von Richtlinienkonfigurationen abgelehnt wurden, werden auf konfigurierte Ratengrenzwerte, Kontingente und Abrechnungsgrenzwerte angerechnet, wenn sie auf der Dienstebene angewendet werden.
Verwaltet und selbstgehostet
API Management bietet sowohl verwaltete als auch selbstgehostete Gateways:
Verwaltet: Das verwaltete Gateway ist die Standardgatewaykomponente, die in Azure für jede API Management-Instanz auf jeder Dienstebene bereitgestellt wird. Ein eigenständiges verwaltetes Gateway kann auch einem Arbeitsbereich in einer API Management-Instanz zugeordnet werden. Beim verwalteten Gateway wird der gesamte API-Datenverkehr über Azure geleitet – unabhängig davon, wo die Back-Ends, die die APIs implementieren, gehostet werden.
Note
Aufgrund von Unterschieden in der zugrunde liegenden Dienstarchitektur weisen die in den verschiedenen API Management-Dienstebenen bereitgestellten Gateways einige Unterschiede bei den Funktionen auf. Ausführliche Informationen finden Sie im Abschnitt Featurevergleich: Verwaltete und selbstgehostete Gateways.
Selbstgehostet: Das selbstgehostete Gateway ist eine optionale, containerisierte Version des standardmäßigen verwalteten Gateways, die für ausgewählte Dienstebenen verfügbar ist. Es ist hilfreich für Hybrid- und Multicloudszenarien, in denen die Gateways unabhängig von Azure in den gleichen Umgebungen ausgeführt werden müssen, in denen API-Back-Ends gehostet werden. Das selbstgehostete Gateway ermöglicht es Kunden mit hybrider IT-Infrastruktur, lokal und in Clouds gehostete APIs über einen einzelnen API Management-Dienst in Azure zu verwalten.
Das selbstgehostete Gateway ist als Linux-basierter Docker-Container gepackt und wird üblicherweise in Kubernetes (sowohl Azure Kubernetes Service als auch Kubernetes mit Azure Arc-Unterstützung) bereitgestellt.
Jedes selbstgehostete Gateway ist einer Gatewayressource in einer cloudbasierten API Management-Instanz zugeordnet, über die sie Konfigurationsupdates erhält und den Status kommuniziert.
Featurevergleich: Verwaltete und selbstgehostete Gateways
In den folgenden Tabellen werden die Features verglichen, die in den folgenden API Management-Gateways verfügbar sind:
- Klassisch: Das verwaltete Gateway, das in den Dienstebenen „Developer“, „Basic“, „Standard“ und „Premium“ verfügbar ist (früher als dedizierte Ebenen gruppiert)
- V2: Das verwaltete Gateway, das in den Tarifen Basic v2, Standard v2 und Premium v2 verfügbar ist
- Verbrauch: Das verwaltete Gateway, das auf der Stufe „Verbrauch“ verfügbar ist
- Selbst gehostet: Das optionale selbst gehostete Gateway, das für ausgewählte Dienstebenen verfügbar ist
- Arbeitsbereich: Das verwaltete Gateway, das in einem Arbeitsbereich in ausgewählten Dienstebenen verfügbar ist
Note
- Einige Features von verwalteten und selbstgehosteten Gateways werden nur auf bestimmten Dienstebenen oder in bestimmten Bereitstellungsumgebungen für selbstgehostete Gateways unterstützt.
- Stellen Sie für die aktuell unterstützten Features des selbstgehosteten Gateways sicher, dass Sie für das Containerimage des selbstgehosteten Gateways ein Upgrade auf die neueste Hauptversion durchgeführt haben.
- Weitere Informationen finden Sie auch in den Einschränkungen für selbstgehostete Gateways.
Infrastructure
| Featureunterstützung | Classic | V2 | Consumption | Self-hosted | Workspace |
|---|---|---|---|---|---|
| Benutzerdefinierte Domänen | ✔️ | ✔️ | ✔️ | ✔️ | ❌ |
| Integrierter Cache | ✔️ | ✔️ | ❌ | ❌ | ✔️ |
| Externer Redis-kompatibler Cache | ✔️ | ✔️ | ✔️ | ✔️ | ❌ |
| Einschleusung virtueller Netzwerke | Entwickler, Premium | Premium v2 | ❌ | ✔️1,2 | ✔️ |
| Eingehende private Endpunkte | ✔️ | Standard v2, Premium v2 | ❌ | ❌ | ❌ |
| Integration ausgehender virtueller Netzwerke | ❌ | Standard v2, Premium v2 | ❌ | ❌ | ✔️ |
| Verfügbarkeitszonen | Premium | Premium v2 | ❌ | ✔️1 | ❌ |
| Bereitstellung über mehrere Regionen hinweg | Premium | ❌ | ❌ | ✔️1 | ❌ |
| Stammzertifikate einer Zertifizierungsstelle für die Zertifikatüberprüfung | ✔️ | ✔️6 | ❌ | ✔️3 | ❌ |
| Verwaltete Domänenzertifikate | ✔️ | ❌ | ✔️ | ❌ | ❌ |
| TLS-Einstellungen | ✔️ | ✔️ | ✔️ | ✔️ | ❌ |
| HTTP/2 (Client-zu-Gateway) | ✔️4 | ✔️4 | ❌ | ✔️ | ❌ |
| HTTP/2 (Gateway-zu-Back-End) | ❌ | ✔️5 | ❌ | ✔️5 | ❌ |
| API-Bedrohungserkennung mit Defender for APIs | ✔️ | ✔️ | ❌ | ❌ | ❌ |
1 Hängt davon ab, wie das Gateway bereitgestellt wird, liegt jedoch in der Verantwortung des Kunden.
2 Konnektivität mit dem selbst gehosteten Gateway v2 Konfigurationsendpunkt erfordert die DNS-Auflösung des Endpunkthosts.
3 Zertifizierungsstellenstammzertifikate für selbstgehostete Gateways werden separat pro Gateway verwaltet
4 Das Clientprotokoll muss aktiviert sein.
5 Konfigurieren Sie mithilfe der forward-request-Richtlinie.
6 Konfigurieren Sie CA-Zertifikatsdetails für die Backend-Zertifikatauthentifizierung in Backend-Einstellungen.
Back-End-APIs
| Featureunterstützung | Classic | V2 | Consumption | Self-hosted | Workspace |
|---|---|---|---|---|---|
| OpenAPI-Spezifikation | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| WSDL-Spezifikation | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| WADL-Spezifikation | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Logik-App | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| App-Dienst | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Funktions-App | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Container-App | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Service Fabric | Entwickler, Premium | ❌ | ❌ | ❌ | ❌ |
| Passthrough-GraphQL | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Synthetisches GraphQL | ✔️ | ✔️ | ✔️1 | ✔️1 | ❌ |
| Pass-through-WebSocket | ✔️ | ✔️ | ❌ | ✔️ | ✔️ |
| Passthrough-gRPC | ❌ | ❌ | ❌ | ✔️ | ❌ |
| OData | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Azure OpenAI in Microsoft Foundry-Modellen und LLMs | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Pass-Through-MCP-Server | ✔️ | ✔️ | ❌ | ✔️ | ❌ |
| Exportieren der REST-API als MCP-Server | ✔️ | ✔️ | ❌ | ✔️ | ❌ |
| A2A-Agent | ❌ | ✔️ | ❌ | ❌ | ❌ |
| Schaltkreisbrecher im Back-End | ✔️ | ✔️ | ❌ | ✔️ | ✔️ |
| Lastenausgleichs-Back-End-Pool | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
Policies
Verwaltete und selbstgehostete Gateways unterstützen alle verfügbaren Richtlinien in Richtliniendefinitionen, mit folgenden Ausnahmen: Details zu den einzelnen Richtlinien finden Sie in der Richtlinienreferenz.
| Featureunterstützung | Classic | V2 | Consumption | Self-hosted1 | Workspace |
|---|---|---|---|---|---|
| Dapr-Integration | ❌ | ❌ | ❌ | ✔️ | ❌ |
| ServiceBus-Integration (Vorschau) | ✔️ | ❌ | ❌ | ❌ | ❌ |
| GraphQL-Resolver und GraphQL-Validierung | ✔️ | ✔️ | ✔️ | ❌ | ❌ |
| Abrufen des Autorisierungskontexts | ✔️ | ✔️ | ✔️ | ❌ | ❌ |
| Authentifizierung mit verwalteter Identität | ✔️ | ✔️ | ✔️ | ✔️ | ❌ |
| Semantische Zwischenspeicherung für Azure OpenAI und LLM | ✔️ | ✔️ | ✔️ | ❌ | ❌ |
| Kontingent und Ratenbegrenzung | ✔️ | ✔️ | ✔️2 | ✔️3 | ✔️ |
1 Konfigurierte Richtlinien, die vom selbstgehosteten Gateway nicht unterstützt werden, werden während der Richtlinienausführung übersprungen.
2 Die Richtlinien für Ratengrenzwerte nach Schlüssel, Kontingent nach Schlüssel und KI-Tokengrenzwerte sind auf der Verbrauchsebene nicht verfügbar.
3 Ratengrenzwerte in einem selbstgehosteten Gateway können so konfiguriert werden, dass sie lokal (clusterknotenübergreifend zwischen Gatewayinstanzen) synchronisiert werden, z. B. per Helm Chart-Bereitstellung für Kubernetes oder mithilfe der Bereitstellungsvorlagen im Azure-Portal. Ratengrenzwerte werden jedoch nicht mit anderen in der API Management-Instanz konfigurierten Gateway-Ressourcen synchronisiert, einschließlich des verwalteten Gateways in der Cloud.
Weitere Informationen
Monitoring
Ausführliche Informationen zu Überwachungsoptionen finden Sie unter Einblick in Azure API Management.
| Featureunterstützung | Classic | V2 | Consumption | Self-hosted | Workspace |
|---|---|---|---|---|---|
| API-Analyse | ✔️ | ✔️1 | ❌ | ❌ | ❌ |
| Application Insights | ✔️ | ✔️ | ✔️ | ✔️2 | ✔️ |
| Protokollierung über Event Hubs | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Metriken in Azure Monitor | ✔️ | ✔️ | ✔️ | ✔️ | ❌ |
| OpenTelemetry Collector | ❌ | ❌ | ❌ | ✔️ | ❌ |
| Anfordern von Protokollen in Azure Monitor und Log Analytics | ✔️ | ✔️ | ❌ | ❌ 3 | ❌ |
| Lokale Metriken und Protokolle | ❌ | ❌ | ❌ | ✔️ | ❌ |
| Anforderungsablaufverfolgung | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
1 Die v2-Ebenen unterstützen Azure Monitor-basierte Analysen.
2 Das Gateway verwendet den integrierten Speicherpuffer von Azure Application Insights und bietet keine Zustellungsgarantien.
3 Das selbstgehostete Gateway sendet derzeit keine Ressourcenprotokolle (Diagnoseprotokolle) an Azure Monitor. Sie können optional Metriken an Azure Monitor senden oder Protokolle lokal konfigurieren und speichern (an dem Ort, an dem das selbstgehostete Gateway bereitgestellt wird).
Authentifizierung und Autorisierung
Verwaltete und selbst gehostete Gateways unterstützen alle verfügbaren API-Authentifizierungs- und Autorisierungsoptionen mit den folgenden Ausnahmen.
| Featureunterstützung | Classic | V2 | Consumption | Self-hosted | Workspace |
|---|---|---|---|---|---|
| Anmeldeinformationsverwaltung | ✔️ | ✔️ | ✔️ | ❌ | ❌ |
Gatewaydurchsatz und -skalierung
Important
Der Durchsatz wird durch die Anzahl und Rate gleichzeitiger Clientverbindungen, durch die Art und Anzahl konfigurierter Richtlinien, durch Nutzdatengrößen, durch die Back-End-API-Leistung und durch andere Faktoren beeinflusst. Der Durchsatz selbstgehosteter Gateways hängt auch von der Computekapazität (CPU und Arbeitsspeicher) des Hosts ab, auf dem es ausgeführt wird. Führen Sie Gatewayauslastungstests unter den voraussichtlichen Produktionsbedingungen durch, um den erwarteten Durchsatz richtig zu ermitteln.
Verwaltetes Gateway
Informationen zum geschätzten maximalen Gatewaydurchsatz der API Management-Dienstebenen finden Sie unter API Management – Preise.
Important
Durchsatzwerte werden lediglich zur Information angegeben und dürfen nicht als Grundlage für die Kapazitäts- und Budgetplanung herangezogen werden. Weitere Informationen finden Sie unter API Management – Preise.
Klassische Ebenen
- Skalieren Sie die Gatewaykapazität, indem Sie Skalierungseinheiten hinzufügen und entfernen, oder upgraden Sie die Dienstebene. (Auf der Developer-Dienstebene steht keine Skalierung zur Verfügung.)
- Auf den Dienstebenen „Basic“, „Standard“ und „Premium“ kann optional die Autoskalierung von Azure Monitor konfiguriert werden.
- Auf der Dienstebene „Premium“ können Sie optional Gatewaykapazität hinzufügen und auf mehrere Regionen verteilen.
v2-Ebenen
- Skalieren Sie die Gatewaykapazität, indem Sie Skalierungseinheiten hinzufügen und entfernen, oder upgraden Sie die Dienstebene.
- Optional konfigurieren Sie die automatische Azure Monitor-Skalierung.
Verbrauchsstufe
- API Management-Instanzen auf der Verbrauchsebene werden automatisch basierend auf dem Datenverkehr skaliert.
Selbstgehostetes Gateway
- Fügen Sie in Umgebungen wie Kubernetes mehrere Gatewayreplikate hinzu, um die erwartete Nutzung zu bewältigen.
- Optional können Sie die automatische Skalierung konfigurieren, um die Datenverkehrsanforderungen zu erfüllen.
Arbeitsbereichs-Gateway
Skalieren Sie die Kapazität, indem Sie Skalierungseinheiten im Arbeitsbereichs-Gateway hinzufügen und entfernen.
Verwandte Inhalte
Weitere Informationen zu:
- API Management in einer Hybrid- und Multicloud-Welt
- Kapazitätsmetrik für Skalierungsentscheidungen
- Einblickfunktionen in API Management
- KI-Gatewayfunktionen in der API-Verwaltung