Sdílet prostřednictvím

Vlastní ukládání do mezipaměti ve službě Azure API Management

PLATÍ PRO: Všechny úrovně služby správy rozhraní API

Služba Azure API Management má integrovanou podporu ukládání odpovědí HTTP do mezipaměti pomocí adresy URL prostředku jako klíče. Klíč můžete upravit pomocí hlaviček požadavků, které používají vary-by vlastnosti. Tato technika je užitečná pro ukládání celých odpovědí HTTP (označovaných také jako reprezentace), ale někdy je užitečné jen ukládat část reprezentace do mezipaměti. Zásady cache-lookup-value a cache-store-value umožňují ukládat a načítat libovolné části dat z definic zásad. Tato schopnost také přidává hodnotu do zásad odesílání požadavků , protože odpovědi z externích služeb můžete ukládat do mezipaměti.

Architecture

Služba API Management používá sdílenou interní mezipaměť dat pro jednotlivé tenanty, abyste při vertikálním navýšení kapacity na více jednotek stále získali přístup ke stejným datům uloženým v mezipaměti. Při práci s nasazením ve více oblastech jsou však v každé oblasti nezávislé mezipaměti. Je důležité, abyste mezipaměť nezacházeli jako s úložištěm dat, kde je jediným zdrojem některých informací. Pokud jste to udělali a později se rozhodli využít nasazení ve více oblastech, zákazníci s uživateli, kteří cestují, můžou přijít o přístup k datům uloženým v mezipaměti.

Poznámka:

Interní mezipaměť není dostupná na úrovni Consumption služby Azure API Management. Místo toho můžete použít externí mezipaměť kompatibilní s Redis . Externí mezipaměť umožňuje větší řízení mezipaměti a flexibilitu pro instance služby API Management ve všech úrovních.

Ukládání fragmentů do mezipaměti

Existují určité případy, kdy vrácené odpovědi obsahují část dat, která je nákladná k určení. Data ale zůstávají po určitou dobu čerstvá. Představte si například službu vytvořenou leteckým společností, která poskytuje informace týkající se rezervací letů, stavu letu atd. Pokud je uživatel členem věrnostního programu leteckých společností, měl by mít k dispozici údaje týkající se jejich aktuálního stavu a nasbírané míle. Tyto informace související s uživatelem můžou být uložené v jiném systému, ale může být žádoucí je zahrnout do odpovědí vrácených o stavu letu a rezervacích. Tato data můžete zahrnout pomocí procesu označovaného jako ukládání fragmentů do mezipaměti. Primární reprezentaci lze vrátit ze zdrojového serveru pomocí určitého typu tokenu, který označuje, kam se mají vložit informace související s uživatelem.

Podívejte se na následující odpověď JSON z back-endového rozhraní API.

{
  "airline" : "Air Canada",
  "flightno" : "871",
  "status" : "ontime",
  "gate" : "B40",
  "terminal" : "2A",
  "userprofile" : "$userprofile$"
}

Sekundární prostředek na /userprofile/{userid} vypadá takto:

{ "username" : "Bob Smith", "Status" : "Gold" }

Aby bylo možné určit vhodné informace o uživateli, které se mají zahrnout, musí služba API Management určit, kdo je koncovým uživatelem. Tento mechanismus je závislý na implementaci. Následující příklad používá Subject deklaraci identity tokenu JWT .

<set-variable
  name="enduserid"
  value="@(context.Request.Headers.GetValueOrDefault("Authorization","").Split(' ')[1].AsJwt()?.Subject)" />

Api Management ukládá enduserid hodnotu do kontextové proměnné pro pozdější použití. Dalším krokem je určit, jestli předchozí požadavek již načetl informace o uživateli a uložil je v mezipaměti. K tomu služba API Management používá zásadu cache-lookup-value .

<cache-lookup-value
key="@("userprofile-" + context.Variables["enduserid"])"
variable-name="userprofile" />
<rate-limit calls="10" renewal-period="60" />

Poznámka:

Po vyhledávání cache přidejte politiku omezení rychlosti (nebo politiku omezení podle klíčů ), která pomůže omezit počet hovorů a zabrání přetížení backendové služby v případě, že cache není dostupná.

Pokud v mezipaměti není žádná položka, která odpovídá hodnotě klíče, není vytvořena žádná userprofile kontextová proměnná. API Management kontroluje úspěch vyhledávání pomocí choose zásad toku řízení.

<choose>
    <when condition="@(!context.Variables.ContainsKey("userprofile"))">
        <!-- If the userprofile context variable doesn’t exist, make an HTTP request to retrieve it.  -->
    </when>
</choose>

userprofile Pokud kontextová proměnná neexistuje, bude muset služba API Management vytvořit požadavek HTTP, aby ji načetl.

<send-request
  mode="new"
  response-variable-name="userprofileresponse"
  timeout="10"
  ignore-error="true">

  <!-- Build a URL that points to the profile for the current end-user -->
  <set-url>@(new Uri(new Uri("https://apimairlineapi.azurewebsites.net/UserProfile/"),
      (string)context.Variables["enduserid"]).AbsoluteUri)
  </set-url>
  <set-method>GET</set-method>
