تكوين واستخدام ترابط الخدمة في Service Fabric

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

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

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

  1. كان لبعض المكونات X في التطبيق المتجانس اعتماد غير موثق على المكون Y، وقمت للتو بتحويل هذه المكونات إلى خدمات منفصلة. نظرًا لأن هذه الخدمات تعمل الآن على عقد مختلفة في المجموعة، فقد تم كسرها.
  2. تتصل هذه المكونات عبر (المسارات المحلية المسماة | الذاكرة المشتركة | الملفات على القرص) وتحتاج حقًا إلى أن تكون قادرة على الكتابة إلى مورد محلي مشترك لأسباب تتعلق بالأداء في الوقت الحالي. ربما يتم إزالة الاعتماد الشديد لاحقًا.
  3. كل شيء على ما يرام، ولكن اتضح أن هذين المكونين حساسان في الواقع/الأداء. عندما نقلهم إلى خدمات منفصلة، تم تقليل أداء التطبيق الكلي أو زيادة زمن الوصول. ونتيجة لذلك، فإن التطبيق العام لا يلبي التوقعات.

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

ما الذي يجب فعله؟ حسنًا، يمكنك محاولة تشغيل الترابط.

كيفية تكوين الترابط

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

ServiceCorrelationDescription affinityDescription = new ServiceCorrelationDescription();
affinityDescription.Scheme = ServiceCorrelationScheme.Affinity;
affinityDescription.ServiceName = new Uri("fabric:/otherApplication/parentService");
serviceDescription.Correlations.Add(affinityDescription);
await fabricClient.ServiceManager.CreateServiceAsync(serviceDescription);

إشعار

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

  • عكس العلاقات (لديك نقطة parentService1 و parentService2 في خدمة الفرع الحالية)، أو
  • قم بتعيين أحد الأصول كمركز بموجب الاتفاقية واطلب من جميع الخدمات الإشارة إلى تلك الخدمة.

يجب أن يكون سلوك الموضع الناتج في المجموعة هو نفسه.

خيارات ترابط مختلفة

يتم تمثيل الترابط عبر واحد من عدة مخططات ارتباط، وله وضعان مختلفان. الوضع الأكثر شيوعًا للترابط هو ما نسميه NonAlignedAffinity. في NonAlignedAffinity، تُوضع النسخ المتماثلة أو مثيلات الخدمات المختلفة على العقد نفسها. الوضع الآخر هو AlignedAffinity. Aligned Affinity مفيد فقط مع الخدمات ذات الحالة. يضمن تكوين خدمتين ذوات الحالة للحصول على التقارب المتوافق أن يتم وضع الأجزاء الأولية لتلك الخدمات على نفس العقد مثل بعضها البعض. كما يتسبب أيضًا في وضع كل زوج من الثانويات لتلك الخدمات على نفس العقد. من الممكن أيضًا (على الرغم من أنه أقل شيوعًا) تكوين NonAlignedAffinity للخدمات ذات الحالة. بالنسبة إلى NonAlignedAffinity، سيتم تشغيل النسخ المتماثلة المختلفة للخدمتين ذوات الحالة على نفس العقد، ولكن يمكن أن ينتهي الأمر بأجزائهما الأولية على عقد مختلفة.

أوضاع الترابط وتأثيراتها

أفضل جهد للحالة المطلوبة

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

سلاسل مقابل نجوم

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

سلاسل مقابل نجوم في سياق علاقات الترابط

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

دعم التقسيم

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

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