التخزين المؤقت المخصص في إدارة واجهة برمجة تطبيقات Azure

ينطبق على: جميع مستويات إدارة واجهة برمجة التطبيقات

تحتوي خدمة Azure API Management على دعم مضمن للتخزين المؤقت لاستجابة HTTP باستخدام عنوان URL للمورد كمفتاح. يمكنك تعديل المفتاح باستخدام رؤوس الطلبات التي تستخدم الخصائص vary-by . هذه التقنية مفيدة للتخزين المؤقت لاستجابات HTTP بأكملها (المعروفة أيضا باسم التمثيلات) ، ولكن في بعض الأحيان يكون من المفيد تخزين جزء من التمثيل مؤقتا. تمنحك نهج قيمة البحث عن ذاكرة التخزين المؤقتوقيمة مخزن ذاكرة التخزين المؤقت القدرة على تخزين أجزاء عشوائية من البيانات واستردادها من داخل تعريفات النهج. تضيف هذه الإمكانية أيضا قيمة إلى نهج طلب الإرسال لأنه يمكنك تخزين الاستجابات مؤقتا من الخدمات الخارجية.

Architecture

تستخدم خدمة إدارة واجهة برمجة التطبيقات ذاكرة تخزين مؤقت للبيانات الداخلية مشتركة لكل مستأجر بحيث لا يزال بإمكانك الوصول إلى نفس البيانات المخزنة مؤقتا، أثناء التوسع إلى وحدات متعددة. ومع ذلك، عند العمل مع نشر متعدد المناطق، توجد ذاكرة تخزين مؤقت مستقلة داخل كل منطقة من المناطق. من المهم عدم التعامل مع ذاكرة التخزين المؤقت كمخزن بيانات ، حيث تكون المصدر الوحيد لبعض المعلومات. إذا فعلت ذلك، وقررت لاحقا الاستفادة من النشر متعدد المناطق، فقد يفقد العملاء الذين لديهم مستخدمون يسافرون الوصول إلى تلك البيانات المخزنة مؤقتا.

Note

ذاكرة التخزين المؤقت الداخلية غير متوفرة في طبقة الاستهلاك في إدارة واجهة برمجة تطبيقات Azure. يمكنك استخدام ذاكرة تخزين مؤقت خارجية متوافقة مع Redis بدلا من ذلك. تسمح ذاكرة التخزين المؤقت الخارجية بمزيد من التحكم في ذاكرة التخزين المؤقت والمرونة لمثيلات إدارة واجهة برمجة التطبيقات في جميع المستويات.

التخزين المؤقت للجزء

هناك حالات معينة تحتوي فيها الردود التي يتم إرجاعها على جزء من البيانات التي يكون تحديدها مكلفا. ومع ذلك ، تظل البيانات جديدة لفترة زمنية معقولة. على سبيل المثال ، ضع في اعتبارك خدمة تم إنشاؤها بواسطة شركة طيران توفر معلومات تتعلق بحجوزات الرحلات الجوية وحالة الرحلة وما إلى ذلك. إذا كان المستخدم عضوا في برنامج نقاط شركات الطيران ، فسيكون لديه أيضا معلومات تتعلق بوضعه الحالي والأميال المتراكمة. قد يتم تخزين هذه المعلومات المتعلقة بالمستخدم في نظام مختلف ، ولكن قد يكون من المستحسن تضمينها في الردود التي يتم إرجاعها حول حالة الرحلة والحجوزات. يمكنك تضمين هذه البيانات باستخدام عملية تسمى التخزين المؤقت للجزء. يمكن إرجاع التمثيل الأساسي من الخادم الأصلي باستخدام نوع من الرمز المميز للإشارة إلى مكان إدراج المعلومات المتعلقة بالمستخدم.

ضع في اعتبارك استجابة JSON التالية من واجهة برمجة تطبيقات الواجهة الخلفية.

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

ويبدو أن المورد /userprofile/{userid} الثانوي في ذلك ،

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

لتحديد معلومات المستخدم المناسبة لتضمينها، تحتاج إدارة واجهة برمجة التطبيقات إلى تحديد هوية المستخدم النهائي. هذه الآلية تعتمد على التنفيذ. يستخدم المثال التالي المطالبة Subject برمز JWT مميز.

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

