Share via

Back-ends in API Management

  • Artikel

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

Stroomonderbreker

API Management maakt 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.
  • Op dit moment kan slechts één regel worden geconfigureerd voor een back-endcircuitonderbreker.

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-ritten weergegeven wanneer er drie of meer 5xx statuscodes zijn die serverfouten in 1 uur aangeven.

De circuitonderbreker wordt na 1 uur opnieuw ingesteld. Als er een Retry-After header aanwezig is in het antwoord, accepteert de circuitonderbreker de waarde en wacht op de opgegeven tijd voordat aanvragen opnieuw naar de back-end worden verzonden.

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

Pool met gelijke taakverdeling

API Management ondersteunt back-endpools wanneer u meerdere back-ends voor een API wilt implementeren en aanvragen voor taakverdeling wilt verdelen over deze back-ends.

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. U kunt maximaal 30 back-ends opnemen in een pool.
  • 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.

Opties voor taakverdeling

API Management ondersteunt de volgende opties voor taakverdeling voor back-endpools:

  • Round robin: aanvragen worden standaard gelijkmatig verdeeld over de back-ends in de pool.
  • Gewogen: gewichten worden toegewezen aan de back-ends in de pool en aanvragen worden verdeeld over de back-ends op basis van het relatieve gewicht dat aan elke back-end is toegewezen. Gebruik deze optie voor scenario's zoals het uitvoeren van een blauwgroene implementatie.
  • Op basis van prioriteit: back-ends zijn ingedeeld in prioriteitsgroepen en aanvragen worden verzonden naar de back-ends in volgorde van de prioriteitsgroepen. Binnen een prioriteitsgroep worden aanvragen gelijkmatig verdeeld over de back-ends of (indien toegewezen) op basis van het relatieve gewicht dat aan elke back-end is toegewezen.

Notitie

Back-ends in groepen met lagere prioriteit worden alleen gebruikt wanneer alle back-ends in groepen met hogere prioriteit niet beschikbaar zijn, omdat circuitonderbrekerregels worden verschoven.

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. Beide back-ends bevinden zich in de groep met de hoogste prioriteit; binnen de groep heeft back-end-1 een groter gewicht dan back-end-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-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
        }
      ]
    }
  }
}

Beperkingen

Gerelateerde inhoud