Bagikan melalui

Penembolokan kustom di Azure API Management

BERLAKU UNTUK: Semua tingkatan manajemen API

Layanan Azure API Management memiliki dukungan bawaan untuk penembolokan respons HTTP menggunakan URL sumber daya sebagai kuncinya. Anda dapat mengubah kunci dengan menggunakan header permintaan yang menggunakan vary-by properti . Teknik ini berguna untuk menyimpan seluruh respons HTTP (juga dikenal sebagai representasi), tetapi terkadang berguna untuk hanya menyimpan sebagian representasi. Kebijakan cache-lookup-value dan cache-store-value memberi Anda kemampuan untuk menyimpan dan mengambil potongan data arbitrer dari dalam definisi kebijakan. Kemampuan ini juga menambahkan nilai ke kebijakan kirim permintaan karena Anda dapat menyimpan respons dari layanan eksternal.

Architecture

Layanan API Management menggunakan cache data internal bersama per penyewa, sehingga saat Anda meningkatkan skala ke beberapa unit, Anda tetap mendapatkan akses ke data cache yang sama. Namun, saat bekerja dengan penyebaran multi-wilayah, ada cache independen di masing-masing wilayah. Penting untuk tidak memperlakukan cache sebagai penyimpanan data, di mana itu adalah satu-satunya sumber dari beberapa informasi. Jika Anda melakukannya, dan kemudian memutuskan untuk memanfaatkan penyebaran multi-wilayah, maka pelanggan dengan pengguna yang melakukan perjalanan mungkin kehilangan akses ke data yang di-cache tersebut.

Nota

Cache internal tidak tersedia di tier Consumption Azure API Management. Anda dapat menggunakan cache eksternal yang kompatibel dengan Redis sebagai gantinya. Cache eksternal memungkinkan kontrol dan fleksibilitas cache yang lebih besar untuk instans API Management di semua tingkatan.

Penembolokan fragmen

Ada kasus tertentu di mana respons yang dikembalikan berisi beberapa bagian data yang mahal untuk ditentukan. Namun, data tetap segar untuk jangka waktu yang wajar. Misalnya, pertimbangkan layanan yang dibangun oleh maskapai yang memberikan informasi yang berkaitan dengan reservasi penerbangan, status penerbangan, dan sebagainya. Jika pengguna adalah anggota program poin maskapai, mereka juga akan memiliki informasi yang berkaitan dengan status mereka saat ini dan akumulasi jarak tempuh. Informasi terkait pengguna ini mungkin disimpan dalam sistem yang berbeda, tetapi mungkin diinginkan untuk menyertakannya dalam respons yang dikembalikan tentang status penerbangan dan reservasi. Anda dapat menyertakan data ini dengan menggunakan proses yang disebut fragment caching. Representasi utama dapat dikembalikan dari server asal menggunakan semacam token untuk menunjukkan di mana informasi terkait pengguna akan dimasukkan.

Pertimbangkan respons JSON berikut dari API backend.

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

Dan sumber daya sekunder di /userprofile/{userid} yang tampilannya seperti,

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

Untuk menentukan informasi pengguna yang sesuai untuk disertakan, API Management perlu mengidentifikasi siapa pengguna akhir. Mekanisme ini bergantung pada implementasi. Contoh berikut menggunakan Subject klaim JWT token.

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

API Management menyimpan enduserid nilai dalam variabel konteks untuk digunakan nanti. Langkah selanjutnya adalah menentukan apakah permintaan sebelumnya sudah mengambil informasi pengguna dan menyimpannya di cache. Untuk ini, API Management menggunakan kebijakan cache-lookup-value.

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

Nota

Tambahkan kebijakan batas tarif (atau kebijakan batas tarif berdasarkan kunci ) setelah pencarian cache untuk membantu membatasi jumlah panggilan dan mencegah kelebihan beban pada layanan backend jika cache tidak tersedia.

Jika tidak ada entri dalam cache yang sesuai dengan nilai kunci, maka tidak ada userprofile variabel konteks yang dibuat. API Management memeriksa keberhasilan pencarian menggunakan choose kebijakan alur kontrol.

<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 Jika variabel konteks tidak ada, API Management harus membuat permintaan HTTP untuk mengambilnya.

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

API Management menggunakan enduserid untuk membuat URL ke sumber daya profil pengguna. Setelah API Management memiliki respons, API Management menarik teks isi dari respons dan menyimpannya kembali ke variabel konteks.

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

Untuk menghindari API Management membuat permintaan HTTP ini lagi ketika pengguna yang sama membuat permintaan lain, Anda dapat menentukan bahwa profil pengguna disimpan di cache.

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

API Management menyimpan nilai dalam cache menggunakan kunci yang sama dengan api Management yang awalnya mencoba mengambilnya. Durasi yang dipilih API Management untuk menyimpan nilai harus didasarkan pada seberapa sering informasi berubah dan seberapa toleran pengguna terhadap informasi yang kedaluarsa.