تخزن إدارة واجهة برمجة التطبيقات القيمة enduserid في متغير سياق لاستخدامها لاحقا. تتمثل الخطوة التالية في تحديد ما إذا كان الطلب السابق قد استرد بالفعل معلومات المستخدم وقام بتخزينها في ذاكرة التخزين المؤقت. لهذا الغرض، تستخدم إدارة واجهة برمجة التطبيقات السياسة cache-lookup-value .

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

Note

أضف سياسة تحديد المعدل (أو سياسة تحديد المعدل حسب المفتاح ) بعد البحث في ذاكرة التخزين المؤقت للمساعدة في تقليل عدد المكالمات ومنع التحميل الزائد على خدمة الواجهة الخلفية في حال عدم توفر الذاكرة المؤقتة.

إذا لم يكن هناك إدخال في ذاكرة التخزين المؤقت يتوافق مع قيمة المفتاح، فلن userprofile يتم إنشاء متغير سياق. تتحقق إدارة واجهة برمجة التطبيقات من نجاح البحث باستخدام choose نهج تدفق التحكم.

<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 موجودا ، فسيتعين على إدارة واجهة برمجة التطبيقات تقديم طلب HTTP لاسترداده.

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

تستخدم إدارة واجهة برمجة التطبيقات لإنشاء enduserid عنوان URL لمورد ملف تعريف المستخدم. بمجرد أن تحصل إدارة واجهة برمجة التطبيقات على الاستجابة، فإنها تسحب النص الأساسي من الاستجابة وتخزنه مرة أخرى في متغير السياق.

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

لتجنب قيام إدارة واجهة برمجة التطبيقات بتقديم طلب HTTP هذا مرة أخرى عندما يقدم نفس المستخدم طلبا آخر، يمكنك تحديد تخزين ملف تعريف المستخدم في ذاكرة التخزين المؤقت.

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

تخزن إدارة واجهة برمجة التطبيقات القيمة في ذاكرة التخزين المؤقت باستخدام نفس المفتاح الذي حاولت إدارة واجهة برمجة التطبيقات استرداده به في الاصل. يجب أن تستند المدة التي تختارها إدارة واجهة برمجة التطبيقات لتخزين القيمة إلى عدد المرات التي تتغير فيها المعلومات ومدى تسامح المستخدمين مع المعلومات القديمة.

من المهم أن تدرك أن استرداد المعلومات من ذاكرة التخزين المؤقت لا يزال طلب شبكة خارج العملية ويمكن أن يضيف عشرات المللي ثانية إلى الطلب. تأتي الفوائد عندما يستغرق تحديد معلومات ملف تعريف المستخدم وقتا أطول من استرداد المعلومات من ذاكرة التخزين المؤقت بسبب الحاجة إلى استعلامات قاعدة البيانات أو تجميع المعلومات من نهايات خلفية متعددة.

تتمثل الخطوة الأخيرة في العملية في تحديث الاستجابة التي تم إرجاعها بمعلومات ملف تعريف المستخدم.

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

يمكنك اختيار تضمين علامات الاقتباس كجزء من الرمز المميز بحيث تظل الاستجابة صالحة JSON حتى في حالة عدم حدوث الاستبدال.

بمجرد دمج هذه الخطوات، تكون النتيجة النهائية هي نهج يشبه النهج التالي.

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

يستخدم نهج التخزين المؤقت هذا بشكل أساسي في مواقع الويب حيث يتم تكوين HTML على جانب الخادم بحيث يمكن تقديمه كصفحة واحدة. يمكن أن يكون مفيدا أيضا في واجهات برمجة التطبيقات حيث لا يمكن للعملاء إجراء التخزين المؤقت ل HTTP من جانب العميل أو من المستحسن عدم وضع هذه المسؤولية على العميل.

يمكن أيضا إجراء هذا النوع نفسه من التخزين المؤقت للأجزاء على خوادم الويب الخلفية باستخدام خادم التخزين المؤقت Redis. ومع ذلك، فإن استخدام خدمة إدارة واجهة برمجة التطبيقات لتنفيذ هذا العمل مفيد عندما تأتي الأجزاء المخزنة مؤقتا من نهايات خلفية مختلفة عن الاستجابات الأساسية.

تعيين الإصدار الشفاف

من الشائع دعم إصدارات تنفيذ متعددة مختلفة من واجهة برمجة التطبيقات في أي وقت. على سبيل المثال، لدعم بيئات مختلفة (التطوير والاختبار والإنتاج وما إلى ذلك) أو لدعم الإصدارات القديمة من واجهة برمجة التطبيقات لإعطاء الوقت لمستهلكي واجهة برمجة التطبيقات للترحيل إلى الإصدارات الأحدث.

