Freigeben über

Verwenden der Azure-API-Verwaltung in einer multiinstanzenübergreifenden Lösung

Azure API Management ist ein umfassendes API-Gateway und Reverseproxy für APIs. Es bietet viele Features, die für API-fokussierte Anwendungen nützlich sind, einschließlich Caching, Antwort-Mocking und einem Entwicklerportal. In diesem Artikel werden einige der wichtigsten Features der API-Verwaltung zusammengefasst, die für mehrinstanzenfähige Lösungen nützlich sind.

Hinweis

Dieser Artikel befasst sich mit der Verwendung der API-Verwaltung, wenn Sie über eigene mehrinstanzenfähige Anwendungen verfügen, die APIs für die interne oder externe Verwendung hosten.

Eine weitere Form von Mehrinstanzenfähigkeit besteht darin, das API-Verwaltungsgateway als Dienst für andere Teams bereitzustellen. Beispielsweise kann eine Organisation über eine freigegebene API-Verwaltungsinstanz verfügen, die von mehreren Anwendungsteams bereitgestellt und verwendet wird. In diesem Artikel wird diese Form von Mehrinstanzenfähigkeit nicht behandelt. Erwägen Sie die Verwendung von Arbeitsbereichen, mit denen Sie eine API-Verwaltungsinstanz für mehrere Teams freigeben können, die möglicherweise über unterschiedliche Zugriffsebenen verfügen.

Isolationsmodelle

Die API-Verwaltung wird in der Regel als freigegebene Komponente mit einer einzelnen Instanz bereitgestellt, die Anforderungen für mehrere Mandanten erfüllt. Basierend auf Ihrem Mandantenmodell gibt es jedoch viele Möglichkeiten, die API-Verwaltung bereitzustellen. In diesem Artikel wird davon ausgegangen, dass Sie Ihre Lösung mithilfe von Bereitstellungsstempeln bereitstellen.

In der Regel bleibt die Verwendung der API-Verwaltung in verschiedenen Isolationsmodellen konsistent. Dieser Abschnitt konzentriert sich auf die Unterschiede in den Kosten und der Komplexität der Isolationsmodelle und darauf, wie jede Herangehensweise Anforderungen an Ihre Back-End-API-Anwendungen weiterleitet.

Überlegung Freigegebene Instanz mit Einzelmandanten-Back-Ends Freigegebene Instanz mit freigegebenem Mehrmandanten-Back-End Instanz für jeden Mandanten
Anzahl der unterstützten Mandanten Mehrere Nahezu unbegrenzt Eine für jede Instanz
Kosten Geringer Geringer Höher
Bereitstellungskomplexität Niedrig. Einzelne Instanz, die für jeden Stempel verwaltet werden soll. Niedrig. Einzelne Instanz, die für jeden Stempel verwaltet werden soll. Hoch. Mehrere zu verwaltende Instanzen.
Komplexität der Routingkonfiguration Höher Geringer Geringer
Empfindlichkeit gegenüber Laut-Nachbarn-Problemen Ja Ja Nein
Netzwerkisolation auf Mandantenebene Nein Nein Ja
Beispielszenario Benutzerdefinierte Domänennamen für jeden Mandanten Große Lösung mit mehreren Mandanten mit freigegebener Anwendungsebene Mandantenspezifische Bereitstellungsstempel

Isolationsmodelle für geteilte Instanzen

Es ist üblich, eine API-Verwaltungsinstanz zwischen mehreren Mandanten zu teilen, wodurch kosten- und bereitstellungs- und verwaltungskomplexität reduziert wird. Die Details dazu, wie Sie eine API-Verwaltungsinstanz freigeben können, hängt davon ab, wie Sie Mandanten Back-End-API-Anwendungen zuweisen.

Einzelmandanten-Back-End-Anwendung

