التنفيذ التلقائي للسحابة المستند إلى الحدث

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

بناء الأنظمة

السيناريوهات

توضح هذه المقالة سيناريوهين رئيسيين لأتمتة السحابة:

1. شعار مركز التكلفة : يتتبع هذا التنفيذ مراكز التكلفة لكل مورد Azure. تُسمِي خدمة Azure Policyجميع الموارد الجديدة في مجموعة بمعرف مركز التكلفة الافتراضي. تراقب Azure Event Grid أحداث إنشاء الموارد، ثم تستدعي دالة Azure. تتفاعل الدالة مع معرف Microsoft Entra، وتتحقق من صحة معرف مركز التكلفة للمورد الجديد. إذا كان الأمر مختلفًا، فإنه يقوم بتحديث العلامة وإرسال بريد إلكتروني إلى مالك المورد. يتم الاستنساخ من استعلامات REST لمعرف Microsoft Entra للتبسيط. يمكن أيضا دمج معرف Microsoft Entra باستخدام الوحدة النمطية Microsoft Graph PowerShell أو مكتبة مصادقة Microsoft (MSAL) ل Python.

2. استجابة التقييد: يراقب هذا المثال قاعدة بيانات Azure Cosmos DB للتقييد. يتم تشغيل تنبيهات Azure Monitor عندما تتجاوز طلبات الوصول إلى البيانات إلى Azure Cosmos DB السعة في وحدات الطلب (أو وحدات الطلب). تم تكوين مجموعة إجراءات Azure Monitor لاستدعاء دالة التنفيذ التلقائي استجابةً لهذه التنبيهات. تقوم الوظيفة بقياس RUs إلى قيمة أعلى، مما يزيد من السعة وبالتالي يوقف التنبيهات.

يتوفر التنفيذ المرجعي للسيناريو الأول على GitHub.

غالبًا ما تتم كتابة الوظائف في سيناريوهات التنفيذ التلقائي للسحابة الخالية من الخوادم هذه في PowerShell و Python، وهما من أكثر لغات البرمجة النصية شيوعًا المستخدمة في التنفيذ التلقائي للنظام. يتم نشرها باستخدام الأدوات الأساسية لوظائف Azure في Azure CLI. بدلاً من ذلك، يمكنك استخدام وحدة تحكم PowerShell من Az.Functionctions لنشر وظائف Azure وإدارتها .

‏‏سير العمل‬

يتم تنفيذ سيناريوهات التنفيذ التلقائي القائم على الأحداث بشكل أفضل باستخدام وظائف Azure. وهي تتبع هذه الأنماط الشائعة:

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

  • منح فرق DevOps حق الوصول إلى مجموعات الموارد التي تم إنشاؤها حديثاً،
  • إرسال إعلام إلى DevOps عند حذف مورد، و
  • الاستجابة لأحداث الصيانة للموارد مثل أجهزة Azure الظاهرية (VMs).

• المهام المجدولة . هذه هي عادةً مهام الصيانة التي يتم تنفيذها باستخدام الدوال التي يشغلها المؤقت . ومن الأمثلة على هذا النمط ما يلي:

  • إيقاف مورد في الليل، والبدء في الصباح
  • قراءة محتوى Blob Storage على فترات منتظمة، وتحويله إلى مستند Azure Cosmos DB،
  • المسح الدوري للموارد التي لم تعد قيد الاستخدام، وإزالتها، و
  • النسخ الاحتياطي الآلي.

• تنبيهات معالجة Azure . يستخدم هذا النمط سهولة دمج تنبيهات Azure Monitor ومجموعات العمل مع دوال Azure. وعادةً ما تتخذ الدالة إجراءات علاجية استجابةً للقياسات وتحليلات السجل والتنبيهات التي تنشأ في التطبيقات والبنية التحتية. سيناريو استجابة التقييد هو مثال على هذا النمط. السيناريوهات الشائعة الأخرى:

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

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

  • مراقبة عمليات تكنولوجيا المعلومات مثل طلبات التغيير أو الموافقات، و
  • إرسال إعلام بالبريد الإلكتروني عند اكتمال مهمة التنفيذ التلقائي.

