تطبيق ويب بلا خادم

معرف Microsoft Entra

Azure API Management

Azure Blob Storage

Azure Content Delivery Network

Azure Functions

Azure Monitor

توضح هذه البنية المرجعية تطبيق ويب بلا خادم. يقدم التطبيق محتوى ثابتًا من تخزين Azure Blob، وينفذ واجهة برمجة تطبيقات باستخدام Azure Functions. تقرأ واجهة برمجة التطبيقات البيانات من Azure Cosmos DB وتعيد النتائج إلى تطبيق الويب.

شعار GitHub يتوفر تطبيقان مرجعيان لهذه البنية على GitHub: تطبيق تسليم الطائرات بدون طيار (ARM وAzure Pipelines) وتطبيق To Do (Bicep وGitHub Actions).

بناء الأنظمة

رسم تخطيطي يوضح البنية المرجعية لتطبيق ويب بلا خادم.

قم بتنزيل ملف Visio لهذه البنية.

مصطلح بلا خادم له معنيان متميزان ولكنهما مرتبطان:

الجهة الخلفية كخدمة (BaaS). توفر الخدمات السحابية الخلفية، مثل قواعد البيانات والتخزين، واجهات برمجة التطبيقات التي تُمكّن تطبيقات العميل من الاتصال مباشرةً بهذه الخدمات.
الدالات كخدمة (FaaS). في هذا النموذج، "الدالة" هي جزء من التعليمات البرمجية التي يتم توزيعها في السحابة ويتم تشغيلها داخل بيئة استضافة تقوم بتجريد الخوادم التي تقوم بتشغيل التعليمة البرمجية بشكل كامل.

يشترك كلا التعريفين في فكرة أن المطورين وموظفي DevOps لا يحتاجون إلى توزيع أو تكوين أو إدارة الخوادم. تركز هذه البنية المرجعية على FaaS باستخدام Azure Functions، على الرغم من أن تقديم محتوى الويب من Azure Blob Storage يمكن أن يكون مثالاً على BaaS. بعض الخصائص المهمة لـ FaaS هي:

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

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

المكونات

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

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

شبكة تسليم المحتوى. استخدم Azure Content Delivery Network لتخزين المحتوى مؤقتا للحصول على زمن انتقال أقل وتسليم أسرع للمحتوى، بالإضافة إلى توفير نقطة نهاية HTTPS.

تطبيقات Function Apps. Azure Functions هي خيار حساب بلا خادم. يستخدم نموذجًا مدفوعًا بالحدث، حيث يتم استدعاء جزء من التعليمات البرمجية ("وظيفة") بواسطة مشغل. في هذه البنية، يتم استدعاء الوظيفة عندما يقوم العميل بتقديم طلب HTTP. يتم توجيه الطلب دائمًا من خلال بوابة واجهة برمجة التطبيقات الموضحة أدناه.

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

يمكن أيضًا استخدام إدارة واجهة برمجة التطبيقات (APIM) لتنفيذ الاهتمامات الشاملة مثل:

فرض حصص الاستخدام وحدود الأسعار
التحقق من صحة رموز OAuth المميزة للمصادقة
تمكين الطلبات عبر الأصل (CORS)
استجابات التخزين المؤقت
طلبات المراقبة والتسجيل

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

قاعدة بيانات Azure Cosmos. قاعدة بيانات Azure Cosmos هي خدمة قاعدة بيانات متعددة النماذج. بالنسبة لهذا السيناريو، يجلب تطبيق الدالة المستندات من Azure Cosmos DB استجابة لطلبات HTTP GET من العميل.

معرف Microsoft Entra. يقوم المستخدمون بتسجيل الدخول إلى تطبيق الويب باستخدام بيانات اعتماد معرف Microsoft Entra الخاصة بهم. يقوم Microsoft Entra ID بإرجاع رمز مميز للوصول لواجهة برمجة التطبيقات، والذي يستخدمه تطبيق الويب لمصادقة طلبات واجهة برمجة التطبيقات (راجع المصادقة).

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

