تغيير الحجم في Service Fabric

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

يتم إجراء تغيير الحجم في Service Fabric بعدة طرق مختلفة:

1. تغيير الحجم عن طريق إنشاء أو إزالة مثيلات الخدمة عديمة الحالة
2. تغيير الحجم عن طريق إنشاء أو إزالة خدمات مسماة جديدة
3. تغيير الحجم عن طريق إنشاء أو إزالة مثيلات التطبيق المسماة الجديدة
4. تغيير الحجم باستخدام الخدمات المقسمة
5. تغيير الحجم عن طريق إضافة وإزالة العقد من نظام المجموعة
6. تغيير الحجم باستخدام مقاييس Cluster Resource Manager

تغيير الحجم عن طريق إنشاء أو إزالة مثيلات الخدمة عديمة الحالة

تعمل إحدى أبسط الطرق للتغيير حجم داخل Service Fabric مع الخدمات عديمة الحالة. عندما تنشئ خدمة عديمة الحالة، تحصل على فرصة لتعريف InstanceCount. يحدد InstanceCount عدد النسخ المُشغلة من رمز تلك الخدمة والمُنشأة عند بدء تشغيل الخدمة. لنفترض، على سبيل المثال، أن هناك 100 عقدة في نظام المجموعة. لنفترض أيضاً أنه تم إنشاء الخدمة بـInstanceCount من 10. أثناء وقت التشغيل، يمكن أن تصبح هذه النسخ العشر المُشغلة من التعليمات البرمجية مشغولة جداً (أو قد لا تكون مشغولة بدرجة كافية). تتمثل إحدى طرق تغيير حجم حمل العمل في تغيير عدد المثيلات. على سبيل المثال، يمكن لبعض أجزاء من رمز المراقبة أو الإدارة تغيير العدد الحالي من المثيلات إلى 50، أو إلى 5، اعتماداً على ما إذا كان حمل العمل يحتاج إلى تغيير حجم نطاقه أو تصغيره بناءً على الحمل.

C#‎:

StatelessServiceUpdateDescription updateDescription = new StatelessServiceUpdateDescription(); 
updateDescription.InstanceCount = 50;
await fabricClient.ServiceManager.UpdateServiceAsync(new Uri("fabric:/app/service"), updateDescription);

PowerShell:

Update-ServiceFabricService -Stateless -ServiceName $serviceName -InstanceCount 50

استخدام Dynamic Instance Count

على وجه التحديد بالنسبة للخدمات عديمة الحالة، توفر Service Fabric طريقة تلقائية لتغيير عدد المثيلات. يسمح هذا للخدمة بتغيير الحجم ديناميكياً مع عدد العقد المتاحة. تتمثل طريقة الاشتراك في هذا السلوك في تعيين عدد المثيلات = -1. InstanceCount = -1 هو إرشاد لـService Fabric يقول "تشغيل هذه الخدمة عديمة الحالة على كل عقدة." إذا تغير عدد العقد، تقوم Service Fabric تلقائياً بتغيير عدد المثيلات لمطابقتها، ما يضمن تشغيل الخدمة على جميع العقد الصالحة.

C#‎:

StatelessServiceDescription serviceDescription = new StatelessServiceDescription();
//Set other service properties necessary for creation....
serviceDescription.InstanceCount = -1;
await fc.ServiceManager.CreateServiceAsync(serviceDescription);

PowerShell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName -Stateless -PartitionSchemeSingleton -InstanceCount "-1"

تغيير الحجم عن طريق إنشاء أو إزالة خدمات مسماة جديدة

مثيل خدمة مسمى هو مثيل محدد لنوع خدمة (راجع دورة حياة تطبيق Service Fabric) داخل بعض مثيلات التطبيق المسماة في المجموعة.

يمكن إنشاء (أو إزالة) مثيلات الخدمة المسماة الجديدة عندما تصبح الخدمات أكثر أو أقل انشغالاً. يسمح ذلك للطلبات بالانتشار عبر المزيد من مثيلات الخدمة، ما يسمح عادةً بتقليل الحمل على الخدمات الحالية. عند إنشاء الخدمات، يضع Service Fabric Cluster Resource Manager الخدمات في نظام مجموعة بطريقة موزعة. القرارات الدقيقة تحكمها المقاييس في نظام المجموعة وقواعد الموضع الأخرى. يمكن إنشاء الخدمات بعدة طرق مختلفة، ولكن الأكثر تداولاً تكون إما من خلال الإجراءات الإدارية مثل شخص يتصل بـNew-ServiceFabricService، أو عن طريق الاتصال بالتعليمة البرمجية CreateServiceAsync. يمكن حتى استدعاء CreateServiceAsync من داخل الخدمات الأخرى التي تعمل في المجموعة.

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

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

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

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

تغيير الحجم عن طريق إنشاء أو إزالة مثيلات التطبيق المسماة الجديدة

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

