Sdílet prostřednictvím


Back-endy ve službě API Management

PLATÍ PRO: Všechny úrovně služby API Management

Back-end (nebo back-end rozhraní API) ve službě API Management je služba HTTP, která implementuje rozhraní API front-endu a jeho operace.

Při importu určitých rozhraní API služba API Management nakonfiguruje back-end rozhraní API automaticky. Služba API Management například při importu nakonfiguruje back-endovou webovou službu:

SLUŽBA API Management také podporuje použití jiných prostředků Azure jako back-endu rozhraní API, například:

  • Cluster Service Fabric.
  • Vlastní služba.

Výhody back-endů

API Management podporuje back-endové entity, abyste mohli spravovat back-endové služby vašeho rozhraní API. Back-endová entita zapouzdřuje informace o back-endové službě a podporuje opakované použití napříč rozhraními API a vylepšené zásady správného řízení.

Použijte back-endy pro jednu nebo více z následujících možností:

Nakonfigurujte a spravujte back-endové entity na webu Azure Portal nebo pomocí rozhraní API nebo nástrojů Azure.

Referenční back-end s využitím zásad služby set-back-end

Po vytvoření back-endu můžete v rozhraních API odkazovat na back-end. set-backend-service Pomocí zásad nasměrujte příchozí požadavek rozhraní API na back-end. Pokud jste už nakonfigurovali back-endovou webovou službu pro rozhraní API, můžete tuto zásadu použít set-backend-service k přesměrování požadavku na entitu back-endu. Příklad:

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

Pomocí podmíněné logiky se set-backend-service zásadami můžete změnit efektivní back-end na základě umístění, volané brány nebo jiných výrazů.

Tady je například zásada pro směrování provozu do jiného back-endu na základě volané brány:

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

Jistič

Služba API Management zveřejňuje vlastnost jističe v back-endovém prostředku za účelem ochrany back-endové služby před zahlcením příliš mnoha žádostí.

  • Vlastnost jističe definuje pravidla pro jízdu jističe, například počet nebo procento podmínek selhání během definovaného časového intervalu a rozsah stavových kódů, které označují chyby.
  • Když dojde k přerušení okruhu, služba API Management přestane odesílat požadavky do back-endové služby po definovanou dobu a vrátí odpověď na službu 503 Není k dispozici klientovi.
  • Po nakonfigurované době trvání jízdy se okruh resetuje a provoz se obnoví do back-endu.

Jistič back-endu je implementace modelu jističe, který umožňuje back-endu zotavit se z přetížených situací. Rozšiřuje obecné zásady omezování rychlosti a souběžnosti , které můžete implementovat za účelem ochrany brány služby API Management a back-endových služeb.

Poznámka:

  • Back-endový jistič se v současné době nepodporuje ve vrstvě Consumption služby API Management.
  • Vzhledem k distribuované povaze architektury služby API Management jsou pravidla jízdy jističe přibližná. Různé instance brány se nesynchronizují a použijí pravidla jističe na základě informací o stejné instanci.

Příklad

Ke konfiguraci jističe v back-endu použijte rozhraní REST API služby API Management nebo šablonu Bicep nebo ARM. V následujícím příkladu jistič v myBackend v instanci API Management myAPIM cesty, pokud existují tři nebo více 5xx stavových kódů označujících chyby serveru za 1 hodinu.

Jistič se resetuje po 1 hodině. Retry-After Pokud v odpovědi existuje hlavička, jistič přijme hodnotu a před opětovným odesláním požadavků do back-endu počká na zadaný čas.

Do šablony Bicep pro back-endový prostředek s jističem zahrňte fragment kódu podobný následujícímu:

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

Fond s vyrovnáváním zatížení

Služba API Management podporuje back-endové fondy, pokud chcete implementovat více back-endů pro rozhraní API a požadavky na vyrovnávání zatížení napříč těmito back-endy.

Back-endový fond použijte pro scénáře, jako jsou například následující:

  • Rozdělte zatížení na několik back-endů, které můžou mít jednotlivé back-endové jističe.
  • Přesunutí zatížení z jedné sady back-endů na jinou pro upgrade (modré zelené nasazení)

Chcete-li vytvořit back-endový fond, nastavte type vlastnost back-endu pool a zadejte seznam back-endů, které tvoří fond.

Poznámka:

  • V současné době můžete do back-endového fondu zahrnout jenom jedno back-endy. Back-end typu pool nemůžete přidat do jiného back-endového fondu. Do fondu můžete zahrnout až 30 back-endů.
  • Vzhledem k distribuované povaze architektury služby API Management je vyrovnávání zatížení back-endu přibližné. Různé instance brány se nesynchronizují a budou vyrovnávat zatížení na základě informací ve stejné instanci.

Možnosti vyrovnávání zatížení

API Management podporuje následující možnosti vyrovnávání zatížení pro back-endové fondy:

  • Kruhové dotazování: Ve výchozím nastavení se požadavky rovnoměrně distribuují napříč back-endy ve fondu.
  • Vážené: Váhy se přiřazují back-endům ve fondu a požadavky se distribuují mezi back-endy na základě relativní váhy přiřazené každému back-endu. Tuto možnost použijte pro scénáře, jako je například provedení modrého zeleného nasazení.
  • Na základě priority: Back-endy jsou uspořádány do skupin priority a požadavky se odesílají do back-endů v pořadí skupin s prioritou. V rámci skupiny priorit se požadavky distribuují rovnoměrně mezi back-endy nebo (pokud jsou přiřazené) podle relativní váhy přiřazené každému back-endu.

Poznámka:

Back-endy ve skupináchsch zařízení s nižší prioritou se použijí jenom v případech, kdy jsou všechny back-endy ve skupinách s vyšší prioritou nedostupné.

Příklad

Ke konfiguraci back-endového fondu použijte rozhraní REST API služby API management nebo šablonu Bicep nebo ARM. V následujícím příkladu je back-end myBackendPool v instanci služby API Management myAPIM nakonfigurovaný s back-endovým fondem. Ukázkové back-endy ve fondu se nazývají back-end-1 a back-end-2. Oba back-endy jsou ve skupině s nejvyšší prioritou; v rámci skupiny má back-end-1 větší váhu než back-end-2 .

Do šablony Bicep pro back-endový prostředek s fondem s vyrovnáváním zatížení zahrňte fragment kódu podobný následujícímu:

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

Omezení

U úrovní Developer a Premium může instance služby API Management nasazená v interní virtuální síti vyvolat chyby HTTP 500 BackendConnectionFailure , pokud je adresa URL koncového bodu brány a adresa URL back-endu stejná. Pokud narazíte na toto omezení, postupujte podle pokynů v článku o interním režimu virtuální sítě na blogu Tech Community v omezení požadavků služby API Management v rámci samoobslužného řetězení.