</send-request>

Služba API Management používá enduserid k vytvoření adresy URL prostředku profilu uživatele. Jakmile má služba API Management odpověď, přetáhne z odpovědi základní text a uloží ji zpět do kontextové proměnné.

<set-variable
    name="userprofile"
    value="@(((IResponse)context.Variables["userprofileresponse"]).Body.As<string>())" />

Abyste zabránili službě API Management, aby tento požadavek HTTP znovu udělal, když stejný uživatel provede další požadavek, můžete určit, že profil uživatele je uložen v mezipaměti.

<cache-store-value
    key="@("userprofile-" + context.Variables["enduserid"])"
    value="@((string)context.Variables["userprofile"])" duration="100000" />

Služba API Management ukládá hodnotu v mezipaměti pomocí stejného klíče, kterým se služba API Management původně pokusila ji načíst. Doba trvání, kterou služba API Management zvolí k uložení hodnoty, by měla být založena na tom, jak často se informace mění a jak jsou tolerantní uživatelé k zastaralým informacím.

Je důležité si uvědomit, že načítání informací z mezipaměti je stále požadavek na síť mimo proces a může do požadavku potenciálně přidat desítky milisekund. Výhody se projeví, když určování informací o uživatelském profilu trvá déle než načítání informací z mezipaměti, což je způsobeno potřebou databázových dotazů nebo agregace informací z vícero back-endů.

Posledním krokem v procesu je aktualizace vrácené odpovědi informacemi o profilu uživatele.

<!-- Update response body with user profile-->
<find-and-replace
    from='"$userprofile$"'
    to="@((string)context.Variables["userprofile"])" />

Jako součást tokenu můžete zahrnout uvozovky, takže i když nedojde k nahrazení, bude odpověď stále platná ve formátu JSON.

Po zkombinování těchto kroků je konečným výsledkem zásada, která vypadá jako následující.

<policies>
    <inbound>
        <!-- How you determine user identity is application dependent -->
        <set-variable
          name="enduserid"
          value="@(context.Request.Headers.GetValueOrDefault("Authorization","").Split(' ')[1].AsJwt()?.Subject)" />

        <!--Look for userprofile for this user in the cache -->
        <cache-lookup-value
          key="@("userprofile-" + context.Variables["enduserid"])"
          variable-name="userprofile" />
        <rate-limit calls="10" renewal-period="60" />

        <!-- If API Management doesn’t find it in the cache, make a request for it and store it -->
        <choose>
            <when condition="@(!context.Variables.ContainsKey("userprofile"))">
                <!-- Make HTTP request to get user profile -->
                <send-request
                  mode="new"
                  response-variable-name="userprofileresponse"
                  timeout="10"
                  ignore-error="true">

                   <!-- Build a URL that points to the profile for the current end-user -->
                    <set-url>@(new Uri(new Uri("https://apimairlineapi.azurewebsites.net/UserProfile/"),(string)context.Variables["enduserid"]).AbsoluteUri)</set-url>
                    <set-method>GET</set-method>
                </send-request>

                <!-- Store response body in context variable -->
                <set-variable
                  name="userprofile"
                  value="@(((IResponse)context.Variables["userprofileresponse"]).Body.As<string>())" />

                <!-- Store result in cache -->
                <cache-store-value
                  key="@("userprofile-" + context.Variables["enduserid"])"
                  value="@((string)context.Variables["userprofile"])"
                  duration="100000" />
            </when>
        </choose>
        <base />
    </inbound>
    <outbound>
        <!-- Update response body with user profile-->
        <find-and-replace
              from='"$userprofile$"'
              to="@((string)context.Variables["userprofile"])" />
        <base />
    </outbound>
</policies>

Tento přístup k ukládání do mezipaměti se primárně používá na webech, kde se HTML skládá na straně serveru, aby se mohl vykreslit jako jedna stránka. Může být také užitečné v rozhraních API, kde klienti nemůžou provádět ukládání do mezipaměti HTTP na straně klienta nebo je žádoucí nepřenášet tuto odpovědnost na klienta.

Stejný druh ukládání fragmentů do mezipaměti lze provést také na back-endových webových serverech pomocí serveru pro ukládání do mezipaměti Redis. Použití služby API Management k provedení této práce je však užitečné, když fragmenty uložené v mezipaměti pocházejí z různých back-endů než primární odpovědi.

Transparentní správa verzí

Je běžné, že se podporuje více různých verzí implementace rozhraní API najednou. Pokud například chcete podporovat různá prostředí (vývoj, testování, produkční atd.) nebo podporovat starší verze rozhraní API, aby měli uživatelé rozhraní API čas na migraci na novější verze.

Jedním z přístupů ke zpracování více verzí je místo toho, aby vývojáři klientů museli změnit adresy URL na /v1/customers/v2/customers, uložit do dat profilu uživatele, která verze rozhraní API, kterou aktuálně chtějí použít, a volat odpovídající back-endovou adresu URL. Pokud chcete určit správnou adresu URL back-endu pro volání konkrétního klienta, je nutné zadat dotaz na některá konfigurační data. Když tato konfigurační data ukládáte do mezipaměti, může služba API Management minimalizovat snížení výkonu tohoto vyhledávání.

Prvním krokem je určení identifikátoru použitého ke konfiguraci požadované verze. V tomto příkladu přidružíme verzi k kódu Product Subscription Key.

<set-variable name="clientid" value="@(context.Subscription.Key)" />

Služba API Management pak vyhledá mezipaměť a zjistí, jestli už načetla požadovanou verzi klienta.

<cache-lookup-value
key="@("clientversion-" + context.Variables["clientid"])"
variable-name="clientversion" />
<rate-limit calls="10" renewal-period="60" />

Poznámka:

Po vyhledávání cache přidejte politiku omezení rychlosti (nebo politiku omezení podle klíčů ), která pomůže omezit počet hovorů a zabrání přetížení backendové služby v případě, že cache není dostupná.

Pak služba API Management zkontroluje, jestli ho v mezipaměti nenašla.

<choose>
    <when condition="@(!context.Variables.ContainsKey("clientversion"))">

Pokud to služba API Management nenašla, služba API Management to načte.

<send-request
    mode="new"
    response-variable-name="clientconfiguresponse"
    timeout="10"
    ignore-error="true">
            <set-url>@(new Uri(new Uri(context.Api.ServiceUrl.ToString() + "api/ClientConfig/"),(string)context.Variables["clientid"]).AbsoluteUri)</set-url>
            <set-method>GET</set-method>
</send-request>

Extrahujte základní text odpovědi z odpovědi.

<set-variable
      name="clientversion"
      value="@(((IResponse)context.Variables["clientconfiguresponse"]).Body.As<string>())" />

Uložte ho zpátky do mezipaměti pro budoucí použití.

<cache-store-value
      key="@("clientversion-" + context.Variables["clientid"])"
      value="@((string)context.Variables["clientversion"])"
      duration="100000" />

Nakonec aktualizujte back-endovou adresu URL tak, aby vybrali verzi služby, kterou klient chce.

<set-backend-service
      base-url="@(context.Api.ServiceUrl.ToString() + "api/" + (string)context.Variables["clientversion"] + "/")" />

Úplná zásada je následující:

<inbound>
    <base />
    <set-variable name="clientid" value="@(context.Subscription.Key)" />
    <cache-lookup-value key="@("clientversion-" + context.Variables["clientid"])" variable-name="clientversion" />
    <rate-limit calls="10" renewal-period="60" />

    <!-- If API Management doesn’t find it in the cache, make a request for it and store it -->
    <choose>
        <when condition="@(!context.Variables.ContainsKey("clientversion"))">
            <send-request mode="new" response-variable-name="clientconfiguresponse" timeout="10" ignore-error="true">
                <set-url>@(new Uri(new Uri(context.Api.ServiceUrl.ToString() + "api/ClientConfig/"),(string)context.Variables["clientid"]).AbsoluteUri)</set-url>
                <set-method>GET</set-method>
            </send-request>
            <!-- Store response body in context variable -->
            <set-variable name="clientversion" value="@(((IResponse)context.Variables["clientconfiguresponse"]).Body.As<string>())" />
            <!-- Store result in cache -->
            <cache-store-value key="@("clientversion-" + context.Variables["clientid"])" value="@((string)context.Variables["clientversion"])" duration="100000" />
        </when>
    </choose>
    <set-backend-service base-url="@(context.Api.ServiceUrl.ToString() + "api/" + (string)context.Variables["clientversion"] + "/")" />
</inbound>

Toto elegantní řešení řeší řadu problémů se správou verzí rozhraní API tím, že uživatelům rozhraní API umožňuje transparentně řídit, ke které back-endové verzi mají přístup klienti, aniž by museli aktualizovat a znovu nasadit své klienty.

Izolace klienta

Ve větších nasazeních s více tenanty některé společnosti vytvářejí samostatné skupiny tenantů na různých nasazeních back-endového hardwaru. Tato struktura minimalizuje počet zákazníků, kteří jsou ovlivněni, když nastanou problémy s hardwarem na backendu. Umožňuje také, aby se nové verze softwaru zaváděly ve fázích. V ideálním případě by tato back-endová architektura měla být pro uživatele rozhraní API transparentní. Tuto transparentnost můžete dosáhnout pomocí techniky podobné transparentnímu verzování, manipulací backendovou adresou URL a stavu konfigurace pro každý klíč rozhraní API.

Místo vrácení upřednostňované verze rozhraní API pro každý klíč předplatného byste vrátili identifikátor, který souvisí s přiřazenou hardwarovou skupinou. Tento identifikátor lze použít k vytvoření příslušné back-endové adresy URL.

Shrnutí

Svoboda používat mezipaměť Azure API Management k ukládání jakéhokoli druhu dat umožňuje efektivní přístup ke konfiguračním datům, které můžou ovlivnit způsob zpracování příchozího požadavku. Dá se také použít k ukládání fragmentů dat, které můžou rozšířit odpovědi vrácené z back-endového rozhraní API.

Související obsah

  • Last updated on