• عرض كشبكة ويب أو واجهة برمجة تطبيقات. يمكن دمج مهام التنفيذ التلقائي باستخدام دوال Azure في تطبيقات الجهات الخارجية أو حتى أدوات سطر الأوامر، عن طريق الكشف عن الوظيفة كشبكة ويب/واجهة برمجة تطبيقات باستخدام مشغل HTTP. تتوفر أساليب مصادقة متعددة في كل من PowerShell و Python لتأمين الوصول الخارجي إلى الدالة. يحدث التشغيل التلقائي استجابة للأحداث الخارجية الخاصة بالتطبيق، على سبيل المثال، التكامل مع تطبيقات الطاقة أو GitHub. تتضمن السيناريوهات الشائعة ما يلي:

  • تشغيل التنفيذ التلقائي لخدمة فاشلة، و
  • إلحاق المستخدمين بموارد المؤسسة.

• إنشاء واجهة ChatOps. يُمَكن هذا النمط العملاء من إنشاء واجهة تشغيلية قائمة على الدردشة، وتشغيل دوال التطوير والعمليات والأوامر بما يتماشى مع التعاون البشري. يمكن أن يتكامل هذا مع إطار عمل Azure Bot واستخدام أوامر Microsoft Teams أو Slack للنشر والمراقبة والأسئلة الشائعة وما إلى ذلك. تنشئ واجهة ChatOps نظامًا في الوقت الفعلي لإدارة حوادث الإنتاج، مع توثيق كل خطوة تلقائيًا على الدردشة. اقرأ كيف يمكن أن يساعدك ChatOps في DevOps بشكل أفضل للحصول على مزيد من المعلومات.

• التنفيذ التلقائي المختلط. يستخدم هذا النمط اتصالات Azure App Service المختلطة لتثبيت مكون برنامج على جهازك المحلي. يسمح هذا المكون بالوصول الآمن إلى الموارد على هذا الجهاز. القدرة على إدارة البيئات المختلطة متاحة حاليًا على الأنظمة المستندة إلى Windows باستخدام دوال PowerShell. تتضمن السيناريوهات الشائعة ما يلي:

  • إدارة أجهزتك المحلية، و
  • إدارة أنظمة أخرى خلف جدار الحماية (على سبيل المثال، SQL Server محلي) من خلال خادم الانتقال السريع.

المكونات

تتكون البنية من المكونات التالية:

• Azure Functions. توفر دوال Azure قدرات الحوسبة التي يحركها الحدث و بلا خادم في هذه البنية. تقوم الدالة بتنفيذ مهام التنفيذ التلقائي، عند تشغيلها بواسطة الأحداث أو التنبيهات. في سيناريوهين، يتم استدعاء دالة مع طلب HTTP. يجب تقليل تعقيد التعليمات البرمجية، عن طريق تطوير الدالة عديمة الحالة وغير فعالة.

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

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

  توفر Logic Apps مصممًا مرئيًا بدون رمز أو منخفض الرمز، ويمكن استخدامه بمفرده في بعض سيناريوهات التنفيذ التلقائي. اقرأ هذه المقارنة بين دوال Azure والتطبيقات المنطقية لمعرفة الخدمة التي يمكن أن تناسب السيناريو خاصتك.

• Event Grid. تحتوي Event Grid على دعم شامل للأحداث من خدمات Azure الأخرى، بالإضافة إلى الأحداث المخصصة (تسمى أيضاً الموضوعات المخصصة). يمكن نشر الأحداث التشغيلية مثل إنشاء الموارد بسهولة إلى دالة التنفيذ التلقائي، باستخدام الآلية المدمجة لشبكة الأحداث.

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

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

• إجراء التنفيذ التلقائي . تمثل هذه الكتلة الواسعة خدمات أخرى يمكن أن تتفاعل معها وظيفتك، لتوفير دالة التنفيذ التلقائي. على سبيل المثال، معرف Microsoft Entra للتحقق من صحة العلامة كما هو الحال في السيناريو الأول، أو قاعدة بيانات لتوفيرها كما في السيناريو الثاني.

الاعتبارات

تنفذ هذه الاعتبارات ركائز Azure Well-Architected Framework، وهو عبارة عن مجموعة من المبادئ التوجيهية التي يمكن استخدامها لتحسين جودة حمل العمل. لمزيد من المعلومات، يرجى مراجعةMicrosoft Azure Well-Architected Framework.

مرونة

دالات Azure

معالجة مهلات HTTP

لتجنب مهلات HTTP لمهمة تنفيذ تلقائي أطول، قم بقائمة انتظار هذا الحدث في ناقل خدمة Microsoft Azure، وتعامل مع التنفيذ التلقائي الفعلي في دالة أخرى. يوضح سيناريو أتمتة استجابة التقييد هذا النمط، على الرغم من أن توفير Azure Cosmos DB RU الفعلي سريع.

Durable Functionsتوفر، التي تحافظ على الحالة بين استدعاءات، بديلاً للنهج أعلاه. تدعم Durable Functions لغات معينة فقط.

أعطال السجل

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

التزامن

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

التكرار

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

Event Grid

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

Azure Monitor

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

الأمان

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

التحكم في الوصول إلى الدالة

تقييد الوصول إلى دالة تم تشغيلها بواسطة HTTP عن طريق تعيين مستوى المصادقة. باستخدام المصادقة المجهولة، يمكن الوصول إلى الدالة بسهولة باستخدام عنوان URL مثل http://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>. يمكن أن تؤدي المصادقة على مستوى الدالة إلى تشويش نقطة نهاية http، عن طريق طلب مفاتيح الدوال في عنوان URL. تم تعيين هذا المستوى في ملف function.json:

{
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "Request",
      "methods": [
        "get",
        "post"
      ]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "Response"
    }
  ]
}

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

ضع في اعتبارك إضافة طبقات أمان على مصادقة الوظيفة، مثل

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

المصادقة على مستوى الدالة هي الخيار الوحيد المتاح لمجموعات إجراءات Azure Monitor باستخدام Azure Functions.

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

إذا كانت خدمة الاتصال تدعم نقاط نهاية الخدمة أو الارتباط الخاص، يمكن النظر في خيارات التكلفة التالية:

• استخدم خطة خدمة التطبيقات المخصصة، حيث يمكنك تأمين الوظائف في شبكة ظاهرية للحد من الوصول إليها. هذا غير ممكن في نموذج بلا خادم يستند إلى الاستهلاك.
• استخدم خطة azure Functions Premium، والتي تتضمن شبكة ظاهرية مخصصة لاستخدامها من قبل تطبيقات الوظائف.

لمقارنة الأسعار والميزات بين هذه الخيارات، اقرأ مقياس واستضافة Azure Functions.

التحكم في ما يمكن للدالة الوصول إليه

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

هناك نوعان من الهويات المدارة المدعومة:

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

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

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

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

تحسين التكلفة

يركز تحسين التكلفة على البحث عن طرق للحد من النفقات غير الضرورية وتحسين الكفاءة التشغيلية. لمزيد من المعلومات، راجع نظرة عامة على ركيزة تحسين التكلفة.

استخدم حاسبة تسعير Azure لتقدير التكاليف. فيما يلي بعض الاعتبارات لخفض التكلفة.

Azure Logic Apps

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

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

للحصول على التفاصيل، راجع نموذج التسعير لـ Azure Logic Apps.

في هذه البنية، يتم استخدام تطبيقات المنطق في سيناريو وضع العلامات في مركز التكلفة لتنسيق سير العمل.

يتم استخدام الموصلات المضمنة للاتصال ب Azure Functions وإرسال إعلام بالبريد الإلكتروني عند اكتمال مهمة التنفيذ التلقائي. يتم عرض الوظائف كشبكة ويب/واجهة برمجة تطبيقات باستخدام مشغل HTTP. يتم تشغيل التطبيقات المنطقية فقط عند حدوث طلب HTTPS. هذه طريقة فعالة من حيث التكلفة بالمقارنة مع التصميم حيث تعمل الدوال باستمرار على الاستقصاء والتحقق من معايير معينة. يتم قياس كل طلب استطلاع كإجراء.

لمزيد من المعلومات، راجع أسعار تطبيقات المنطق.

دالات Azure

تتوفر دوال Azure مع خطط التسعير الثلاثة التالية .

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

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

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

في سيناريوهات التشغيل التلقائي هذه، يتم استخدام Azure Functions لمهام مثل تحديث العلامات في معرف Microsoft Entra، أو تغيير تكوين Azure Cosmos DB عن طريق توسيع نطاق وحدات الطلب إلى قيمة أعلى. خطة الاستهلاك هي المناسبة لحالة الاستخدام هذه لأن هذه المهام تفاعلية وليست طويلة الأمد.

Azure Cosmos DB

فاتورة Azure Cosmos DB لمعدل النقل الموفر والتخزين المستهلك بالساعة. يتم التعبير عن معدل النقل المقدم بوحدات الطلب في الثانية (وحدة طلب/ثانية)، والتي يمكن استخدامها لعمليات قاعدة البيانات النموذجية، مثل عمليات الإدراج، والقراءات. يتم محاسبة التخزين لكل جيجا بايت مستخدم لبياناتك وفهرسك المخزنة. راجع نموذج تسعير Azure Cosmos DB لمزيد من المعلومات.

في هذه البنية، عندما تتجاوز طلبات الوصول إلى البيانات إلى Azure Cosmos DB السعة في وحدات الطلب (أو وحدات الطلب)، يقوم Azure Monitor بتشغيل التنبيهات. استجابة لتلك التنبيهات، يتم تكوين مجموعة إجراءات Azure Monitor لاستدعاء دالة التنفيذ التلقائي. تقوم الدالة بتحجيم وحدات الطلب إلى قيمة أعلى. يساعد هذا في الحفاظ على انخفاض التكلفة لأنك تدفع فقط مقابل الموارد التي تحتاجها أحمال العمل خاصتك على أساس كل ساعة.

للحصول على تقدير تكلفة سريع لحمل العمل الخاص بك، استخدم حاسبة سعة Azure Cosmos DB.

لمزيد من المعلومات، راجع قسم التكلفة في Microsoft Azure Well-Architected Framework.

اعتبارات النشر

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

إذا كان التنفيذ التلقائي يغطي تطبيقات متعددة، فاحتفظ بالموارد المطلوبة من قبل التنفيذ التلقائي في مجموعة موارد منفصلة. يمكن مشاركة مجموعة موارد واحدة بين التنفيذ التلقائي وموارد التطبيق، إذا كان التنفيذ التلقائي يغطي تطبيقاً واحداً.

إذا كان سير العمل يتضمن عدداً من وظائف التنفيذ التلقائي، فقم بتجميع الوظائف التي تلبي سيناريو واحد في تطبيق دالة واحد. اقرأ إدارة تطبيق الدوال للحصول على مزيد من المعلومات.

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

لمزيد من المعلومات، راجع قسم DevOps في Microsoft Azure Well-Architected Framework.

الإجراءات الإلزامية على موارد Azure

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

نشر هذا السيناريو

لنشر سيناريو مركز التكلفة، راجع خطوات النشر على GitHub.

الخطوات التالية

• التدريب: مقدمة إلى Azure Functions
• الوثائق: مقدمة إلى Azure Functions
• ما هي Azure Event Grid؟

الموارد ذات الصلة

• معاينة التعليمات البرمجية: تطبيق بلا خادم مع وظائف
• تصميم بنية الوظائف بلا خادم
• البنيات المرجعية للوظائف بلا خادم