Penting untuk disadari bahwa mengambil informasi dari cache masih merupakan permintaan jaringan yang tidak diproses dan berpotensi menambahkan puluhan milidetik ke permintaan. Manfaatnya datang ketika menentukan informasi profil pengguna membutuhkan waktu lebih lama daripada mengambil informasi dari cache karena kebutuhan akan kueri database atau menggabungkan informasi dari beberapa back-end.

Langkah terakhir dalam proses ini adalah memperbarui respons yang dikembalikan dengan informasi profil pengguna.

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

Anda dapat memilih untuk menyertakan tanda kutip sebagai bagian dari token sehingga bahkan ketika penggantian tidak terjadi, respons masih valid JSON.

Setelah Anda menggabungkan langkah-langkah ini, hasil akhirnya adalah kebijakan yang terlihat seperti berikut ini.

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

Pendekatan penyimpanan sementara ini terutama digunakan di situs web yang menyusun HTML di sisi server untuk dirender menjadi satu halaman. Ini juga dapat berguna dalam API di mana klien tidak dapat melakukan penembolokan HTTP sisi klien atau diinginkan untuk tidak menempatkan tanggung jawab itu pada klien.

Caching fragmen sejenis ini juga dapat dilakukan pada server web backend menggunakan server caching Redis. Namun, menggunakan layanan API Management untuk melakukan pekerjaan ini berguna ketika fragmen cache berasal dari back-end yang berbeda dari respons utama.

Penerapan versi transparan

Praktik umum bagi beberapa versi implementasi API yang berbeda untuk didukung kapan saja. Misalnya, untuk mendukung lingkungan yang berbeda (dev, test, production, dll.) atau untuk mendukung versi API yang lebih lama untuk memberikan waktu bagi konsumen API untuk bermigrasi ke versi yang lebih baru.

Salah satu pendekatan untuk menangani beberapa versi, alih-alih mengharuskan pengembang klien untuk mengubah URL dari /v1/customers ke /v2/customers, adalah menyimpan dalam data profil konsumen versi API mana yang saat ini ingin mereka gunakan dan memanggil URL backend yang sesuai. Untuk menentukan URL backend yang benar untuk memanggil klien tertentu, perlu untuk mengkueri beberapa data konfigurasi. Saat Anda menyimpan data konfigurasi ini, API Management dapat meminimalkan penalti performa untuk melakukan pencarian ini.

Langkah pertama adalah menentukan pengidentifikasi yang digunakan untuk mengonfigurasi versi yang diinginkan. Dalam contoh ini, kami mengaitkan versi ke kunci langganan produk.

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

API Management kemudian melakukan pencarian cache untuk melihat apakah sudah mengambil versi klien yang diinginkan.

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

Nota

Tambahkan kebijakan batas tarif (atau kebijakan batas tarif berdasarkan kunci ) setelah pencarian cache untuk membantu membatasi jumlah panggilan dan mencegah kelebihan beban pada layanan backend jika cache tidak tersedia.

Kemudian, API Management memeriksa untuk melihat apakah tidak menemukannya di cache.

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

Jika API Management tidak berhasil menemukannya, API Management akan mengambilnya.

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

Ekstrak teks isi respons dari respons.

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

Simpan kembali di cache untuk digunakan di masa mendatang.

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

Dan akhirnya perbarui URL back-end untuk memilih versi layanan yang diinginkan oleh klien.

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

Kebijakan lengkapnya adalah sebagai berikut:

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

Solusi elegan ini membahas banyak masalah penerapan versi API, dengan memungkinkan konsumen API mengontrol versi backend mana yang diakses klien mereka tanpa harus memperbarui dan menyebarkan ulang klien mereka.

Isolasi penyewa

Dalam konteks penyebaran multipenyewa berskala besar, beberapa perusahaan membuat grup penyewa terpisah pada penyebaran perangkat keras backend yang terpisah. Struktur ini meminimalkan jumlah pelanggan yang terkena dampak ketika ada masalah perangkat keras di backend. Ini juga memungkinkan versi perangkat lunak baru untuk diluncurkan secara bertahap. Idealnya arsitektur backend ini harus transparan bagi konsumen API. Anda dapat mencapai transparansi ini dengan menggunakan teknik yang mirip dengan penerapan versi transparan, memanipulasi URL backend menggunakan status konfigurasi per kunci API.

Alih-alih mengembalikan versi API pilihan untuk setiap kunci langganan, Anda akan mengembalikan pengidentifikasi yang mengaitkan penyewa dengan grup perangkat keras yang ditetapkan. Pengidentifikasi tersebut dapat digunakan untuk membuat URL backend yang sesuai.

Ringkasan

Kebebasan untuk menggunakan cache manajemen Azure API untuk menyimpan segala jenis data memungkinkan akses efisien ke data konfigurasi yang dapat memengaruhi cara permintaan masuk diproses. Ini juga dapat digunakan untuk menyimpan fragmen data yang dapat menambah respons, dikembalikan dari API backend.

Konten terkait

  • Last updated on