Azure Pipelines. Azure Pipelines هي خدمة تكامل مستمر (CI) وتسليم مستمر (CD)، تقوم بإنشاء التطبيق واختباره وتوزيعه.

GitHub Actions. سير العمل هو عملية تلقائية (تكامل مستمر/ تسليم مستمر) قمت بإعدادها في مستودع GitHub. يمكنك إنشاء أي مشروع أو اختباره أو تجميعه أو إصداره أو توزيعه على GitHub باستخدام سير عمل.

تفاصيل السيناريو

حالات الاستخدام المحتملة

حل تسليم الطائرات بدون طيار هذا مثالي للصناعات الطائرات والطيران والفضاء والروبوتات.

التوصيات

خطط تطبيق Function App

تدعم وظائف Azure Functions نموذجين للاستضافة. باستخدام خطة الاستهلاك، يتم تخصيص طاقة الحساب تلقائيًا عند تشغيل الكود الخاص بك. مع خطة خدمة التطبيق، يتم تخصيص مجموعة من الأجهزة الظاهرية للتعليمة البرمجية الخاصة بك. تحدد خطة App Service عدد الأجهزة الظاهرية وحجم الجهاز الظاهري.

لاحظ أن خطة App Service ليست بلا خادم بدقة، وفقا للتعريف المعطى أعلاه. نموذج البرمجة هو نفسه، ومع ذلك، يمكن تشغيل تعليمة الوظيفة البرمجية نفسه في كل من خطة الاستهلاك وخطة خدمة التطبيقات.

فيما يلي بعض العوامل التي يجب مراعاتها عند اختيار نوع الخطة المراد استخدامها:

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

حدود تطبيق الوظائف

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

استخدم تطبيقات الوظائف لتجميع الوظائف التي تشترك في نفس دورة الحياة والإعدادات. يجب استضافة الوظائف التي لا تشترك في نفس دورة الحياة في تطبيقات وظائف مختلفة.

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

روابط الوظائف

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

على سبيل المثال، تستخدم الدالة GetStatus في التنفيذ المرجعي ربط إدخال Azure Cosmos DB. تم تكوين هذا الربط للبحث عن مستند في Azure Cosmos DB، باستخدام معلمات الاستعلام التي تم أخذها من سلسلة الاستعلام في طلب HTTP. إذا تم العثور على المستند، يتم تمريره إلى الدالة كمعلمة.