متى يجب استخدام إنشاء مثيل تطبيق مسمى جديد بدلاً من إنشاء مثيلات خدمة مسماة جديدة في بعض التطبيقات الموجودة بالفعل؟ هناك حالات قليلة:

• مثيل التطبيق الجديد مخصص للعميل الذي يحتاج تعليمته البرمجية للعمل ضمن هوية معينة أو إعدادات أمان معينة.
  • يسمح Service Fabric بتعريف حزم التعليمات البرمجية المختلفة للتشغيل تحت هويات معينة. لبدء تشغيل نفس حزمة التعليمات البرمجية بهويات مختلفة، يجب أن تحدث عمليات التنشيط في مثيلات تطبيق مختلفة. ضع في اعتبارك حالة تم فيها توزيع حمل عمل عميل موجود. قد تعمل تحت هوية معينة حتى تتمكن من مراقبة وصولهم إلى الموارد الأخرى والتحكم فيه، مثل قواعد البيانات البعيدة أو الأنظمة الأخرى. في هذه الحالة، عندما يقوم عميل جديد بالتسجيل، ربما لا ترغب في تنشيط التعليمة البرمجية الخاصة به في نفس السياق (مساحة العملية). بينما يمكنك ذلك، فإن هذا يجعل من الصعب على التعليمة البرمجية للخدمة الخاصة بك العمل في سياق هوية معينة. يجب أن يكون لديك عادةً المزيد من التعليمات البرمجية للأمان والعزل وإدارة الهوية. بدلاً من استخدام مثيلات خدمة مسماة مختلفة في مثيل التطبيق نفسه وبالتالي مساحة العملية نفسها، يمكنك استخدام مثيلات تطبيق Service Fabric مختلفة التسمية. هذا يجعل من السهل تحديد سياقات الهوية المختلفة.
• تعمل مثيل التطبيق الجديد أيضاً كوسيلة للتكوين
  • بشكل افتراضي، سيتم تشغيل جميع مثيلات الخدمة المسماة لنوع خدمة معين داخل مثيل التطبيق في نفس العملية على عقدة معينة. ما يعنيه هذا هو أنه بينما يمكنك تكوين كل مثيل خدمة بشكل مختلف، فإن القيام بذلك أمر معقد. يجب أن تحتوي الخدمات على بعض الرموز المميزة التي تستخدمها للبحث عن التكوين الخاص بها داخل حزمة التكوين. عادة ما يكون مجرد اسم الخدمة. هذا يعمل بشكل جيد، لكنه يقرن التكوين بأسماء مثيلات الخدمة المسماة الفردية داخل هذا المثيل للتطبيق. قد يكون هذا مربكاً وتصعب إدارته نظراً لأن التكوين عادةً ما يكون بيانات اصطناعية لوقت التصميم مع قيم محددة لمثيلات التطبيق. يعني إنشاء المزيد من الخدمات دائماً المزيد من ترقيات التطبيقات لتغيير المعلومات داخل حزم التكوين أو لتوزيع حزم جديدة حتى تتمكن الخدمات الجديدة من البحث عن معلوماتها المحددة. غالباً ما يكون من الأسهل إنشاء مثيل تطبيق مسمى جديد بالكامل. ثم يمكنك استخدام معلمات التطبيق لتعيين أي تكوين ضروري للخدمات. بهذه الطريقة يمكن لجميع الخدمات التي المنشأة داخل مثيل التطبيق المسماة أن ترث إعدادات تكوين معينة. على سبيل المثال، بدلاً من وجود ملف تكوين واحد مع الإعدادات والتخصيصات لكل عميل، مثل البيانات السرية أو حدود موارد العميل، سيكون لديك بدلاً من ذلك مثيل تطبيق مختلف لكل عميل مع تجاوز هذه الإعدادات.
• يعمل التطبيق الجديد كحدود للترقية
  • داخل Service Fabric، تعمل مثيلات التطبيق المسماة المختلفة كحدود للترقية. لن تؤثر ترقية مثيل تطبيق مسمى واحد على التعليمة البرمجية التي يعمل عليها مثيل تطبيق آخر مسمى. ستنتهي التطبيقات المختلفة بتشغيل إصدارات مختلفة من التعليمة البرمجية نفسها على العقد نفسها. يمكن أن يكون هذا عاملاً عندما تحتاج إلى اتخاذ قرار تغيير الحجم لأنه يمكنك اختيار ما إذا كانت التعليمة البرمجية الجديدة يجب أن تتبع نفس الترقيات مثل خدمة أخرى أم لا. على سبيل المثال، لنفترض أن مكالمة تصل إلى خدمة المدير المسؤولة عن تغيير حجم حمل عمل عميل معين من خلال إنشاء الخدمات وحذفها ديناميكياً. ومع ذلك، في هذه الحالة، يكون الاتصال لحمل عمل مرتبطاً بعميل جديد. يحب معظم العملاء الانعزال عن بعضهم البعض ليس فقط لأسباب الأمان والتكوين المذكورة سابقاً، ولكن لأنها توفر المزيد من المرونة فيما يتعلق بتشغيل إصدارات معينة من البرنامج واختيار وقت الترقية. يمكنك أيضاً إنشاء مثيل تطبيق جديد وإنشاء الخدمة هناك ببساطة لتقسيم مقدار خدماتك التي ستلمسها أي ترقية واحدة. توفر مثيلات التطبيق المنفصلة قدراً أكبر من التفاصيل عند إجراء ترقيات للتطبيق، كما تتيح أيضاً اختبار A/B وعمليات توزيع Blue/Green.