Wenn Sie unterschiedliche Back-End-Anwendungen für jeden Mandanten bereitstellen, können Sie für jede Anforderung eine einzelne API-Verwaltungsinstanz bereitstellen und den Datenverkehr an das richtige Mandanten-Back-End weiterleiten. Bei diesem Ansatz müssen Sie die API-Verwaltung mit den Back-End-Hostnamen für jeden Mandanten konfigurieren oder eine andere Möglichkeit haben, eine eingehende Anforderung dem Back-End des richtigen Mandanten zuzuordnen.

Da ein zusätzlicher Suchvorgang erforderlich ist, kann dieser Ansatz möglicherweise nicht auf eine große Anzahl von Mandanten skaliert werden, die eine einzelne API-Verwaltungsinstanz gemeinsam nutzen. Möglicherweise liegt auch ein Leistungsmehraufwand vor, wenn Sie das Mandanten-Back-End durchsuchen. Die Größe dieses Leistungsaufwands hängt jedoch davon ab, wie Sie diese Suche entwerfen.

Freigegebene Mehrmandanten-Back-End-Anwendung

In Szenarien, in denen Ihre Mandanten eine gemeinsame Back-End-Anwendung teilen, wird der API-Verwaltungsroutingprozess vereinfacht, da Sie alle Anforderungen an ein einzelnes Back-End weiterleiten können. Wenn Sie Wildcarddomänen oder vom Anbieter ausgegebene Domänen verwenden, können Sie mit diesem Ansatz möglicherweise nahezu ungebundene Skalierung erreichen. Da Anforderungen nicht dem Back-End eines Mandanten zugeordnet werden müssen, hat dies keine Auswirkungen auf die Leistung durch angepasste Routingentscheidungen.

Instanz für jeden Mandanten

In einigen Szenarien können Sie eine Instanz der API-Verwaltung für jeden Mandanten bereitstellen. Wir empfehlen diesen Ansatz nur, wenn Sie wenige Mandanten haben oder strenge Compliance-Anforderungen bestehen, die Sie daran hindern, eine Infrastruktur zwischen Mandanten zu teilen. Wenn Sie beispielsweise ein dediziertes virtuelles Netzwerk für jeden Mandanten bereitstellen, müssen Sie wahrscheinlich auch eine dedizierte API-Verwaltungsinstanz für jeden Mandanten bereitstellen.

Tipp

Wenn Der einzige Grund für die Bereitstellung mehrerer Instanzen darin besteht, Benutzer in verschiedenen geografischen Regionen zu unterstützen, sollten Sie überlegen, ob das Multiregion-Bereitstellungsfeature in der API-Verwaltung Ihre Anforderungen erfüllt.

Wenn Sie eine Instanz der API-Verwaltung bereitstellen, müssen Sie die Dienstgrenzwerte berücksichtigen, einschließlich aller Grenzwerte, die für die Anzahl der API-Verwaltungsinstanzen innerhalb eines Azure-Abonnements oder einer Region gelten können.

Einzelmandanteninstanzen weisen in der Regel eine minimale Routingkonfiguration auf, da Sie alle Anforderungen an ein einzelnes Back-End weiterleiten können. Dieses Szenario erfordert keine benutzerdefinierten Routingentscheidungen, sodass keine Auswirkungen auf die Leistung erzielt werden. In der Regel fallen jedoch höhere Ressourcenkosten an, als wenn Sie eine freigegebene Instanz bereitstellen. Wenn Sie Einzelmandanteninstanzen bereitstellen müssen, überlegen Sie, ob selbst gehostete Gateways es Ihnen ermöglichen, mandantenspezifische Computeressourcen wiederzuverwenden, die Sie bereits bereitstellen.

API-Verwaltungsfunktionen, die mehrinstanzenfähige Unterstützung bieten

Die API-Verwaltung verwendet Richtlinien , um Flexibilität zu ermöglichen. Sie können anpassen, wie Anforderungen überprüft, weitergeleitet und verarbeitet werden, wenn Sie Richtlinien verwenden. Und wenn Sie eine mehrinstanzenfähige Lösung mit API-Verwaltung entwerfen, verwenden Sie Richtlinien, um viele seiner Funktionen zu implementieren.

Identifizieren von Mandanten für eingehende Anforderungen

Überlegen Sie, wie Sie den entsprechenden Mandanten innerhalb jeder eingehenden Anforderung identifizieren können. In einer mehrinstanzenfähigen Lösung ist es wichtig, dass Sie ein klares Verständnis darüber haben, wer jede Anforderung vornimmt, damit Sie die Daten für diesen bestimmten Mandanten und niemand anderes zurückgeben.

DIE API-Verwaltung stellt Abonnements bereit, die Sie zum Authentifizieren von Anforderungen verwenden können. Diese Abonnements verwenden einen eindeutigen Abonnementschlüssel , der den Abonnenten identifiziert, der die Anforderung durchführt. Wenn Sie Abonnements verwenden möchten, überlegen Sie, wie Sie die API-Verwaltungsabonnements Ihrem eigenen Mandanten oder Kundenbezeichner zuordnen können. Abonnements sind eng in das Entwicklerportal integriert. Für die meisten Lösungen empfiehlt es sich, Abonnements zum Identifizieren von Mandanten zu verwenden.

Alternativ können Sie den Mandanten mithilfe anderer Methoden identifizieren. Die folgenden Beispielansätze werden in einer benutzerdefinierten Richtlinie ausgeführt, die Sie definieren:

  • Verwenden Sie eine benutzerdefinierte Komponente der URL, z. B. eine Unterdomäne, einen Pfad oder eine Abfragezeichenfolge. In der URL https://api.contoso.com/tenant1/products können Sie z. B. den ersten Teil des Pfads tenant1 extrahieren und als Mandantenkennzeichen behandeln. Angesichts der eingehenden URL https://tenant1.contoso.com/products, können Sie ähnlich dazu auch die Unterdomäne extrahieren, tenant1. Um diesen Ansatz zu verwenden, sollten Sie den Pfad oder die Abfragezeichenfolge aus der Context.Request.Url Eigenschaft analysieren.

  • Verwenden Sie einen Anforderungsheader. Ihre Clientanwendungen können z. B. eine benutzerdefinierte TenantID Kopfzeile zu Anforderungen hinzufügen. Um diesen Ansatz zu verwenden, ziehen Sie das Lesen aus der Context.Request.Headers Sammlung in Betracht.

  • Extrahieren von Ansprüchen aus einem JSON-Webtoken (JWT). Sie können beispielsweise einen individuellen tenantId Anspruch in einem JWT haben, den Ihr Identitätsanbieter ausgibt. Um diesen Ansatz zu verwenden, verwenden Sie die Validate-jwt-Richtlinie , und legen Sie die output-token-variable-name Eigenschaft fest, damit Ihre Richtliniendefinition die Werte aus dem Token lesen kann.

  • Suchen Sie Mandanten-IDs dynamisch. Sie können mit einer externen Datenbank oder einem externen Dienst kommunizieren, während die Anforderung verarbeitet wird. Mit diesem Ansatz können Sie eine benutzerdefinierte Mandantenzuordnungslogik erstellen, um einer bestimmten URL einen logischen Mandantenbezeichner zuzuordnen oder weitere Informationen zu einem Mandanten zu erhalten. Verwenden Sie die Send-Request-Richtlinie , um diesen Ansatz anzuwenden.

    Dieser Ansatz erhöht wahrscheinlich die Latenz Ihrer Anforderungen. Um diesen Effekt zu mindern, ist es ratsam, zwischenspeichern zu verwenden, um die Anzahl der Aufrufe an die externe API zu reduzieren. Sie können die Richtlinien für cache-store-value und cache-lookup-value verwenden, um einen Caching-Ansatz zu implementieren. Achten Sie darauf, den Cache bei jedem hinzugefügten, entfernten oder verschobenen Mandanten, der sich auf die Back-End-Abfrage auswirkt, ungültig zu machen.

