تحديد خيار حساب Azure للخدمات المصغرة

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

  • منسق خدمة يدير الخدمات التي تعمل على عقد مخصصة (الأجهزة الظاهرية).
  • هيكل بلا خادم باستخدام الوظائف كخدمة (FaaS).

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

منسقو الخدمة

يعالج المنسق المهام المتعلقة بتوزيع وإدارة مجموعة من الخدمات. تتضمن هذه المهام وضع الخدمات على العقد، ومراقبة صحة الخدمات، وإعادة تشغيل الخدمات غير السليمة، وموازنة تحميل نسبة استخدام الشبكة عبر مثيلات الخدمة، واكتشاف الخدمة، وتوسيع نطاق عدد مثيلات الخدمة، وتطبيق تحديثات التكوين. يشمل المنسقون الشائعون Kubernetes، وService Fabric وDC/OS وDocker Swarm.

على النظام الأساسي لـ Azure، ضع في اعتبارك الخيارات التالية:

  • تعتبر ⁦⁩Azure Kubernetes Service (AKS) خدمة مُدارة من Kubernetes. توفر AKS Kubernetes وتعرض نقاط نهاية Kubernetes API، ولكنها تستضيف وتدير وحدة التحكم Kubernetes، وإجراء الترقيات التلقائية، والتحديث الجزئي التلقائي، والتحجيم التلقائي، ومهام الإدارة الأخرى. يمكنك التفكير في AKS على أنها "واجهات برمجة تطبيقات Kubernetes كخدمة".

  • Azure Container Apps هي خدمة مدارة مبنية على Kubernetes تقوم بتجريد تعقيدات تنسيق الحاوية ومهام الإدارة الأخرى. تعمل تطبيقات الحاوية على تبسيط توزيع وإدارة التطبيقات والخدمات المصغرة الحاوية في بيئة بلا خادم مع توفير ميزات Kubernetes.

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

  • يمكن تشغيل خيارات أخرى مثل Docker Enterprise Edition في بيئة IaaS على Azure. يمكنك العثور على قوالب التوزيع على Azure Marketplace.

الحاويات

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

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

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

  • عزل الموارد. يمكنك تحديد مقدار الذاكرة والمعالج المتوفر للحاوية، والذي يمكن أن يساعد على ضمان أن عملية الهروب لا تستنفد موارد المضيف. لمزيد من المعلومات، راجع نمط Bulkhead .

بلا خادم (وظائف كخدمة)

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

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

منسق أم بلا خادم؟

فيما يلي بعض العوامل التي يجب مراعاتها عند الاختيار بين نهج المنسق ونهج بلا خادم.

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

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

قابلية النقل. يمكن تشغيل جميع المنسقين المدرجين هنا (Kubernetes وDC/OS وDocker Swarm وService Fabric) محلياً أو في سحب عامة متعددة.

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

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

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

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

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