Back-ends in API Management

VAN TOEPASSING OP: Alle API Management-lagen

Een back-end (of API-back-end) in API Management is een HTTP-service waarmee uw front-end-API en de bijbehorende bewerkingen worden geïmplementeerd.

Bij het importeren van bepaalde API's configureert API Management de API-back-end automatisch. Api Management configureert bijvoorbeeld de back-endwebservice bij het importeren:

API Management biedt ook ondersteuning voor het gebruik van andere Azure-resources als API-back-end, zoals:

Voordelen van back-ends

API Management ondersteunt back-endentiteiten, zodat u de back-endservices van uw API kunt beheren. Een back-endentiteit bevat informatie over de back-endservice, waardoor herbruikbaarheid tussen API's en verbeterde governance wordt bevorderd.

Gebruik back-ends voor een of meer van de volgende opties:

  • De referenties van aanvragen voor de back-endservice autoriseren
  • Profiteer van API Management-functionaliteit voor het onderhouden van geheimen in Azure Key Vault als benoemde waarden zijn geconfigureerd voor verificatie van header- of queryparameters.
  • Regels voor circuitonderbrekers definiëren om uw back-end te beschermen tegen te veel aanvragen
  • Aanvragen routeren of verdelen naar meerdere back-ends

Back-endentiteiten configureren en beheren in Azure Portal of met behulp van Azure-API's of hulpprogramma's.

Verwijzen naar back-end met behulp van beleid voor set-backend-service

Nadat u een back-end hebt gemaakt, kunt u verwijzen naar de back-end in uw API's. Gebruik het set-backend-service beleid om een binnenkomende API-aanvraag naar de back-end te sturen. Als u al een back-endwebservice voor een API hebt geconfigureerd, kunt u het set-backend-service beleid gebruiken om de aanvraag om te leiden naar een back-endentiteit. Voorbeeld:

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

U kunt voorwaardelijke logica met het set-backend-service beleid gebruiken om de effectieve back-end te wijzigen op basis van locatie, gateway die werd aangeroepen of andere expressies.

Hier volgt bijvoorbeeld een beleid voor het routeren van verkeer naar een andere back-end op basis van de gateway die werd aangeroepen:

<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/>

Circuitonderbreker (preview)

Vanaf API-versie 2023-03-01 preview maakt API Management een circuitonderbrekereigenschap beschikbaar in de back-endresource om een back-endservice te beschermen tegen te veel aanvragen.

  • De eigenschap circuitonderbreker definieert regels om de circuitonderbreker te doorlopen, zoals het aantal of het percentage mislukte omstandigheden tijdens een gedefinieerd tijdsinterval en een reeks statuscodes die fouten aangeven.
  • Wanneer de circuitonderbreker wordt verplaatst, stopt API Management het verzenden van aanvragen naar de back-endservice gedurende een gedefinieerde tijd en retourneert een 503-service niet-beschikbaar antwoord op de client.
  • Na de geconfigureerde duur van de reis wordt het circuit opnieuw ingesteld en wordt het verkeer hervat naar de back-end.

De circuitonderbreker van de back-end is een implementatie van het circuitonderbrekerpatroon , zodat de back-end kan herstellen uit overbelastingssituaties. Het vergroot algemene beleidsregels voor snelheidsbeperking en gelijktijdigheid die u kunt implementeren om de API Management-gateway en uw back-endservices te beveiligen.

Notitie

  • Op dit moment wordt de onderbreking van het back-endcircuit niet ondersteund in de verbruikslaag van API Management.
  • Vanwege de gedistribueerde aard van de API Management-architectuur zijn de trippingregels voor circuitonderbrekers bij benadering. Verschillende exemplaren van de gateway worden niet gesynchroniseerd en passen circuitonderbrekerregels toe op basis van de informatie in hetzelfde exemplaar.

Opmerking

Gebruik de REST API van API Management of een Bicep- of ARM-sjabloon om een circuitonderbreker in een back-end te configureren. In het volgende voorbeeld wordt de circuitonderbreker in myBackend in het API Management-exemplaar myAPIM-trips weergegeven wanneer er drie of meer 5xx statuscodes zijn die serverfouten per dag aangeven. De circuitonderbreker wordt na één uur opnieuw ingesteld.

Neem een fragment op dat vergelijkbaar is met het volgende in uw Bicep-sjabloon voor een back-endresource met een circuitonderbreker:

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 met gelijke taakverdeling (preview)

Vanaf API-versie 2023-05-01 preview ondersteunt API Management back-endpools wanneer u meerdere back-ends wilt implementeren voor een API en taakverdelingsaanvragen voor deze back-ends. Momenteel ondersteunt de back-endpool round robin-taakverdeling.

Gebruik een back-endpool voor scenario's zoals de volgende:

  • Spreid de belasting over meerdere back-ends, die mogelijk afzonderlijke back-endcircuitonderbrekers hebben.
  • Verschuif de belasting van de ene set back-ends naar een andere voor de upgrade (blauwgroene implementatie).

Als u een back-endpool wilt maken, stelt u de type eigenschap van de back-end pool in op een lijst met back-ends waaruit de pool bestaat.

Notitie

  • Op dit moment kunt u slechts enkele back-ends opnemen in een back-endpool. U kunt geen back-end van het type pool toevoegen aan een andere back-endpool.
  • Vanwege de gedistribueerde aard van de API Management-architectuur is back-endtaakverdeling bij benadering. Verschillende exemplaren van de gateway worden niet gesynchroniseerd en worden verdeeld op basis van de informatie op hetzelfde exemplaar.

Opmerking

Gebruik de API Management REST API of een Bicep- of ARM-sjabloon om een back-endpool te configureren. In het volgende voorbeeld is de back-end myBackendPool in het API Management-exemplaar myAPIM geconfigureerd met een back-endpool. Voorbeelden van back-ends in de pool hebben de naam backend-1 en backend-2.

Neem een fragment op dat vergelijkbaar is met het volgende in uw Bicep-sjabloon voor een back-endresource met een pool met gelijke taakverdeling:

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'
        }
      ]
    }
  }
}

Beperking

Voor ontwikkelaars - en Premium-lagen kan een API Management-exemplaar dat is geïmplementeerd in een intern virtueel netwerk HTTP 500-fouten BackendConnectionFailure veroorzaken wanneer de URL van het gatewayeindpunt en de back-end-URL hetzelfde zijn. Als u deze beperking ondervindt, volgt u de instructies in het artikel over de beperking van selfchained API Management-aanvragen in de interne virtuele netwerkmodus in de Tech Community-blog.

  • Een Service Fabric-back-end instellen met behulp van Azure Portal.