Benannte Werte

Die API-Verwaltung unterstützt benannte Werte, die benutzerdefinierte Konfigurationseinstellungen sind, die Sie in allen Richtlinien verwenden können. Sie können z. B. einen benannten Wert verwenden, um die Back-End-URL eines Mandanten zu speichern und diesen Wert an mehreren Stellen in Ihren Richtlinien wiederzuverwenden. Wenn Sie die URL aktualisieren müssen, können Sie sie an einem zentralen Ort aktualisieren.

Warnung

Bei einer Multitenant-Lösung ist es wichtig, vorsichtig zu sein, wenn Sie die Namen Ihrer benannten Werte festlegen. Wenn die Einstellungen zwischen Mandanten variieren, stellen Sie sicher, dass Sie den Mandantenbezeichner in den Namen einbeziehen. Sie können z. B. ein Muster tenantId-key:value wie nach der Bestätigung verwenden, dass tenantId für die Anforderung geeignet ist.

Beziehen Sie den Bezeichner ein, um die Wahrscheinlichkeit zu verringern, versehentlich auf den Wert eines anderen Mandanten zu verweisen oder dazu verleitet zu werden darauf zu verweisen, wenn Sie eine Anforderung für einen anderen Mandanten verarbeiten.

Authentifizieren eingehender Anforderungen

API-Anforderungen, die an das API-Verwaltungsgateway gestellt werden, müssen in der Regel authentifiziert werden. Die API-Verwaltung bietet mehrere Methoden zum Authentifizieren eingehender Anforderungen an das Gateway, einschließlich OAuth 2.0- und Clientzertifikaten. Berücksichtigen Sie die Typen an Anmeldeinformationen, die Sie unterstützen sollten und wo sie überprüft werden sollen. Überlegen Sie beispielsweise, ob die Überprüfung in der API-Verwaltung, in Ihren Back-End-Anwendungen oder an beiden Stellen erfolgen soll.

Weitere Informationen finden Sie unter Authentifizierung und Autorisierung für APIs in der API-Verwaltung.

Hinweis

Wenn Sie einen Abonnementschlüssel oder API-Schlüssel verwenden, empfiehlt es sich, auch eine andere Authentifizierungsmethode zu verwenden.

Ein Abonnementschlüssel allein ist keine starke Form der Authentifizierung. Es ist jedoch hilfreich für andere Szenarien, z. B. zum Nachverfolgen der API-Nutzung eines einzelnen Mandanten.

Weiterleiten an mandantenspezifische Back-Ends

Wenn Sie die API-Verwaltung als freigegebene Komponente verwenden, müssen Sie möglicherweise eingehende API-Anforderungen an verschiedene mandantenspezifische Back-Ends weiterleiten. Diese Back-Ends können sich in unterschiedlichen Bereitstellungsstempeln oder in unterschiedlichen Anwendungen innerhalb eines einzelnen Stempels unterscheiden. Um das Routing in einer Richtliniendefinition anzupassen, verwenden Sie die Set-Back-End-Dienstrichtlinie . Sie müssen die neue Basis-URL angeben, an die die Anforderung umgeleitet werden soll.

Cacheantworten oder andere Daten

Die API-Verwaltung verfügt über ein leistungsfähiges Cachefeature, mit dem Sie ganze HTTP-Antworten oder andere Daten zwischenspeichern können. Sie können z. B. den Cache für Mandantenzuordnungen verwenden, wenn Sie benutzerdefinierte Logik verwenden oder die Zuordnung von einem externen Dienst nachschlagen.

Verwenden Sie die Cachespeicherwert- und Cache-Nachschlagewertrichtlinien , um einen Caching-Ansatz zu implementieren.

Warnung

Bei einer Multiinstanzenlösung ist es wichtig, beim Festlegen der Cacheschlüssel vorsichtig zu sein. Wenn die zwischengespeicherten Daten zwischen Mandanten variieren können, stellen Sie sicher, dass Sie den Mandantenbezeichner in den Cacheschlüssel einschließen.

Beziehen Sie den Bezeichner ein, um die Wahrscheinlichkeit zu verringern, versehentlich auf den Wert eines anderen Mandanten zu verweisen oder dazu verleitet zu werden darauf zu verweisen, wenn Sie eine Anforderung für einen anderen Mandanten verarbeiten.

APIs für große Sprachmodelle

Verwenden Sie die KI-Gatewayfeatures in der API-Verwaltung, wenn Ihre APIs große Sprachmodelle aufrufen. Diese Features helfen Ihnen, Kosten, Leistung und Isolation in Multitenant-Lösungen zu steuern.

Semantische Zwischenspeicherung

Wenn Sich Ihre APIs vor Azure OpenAI-Modellen befinden, sollten Sie die Verwendung der semantischen Zwischenspeicherung in der API-Verwaltung in Betracht ziehen, um Kosten und Latenz für wiederholte oder nahezu duplizierte Eingabeaufforderungen zu reduzieren.

Weitere Informationen finden Sie in den folgenden Ressourcen:

Sie sollten den Cache pro Mandant mithilfe des vary-by Elements partitionieren, sodass Eingabeaufforderungen und Antworten auf den Mandanten isoliert sind, für den sie vorgesehen sind. Platzieren Sie die lookup Richtlinie in eingehende Verarbeitung und die store Richtlinie in die ausgehende Verarbeitung.

Das folgende Beispiel zeigt, wie semantische Cacheeinträge nach Abonnement-ID oder Schlüssel partitioniert werden:

<!-- inbound -->
<azure-openai-semantic-cache-lookup
   score-threshold="0.05"
   embeddings-backend-id="embeddings-backend"
   embeddings-backend-auth="system-assigned">
   <vary-by>@(context.Subscription.Id)</vary-by>
   <!-- or: <vary-by>@(context.Subscription.Key)</vary-by> -->
</azure-openai-semantic-cache-lookup>

<!-- outbound -->
<azure-openai-semantic-cache-store duration="60" />

Im folgenden Beispiel wird der semantische Cache nach Mandantenanspruch oder Header partitioniert:

<!-- inbound; requires validate-jwt if using a claim -->
<azure-openai-semantic-cache-lookup
   score-threshold="0.05"
   embeddings-backend-id="embeddings-backend"
   embeddings-backend-auth="system-assigned">
   <vary-by>@(context.Principal?.Claims.GetValueOrDefault("tenantId", ""))</vary-by>
   <!-- Alternative using a custom header: -->
   <!-- <vary-by>@(context.Request.Headers.GetValueOrDefault("TenantID", ""))</vary-by> -->
</azure-openai-semantic-cache-lookup>

<!-- outbound -->
<azure-openai-semantic-cache-store duration="60" />

Tokenbasierte Grenzwerte für große Sprachmodelle

Verwenden Sie tokenbasierte Grenzwerte im KI-Gateway, um die Nutzung für jeden Mandanten zu beschränken, nicht nur für einzelne Anforderungen. Wenn Sie Azure OpenAI-Back-Ends verwenden, verwenden Sie die Azure-openai-token-limit-Richtlinie. Verwenden Sie für OpenAI-kompatible Back-Ends oder die Azure AI Model Inference-API die Richtlinie "llm-token-limit". Weitere Informationen finden Sie unter Tokengrenzrichtlinie.

Wählen Sie einen für den Mandanten eindeutigen Schlüssel aus, z. B. eine Abonnement-ID oder einen Mandanten-ID-Tokenanspruch, um sicherzustellen, dass die Grenzwerte jeden Mandanten effektiv isolieren. Die Tokenverwendung wird unabhängig von jedem Gateway, jeder Region oder jedem Arbeitsbereich nachverfolgt, und Indikatoren werden nicht über die gesamte Instanz aggregiert.

Im folgenden Beispiel wird jeder Mandant auf 60.000 Token pro Minute pro Abonnement beschränkt:

<azure-openai-token-limit
   counter-key="@(context.Subscription.Id)"
   tokens-per-minute="60000"
   estimate-prompt-tokens="false" />

Das folgende Beispiel beschränkt sich auf die Einschränkung nach Mandantenanspruch oder Header:

<!-- Using a tenant claim; requires validate-jwt earlier in the pipeline -->
<azure-openai-token-limit
   counter-key="@(context.Principal?.Claims.GetValueOrDefault(&quot;tenantId&quot;, &quot;&quot;))"
   tokens-per-minute="60000"
   estimate-prompt-tokens="false" />

<!-- Or using a custom header populated by your edge/CDN/gateway -->
<azure-openai-token-limit
   counter-key="@(context.Request.Headers.GetValueOrDefault(&quot;TenantID&quot;, &quot;&quot;))"
   tokens-per-minute="60000"
   estimate-prompt-tokens="false" />

Hinweis

Überprüfen Sie, ob der Anspruch oder die Kopfzeile vorhanden und nicht leer ist, bevor Sie Grenzwerte anwenden, um unbeabsichtigtes Reduzieren vieler Mandanten unter einem einzelnen Zähler zu vermeiden.

Benutzerdefinierte Domänen

Verwenden Sie die API-Verwaltung, um Ihre eigenen benutzerdefinierten Domänen für das API-Gateway und das Entwicklerportal zu konfigurieren. In einigen Ebenen können Sie Wildcarddomänen oder mehrere vollqualifizierte Domänennamen (FQDNs) konfigurieren.

Sie können die API-Verwaltung auch zusammen mit einem Dienst wie Azure Front Door verwenden. In dieser Art von Konfiguration behandelt Azure Front Door häufig benutzerdefinierte Domänen und TLS-Zertifikate (Transport Layer Security) und kommuniziert mit der API-Verwaltung mithilfe eines einzelnen Domänennamens. Wenn die ursprüngliche URL vom Client Mandanteninformationen enthält, die Sie zur späteren Verarbeitung an die API-Verwaltungsinstanz senden müssen, erwägen Sie die Verwendung des X-Forwarded-Host Anforderungsheaders, oder verwenden Sie Azure Front Door-Regeln , um die Informationen als HTTP-Header zu übergeben.

Ratenbegrenzungen

Es ist üblich, Kontingente oder Zinsgrenzwerte in einer Mehrinstanzenlösung anzuwenden. Zinslimits können Ihnen helfen, das laute Nachbarproblem zu mindern. Sie können auch Preisbeschränkungen verwenden, um die Dienstqualität zu erzwingen und zwischen verschiedenen Preisstufen zu unterscheiden.

Verwenden Sie die API-Verwaltung, um mandantenspezifische Ratengrenzwerte zu erzwingen. Wenn Sie mandantenspezifische Abonnements verwenden, sollten Sie die Kontingentrichtlinie verwenden, um ein Kontingent für jedes Abonnement zu erzwingen. Alternativ können Sie die Kontingent-nach-Schlüssel-Richtlinie verwenden, um mit einem anderen Schlüssel wie einem Mandantenbezeichner, den Sie aus der Anforderungs-URL oder einem JWT erhalten, Kontingente zu erzwingen.

Weitere Informationen finden Sie unter tokenbasierte Grenzwerte für große Sprachmodelle.

Von Bedeutung

Der Leistungsumfang unterscheidet sich je nach Richtlinien- und Bereitstellungstopologie:

  • Die rate-limit Richtlinien rate-limit-by-key verwalten separate Leistungsindikatoren für jedes Gatewayreplikat. In Bereitstellungen von Gateways mit mehreren Regionen oder Arbeitsbereichen erzwingt jedes regionale oder jedes Arbeitsbereichs-Gateway seinen eigenen Zähler.

  • Die Richtlinien azure-openai-token-limit und llm-token-limit verfolgen auch Tokens für jedes Gateway, jede Region oder jeden Arbeitsbereich und aggregieren nicht über die gesamte Dienstinstanz.

  • Die quota- und quota-by-key-Richtlinien sind global auf Dienstebene und gelten regionsübergreifend für eine bestimmte Instanz.