[Function("GetStatusFunction")]
public IActionResult Run([HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req,
        [CosmosDBInput(
           databaseName: "%COSMOSDB_DATABASE_NAME%",
           containerName:"%COSMOSDB_DATABASE_COL%",
           Connection  = "COSMOSDB_CONNECTION_STRING",
           Id = "{Query.deviceId}",
           PartitionKey = "{Query.deviceId}")] DeviceState? deviceStatus)
{
  ...
}

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

الاعتبارات

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

قابلية التوسع

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

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

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

التعافي من الكوارث

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

تدعم إدارة APIM التوزيع متعدد المناطق، والذي يمكن استخدامه لتوزيع مثيل إدارة APIM واحد عبر أي عدد من مناطق Azure. لمزيد من المعلومات، راجع كيفية نشر مثيل خدمة Azure API Management لمناطق Azure المتعددة.
استخدم Traffic Manager لتوجيه طلبات HTTP إلى المنطقة الأساسية. إذا أصبح تطبيق الوظائف الذي يعمل في تلك المنطقة غير متاح، يمكن أن يفشل Traffic Manager في منطقة ثانوية.
يدعم Azure Cosmos DB مناطق كتابة متعددة، ما يتيح عمليات الكتابة إلى أي منطقة تضيفها إلى حساب Azure Cosmos DB الخاص بك. إذا لم تقم بتمكين الكتابة المتعددة، فلا يزال بإمكانك الفشل في منطقة الكتابة الأساسية. تتعامل SDKs لعميل Azure Cosmos DB وروابط Azure Function تلقائيا مع تجاوز الفشل، لذلك لا تحتاج إلى تحديث أي إعدادات تكوين تطبيق.

الأمان

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

المصادقة

GetStatus تستخدم واجهة برمجة التطبيقات في التنفيذ المرجعي معرف Microsoft Entra لمصادقة الطلبات. يدعم معرف Microsoft Entra بروتوكول OpenID Connect، وهو بروتوكول مصادقة تم إنشاؤه أعلى بروتوكول OAuth 2.

في هذه البنية، يكون تطبيق العميل تطبيقًا من صفحة واحدة (SPA) يتم تشغيله في المتصفح. لا يمكن لهذا النوع من تطبيقات العميل الاحتفاظ بسر العميل أو رمز التخويل مخفيا، لذا فإن تدفق المنح الضمني مناسب. (راجع ما هو تدفق OAuth 2.0 الذي يتعين عليّ أستخدامه؟). إليك التدفق الكلي:

ينقر المستخدم على ارتباط "تسجيل الدخول" في تطبيق الويب.
تتم إعادة توجيه المستعرض في صفحة تسجيل الدخول إلى Microsoft Entra.
يقوم المستخدم بتسجيل الدخول.
يعيد معرف Microsoft Entra توجيهه مرة أخرى إلى تطبيق العميل، بما في ذلك رمز مميز للوصول في جزء عنوان URL.
عندما يستدعي تطبيق الويب واجهة برمجة التطبيقات، فإنه يتضمن الرمز المميز للوصول في عنوان المصادقة. يتم إرسال معرّف التطبيق باعتباره مطالبة الجمهور ("aud") في الرمز المميز للوصول.
تتحقق واجهة برمجة التطبيقات الخلفية من الرمز المميز للوصول.

لتكوين المصادقة:

تسجيل تطبيق في مستأجر Microsoft Entra. يؤدي هذا إلى إنشاء معرّف التطبيق، والذي يضمّنه العميل مع عنوان URL لتسجيل الدخول.
تمكين مصادقة Microsoft Entra داخل تطبيق الوظائف. لمزيد من المعلومات، راجع المصادقة والتخويل في Azure App Service.
أضف نهج validate-jwt إلى إدارة واجهة برمجة التطبيقات (APIM) لتخويل الطلب مسبقًا عن طريق التحقق من الرمز المميز للوصول.

لمزيد من التفاصيل، راجع الملف التمهيدي لـ GitHub.

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

ضمن واجهة برمجة التطبيقات، استخدم النطاقات لمنح التطبيقات تحكمًا دقيقًا في الأذونات التي يطلبونها من المستخدم. على سبيل المثال، قد تحتوي واجهة برمجة التطبيقات على نطاقات Read وWrite، وقد يطلب تطبيق عميل معين من المستخدم تخويل الأذونات Read فقط.

التصريح

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

يحتوي الرمز المميز للمعرف الذي يرجعه معرف Microsoft Entra إلى العميل على بعض مطالبات المستخدم. ضمن تطبيق الوظيفة، تتوفر هذه المطالبات في عنوان X-MS-CLIENT-PRINCIPAL للطلب. ومع ذلك، من الأسهل قراءة هذه المعلومات من البيانات المرتبطة. بالنسبة للمطالبات الأخرى، استخدم Microsoft Graph للاستعلام عن معرف Microsoft Entra. (يجب أن يوافق المستخدم على هذا الإجراء عند تسجيل الدخول.)

لمزيد من المعلومات، راجع التعامل مع هويات العميل.

CORS

في هذه البنية المرجعية، لا يشترك تطبيق الويب وواجهة برمجة التطبيقات في نفس الأصل. وهذا يعني أنه عندما يستدعي التطبيق واجهة برمجة التطبيقات، فإنه طلب عبر المنشأ. يمنع أمان المتصفح صفحة الويب من إرسال طلبات AJAX إلى مجال آخر. يُطلق على هذا التقييد نهج نفس المصدر ويمنع أي موقع ويب ضار من قراءة بيانات حساسة من موقع ويب آخر. لتمكين طلب عبر الأصل، أضف نهج مشاركة الموارد عبر الأصل (CORS) إلى بوابة APIM:

<cors allow-credentials="true">
    <allowed-origins>
        <origin>[Website URL]</origin>
    </allowed-origins>
    <allowed-methods>
        <method>GET</method>
    </allowed-methods>
    <allowed-headers>
        <header>*</header>
    </allowed-headers>
</cors>

في هذا المثال، تكون سمة allow-credentialsصحيحة. هذا يصرح للمتصفح بإرسال بيانات الاعتماد (بما في ذلك ملفات تعريف الارتباط) مع الطلب. وإلا، بشكل افتراضي، لا يرسل المستعرض بيانات اعتماد مع طلب عبر المنشأ.

إشعار

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

افرض HTTPS

للحصول على أقصى قدر من الأمان، اطلب HTTPS طوال مسار الطلب:

شبكة تسليم المحتوى. تقوم شبكة Azure CDN بدعم HTTPS على المجال الفرعي *.azureedge.net بشكل افتراضي. لتمكين HTTPS في شبكة CDN لأسماء المجالات المخصصة، راجع البرنامج التعليمي: تكوين HTTPS على مجال Azure CDN المخصص.
استضافة مواقع الويب الثابتة. قم بتمكين خيار "النقل الآمن المطلوب" في حساب التخزين. عند تمكين هذا الخيار، لا يسمح حساب التخزين إلا بالطلبات من اتصالات HTTPS الآمنة.

إدارة واجهة برمجة التطبيقات. قم بتكوين واجهات برمجة التطبيقات لاستخدام بروتوكول HTTPS فقط. يمكنك تكوين هذا في مدخل Microsoft Azure أو من خلال قالب Resource Manager:

{
    "apiVersion": "2018-01-01",
    "type": "apis",
    "name": "dronedeliveryapi",
    "dependsOn": [
        "[concat('Microsoft.ApiManagement/service/', variables('apiManagementServiceName'))]"
    ],
    "properties": {
        "displayName": "Drone Delivery API",
        "description": "Drone Delivery API",
        "path": "api",
        "protocols": [ "HTTPS" ]
    },
    ...
}

Azure Functions. قم بتمكين إعداد "HTTPS فقط".

تأمين تطبيق الوظائف

يجب أن تمر جميع الاستدعاءات إلى الوظيفة عبر بوابة واجهة برمجة التطبيقات. يمكن تحقيق ذلك على النحو التالي:

تكوين تطبيق الوظائف للمطالبة بمفتاح وظيفة. ستتضمن بوابة APIM مفتاح الوظيفة عندما تستدعي تطبيق الوظيفة. هذا يمنع العملاء من استدعاء الوظيفة مباشرةً، وتجاوز البوابة.
بوابة APIM لها عنوان IP ثابت. تقييد Azure Function للسماح فقط بالمكالمات من عنوان IP ثابت. لمزيدٍ من المعلومات، راجع قيود على عناوين IP ثابتة لخدمة Azure App. (هذه الميزة متاحة لخدمات المستوى القياسي فقط.)

حماية أسرار التطبيقات

لا تقم بتخزين أسرار التطبيقات، مثل بيانات اعتماد قاعدة البيانات، في التعليمات البرمجية أو ملفات التكوين. بدلاً من ذلك، استخدم إعدادات التطبيق المخزنة بشكل مشفر في Azure. لمزيد من المعلومات، راجع الأمان في خدمة تطبيق Azure وAzure Functions.

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

DevOps

يتم أتمتة ممارسات النشر الآمنة باستخدام خدمة CI/CD موثوقة مثل Azure Pipelines أو GitHub Actions. يتم استخدام هذه الخدمات لإنشاء ونشر كل تغيير مصدر في الواجهة الأمامية والخلفية تلقائيا. يجب أن يكون المصدر موجودًا في نظام التحكم بالإصدار عبر الإنترنت. لمزيد من التفاصيل بشأن Azure Pipelines، اقرأ إنشاء البنية الأساسية لبرنامج ربط العمليات التجارية الأولى. لمعرفة المزيد حول إجراءات GitHub ل Azure، راجع نشر التطبيقات إلى Azure.

توزيع الواجهة الأمامية

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

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

التوزيع الخلفي

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

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

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

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

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

إذا قمت بإجراء تغيير قاطع في واجهة برمجة التطبيقات، فقم بنشر إصدار جديد في APIM. قم بتوزيع الإصدار الجديد جنبًا إلى جنب مع الإصدار الأصلي في تطبيق Function App المنفصل. يتيح لك هذا ترحيل العملاء الحاليين إلى واجهة برمجة التطبيقات الجديدة دون مقاطعة تطبيقات العميل. في نهاية الأمر، يمكنك إهمال الإصدار السابق. تدعم APIM العديد من أنظمة تعيين الإصدار: مسار URL أو عنوان HTTP أو سلسلة الاستعلام. لمزيد من المعلومات بشأن تعيين إصدار واجهة برمجة التطبيقات بشكل عام، راجع تعيين إصدار واجهة برمجة تطبيقات ويب RESTful.

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

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

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

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

دالات Azure

تدعم وظائف Azure Functions نموذجين للاستضافة.

خطة الاستهلاك.

يتم تخصيص قوة الحساب تلقائياً عند تشغيل التعليمة البرمجية الخاصة بك.
خطة خدمة التطبيق.

يتم تخصيص مجموعة من الأجهزة الظاهرية للتعليمة البرمجية الخاص بك. تحدد الخطة هذه عدد الأجهزة الظاهرية وحجم الجهاز الظاهري.

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

Azure Cosmos DB

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

يتم محاسبة التخزين لكل جيجا بايت مستخدم لبياناتك وفهرسك المخزنة.

راجع نموذج تسعير Azure Cosmos DB لمزيد من المعلومات.

في هذه البنية، يجلب تطبيق الدالة المستندات من Azure Cosmos DB استجابة لطلبات HTTP GET من العميل. Azure Cosmos DB فعال من حيث التكلفة في هذه الحالة لأن عمليات القراءة أرخص بكثير من عمليات الكتابة المعبر عنها على RU/s.

شبكة تسليم المحتوى

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

في هذه البنية المرجعية، يتواجد التوزيع في منطقة Azure واحدة.

لخفض التكاليف، ضع في اعتبارك زيادة TTL في ذاكرة التخزين المؤقت عن طريق تخزين ملفات الموارد مؤقتًا لمدة أطول وتعيين أطول مدة TTL ممكنة على المحتوى الخاص بك.

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

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

لتوزيع تنفيذ مرجعي لهذه البنية، راجع الملف التمهيدي GitHub.

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

وثائق المنتج:

وحدات التعلم:

لمعرفة المزيد حول التنفيذ المرجعي، اقرأ إرشادات التعليمة البرمجية: تطبيق بلا خادم مع Azure Functions.

إرشادات ذات صلة:

مشاركة عبر

تطبيق ويب بلا خادم

بناء الأنظمة

المكونات

تفاصيل السيناريو

حالات الاستخدام المحتملة

التوصيات

خطط تطبيق Function App

حدود تطبيق الوظائف

روابط الوظائف

الاعتبارات

قابلية التوسع

التعافي من الكوارث

الأمان

المصادقة

التصريح

CORS

افرض HTTPS

تأمين تطبيق الوظائف

حماية أسرار التطبيقات

DevOps

توزيع الواجهة الأمامية

التوزيع الخلفي

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

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

دالات Azure

Azure Cosmos DB

شبكة تسليم المحتوى

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

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

الملاحظات

الملاحظات

الموارد الإضافية

مشاركة عبر

تطبيق ويب بلا خادم

بناء الأنظمة

المكونات

تفاصيل السيناريو

حالات الاستخدام المحتملة

التوصيات

خطط تطبيق Function App

حدود تطبيق الوظائف

روابط الوظائف

الاعتبارات

قابلية التوسع

التعافي من الكوارث

الأمان

المصادقة

التصريح

CORS

افرض HTTPS

تأمين تطبيق الوظائف

حماية أسرار التطبيقات

DevOps

توزيع الواجهة الأمامية

التوزيع الخلفي

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

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

دالات Azure

Azure Cosmos DB

شبكة تسليم المحتوى

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

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

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

الملاحظات

الملاحظات

الموارد الإضافية