مشاركة عبر

مقدمة حول Service Fabric Reliable Actors

  • مقالة

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

ما المقصود بالجهات؟

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

الوقت المناسب لاستخدام Reliable Actors

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

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

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

الجهات في Service Fabric

في Service Fabric، يتم تنفيذ الجهات في إطار عمل Reliable Actors: إطار عمل تطبيق قائم على نمط الجهة يستند إلى Service Fabric Reliable Services. إن كل خدمة Reliable Actor تكتبها هي في الواقع Reliable Service مقسمة وذات حالة خاصة.

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

دورة حياة الجهات

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

يحمل تجريد دورة حياة الجهة الظاهرية هذه بعض التحذيرات كنتيجة لنموذج الجهة الظاهرية، وفي الواقع ينحرف تطبيق Reliable Actor أحياناً عن هذا النموذج.

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

التوزيع وتجاوز الفشل

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

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

على سبيل المثال، سيتم توزيع خدمة جهة تحتوي على تسعة أقسام تم نشرها على ثلاث عقد باستخدام موضع قسم الجهة الظاهرية على النحو التالي:

توزيع Reliable Actors

يدير "إطار عمل الجهة" نظام الأقسام وإعدادات النطاق الرئيسي نيابة عنك. يسهل ذلك من بعض الخيارات ولكنه يحمل أيضاً بعض الاعتبارات:

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

لمزيد من المعلومات حول كيفية تقسيم خدمات الجهات، راجع مفاهيم التقسيم للجهات.

التواصل مع الجهات

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

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

وكيل الجهة

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

// Create a randomly distributed actor ID
ActorId actorId = ActorId.CreateRandom();

// This only creates a proxy object, it does not activate an actor or invoke any methods yet.
IMyActor myActor = ActorProxy.Create<IMyActor>(actorId, new Uri("fabric:/MyApp/MyActorService"));

// This will invoke a method on the actor. If an actor with the given ID does not exist, it will be activated by this method call.
await myActor.DoWorkAsync();

// Create actor ID with some name
ActorId actorId = new ActorId("Actor1");

// This only creates a proxy object, it does not activate an actor or invoke any methods yet.
MyActor myActor = ActorProxyBase.create(actorId, new URI("fabric:/MyApp/MyActorService"), MyActor.class);

// This will invoke a method on the actor. If an actor with the given ID does not exist, it will be activated by this method call.
myActor.DoWorkAsync().get();

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

تقوم فئة ActorProxy(C#) / ActorProxyBase(Java) على جانب العميل بتنفيذ الحلول اللازمة لتحديد موقع الجهة بواسطة المعرف وفتح قناة اتصال معه. كما أنها تعيد محاولة تحديد موقع الجهة في حالات فشل الاتصالات وتجاوزات الفشل. ونتيجة لذلك، يتميز تسليم الرسائل بالخصائص التالية:

  • تسليم الرسائل هو أفضل جهد.
  • قد تتلقى الجهات رسائل مكررة من نفس العميل.

التزامن

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

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

اتصال Reliable Actors

الوصول القائم على الأدوار

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

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

يوضح المثال التالي المفاهيم السابقة. فكر في نوع جهة تنفذ أسلوبين غير متزامنين (على سبيل المثال، Method1 وMethod2)، ومؤقت، وتذكير. يعرض الرسم التخطيطي التالي مثالاً على جدول زمني لتنفيذ هذه الأساليب وعمليات رد الاتصال نيابة عن اثنين من الجهات (ActorId1 وActorId2) اللذان ينتميان إلى هذا النوع من الجهات.

التزامن والوصول المستندين إلى دور وقت تشغيل Reliable Actors

يتبع هذا الرسم التخطيطي هذه الاتفاقيات:

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

بعض النقاط الهامة التي يجب مراعاتها:

  • أثناء تنفيذ Method1 نيابة عن ActorId2 استجابةً لطلب العميل xyz789، يصل طلب عميل آخر (abc123) يتطلب أيضاً تنفيذ Method1 بواسطة ActorId2. ولكن لا يبدأ التنفيذ الثاني من Method1 حتى ينتهي التنفيذ السابق. وبالمثل، يتم إطلاق تذكير مسجل بواسطة ActorId2 أثناء تنفيذ Method1 استجابةً لطلب العميل xyz789. يتم تنفيذ رد الاتصال للتذكير فقط بعد اكتمال كل من عمليات تنفيذ Method1. يرجع كل هذا إلى التزامن القائم على الأدوار الذي يتم فرضه على ActorId2.
  • وبالمثل، يتم أيضاً فرض التزامن القائم على الأدوار لـ ActorId1، كما يتضح من تنفيذ Method1 وMethod2 ورد الاتصال للمؤقت نيابةً عن ActorId1 الذي يحدث بطريقة تسلسلية.
  • يتداخل تنفيذ Method1 نيابةً عن ActorId1 مع تنفيذه نيابةً عن ActorId2. وذلك لأن التزامن القائم على الأدوار يتم فرضه فقط داخل الجهة وليس عبر الجهات.
  • في بعض عمليات تنفيذ الأسلوب/رد الاتصال، يرجع Task(C#) / CompletableFuture(Java) الذي يتم إرجاعه بواسطة تنفيذ الأسلوب/رد الاتصال بعد عودة الأسلوب. في بعض الحالات الأخرى، تكون العملية غير المتزامنة قد انتهت بالفعل بحلول الوقت الذي يرجع فيه الأسلوب/رد الاتصال. في كلتا الحالتين، يتم تحرير التأمين لكل جهة فقط بعد إرجاع كل من الأسلوب ورد الاتصال وانتهاء العملية غير المتزامنة.

إعادة الدخول

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

نطاق ضمانات التزامن

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

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

ابدأ من خلال إنشاء أول خدمة ـReliable Actor: