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 („Circuit Breaker“, Vorschau)

Ab der API-Version „2023-03-01 preview“ stellt API Management die Eigenschaft circuit breaker (Trennschalter) 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 die Sicherung in myBackend in der API Management-Instanz myAPIM ausgelöst, wenn mindestens drei 5xx-Statuscodes an einem Tag auftreten. Diese Codes deuten auf Serverfehler hin. Der Trennschalter wird nach einer Stunde zurückgesetzt.

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-03-01-preview' = {
  name: 'myAPIM/myBackend'
  properties: {
    url: 'https://mybackend.com'
    protocol: 'https'
    circuitBreaker: {
      rules: [
        {
          failureCondition: {
            count: 3
            errorReasons: [
              'Server errors'
            ]
            interval: 'P1D'
            statusCodeRanges: [
              {
                min: 500
                max: 599
              }
            ]
          }
          name: 'myBreakerRule'
          tripDuration: 'PT1H'
        }
      ]
    }
   }
 }

Pool mit Lastenausgleich (Vorschau)

Ab der API-Version 2023-05-01 (Vorschau) unterstützt API Management 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. Derzeit unterstützt der Back-End-Pool Roundrobin-Lastenausgleiche.

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.
  • 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.

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.

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-05-01-preview' = {
  name: 'myAPIM/myBackendPool'
  properties: {
    description: 'Load balancer for multiple backends'
    type: 'Pool'
    protocol: 'http'
    url: 'https://example.com'
    pool: {
      services: [
        {
          id: '/backends/backend-1'
        }
        {
          id: '/backends/backend-2'
        }
      ]
    }
  }
}

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