Megosztás a következőn keresztül:

Egyéni gyorsítótárazás az Azure API Managementben

Alkalmazható minden API Management-szintre

Az Azure API Management szolgáltatás beépített támogatást nyújt a HTTP-válasz gyorsítótárazására az erőforrás URL-címének kulcsként való használatával. A kulcsot a tulajdonságokat használó vary-by kérelemfejlécekkel módosíthatja. Ez a technika a teljes HTTP-válaszok (más néven reprezentációk) gyorsítótárazásához hasznos, de néha hasznos lehet egy reprezentáció egy részének gyorsítótárazása. A gyorsítótár-keresési érték és a gyorsítótár-tároló-érték szabályzatok lehetővé teszik tetszőleges adatrészek tárolását és lekérését a szabályzatdefiníciókban. Ez a képesség a küldési kérések házirendjéhez is hozzáad értéket, mivel a külső szolgáltatásokból érkező válaszokat gyorsítótárazhatja.

Architecture

Az API Management szolgáltatás bérlőnként megosztott belső adatgyorsítótárat használ, így több egységre skálázva továbbra is hozzáférhet ugyanazokhoz a gyorsítótárazott adatokhoz. Többrégiós üzembe helyezés esetén azonban mindegyik régióban vannak független gyorsítótárak. Fontos, hogy ne kezelje a gyorsítótárat adattárként, ahol ez az egyetlen információforrás. Ha igen, és később úgy döntött, hogy kihasználja a többrégiós üzembe helyezés előnyeit, akkor az utazó felhasználók elveszítik a hozzáférést a gyorsítótárazott adatokhoz.

Megjegyzés:

A belső gyorsítótár nem érhető el az Azure API Management használati szintjén. Ehelyett használhat külső Redis-kompatibilis gyorsítótárat . A külső gyorsítótár minden szinten nagyobb gyorsítótár-vezérlést és rugalmasságot tesz lehetővé az API Management-példányok számára.

Szegmens gyorsítótárazás

Vannak olyan esetek, amikor a visszaadott válaszok az adatok egy részét tartalmazzák, amelyek meghatározása költséges. Az adatok azonban ésszerű ideig frissek maradnak. Vegyük például egy légitársaság által létrehozott szolgáltatást, amely a repülőjegy foglalásokkal, a repülési állapottal stb. kapcsolatos információkat nyújt. Ha a felhasználó tagja a légitársaságok pont programjának, akkor a jelenlegi állapotukkal és a halmozott futásteljesítményükkel kapcsolatos információkkal is rendelkeznének. Előfordulhat, hogy a felhasználóval kapcsolatos információkat egy másik rendszerben tárolják, de célszerű lehet belefoglalni a járat állapotára és foglalásaira adott válaszokba. Ezeket az adatokat a töredékek gyorsítótárazásával is felveheti. Az elsődleges reprezentáció visszaadható az eredeti kiszolgálóról, valamilyen jogkivonat használatával, amely jelzi a felhasználóval kapcsolatos információk beszúrásának helyét.

Fontolja meg a következő JSON-választ egy háttér API-ból.

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

És egy másodlagos erőforrás, /userprofile/{userid} amely úgy néz ki,

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

A megfelelő felhasználói adatok meghatározásához az API Managementnek azonosítania kell, hogy ki a végfelhasználó. Ez a mechanizmus implementációfüggő. Az alábbi példa egy Subject token igényét használja JWT.

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

Az API Management egy környezeti változóban tárolja az enduserid értéket későbbi használatra. A következő lépés annak megállapítása, hogy egy korábbi kérés már lekérte-e a felhasználói adatokat, és tárolta-e őket a gyorsítótárban. Ehhez az API Management a szabályzatot cache-lookup-value használja.

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

Megjegyzés:

Adjon hozzá egy sebességkorlát-szabályzatot (vagy kulcsonkénti sebességkorlátozási szabályzatot) a gyorsítótár-keresés után, hogy korlátozza a hívások számát, és megakadályozza a háttérszolgáltatás túlterhelését abban az esetben, ha a gyorsítótár nem érhető el.

Ha nincs olyan bejegyzés a gyorsítótárban, amely megfelel a kulcsértéknek, akkor a rendszer nem userprofile hoz létre környezeti változót. Az API Management a vezérlőfolyamat-szabályzattal choose ellenőrzi a keresés sikerességét.

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

Ha a userprofile környezeti változó nem létezik, akkor az API Managementnek HTTP-kérést kell küldenie a lekéréséhez.

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

Az API Management a enduserid segítségével hozza létre a felhasználóiprofil-erőforrás URL-jét. Miután az API Management megkapta a választ, lekéri a törzsszöveget a válaszból, és egy környezeti változóba tárolja.

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

Ha szeretné elkerülni, hogy az API Management újra végrehajtsa ezt a HTTP-kérést, amikor ugyanaz a felhasználó újabb kérést intéz, megadhatja, hogy a felhasználói profil a gyorsítótárban legyen tárolva.

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

Az API Management a gyorsítótárban tárolja az értéket ugyanazzal a kulccsal, amellyel az API Management eredetileg megpróbálta lekérni. Az API Management által az érték tárolására választott időtartamnak azon kell alapulnia, hogy milyen gyakran változnak az információk, és milyen toleránsak a felhasználók az elavult információkhoz.