تتمثل إحدى طرق التعامل مع إصدارات متعددة ، بدلا من مطالبة مطوري العملاء بتغيير عناوين URL من /v1/customers إلى /v2/customers، في تخزين إصدار واجهة برمجة التطبيقات الذي يرغب حاليا في استخدامه في بيانات ملف تعريف المستهلك واستدعاء عنوان URL المناسب للواجهة الخلفية. لتحديد عنوان URL الصحيح للواجهة الخلفية للاتصال بعميل معين، من الضروري الاستعلام عن بعض بيانات التكوين. عند تخزين بيانات التكوين هذه مؤقتا، يمكن لإدارة واجهة برمجة التطبيقات تقليل عقوبة الأداء لإجراء هذا البحث.

تتمثل الخطوة الأولى في تحديد المعرف المستخدم لتكوين الإصدار المطلوب. في هذا المثال، نقوم بإقران الإصدار بمفتاح اشتراك المنتج.

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

Note

أضف سياسة تحديد المعدل (أو سياسة تحديد المعدل حسب المفتاح ) بعد البحث في ذاكرة التخزين المؤقت للمساعدة في تقليل عدد المكالمات ومنع التحميل الزائد على خدمة الواجهة الخلفية في حال عدم توفر الذاكرة المؤقتة.

بعد ذلك ، تتحقق إدارة واجهة برمجة التطبيقات لمعرفة ما إذا لم تعثر عليها في ذاكرة التخزين المؤقت.

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

استخرج نص نص الاستجابة من الاستجابة.

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

قم بتخزينه مرة أخرى في ذاكرة التخزين المؤقت لاستخدامه في المستقبل.

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

وأخيرا قم بتحديث عنوان URL الخلفي لتحديد إصدار الخدمة الذي يرغب فيه العميل.

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

السياسة الكاملة هي كما يلي:

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

يعالج هذا الحل الأنيق العديد من مخاوف إصدار واجهة برمجة التطبيقات، من خلال تمكين مستهلكي واجهة برمجة التطبيقات من التحكم بشفافية في إصدار الواجهة الخلفية الذي يصل إليه عملاؤهم دون الحاجة إلى تحديث عملائهم وإعادة نشرهم.

عزل المستأجر

في عمليات النشر الأكبر حجما متعددة المستأجرين، تنشئ بعض الشركات مجموعات منفصلة من المستأجرين في عمليات نشر مميزة للأجهزة الخلفية. يقلل هذا الهيكل من عدد العملاء الذين يتأثرون عند وجود مشكلة في الأجهزة على الواجهة الخلفية. كما أنه يتيح طرح إصدارات البرامج الجديدة على مراحل. من الناحية المثالية ، يجب أن تكون بنية الواجهة الخلفية هذه شفافة لمستهلكي واجهة برمجة التطبيقات. يمكنك تحقيق هذه الشفافية باستخدام تقنية مشابهة لتعيين الإصدار الشفاف، ومعالجة عنوان URL للواجهة الخلفية باستخدام حالة التكوين لكل مفتاح واجهة برمجة التطبيقات.

بدلا من إرجاع إصدار مفضل من واجهة برمجة التطبيقات لكل مفتاح اشتراك، يمكنك إرجاع معرف يربط مستأجرا بمجموعة الأجهزة المعينة. يمكن استخدام هذا المعرف لإنشاء عنوان URL المناسب للواجهة الخلفية.

ملخص

تتيح حرية استخدام ذاكرة التخزين المؤقت لإدارة واجهة برمجة تطبيقات Azure لتخزين أي نوع من البيانات الوصول الفعال إلى بيانات التكوين التي يمكن أن تؤثر على طريقة معالجة الطلب الوارد. يمكن استخدامه أيضا لتخزين أجزاء البيانات التي يمكن أن تزيد من الاستجابات، التي يتم إرجاعها من واجهة برمجة تطبيقات الواجهة الخلفية.

المحتويات ذات الصلة

• نظرة عامة على التخزين المؤقت في إدارة واجهة برمجة تطبيقات Azure
• سياسات التخزين المؤقت لإدارة واجهة برمجة التطبيقات
• كيفية استخدام ذاكرة تخزين مؤقت خارجية مع إدارة واجهة برمجة تطبيقات Azure