• مثيل التطبيق الحالي ممتلئ
  • في Service Fabric، تعد سعة التطبيق مفهوماً يمكنك استخدامه للتحكم في كمية الموارد المتاحة لمثيلات تطبيق معينة. على سبيل المثال، قد تقرر أن خدمة معينة تحتاج إلى إنشاء مثيل آخر من أجل تغيير الحجم. ومع ذلك، فإن هذا المثيل للتطبيق خارج السعة لمقياس معين. إذا كان لا يزال يتعين منح هذا العميل أو حمل العمل مزيداً من الموارد، يمكنك إما زيادة السعة الحالية لهذا التطبيق أو إنشاء تطبيق جديد.

تغيير الحجم على مستوى القسم

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

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

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

تغيير الحجم باستخدام Service Fabric Cluster Resource Manager والمقاييس

المقاييس هي كيفية تعبير الخدمات عن استهلاك مواردها إلى Service Fabric. يمنح استخدام المقاييس Cluster Resource Manager فرصة لإعادة تنظيم تخطيط نظام المجموعة وتحسينه. على سبيل المثال، قد يكون هناك الكثير من الموارد في نظام المجموعة، ولكن قد لا يتم تخصيصها للخدمات التي تقوم بالعمل حالياً. يسمح استخدام المقاييس لـCluster Resource Manager بإعادة تنظيم نظام المجموعة لضمان وصول الخدمات إلى الموارد المتاحة.

تغيير الحجم عن طريق إضافة وإزالة العقد من نظام المجموعة

هناك خيار آخر للتغيير حجم باستخدام Service Fabric وهو تغيير حجم نظام المجموعة. تغيير حجم نظام المجموعة يعني إضافة أو إزالة العقد لواحد أو أكثر من أنواع العقد في نظام المجموعة. على سبيل المثال، ضع في اعتبارك حالة تكون فيها جميع العقد في نظام المجموعة قوية. هذا يعني أن موارد نظام المجموعة يتم استهلاكها بالكامل تقريباً. في هذه الحالة، فإن إضافة المزيد من العقد إلى نظام المجموعة هي أفضل طريقة للتغيير حجم. بمجرد انضمام العقد الجديدة إلى نظام المجموعة، يقوم Service Fabric Cluster Resource Manager بنقل الخدمات إليها، ما يؤدي إلى تقليل إجمالي الحمل على العقد الحالية. بالنسبة للخدمات عديمة الحالة مع عدد المثيلات = -1، يتم إنشاء المزيد من مثيلات الخدمة تلقائياً. هذا يسمح لبعض المكالمات بالانتقال من العقد الحالية إلى العقد الجديدة.

لمزيد من المعلومات، راجع تغيير حجم نظام المجموعة.

اختيار نظام أساسي

نظراً لاختلافات التنفيذ بين أنظمة التشغيل، يمكن أن يكون اختيار استخدام Service Fabric مع Windows أو Linux جزءاً حيوياً من تغيير حجم تطبيقك. أحد العوائق المحتملة هو كيفية إجراء التسجيل المرحلي. تستخدم Service Fabric على Windows برنامج تشغيل kernel لسجل واحد لكل جهاز، تتم مشاركته بين النسخ المماثلة للخدمات ذات الحالة. يزن هذا السجل حوالي 8 غيغابايت. من ناحية أخرى، يستخدم Linux سجلاً مرحلياً سعة 256 ميغابايت لكل نسخة مماثلة، ما يجعله أقل مثالية للتطبيقات التي ترغب في زيادة عدد النسخ المماثلة الخفيفة للخدمة التي تعمل على عقدة معينة. هذه الاختلافات في متطلبات التخزين المؤقت يمكن أن تفيد النظام الأساسي المطلوب لنشر نظام مجموعة Service Fabric.

تجميع جميع العناصر

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

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

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

عند البناء للتغيير حجم، ضع في اعتبارك النمط الديناميكي التالي. قد تحتاج إلى تكييفه مع وضعك:

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

يتميز نمط الخلق الديناميكي بالعديد من الفوائد:

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

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

لمزيد من المعلومات عن مفاهيم Service Fabric، راجع المقالات التالية:

• توفر خدماتService Fabric services
• خدمات Partitioning Service Fabric