Fontos tisztában lennie azzal, hogy az információk gyorsítótárból való lekérése még mindig folyamaton kívüli hálózati kérés, és akár több tíz ezredmásodpercet is hozzáadhat a kéréshez. Az előnyök akkor jönnek létre, ha a felhasználói profil adatainak meghatározása hosszabb időt vesz igénybe, mint az adatok lekérése a gyorsítótárból, mivel adatbázis-lekérdezésekre van szükség, vagy az információk több háttérrendszerből való összesítése miatt.

A folyamat utolsó lépése a visszaadott válasz frissítése a felhasználói profil adataival.

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

Dönthet úgy, hogy az idézőjeleket a token részeként adja meg, így a válasz akkor is érvényes JSON marad, ha a cseréje nem történik meg.

A lépések kombinálása után a végeredmény egy szabályzat, amely az alábbihoz hasonlóan néz ki.

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

Ezt a gyorsítótárazási módszert elsősorban olyan webhelyeken használják, ahol a HTML a kiszolgáló oldalán áll, így egyetlen oldalként jeleníthető meg. Olyan API-kban is hasznos lehet, amelyekben az ügyfelek nem végezhetnek ügyféloldali HTTP-gyorsítótárazást, vagy kívánatos, hogy az ügyfél ne viselje ezt a felelősséget.

Ugyanez a fajta fragmentum-gyorsítótárazás a háttérben futó webkiszolgálókon is elvégezhető egy Redis-gyorsítótárazási kiszolgálóval. Az API Management szolgáltatás használata azonban akkor hasznos, ha a gyorsítótárazott töredékek más háttérrendszerből származnak, mint az elsődleges válaszok.

Transzparens verziószámozás

Gyakori eljárás, hogy egy API több különböző implementációs verziója is támogatott egyszerre. Például különböző környezetek (fejlesztés, tesztelés, éles környezet stb.) támogatása, vagy az API régebbi verzióinak támogatása, hogy időt biztosítson az API-felhasználók számára az újabb verziókra való migrálásra.

A több verzió kezelésének egyik módszere, ahelyett, hogy az ügyfélfejlesztőknek az URL-címek /v1/customers/v2/customersmódosítását kellene megkövetelniük, az az, hogy a felhasználó profiladataiban tárolják az API aktuálisan használni kívánt verzióját, és meghívják a megfelelő háttér URL-címet. Egy adott ügyfél meghívásához a megfelelő háttérRENDSZER-URL-cím meghatározásához le kell kérdezni néhány konfigurációs adatot. A konfigurációs adatok gyorsítótárazásakor az API Management minimálisra csökkentheti a keresés teljesítményhatását.

Az első lépés a kívánt verzió konfigurálásához használt azonosító meghatározása. Ebben a példában a verziót a termék-előfizetés kulcsához társítjuk.

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

Az API Management ezután gyorsítótár-kereséssel ellenőrzi, hogy az már lekérte-e a kívánt ügyfélverziót.

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

Megjegyzés:

Adjon hozzá egy sebességkorlát-szabályzatot (vagy kulcsonkénti sebességkorlátozási szabályzatot) a gyorsítótár-keresés után, hogy korlátozza a hívások számát, és megakadályozza a háttérszolgáltatás túlterhelését abban az esetben, ha a gyorsítótár nem érhető el.

Ezután az API Management ellenőrzi, hogy nem található-e a gyorsítótárban.

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

Ha az API Management nem találta meg, az API Management lekéri.

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

Bontsa ki a válasz törzsszövegét a válaszból.

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

Tárolja újra a gyorsítótárban későbbi használatra.

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

Végül frissítse a háttér URL-címét, hogy kiválassza az ügyfél által kívánt szolgáltatás verzióját.

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

A teljes szabályzat a következő:

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

Ez az elegáns megoldás számos API-verziószámozási problémát kezel azáltal, hogy lehetővé teszi az API-fogyasztók számára, hogy transzparensen szabályozhassák, hogy az ügyfeleik melyik háttérverzióhoz férnek hozzá anélkül, hogy frissíteniük és újra üzembe kellene helyezniük az ügyfeleiket.

Bérlők elkülönítése

A nagyobb, több-bérlős telepítéseknél egyes vállalatok külön bérlőcsoportokat hoznak létre a háttérhardverek különálló telepítésein. Ez a struktúra minimálisra csökkenti azoknak az ügyfeleknek a számát, akiket a háttérrendszer hardverproblémái érintenek. Emellett lehetővé teszi az új szoftververziók fázisokban történő bevezetését is. Ideális esetben ennek a háttérarchitektúrának átláthatónak kell lennie az API-felhasználók számára. Ezt az átláthatóságot az átlátható verziószámozáshoz hasonló technikával érheti el, amely az API-kulcsonkénti konfigurációs állapot használatával módosítja a háttérRENDSZER URL-címét.

Ahelyett, hogy az API előnyben részesített verzióját adná vissza az egyes előfizetési kulcsokhoz, egy olyan azonosítót adna vissza, amely a bérlőt a hozzárendelt hardvercsoporthoz kapcsolja. Ez az azonosító használható a megfelelő háttér URL-cím létrehozásához.

Összefoglalás

Az Azure API felügyeleti gyorsítótárának bármilyen adat tárolására való használatának szabadsága lehetővé teszi a konfigurációs adatok hatékony elérését, amely befolyásolhatja a bejövő kérések feldolgozásának módját. Emellett olyan adattöredékek tárolására is használható, amelyek képesek a válaszok kiegészítésére, amelyeket egy háttér API-ból ad vissza.

Kapcsolódó tartalom

  • Last updated on