Wenn Sie eine global konsistente Drosselung pro Mandant benötigen, bevorzugen Sie Kontingente, erzwingen Sie Grenzwerte an einer Upstream-Edge, die den gesamten Datenverkehr sieht, oder leiten Sie einen Mandanten an ein einzelnes Gateway oder eine Region.

Monetisierung

Die API-Verwaltungsdokumentation enthält umfassende Anleitungen zur Monetarisierung von APIs, einschließlich einer Beispielimplementierung. Die Monetarisierungsansätze kombinieren viele der Features der API-Verwaltung, sodass Entwickler eine API veröffentlichen, Abonnements verwalten und auf der Grundlage verschiedener Nutzungsmodelle berechnen können.

Kapazitätsmanagement

Eine API-Verwaltungsinstanz unterstützt eine bestimmte Kapazität, die die ressourcen darstellt, die für die Verarbeitung Ihrer Anforderungen verfügbar sind. Wenn Sie komplexe Richtlinien verwenden oder weitere APIs für die Instanz bereitstellen, verbrauchen Sie mehr Kapazität. Sie können die Kapazität einer Instanz auf verschiedene Arten verwalten, z. B. durch den Kauf weiterer Einheiten. Sie können die Kapazität Ihrer Instanz auch dynamisch skalieren.

Einige mehrmandantenfähige Instanzen verbrauchen möglicherweise mehr Kapazität als Einzelmandanteninstanzen, z. B. wenn Sie viele Richtlinien für das Routing von Anforderungen an verschiedene Mandanten-Back-Ends verwenden. Berücksichtigen Sie die Kapazitätsplanung sorgfältig und planen Sie, die Kapazität Ihrer Instanz zu erhöhen, wenn Sie einen Anstieg Ihrer Nutzung feststellen. Außerdem sollten Sie die Leistung Ihrer Lösung testen, um Ihre Kapazitätsanforderungen vorab zu verstehen.

Weitere Informationen zum Skalieren der API-Verwaltung finden Sie unter Upgrade und Skalierung einer API-Verwaltungsinstanz.

Bereitstellungen in mehreren Regionen

API Management unterstützt Multiregion-Bereitstellungen. Dies bedeutet, dass Sie eine einzelne logische API-Verwaltungsressource in mehreren Azure-Regionen bereitstellen können, ohne ihre Konfiguration auf separate Ressourcen replizieren zu müssen. Diese Funktion ist besonders hilfreich, wenn Sie Ihre Lösung global verteilen oder replizieren. Sie können eine Flotte von API-Verwaltungsinstanzen in mehreren Regionen effektiv bereitstellen, was die Verarbeitung von Anforderungen mit geringer Latenz ermöglicht und sie als eine einzige logische Instanz verwaltet.

Von Bedeutung

Die Multiregion-Bereitstellung wird nur auf der Premium-Ebene (klassisch) unterstützt. Sie ist in den Ebenen "Verbrauch", "Entwickler", "Basic", "Standard", "Basic v2", "Standard v2" oder "Premium v2" (Vorschau) nicht verfügbar. Wenn Sie sich auf v2-Ebenen befinden und für mehrere Regionen bereitstellen müssen, verwenden Sie für jede Region eine separate Instanz, und verwenden Sie externes Routing (z. B. Azure Front Door) oder selbst gehostete Gateways.

Wenn Sie jedoch vollständig isolierte API-Verwaltungsinstanzen benötigen, können Sie auch unabhängige API-Verwaltungsressourcen in verschiedenen Regionen bereitstellen. Dieser Ansatz trennt die Verwaltungsebene für jede API-Verwaltungsinstanz.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautoren:

Anderer Mitwirkender:

Um nicht-öffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.

  • Last updated on