تعرف على الفروق بين Cloud Services وService Fabric قبل ترحيل التطبيقات.
Microsoft Azure Service Fabric هي الجيل القادم من النظام الأساسي للتطبيقات السحابية المخصص للتطبيقات الموزعة والقابلة للتطوير والموثوق بها للغاية. وهو يقدم العديد من الميزات الجديدة لتحزيم التطبيقات السحابية الموزعة وتوزيعها وترقيتها وإدارتها.
هذا دليل تمهيدي لترحيل التطبيقات من Cloud Services إلى Service Fabric. وهو يركز في المقام الأول على الفروق في البنية والتصميم بين Cloud Services وService Fabric.
التطبيقات والبنية الأساسية
الفرق الأساسي بين Cloud Services وService Fabric هو العلاقة بين الأجهزة الظاهرية وأحمال العمل والتطبيقات. ويُقصد بحمل العمل هنا التعليمات البرمجية التي تكتبها لتنفيذ مهمة معينة أو تقديم خدمة.
- ويتعلق Cloud Services بتوزيع التطبيقات كأجهزة ظاهرية. وتكون التعليمات البرمجية التي تكتبها مقترنة جداً بمثيل جهاز ظاهري، مثل دور الويب أو العامل. ويشير توزيع حمل عمل في Cloud Services إلى توزيع مثيل جهاز ظاهري واحد أو أكثر من مثيل يعمل عليه حمل العمل. لا يوجد فصل بين التطبيقات والأجهزة الظاهرية، وبالتالي، لا يوجد تعريف رسمي للتطبيق. يمكن اعتبار التطبيق بمثابة مجموعة من مثيلات دور الويب أو العامل ضمن توزيع Cloud Services أو بمثابة توزيع خدمات سحابية بأكمله. في هذا المثال، يتم عرض تطبيق كمجموعة من مثيلات الدور.
- يتعلق Service Fabric بتوزيع التطبيقات على الأجهزة الظاهرية أو الأجهزة الموجودة التي تعمل عليها Service Fabric على Windows أو Linux. يتم فصل الخدمات التي تكتبها تماماً عن البنية الأساسية الرئيسية، والتي يتم تجريدها بواسطة النظام الأساسي لتطبيق Service Fabric، بحيث يمكن توزيع أحد التطبيقات في بيئات متعددة. يسمى حمل العمل في Service Fabric "خدمة"، ويتم تجميع خدمة واحدة أو أكثر في تطبيق محدد رسمياً يعمل على النظام الأساسي لتطبيق Service Fabric. يمكن توزيع تطبيقات متعددة على نظام مجموعة Service Fabric واحد.
Service Fabric نفسه هو طبقة من النظام الأساسي للتطبيقات تعمل على Windows أو Linux، في حين أن Cloud Services هو نظام لتوزيع الأجهزة الظاهرية المُدارة بواسطة Azure باستخدام أحمال العمل المرفقة. يتميز نموذج تطبيق Service Fabric بعدد من المزايا:
- أوقات توزيع سريعة. يمكن أن يستغرق إنشاء مثيلات الأجهزة الظاهرية وقتاً طويلاً. في Service Fabric، يتم توزيع الأجهزة الظاهرية مرة واحدة فقط لتشكيل نظام مجموعة يستضيف النظام الأساسي لتطبيق Service Fabric. من هذه النقطة، يمكن توزيع حزم التطبيقات على نظام المجموعة بسرعة كبيرة.
- استضافة عالية الكثافة. في Cloud Services، يستضيف الجهاز الظاهري لدور العامل حمل عمل واحداً. في Service Fabric، تكون التطبيقات منفصلة عن الأجهزة الظاهرية التي تعمل عليها التطبيقات، أي أنه يمكنك توزيع عدد كبير من التطبيقات على عدد صغير من الأجهزة الظاهرية، فيمكن بذلك أن تنخفض التكلفة الإجمالية لعمليات التوزيع الكبيرة.
- يمكن تشغيل النظام الأساسي لتطبيق Service Fabric في أي مكان به أجهزة Windows Server أو Linux، سواء أكان ذلك في Azure أم داخلياً. يوفر النظام الأساسي طبقة تجريد فوق البنية الأساسية الرئيسية بحيث يمكن تشغيل تطبيقك على بيئات مختلفة.
- إدارة تطبيقات موزعة. Service Fabric هو نظام أساسي لا يستضيف التطبيقات الموزعة فحسب، بل يساعد أيضاً في إدارة دورة حياتها بشكل مستقل عن دورة حياة الجهاز الظاهري أو الجهاز المضيف.
تصميم التطبيق
تتضمن بنية تطبيق Cloud Services عادةً العديد من تبعيات الخدمات الخارجية، مثل ناقل خدمة Azure وAzure Table and Blob Storage وSQL وRedis وغير ذلك لإدارة حالة التطبيق وبياناته والاتصال بين أدوار الويب والعامل في توزيع Cloud Services. مثال على تطبيق Cloud Services الكامل قد يبدو كما يلي:
يمكن لتطبيقات Service Fabric أيضاً اختيار استخدام الخدمات الخارجية نفسها في تطبيق كامل. باستخدام هذا المثال على بنية Cloud Services، يكون أبسط مسار ترحيل من Cloud Services إلى Service Fabric هو استبدال توزيع Cloud Services بتطبيق Service Fabric فقط، مع الحفاظ على البنية العامة كما هي. يمكن نقل أدوار الويب والعامل إلى خدمات Service Fabric عديمة الحالة بأدنى حد من تغييرات التعليمات البرمجية.
وفي هذه المرحلة، يجب أن يستمر النظام في العمل كما كان من قبل. بالاستفادة من ميزات Service Fabric ذات الحالة الخاصة، يمكن استيعاب مخازن الحالات الخارجية كخدمات لها حالة خاصة حيثما أمكن ذلك. ويتسم ذلك بمشاركة أكبر من الترحيل البسيط لأدوار الويب والعامل إلى خدمات Service Fabric عديمة الحالة، كما أنه يتطلب كتابة الخدمات المخصصة التي توفر وظائف مكافئة للتطبيق كما فعلت الخدمات الخارجية من قبل. وتشمل فوائد إجراء ذلك ما يلي:
- إزالة التبعيات الخارجية
- توحيد نماذج التوزيع والإدارة والترقية.
قد يبدو مثال على البنية الناتجة عن استيعاب هذه الخدمات كما يلي:
الاتصال وسير العمل
تتكون معظم تطبيقات Cloud Services من أكثر من طبقة واحدة. وبالمثل، يتكون تطبيق Service Fabric من أكثر من خدمة واحدة (عادة العديد من الخدمات). يمثل نموذجا الاتصال الشائعان اتصالاً مباشراً ويكونان عبر مخزن دائم خارجي.
الاتصال المباشر
مع الاتصال المباشر، يمكن أن تتصل الطبقات مباشرة من خلال نقطة النهاية التي تتعرض لها كل طبقة. في البيئات عديمة الحالة مثل Cloud Services، يعني هذا تحديد مثيل لدور جهاز ظاهري، إما بشكل عشوائي أو دوري لموازنة الحمل، والاتصال بنقطة نهايته مباشرة.
الاتصال المباشر هو نموذج الاتصال الشائع في Service Fabric. الفرق الرئيسي بين Service Fabric وCloud Services هو أنه في Cloud Services، تتصل بجهاز ظاهري، بينما في Service Fabric، تتصل بخدمة. وهذا تمييز هام لسببين:
- الخدمات في Service Fabric غير مرتبطة بالأجهزة الظاهرية التي تستضيفها؛ فقد تتحرك الخدمات في نظام المجموعة، وفي الواقع، يتوقع أن تتحرك لأسباب مختلفة منها: موازنة الموارد، وتجاوز الفشل، وترقيات التطبيقات والبنية الأساسية، وقيود الموضع أو الحمل. وهذا يعني أن عنوان مثيل الخدمة يمكن أن يتغير في أي وقت.
- يمكن أن يستضيف الجهاز الظاهري في Service Fabric خدمات متعددة، كل منها لها نقاط نهاية فريدة.
يوفر Service Fabric آلية اكتشاف خدمات، تسمى خدمة التسمية، والتي يمكن استخدامها لحل عناوين نقاط نهاية الخدمات.
قوائم الانتظار
آلية الاتصال الشائعة بين الطبقات في البيئات عديمة الحالة مثل Cloud Services هي استخدام قائمة انتظار تخزين خارجية لتخزين مهام العمل بشكل دائم من طبقة إلى أخرى. السيناريو الشائع هو طبقة ويب ترسل مهاماً إلى Azure Queue أو Azure Service Bus حيث يمكن لمثيلات دور العامل إلغاء استعلام المهام ومعالجتها.
يمكن استخدام نموذج الاتصال نفسه في Service Fabric. قد يكون هذا مفيداً عند ترحيل تطبيق Cloud Services موجود إلى Service Fabric.
التماثل
يتشابه Cloud Services مع Service Fabric من حيث درجة التحكم مقابل سهولة الاستخدام، ولكنها الآن خدمة قديمة ويوصى باستخدام Service Fabric للتطوير الجديد؛ فيما يلي مقارنة بين واجهتي برمجة التطبيقات:
| واجهة برمجة تطبيقات Cloud Services | واجهة برمجة تطبيقات Service Fabric | ملاحظات |
|---|---|---|
| RoleInstance.GetID | FabricRuntime.GetNodeContext.NodeId أو .NodeName | المعرف هو خاصية NodeName |
| RoleInstance.GetFaultDomain | FabricClient.QueryManager.GetNodeList | تصفية على NodeName واستخدام خاصية FD |
| RoleInstance.GetUpgradeDomain | FabricClient.QueryManager.GetNodeList | تصفية على NodeName، واستخدام خاصية Upgrade |
| RoleInstance.GetInstanceEndpoints | FabricRuntime.GetActivationContext أو Naming (ResolveService) | CodePackageActivationContext الذي يتم توفيره من كل من FabricRuntime.GetActivationContext وضمن النسخ المتماثلة عبر ServiceInitializationParameters.CodePackageActivationContext المقدمة أثناء .Initialize |
| RoleEnvironment.GetRoles | FabricClient.QueryManager.GetNodeList | إذا كنت تريد إجراء النوع نفسه من التصفية حسب النوع، يمكنك الحصول على قائمة أنواع العُقد من بيان نظام المجموعة عبر FabricClient.ClusterManager.GetClusterManifest والحصول على أنواع الأدوار/العُقد منه. |
| RoleEnvironment.GetIsAvailable | Connect-WindowsFabricCluster أو إنشاء FabricRuntime موجَّهة إلى عقدة معينة | * |
| RoleEnvironment.GetLocalResource | CodePackageActivationContext.Log/Temp/Work | * |
| RoleEnvironment.GetCurrentRoleInstance | CodePackageActivationContext.Log/Temp/Work | * |
| LocalResource.GetRootPath | CodePackageActivationContext.Log/Temp/Work | * |
| Role.GetInstances | FabricClient.QueryManager.GetNodeList أو ResolveService | * |
| RoleInstanceEndpoint.GetIPEndpoint | FabricRuntime.GetActivationContext أو Naming (ResolveService) | * |
الخطوات التالية
يكون أبسط مسار ترحيل من Cloud Services إلى Service Fabric هو استبدال توزيع Cloud Services بتطبيق Service Fabric فقط، مع الحفاظ على البنية العامة للتطبيق كما هي تقريباً. تقدم المقالة التالية دليلاً للمساعدة في تحويل دور الويب أو العامل إلى خدمة Service Fabric عديمة الحالة.
الملاحظات
قريبًا: خلال عام 2024، سنتخلص تدريجيًا من GitHub Issues بوصفها آلية إرسال ملاحظات للمحتوى ونستبدلها بنظام ملاحظات جديد. لمزيد من المعلومات، راجع https://aka.ms/ContentUserFeedback.
إرسال الملاحظات وعرضها المتعلقة بـ