Verwenden von Azure API Management in einer Mehrinstanzenlö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 befasst sich mit den Kosten- und Komplexitätsunterschieden zwischen den Isolierungsmodellen und damit, wie die einzelnen Ansätze Anforderungen an Ihre Back-End-API-Anwendungen weiterleiten.

Überlegung Geteilte Instanz mit Single-Tenant-Backends Freigegebene Instanz mit gemeinsam genutztem Multitenant-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, wie Sie eine API Management-Instanz gemeinsam nutzen können, hängen davon ab, wie Sie den Back-End-API-Anwendungen Mandanten zuweisen.

Single-Tenant-Backend-Anwendung

Wenn Sie unterschiedliche Back-End-Anwendungen für jeden Mandanten bereitstellen, können Sie eine einzelne API-Verwaltungsinstanz bereitstellen und den Datenverkehr für jede Anforderung 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. Es kann auch ein gewisser Leistungsaufwand entstehen, wenn Sie das Back-End des Mandanten abrufen. Die Größe dieses Leistungsaufwands hängt jedoch davon ab, wie Sie diese Suche entwerfen.

Gemeinsam genutzte mandantenfähige 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 ausgestellte Domänen verwenden, können Sie die Routingkonfiguration pro Mandant für das Gateway vermeiden. Da Anfragen 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 service-Grenzwerte 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). Beispielsweise könnten Sie einen angepassten tenantId-Anspruch in einem JWT haben, das Ihr Identitätsanbieter ausstellt. 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. Stellen Sie sicher, dass Sie Ihren Cache bei jedem hinzugefügten, entfernten oder verschobenen Mandanten, der sich auf die Back-End-Abfrage auswirkt, ungültig machen.

Von Bedeutung

Behandeln Sie Mandanten-IDs in URLs, Hostnamen, Abfragezeichenfolgen und Anforderungsheadern als nicht vertrauenswürdige Routinghinweise. Authentifizieren Sie den Anrufer, und stellen Sie sicher, dass der Anrufer berechtigt ist, auf den aufgelösten Mandanten zuzugreifen, bevor Sie die Anforderung weiterleiten oder auf Mandantendaten zugreifen. Bevorzugen Sie nach Möglichkeit einen Mandanten-Claim aus einem validierten Token. Wenn ein vertrauenswürdiger Edgedienst den Mandantenbezeichner in einem Header bereitstellt, entfernen oder überschreiben Sie jeden vom Client bereitgestellten Wert am Edge.

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.

Eingehende Anfragen authentifizieren und autorisieren

API-Anfragen, die an das API-Verwaltungsgateway gesendet werden, benötigen in der Regel Authentifizierung und Autorisierung. Die API-Verwaltung kann OAuth 2.0-Zugriffstoken und Clientzertifikate überprüfen. OAuth 2.0 stellt autorisierung bereit. Wenn Sie Benutzer authentifizieren müssen, verwenden Sie ein Authentifizierungsprotokoll wie OpenID Connect. Überlegen Sie, welche Anmeldeinformationen Sie unterstützen und ob Sie sie in API Management, in Ihren Back-End-Anwendungen oder an beiden Stellen überprüfen.

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 verschiedenen Bereitstellungsstufen befinden, oder es kann sich um verschiedene Anwendungen innerhalb einer einzigen Stufe handeln. 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 Ihre APIs vor unterstützten APIs für große Sprachmodelle sitzen, 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 der eingehenden Verarbeitung und die store-Richtlinie in der ausgehenden Verarbeitung.

Von Bedeutung

Semantisches Caching verwendet Ähnlichkeit anstelle exakter Übereinstimmung. Ein Cachetreffer kann eine Antwort zurückgeben, die für die aktuelle Anfrage falsch, veraltet oder unsicher ist. Evaluieren Sie die semantische Zwischenspeicherung für Ihre Workload, optimieren Sie den Ähnlichkeitsschwellenwert, und wenden Sie ggf. Inhaltssicherheits- und Validierungssteuerelemente an.

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

<!-- inbound -->
<llm-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> -->
</llm-semantic-cache-lookup>

<!-- outbound -->
<llm-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 -->
<llm-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> -->
</llm-semantic-cache-lookup>

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

Tokenbasierte Grenzwerte für große Sprachmodelle

Verwenden Sie die llm-Token-Begrenzungsrichtlinie im KI-Gateway, um die Nutzung für jeden Mandanten zu begrenzen, nicht nur für einzelne Anfragen. Die Richtlinie unterstützt Azure OpenAI und andere unterstützte APIs für große Sprachmodelle. 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:

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

Das folgende Beispiel legt Beschränkungen anhand von Mandantenansprüchen oder -headern fest:

<!-- Using a tenant claim; requires validate-jwt earlier in the pipeline -->
<llm-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 -->
<llm-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 vor der Anwendung von Beschränkungen, ob der Anspruch oder Header vorhanden und nicht leer ist, um zu vermeiden, dass versehentlich viele Mandanten unter einem einzigen Zähler zusammengefasst werden.

Benutzerdefinierte Domänen

Verwenden Sie die API-Verwaltung, um Ihre eigenen benutzerdefinierten Domänen für das API-Gateway und das Entwicklerportal zu konfigurieren.

Die Ebenen "Standard v2" und "Premium v2" unterstützen Wildcard-Hostnamen. Wenn jeder Mandant eine Unterdomäne verwendet, z. B. tenant1.api.contoso.com, erwägen Sie, einen Wildcard-Hostnamen zu konfigurieren, z. B. *.api.contoso.com. Wildcard-Hostnamen können das Onboarding von Mandanten und die Zertifikatverwaltung vereinfachen, da Sie keinen Hostnamen für jeden Mandanten konfigurieren müssen.

Wenn Mandanten unterschiedliche FQDNs benötigen, die keine gemeinsame übergeordnete Domäne verwenden, verwenden Sie mehrere benutzerdefinierte Hostnamen auf dem Gateway auf der Premium v2-Ebene. Anschließend können Sie den Hostname der Anfrage verwenden, um den Mandanten aufzulösen und die Anfrage an das entsprechende Back-End weiterzuleiten. Verwenden Sie den Hostnamen nicht als Nachweis dafür, dass der Aufrufer für diesen Mandanten autorisiert ist.

Von Bedeutung

In den Ebenen Standard v2 und Premium v2 muss ein benutzerdefinierter Hostname für das Gateway öffentlich aufgelöst werden können. Sie können den Hostnamen nicht auf eine private DNS-Zone beschränken.

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, sollten Sie die Verwendung des X-Forwarded-Host Anforderungsheaders in Betracht ziehen oder Azure Front Door-Regeln verwenden, um die Informationen als HTTP-Header zu übergeben. Weitere Informationen finden Sie unter Beibehalten des ursprünglichen HTTP-Hostnamens.

Von Bedeutung

Weitergeleiteten Headern nur vertrauen, wenn sie von einem bekannten Proxy stammen. Konfigurieren Sie den Edgedienst, um vom Client bereitgestellte weitergeleitete Header zu entfernen oder zu überschreiben, und beschränken Sie den direkten Zugriff auf das API-Verwaltungsgateway, sofern möglich.

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 Richtlinie quota-by-key in Betracht ziehen, um Kontingente mithilfe eines beliebigen anderen Rate-Limit-Schlüssels durchzusetzen, wie z. B. einer Mandanten-ID, die Sie aus der Anforderungs-URL oder einem JWT abfragen.

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

Von Bedeutung

Der Bereich des Zählers variiert je nach Richtlinie und Bereitstellungstopologie:

  • Die Richtlinien rate-limit und rate-limit-by-key verwalten separate Zähler für jedes Gateway, auf das Sie sie anwenden. Bei bereichsübergreifenden oder Workspace-Gateway-Bereitstellungen wendet jedes regionale oder Workspace-Gateway seinen eigenen Zähler an.

  • Die llm-token-limit Richtlinie verfolgt auch Token für jedes Gateway, jede Region oder jeden Arbeitsbereich und aggregiert keine Zählungen ü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, sollten Sie Kontingente bevorzugen, Beschränkungen an einem vorgelagerten Edge durchsetzen, der den gesamten Datenverkehr erfasst, oder einen Mandanten an ein einzelnes Gateway oder eine einzelne Region Route.

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 Multi-Mandanten-Instanzen können mehr Kapazität verbrauchen als Single-Mandanten-Instanzen, z. B. wenn Sie viele Richtlinien für die Weiterleitung von Anforderungen an verschiedene Back-Ends von Mandanten 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 Bereitstellungen in mehreren Regionen, was bedeutet, dass Sie eine einzelne logische API Management-Ressource über mehrere Azure-Regionen bereitstellen können, ohne deren Konfiguration auf separate Ressourcen kopieren zu müssen. Diese Funktion ist besonders hilfreich, wenn Sie Ihre Lösung global verteilen oder replizieren. Sie können regionale Gateways für die Verarbeitung von Anfragen mit geringer Latenz bereitstellen und als einzelne API-Verwaltungsinstanz verwalten.

Von Bedeutung

Die Multiregion-Bereitstellung wird nur in der Premium-Stufe (klassisch) unterstützt, nicht in Premium v2 oder anderen Ebenen. Wenn Ihre Instanz eine andere Ebene verwendet, Sie aber für mehrere Regionen bereitstellen müssen, verwenden Sie eine separate Instanz für jede Region und externes Routing, z. B. Azure Front Door.

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:

  • John Downs | Principal Software Engineer, Azure Patterns & Practices
  • Daniel Scott-Raynsford | Senior Partner Solution Architect, Enterprise Partner Solutions

Anderer Mitwirkender:

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

  • Zuletzt aktualisiert um