مشاركة عبر

كيف يستخدم المستخدمون الموثوقون النظام الأساسي لتصميم الخدمة

  • مقالة

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

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

تشكّل هذه المكونات معًا إطار عمل المستخدم الموثوق.

طبقات الخدمة

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

طبقات خدمة المستخدم

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

في الخدمات الموثوقة، ترث خدمتك الفئة المستخدمةStatefulService. هذه الفئة نفسها مشتقة من StatefulServiceBase (أو StatelessService من أجل الخدمات عديمة الحالة). في المستخدمين الموثوقين، يمكنك استخدام خدمة المستخدم. خدمة المستخدم هي تنفيذ مختلف للفئة التي StatefulServiceBase تنفذ نمط المستخدم حيث يعمل المستخدمون الخاص بك. ونظرًا لأن خدمة المستخدم نفسها هي مجرد تنفيذ StatefulServiceBase، فيمكنك كتابة خدمتك الخاصة المشتقة من ActorService ميزات مستوى الخدمة وتنفذها StatefulServiceبنفس الطريقة التي تقوم بها عند التوريث، مثل:

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

لمزيد من المعلومات، راجع تنفيذ ميزات مستوى الخدمة في خدمة المستخدم الخاصة بك.

نموذج التطبيق

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

بيان تطبيق الخدمة

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

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

بيان التطبيق

تقوم أدوات تحديث إصدار إطار عمل المستخدم بإنشاء تعريف خدمة افتراضي لخدمة المستخدم الخاصة بك تلقائيًا. تقوم أدوات تحديث الإصدار بتثبيت خصائص الخدمة الافتراضية:

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

مفاهيم تقسيم تصميم الخدمة للمستخدمين

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

تقسيم المستخدم وتوزيعه

يمكن إنشاء خدمات موثوقة باستخدام أنظمة التقسيم المختلفة ونطاقات مفاتيح التقسيم. تستخدم خدمة المستخدم نظام تقسيم Int64 مع نطاق كامل لمفاتيح Int64 لتعيين المستخدمين إلى أقسام.

معرّف المستخدم

كل مستخدم يتم إنشاؤه في الخدمة لديه معرّف خاص مرتبط به، يمثله الفئةActorId. ActorId وهو قيمة معرّف مبهمة يمكن استخدامه للتوزيع الموحد للمستخدمين عبر أقسام الخدمة عن طريق إنشاء معرفات عشوائية:

ActorProxy.Create<IMyActor>(ActorId.CreateRandom());

ActorProxyBase.create<MyActor>(MyActor.class, ActorId.newId());

ويتم تجزئة كل قيمة منهمActorId إلى Int64. هذا هو السبب في أن خدمة المستخدم يجب أن تستخدم نظام تقسيم Int64 مع نطاق كامل لمفاتيح Int64. ومع ذلك، يمكن استخدام قيم المعرّف المخصص في السلاسل ActorIDبما في ذلك GUIDs/UUIDs وInt64s.

ActorProxy.Create<IMyActor>(new ActorId(Guid.NewGuid()));
ActorProxy.Create<IMyActor>(new ActorId("myActorId"));
ActorProxy.Create<IMyActor>(new ActorId(1234));

ActorProxyBase.create(MyActor.class, new ActorId(UUID.randomUUID()));
ActorProxyBase.create(MyActor.class, new ActorId("myActorId"));
ActorProxyBase.create(MyActor.class, new ActorId(1234));

عندما تستخدم GUIDs/UUIDs والسلاسل، يتم تجزئة القيم إلى Int64. ومع ذلك، عندما تقدم Int64 بشكل صريح إلىActorIdسيقوم Int64 بالتعيين مباشرةً إلى قسم دون مزيد من التجزئة. يمكنك استخدام هذه التقنية للتحكم في القسم الذي يتم وضع المستخدمين فيه.

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