Teilen über

Back-Ends in API Management

  • Artikel

GILT FÜR: Alle API Management-Ebenen

Ein Back-End (oder API-Back-End) in API Management ist ein HTTP-Dienst, der Ihre Front-End-API und die zugehörigen Vorgänge implementiert.

Beim Importieren bestimmter APIs wird das API-Back-End in API Management automatisch konfiguriert. Beispielsweise konfiguriert API Management den Back-End-Webdienst, wenn Folgendes importiert wird:

API Management unterstützt auch die Verwendung anderer Azure-Ressourcen als API-Back-End, wie z.B.:

Vorteile von Back-Ends

API Management unterstützt Back-End-Entitäten, damit Sie die Back-End-Dienste Ihrer API verwalten können. Eine Back-End-Entität fasst Informationen über den Back-End-Dienst zusammen, fördert die API-übergreifende Wiederverwendbarkeit und verbessert die Governance.

Verwenden Sie Back-Ends für einen oder mehrere der folgenden Zwecke:

  • Autorisieren der Anmeldeinformationen von Anforderungen an den Back-End-Dienst
  • Nutzung der API Management-Funktionalität, um Geheimnisse in Azure Key Vault zu verwalten, wenn benannte Werte für die Authentifizierung der Header- oder Abfrageparameter konfiguriert sind
  • Definieren von Sicherungsregeln, um Ihr Back-End vor zu vielen Anforderungen zu schützen
  • Weiterleitung oder Lastenausgleich für Anforderungen mit mehreren Back-Ends

Konfigurieren und verwalten Sie Back-End-Entitäten im Azure-Portal oder mithilfe von Azure-APIs oder -Tools.

Verweisen auf das Back-End mithilfe der set-backend-service-Richtlinie

Nach dem Erstellen eines Back-Ends können Sie in Ihren APIs auf das Back-End verweisen. Verwenden Sie die set-backend-service-Richtlinie, um eine eingehende API-Anforderung an das Back-End weiterzuleiten. Wenn Sie bereits einen Back-End-Webdienst für eine API konfiguriert haben, können Sie die set-backend-service-Richtlinie stattdessen verwenden, um die Anforderung an eine Back-End-Entität umzuleiten. Zum Beispiel:

<policies>
    <inbound>
        <base />
        <set-backend-service backend-id="myBackend" />
    </inbound>
    [...]
<policies/>

Sie können eine bedingte Logik mit der set-backend-service-Richtlinie nutzen, um das tatsächlich verwendete Back-End basierend auf dem Standort, dem aufgerufenen Gateway oder anderen Ausdrücken zu ändern.

Hier ist beispielsweise eine Richtlinie zum Weiterleiten von Datenverkehr an ein anderes Back-End basierend auf dem aufgerufenen Gateway:

<policies>
    <inbound>
        <base />
        <choose>
            <when condition="@(context.Deployment.Gateway.Id == "factory-gateway")">
                <set-backend-service backend-id="backend-on-prem" />
            </when>
            <when condition="@(context.Deployment.Gateway.IsManaged == false)">
                <set-backend-service backend-id="self-hosted-backend" />
            </when>
            <otherwise />
        </choose>
    </inbound>
    [...]
<policies/>

Trennschalter

API Management stellt die Eigenschaft circuit breaker (Schutzschalter) in der Back-End-Ressource zur Verfügung, um einen Back-End-Dienst vor der Überlastung durch zu viele Anforderungen zu schützen.

  • Die Eigenschaft „circuit breaker“ definiert Regeln, die angeben, bei welchen Ereignissen der Trennschalter ausgelöst werden soll. Hierbei kann es sich beispielsweise um die Anzahl oder den Prozentsatz an Fehlerbedingungen während eines definierten Zeitintervalls handeln oder eine Reihe von Statuscodes, die auf Fehler hinweisen.
  • Wenn der Trennschalter ausgelöst wird, sendet API Management über einen definierten Zeitraum keine Anforderungen mehr an den Back-End-Dienst und gibt die Antwort „503 – Dienst nicht verfügbar“ an die anfordernden Clients zurück.
  • Nach dem konfigurierten Zeitraum wird die Verbindung zurückgesetzt, und der Datenverkehr wird wieder an das Back-End geleitet.

Der Trennschalter im Back-End ist eine Implementierung des Trennschaltermusters, um dem Back-End die Möglichkeit zu geben, sich nach Überlastungssituationen zu erholen. Dieses Feature erweitert die allgemeinen Richtlinien für Ratenbegrenzung und Parallelitätsbegrenzung, die Sie implementieren können, um das API Management-Gateway und Ihre Back-End-Dienste zu schützen.

Hinweis

  • Derzeit wird die Back-End-Sicherung im Tarif Verbrauch für API Management nicht unterstützt.
  • Aufgrund der verteilten Architektur von API Management sind die Regeln für die Auslösung von Sicherungen ungenau. Verschiedene Instanzen des Gateways werden untereinander nicht synchronisiert und wenden Sicherungsregeln basierend auf den Informationen zur jeweiligen Instanz an.

Beispiel

Verwenden Sie die REST-API für API Management oder eine Bicep- oder ARM-Vorlage, um eine Sicherung in einem Back-End zu konfigurieren. Im folgenden Beispiel wird der Schutzschalter in myBackend in der API Management-Instanz myAPIM ausgelöst, wenn mindestens drei 5xx-Statuscodes an einem Tag auftreten. Diese Codes zeigen Serverfehler in 1 Stunde an.

Der Schutzschalter wird nach 1 Stunde zurückgesetzt. Wenn die Antwort einen Retry-After-Header enthält, akzeptiert der Schutzschalter den Wert und wartet die angegebene Zeit ab, bevor Anforderungen erneut an das Back-End gesendet werden.

Fügen Sie einen ähnlichen Codeschnipsel wie den folgenden in Ihrer Bicep-Vorlage für eine Back-End-Ressource mit Sicherung ein:

resource symbolicname 'Microsoft.ApiManagement/service/backends@2023-09-01-preview' = {
  name: 'myAPIM/myBackend'
  properties: {
    url: 'https://mybackend.com'
    protocol: 'https'
    circuitBreaker: {
      rules: [
        {
          failureCondition: {
            count: 3
            errorReasons: [
              'Server errors'
            ]
            interval: 'PT1H' 
            statusCodeRanges: [
              {
                min: 500
                max: 599
              }
            ]
          }
          name: 'myBreakerRule'
          tripDuration: 'PT1H'  
          acceptRetryAfter: true
        }
      ]
    }
   }
 }

Pool mit Lastenausgleich

API Management unterstützt Back-End-Pools, wenn Sie mehrere Back-Ends für eine API implementieren und einen Lastenausgleich für Anforderungen mit diesen Back-Ends durchführen möchten.

Verwenden Sie einen Back-End-Pool für Szenarios wie die folgenden:

  • Verteilen der Last auf mehrere Back-Ends, die möglicherweise über einzelne Back-End-Sicherungen verfügen
  • Verschieben der Last von einer Gruppe von Back-Ends auf eine andere für ein Upgrade (Blau-Grün-Bereitstellung)

Legen Sie zum Erstellen eines Back-End-Pools die Eigenschaft type des Back-Ends auf pool fest, und geben Sie eine Liste der Back-Ends an, die Teil des Pools sind.

Hinweis

  • Derzeit können Sie nur einzelne Back-Ends in einen Back-End-Pool aufnehmen. Back-Ends vom Typ pool können nicht einem anderen Back-End-Pool hinzugefügt werden. Sie können bis zu 30 Back-Ends in einen Pool aufnehmen.
  • Aufgrund der verteilten Architektur von API Management sind Lastenausgleiche für Back-Ends ungenau. Verschiedene Instanzen des Gateways werden untereinander nicht synchronisiert und führen Lastenausgleiche basierend auf den Informationen zur jeweiligen Instanz durch.

Optionen für den Lastenausgleich

API Management unterstützt die folgenden Lastenausgleichsoptionen für Back-End-Pools:

  • Round-robin: Standardmäßig werden Anforderungen gleichmäßig über die Back-Ends im Pool verteilt.
  • Gewichtet: Den Back-Ends im Pool werden Gewichtungen zugewiesen, und Anforderungen werden auf der Grundlage der jedem Backend zugewiesenen relativen Gewichtung auf die Back-Ends verteilt. Verwenden Sie diese Option für Szenarien wie das Durchführen einer Blau-Grün-Bereitstellung.
  • Prioritätsbasiert: Back-Ends werden in Prioritätsgruppen organisiert, und Anforderungen werden in der Reihenfolge der Prioritätsgruppen an die Backends gesendet. Innerhalb einer Prioritätsgruppe werden Anforderungen entweder gleichmäßig über die Back-Ends verteilt oder (sofern zugewiesen) entsprechend der relativen Gewichtung, die jedem Back-End zugewiesen wurde.

Hinweis

Back-Ends in niedrigeren Prioritätsgruppen werden nur verwendet, wenn alle Back-Ends in höheren Prioritätsgruppen nicht verfügbar sind, weil Schutzschalterregeln ausgelöst wurden.

Beispiel

Verwenden Sie die REST-API für API Management oder eine Bicep- oder ARM-Vorlage, um einen Back-End-Pool zu konfigurieren. Im folgenden Beispiel wird das Back-End myBackendPool in der API Management-Instanz myAPIM mit einem Back-End-Pool konfiguriert. Die Namen der Beispiel-Back-Ends im Pool lauten backend-1 und backend-2. Beide Back-Ends befinden sich in der höchsten Prioritätsgruppe. Innerhalb der Gruppe hat backend-1 eine größere Gewichtung als backend-2.

Fügen Sie einen ähnlichen Codeschnipsel wie den folgenden in Ihrer Bicep-Vorlage für eine Back-End-Ressource mit einem Pool mit Lastenausgleich ein:

resource symbolicname 'Microsoft.ApiManagement/service/backends@2023-09-01-preview' = {
  name: 'myAPIM/myBackendPool'
  properties: {
    description: 'Load balancer for multiple backends'
    type: 'Pool'
    pool: {
      services: [
        {
          id: '/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.ApiManagement/service/<APIManagementName>/backends/backend-1'
          priority: 1
          weight: 3
        }
        {
          id: '/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.ApiManagement/service/<APIManagementName>/backends/backend-2'
          priority: 1
          weight: 1
        }
      ]
    }
  }
}

Einschränkung

Für die Ebenen Developer und Premium Ebenen kann eine API Management-Instanz, die in einem internen virtuellen Netz bereitgestellt wird, einen HTTP 500 BackendConnectionFailure-Fehler auslösen, wenn die Gateway-Endpunkt-URL und die Back-End-URL identisch sind. Wenn Sie auf diese Einschränkung stoßen, befolgen Sie die Anweisungen im Artikel Self-Chained API Management request limitation in internal virtual network mode im Tech Community Blog.

Zugehöriger Inhalt