أفضل طريقة لاستضافة تطبيق صفحة واحدة (SPA) في Microsoft Azure

خدمة تطبيقات Azure التقليدية مقابل وظائف Azure V2 مع الوكلاء مقابل موقع التخزين الثابت Azure (معاينة)

أحتاج كثيرًا إلى نشر مواقع ويب ثابتة (مثل موقع الشركة على الويب https://www.media-lesson.com) أو تطبيقات صفحة واحدة وأبحث دائمًا عن طرق لتحسين التكلفة ووقت النشر.

أعلنت شركة Microsoft مؤخرًا عن معاينة عامة لاستضافة مواقع الويب الثابتة الخاصة بـ Azure Storage مضيفة خيارًا آخر لاستضافة تطبيق صفحة واحدة (SPA) على Azure.

قبل أن تضيف Microsoft دعمًا للوكلاء في وقت تشغيل وظائف Azure 2.0.11776-alpha في 14 مايو ، مما يوفر طريقة لاستضافة موقع ويب ثابت في Azure Storage وإعادة توجيه حركة المرور عبر مسار وكيل Azure.

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

ونظرًا لأننا نقوم بتقييم خيارات الاستضافة ، فمن الجدير أيضًا مقارنة النشر اليدوي والتلقائي باستخدام خدمات Visual Studio Team (VSTS) للخدمات المذكورة.

لذلك دعونا نجيب على هذه الأسئلة للمساعدة في تحديد الخدمة التي يجب استخدامها عند استضافة تطبيق صفحة واحدة:

  1. ما مقدار الجهد المبذول لنشر تطبيق يدويًا وتلقائيًا؟
  2. ما مقدار التكوين المطلوب؟
  3. كيف مقياس؟
  4. كيف يعمل؟
  5. كم يكلف؟

اختبار التطبيق

لذلك دعونا نبدأ هذه التجربة عن طريق إنشاء SPA بسيط يعتمد على Angular باستخدام Angular CLI كتطبيق اختبار للنشر والاختبار على 3 خدمات مختلفة: ng new testapp - routing يرجى ملاحظة أنني أضيف مباشرة ميزة التوجيه إلى التطبيق باستخدام المعلمة - routing. أجد أن هذا جانبًا مهمًا يجب اختباره عند النظر في خيارات الاستضافة حيث أن التوجيه قد يمثل تحديًا في التكوين في بعض البيئات مثل خدمة التطبيقات لأننا نحتاج إلى تكوين خادم الويب للسماح بمعالجة الطريق من خلال تطبيق العميل بدلاً من جانب الخادم.

لاختبار التوجيه بشكل كامل ، نحتاج أيضًا إلى الحصول على بعض مسارات العينات. لذلك ، دعونا نضيف منزلًا ومكوِّنًا حول تطبيقنا باستخدام CLI: ng تنشئ مكونًا رئيسيًا مكونًا للمنزل و ng تنشئ مكونًا عنه. بعد ذلك نحتاج إلى وجود طريقين في التطبيق-routing.module.ts للسماح بالتنقل بين المكونين:

أخيرًا ، بعض أزرار التنقل للسماح للمستخدم بالتنقل بين المكونين في app.component.html:

دعونا نبني تطبيقنا محليًا استعدادًا للنشر اليدوي باستخدام ng build --prod الذي يوفر لنا هذا المجلد الصغير من القطع الأثرية للبناء:

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

تثبيت npm

بناء npm

نشر بناء قطعة أثرية من مسار dist إلى التطبيق

خدمة التطبيقات Azure

Azure App Service عبارة عن عرض PaaS (النظام الأساسي كخدمة) والطريقة الكلاسيكية لاستضافة محتوى الويب على Azure. باستخدام خدمة التطبيق ، نحتاج إلى العناية بضبط وتوسيع نطاق خدمتنا باليد. لاختبار ذلك ، دعونا ننشئ خدمة تطبيق جديدة في بوابة أزور. اخترت فئة S1 لهذا الاختبار لأنها فئة مستوى الدخول لتطبيقات الإنتاج.

تكوين التوجيه

نظرًا لطبيعة كونه عرضًا PaaS ، يجب على المطورين الاهتمام بتهيئة خادم الويب الأساسي (في حالة نظام التشغيل Windows ، فإنه IIS). هذا يعني تمكين التوجيه داخل تطبيق Angular الخاص بنا ، وعلينا توفير ملف web.config مع إرشادات لخادم الويب حول كيفية التعامل مع التوجيه أو استضافة التطبيق الزاوي داخل تطبيق ASP.Net Core 2.1 مع تمكين الوسيطة SpaServices. هنا عينة بسيطة من web.config مع توجيه SPA:

دليل النشر

للنشر اليدوي ، دعونا فقط نستخدم FTP لتحميل محتوى مجلد dist الخاص بنا و web.config إلى مجلد wwwroot لخدمة التطبيق. يمكن تنزيل بيانات اعتماد FTP في بوابة Azure في علامة تبويب النظرة العامة لخدمة التطبيق من خلال النقر على "الحصول على نشر ملف التعريف".

نشر مستمر باستخدام خدمات فريق Visual Studio

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

لتكوين نقطة نهاية لخدمة FTP ، انقر فوق "إدارة" وإضافة نقطة نهاية عامة جديدة باستخدام نفس بيانات الاعتماد المستخدمة للنشر اليدوي.

وظائف أزور

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

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

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

أول من يعيد توجيه الطلبات إلى عنوان url الأساسي إلى index.html الخاص بنا

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

دليل النشر

لنشر يدويًا ، انقر فوق "حاويات" في حساب التخزين في بوابة أزور واختر حاوية "الويب" التي أنشأناها للتو. الآن دعنا نرفع الملفات من البناء المحلي.

نشر مستمر باستخدام خدمات فريق Visual Studio

لاختبار ذلك ، نحتاج إلى إنشاء تعريف إصدار ثانٍ في VSTS باستخدام قالب العملية الفارغ وإضافة مهمة AzureBlob File Copy:

أزور التخزين

هذا هو الخيار الأحدث الذي دخل مؤخرًا في المعاينة العامة. تتمثل الفكرة في استخدام السعة التخزينية لاستضافة SPA لأن خادم الويب الحقيقي ليس ضروريًا لتقديم ملفات ثابتة فقط تؤهل هذا الخيار للكلمة الطنانة "serverless". لذلك فلنقم بإنشاء حساب تخزين جديد (للأغراض العامة الإصدار 2) ثم قم بتمكين ميزة موقع الويب الثابت:

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

دليل النشر

لنشر يدويًا ، انقر فوق "حاويات" في حساب التخزين في بوابة Azure وحدد حاوية "$ web" (التي يتم إنشاؤها تلقائيًا عند تمكين موقع ثابت). الآن لنقم بتحميل الملفات من البناء المحلي:

وهذا كل شيء!

نشر مستمر باستخدام خدمات فريق Visual Studio

لاختبار ذلك ، نحتاج إلى إنشاء تعريف إصدار ثالث في VSTS باستخدام قالب العملية الفارغ وإضافة مهمة AzureBlob File Copy:

تأكد من تحديد الإصدار 2. * (المعاينة) وإلا فسوف تفشل عملية النشر بسبب عدم السماح بالحرف "$" في اسم الحاوية سابقًا.

أداء

للحصول على فكرة عن الأداء ، دعنا نجري بعض اختبارات تحميل المدفعية. نشراتنا الثلاثة. فيما يلي نتائجي عند إطلاق 1000 و 10000 و 100000 طلب:

هناك ميزة أداء جذرية باستخدام Azure Storage وتجنب مكون خادم الويب بينما تعمل وظائف الخدمة والتطبيقات بسرعة مماثلة. هذا منطقي حيث أن كلاهما يشتركان في نفس البنية التحتية الأساسية. لقد اندهشت قليلاً من أن تطبيق Function يعمل بشكل أبطأ من خدمة التطبيقات.

أجد هذا أكثر غرابة عند مقارنة إجمالي أوقات التشغيل لإكمال اختبار الطلبات البالغ عددها 100،000 طلب. استغرق هذا حوالي 46 ثانية لإكماله إلى Azure Storage و 14 دقيقة و 27 ثانية لخدمة التطبيقات وحتى 17 دقيقة و 2 ثانية لتطبيق Function. كنت أتوقع أن يكتسب تطبيق Function السرعة بمرور الوقت لأنني كنت أتوقع أن يكون الحجم أفقياً تلقائيًا. لا يبدو أنه يعمل في هذا السيناريو.

لذلك لدينا فائز واضح في هذا التخصص: التخزين سريع حقًا!

التكاليف

الحصول على التكلفة الصحيحة أمر صعب ، حيث تحتوي جميعها على نماذج فوترة مختلفة. إليك مثال حسابي للتكاليف الشهرية لـ 100.000 طلب / يوم في منطقة غرب أوروبا (لست متأكدًا تمامًا بنسبة 100٪ أنها كاملة ودقيقة!):

خدمة التطبيق

مثيل S1 واحد في غرب أوروبا يعمل بنظام Windows (وحدة أساسية واحدة ، ذاكرة وصول عشوائي سعتها 1.75 جيجابايت ، تخزين 50 جيجابايت) = 61.56 € / شهر

وظيفة التطبيق (+ التخزين)

يتكون SPA الخاص بنا من 5 ملفات * 100000 طلب / يوم * 31 = 15500000 طلب في الشهر. الحجم الكلي لتطبيقنا هو 0،33 ميغابايت تقريبًا يمثل 0،98 تيرابايت من حركة المرور الصادرة في الإجمالي الشهري. الحد الأدنى لوقت التنفيذ هو 100 مللي ثانية (وهو ما يكفي لغرض وكيلنا) حيث يمكننا معالجة 10 طلبات / تنفيذ ثانية.

تطبيق وظيفة 1x مع 1.550.000 تنفيذ مع وقت تنفيذ لكل ثانية (شهريًا أقل من 128 ميجابايت من الذاكرة) لمعالجة الطلبات التي تمر عبر الوكلاء = 0.17 يورو / شهر

1 × التخزين للأغراض العامة حساب V2 Block Blob Storage مع LRS التكرار وطبقة الوصول الساخن. سعة 1 جيجابايت (نحتاج في الواقع إلى 300 كيلو بايت فقط ولكن هذا هو أصغر حجم متاح) و 100 عملية كتابة و 100 عملية قائمة و 15500000 عملية قراءة واسترجاع بيانات 0،98 تيرابايت = 5.64 يورو / شهر

المجموع: 5.81 € / شهر.

تخزين

بالنسبة للتخزين ، نأخذ نفس الحساب من أعلاه:

1 × التخزين للأغراض العامة حساب V2 Block Blob Storage مع LRS التكرار وطبقة الوصول الساخن. سعة 1 جيجابايت (نحتاج في الواقع إلى 300 كيلو بايت فقط ولكن هذا هو أصغر حجم متاح) و 100 عملية كتابة و 100 عملية قائمة و 15500000 عملية قراءة واسترجاع بيانات 0،98 تيرابايت = 5.64 يورو / شهر

استنتاج

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

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

لا تتردد في تقديم ملاحظات.