نظرة عامة على Reliable Services
يعمل Azure Service Fabric على تبسيط كتابة الخدمات عديمة الحالة وذات الحالة الخاصة وإدارتها. يغطي هذا الموضوع:
- نموذج برمجة الخدمات الموثوقة للخدمات عديمة الحالة وذات الحالة الخاصة.
- الخيارات التي يجب عليك اتخاذها عند كتابة خدمة موثوقة.
- بعض السيناريوهات والأمثلة على الوقت المناسب لاستخدام الخدمات الموثوقة وكيفية كتابتها.
الخدمات الموثوقةهي أحد نماذج البرمجة المتوفرة في Service Fabric. آخر هو نموذج برمجة المستخدم الموثوق به، والذي يوفر إطار عمل تطبيق المستخدم الافتراضي على رأس نموذج الخدمات الموثوقة. لمزيد من المعلومات حول المستخدمين الموثوقين راجع مقدمة عن المستخدمين الموثوقين في Service Fabric.
يدير Service Fabric مدة بقاء الخدمات، من التوفير والنشر إلى الترقية والحذف، عبر إدارة تطبيقات Service Fabric.
ما هي الخدمات الموثوقة
تمنحك الخدمات الموثوقة نموذج برمجة بسيطاً وقوياً وعالي المستوى لمساعدتك في التعبير عن ما هو مهم لتطبيقك. باستخدام نموذج برمجة الخدمات الموثوقة، ستحصل على:
- الوصول إلى واجهات برمجة تطبيقات Service Fabric. على عكس خدمات Service Fabric المصممة كـ ملفات تنفيذية للضيف، يمكن للخدمات الموثوقة استخدام واجهات برمجة تطبيقات Service Fabric مباشرة. وهذا يسمح للخدمات بما يلي:
- الاستعلام عن النظام
- الإبلاغ عن صحة الكيانات في نظام المجموعة
- تلقي إشعارات حول تغييرات التكوين والتعليمات البرمجية
- البحث عن الخدمات الأخرى والتواصل معها،
- استخدام المجموعات الموثوقة
- الوصول إلى العديد من الإمكانات الأخرى، كل ذلك من نموذج برمجة من الدرجة الأولى في العديد من لغات البرمجة.
- نموذج بسيط لتشغيل التعليمات البرمجية الخاصة بك التي تبدو مثل نماذج برمجة أخرى مألوفة. تحتوي التعليمات البرمجية الخاصة بك على نقطة دخول محددة جيدًا ودورة حياة مدارة بسهولة.
- نموذج اتصال قابل للتوصيل. استخدم وسيلة النقل التي تختارها، مثل HTTP مع واجهة برمجة تطبيقات الويب أو WebSockets أو بروتوكولات TCP المخصصة أو أي شيء آخر. توفر الخدمات الموثوقة بعض الخيارات الرائعة وغير التقليدية التي يمكنك استخدامها، أو يمكنك توفير خياراتك الخاصة.
- بالنسبة للخدمات ذات الحالة الخاصة، يتيح لك نموذج برمجة الخدمات الموثوقة تخزين حالتك باستمرار وموثوقية داخل خدمتك باستخدام المجموعات الموثوقة. المجموعات الموثوقة هي مجموعة من فئات التجميع المتوفرة والموثوقة بشكل كبير وهي أيضاً مألوفة لأي شخص يستخدم مجموعات C#. تقليديًا، كانت الخدمات تحتاج إلى أنظمة خارجية لإدارة الحالات بشكل موثوق. باستخدام المجموعات الموثوقة، يمكنك تخزين حالتك بجوار حسابك بنفس التوافر العالي والموثوقية التي تتوقعها من المخازن الخارجية المتوفرة بشكل كبير. يعمل هذا النموذج أيضا على تحسين زمن الانتقال لأنك تشارك في تحديد موقع الحساب والحالة التي يحتجاها للعمل.
ما الذي يجعل الخدمات الموثوقة مختلفة
تختلف الخدمات الموثوقة عن الخدمات التي ربما تكون قد كتبتها من قبل، لأن Service Fabric يوفر:
- الموثوقية - تظل خدمتك قيد التشغيل حتى في البيئات غير الموثوقة حيث تفشل أجهزتك أو تواجه مشكلات في الشبكة، أو في الحالات التي تواجه فيها الخدمات نفسها أخطاء وتتعطل أو تفشل. بالنسبة للخدمات ذات الحالة الخاصة، يتم الحفاظ على حالتك حتى في وجود شبكة أو في حالات الفشل الأخرى.
- التوفر - يمكن الوصول إلى خدمتك وهي خدمة تفاعلية. يحافظ Service Fabric على العدد المطلوب من النسخ قيد التشغيل.
- قابلية التوسع - يتم فصل الخدمات عن أجهزة محددة، ويمكن أن تنمو أو تتقلص حسب الضرورة من خلال إضافة الأجهزة أو الموارد الأخرى أو إزالتها. يتم تقسيم الخدمات بسهولة (خاصة في الحالة ذات الخاصة) لضمان قدرة الخدمة على قياس الأعطال الجزئية والتعامل معها. يمكن إنشاء الخدمات وحذفها ديناميكيًا عبر التعليمات البرمجية، مما يتيح إنشاء المزيد من المثيلات حسب الضرورة، على سبيل المثال استجابة لطلبات العملاء. وأخيرا، يشجع Service Fabric الخدمات على أن تكون خفيفة الوزن. يسمح Service Fabric بتوفير الآلاف من الخدمات ضمن عملية واحدة، بدلًا من طلب مثيلات أو عمليات نظام التشغيل بالكامل أو تخصيصها لمثيل واحد من الخدمة.
- الاتساق - يمكن ضمان اتساق أي معلومات مخزنة في خدمة موثوقة. وينطبق ذلك حتى عبر مجموعات موثوقة متعددة داخل الخدمة. يمكن إجراء التغييرات عبر المجموعات داخل الخدمة بطريقة ذرية من الناحية المعاملاتية.
دورة حياة الخدمة
سواء كانت الخدمة ذات حالة خاصة أو عديمة الحالة، توفر الخدمات الموثوقة دورة حياة بسيطة تتيح لك توصيل التعليمات البرمجية بسرعة والبدء. يتطلب الحصول على خدمة جديدة وتشغيلها تنفيذ أسلوبين:
- CreateServiceReplicaListeners/CreateServiceInstanceListeners - هذا الأسلوب هو المكان الذي تحدد فيه الخدمة مكدس (مكدسات) الاتصال الذي تريد استخدامه. مكدس الاتصال، مثل واجهة برمجة التطبيقات للويب، هو ما يحدد نقطة نهاية الانصات أو نقاط النهاية للخدمة (كيفية وصول العملاء إلى الخدمة). كما يحدد كيفية تفاعل الرسائل التي تظهر مع باقي التعليمة البرمجية الخدمة.
- RunAsync - هذا الأسلوب هو المكان الذي تدير فيه خدمتك منطق أعمالها، وحيث ستبدأ أي مهام خلفية يجب تشغيلها طوال مدة بقاء الخدمة. رمز الإلغاء الذي يتم توفيره هو إشارة إلى متى يجب أن يتوقف هذا العمل. على سبيل المثال، إذا كانت الخدمة بحاجة إلى سحب الرسائل من قائمة انتظار موثوقة ومعالجتها، فهذا هو المكان الذي فيه ذلك الإجراء.
إذا كنت تتعلم عن الخدمات الموثوقة لأول مرة، فتابع القراءة! إذا كنت تبحث عن معاينة تفصيلية حول دورة حياة الخدمات الموثوقة، فراجع نظرة عامة على دورة حياة الخدمات الموثوقة.
أمثلة على الخدمات
دعونا نلقي نظرة فاحصة على كيفية عمل نموذج الخدمات الموثوقة مع كل من الخدمات عديمة الحالة وذات الحالة الخاصة.
خدمات موثوقة عديمة الحالة
الخدمة عديمة الحالة هي الخدمة التي لا توجد فيها حالة يتم الحفاظ عليها داخل الخدمة عبر الاستدعاءات. أي حالة موجودة يمكن التخلص منها بالكامل ولا تتطلب المزامنة أو النسخ المتماثل أو الاستمرار أو التوافر العالي.
على سبيل المثال، حاسبة ليس لها ذاكرة وتتلقى جميع الشروط والعمليات لتنفيذها في وقت واحد.
في هذه الحالة، يمكن أن يكون RunAsync()(#C) أوrunAsync() (Java) للخدمة فارغًا نظرًا لعدم وجود وظيفة معالجة في الخلفية تحتاج الخدمة إلى القيام بها. عند إنشاء خدمة الحاسبة، فإنها ترجع ICommunicationListener (C#) أو CommunicationListener (Java) (على سبيل المثال واجهة برمجة التطبيقات للويب) التي تفتح نقطة نهاية انصات على منفذ ما. ترتبط نقطة نهاية الانصات هذه بطرق الحساب المختلفة (على سبيل المثال: "Add(n1, n2)") التي تحدد واجهة برمجة التطبيقات العامة للحاسبة.
عند إجراء استدعاء من قِبل عميل، يتم استدعاء الأسلوب المناسب، وتقوم خدمة الحاسبة بتنفيذ العمليات على البيانات المقدمة وإرجاع النتيجة. لا يخزن أي حالة.
عدم تخزين أي حالة داخلية يجعل هذه الحاسبة النموذجية بسيطة. لكن معظم الخدمات ليست عديمة الحالة حقًا. بدلًا من ذلك، تقوم بإخراج حالتها إلى مخزن آخر. (على سبيل المثال، أي تطبيق ويب يعتمد على الاحتفاظ بحالة الجلسة في مخزن مساعد أو ذاكرة تخزين مؤقت ليس عديم الحالة.)
مثال شائع على كيفية استخدام الخدمات عديمة الحالة في Service Fabric هو استخدامها كواجهة أمامية تعرض واجهة برمجة التطبيقات العامة لتطبيق ويب. ثم تتحدث خدمة الواجهة الأمامية إلى الخدمات ذات الحالة لإكمال طلب المستخدم. في هذه الحالة، يتم توجيه الاستدعاءات من العملاء إلى منفذ معروف، مثل 80، حيث تستمع الخدمة عديمة الحالة. تتلقى هذه الخدمة عديمة الحالة الاستدعاء وتحدد ما إذا كان الاستدعاء من طرف موثوق به كما تحدد الخدمة الموجه إليها. بعد ذلك، تقوم الخدمة عديمة الحالة بإعادة توجيه الاستدعاء إلى القسم الصحيح من الخدمة ذات الحالة الخاصة وتنتظر الرد. عندما تتلقى الخدمة عديمة الحالة ردًا، فإنها ترد على العميل الأصلي. مثال على هذه الخدمة هو عينة الشروع في العمل في Service Fabric (#C / Java) من بين عينات Service Fabric الأخرى في هذا المستودع.
الخدمات الموثوقة ذات الحالة الخاصة
الخدمة ذات الحالة الخاصةهي التي يجب فيها الحفاظ على اتساق جزء من الحالة ووجوده حتى تعمل الخدمة. فكر في خدمة تحسب باستمرار متوسط التداول لقيمة استنادًا إلى التحديثات التي تتلقاها. للقيام بذلك، يجب أن يكون لدى الخدمة المجموعة الحالية من الطلبات الواردة التي تحتاج إلى معالجتها والمتوسط الحالي. أي خدمة تقوم باسترداد المعلومات ومعالجتها وتخزينها في مخزن خارجي (مثل كائن ثنائي كبير الحجم لـ Azure أو مخزن الجداول اليوم) تكون خدمة ذات حالة خاصة. إنها تحتفظ بحالتها في مخزن الحالة الخارجية.
تقوم معظم الخدمات اليوم بتخزين حالتها خارجيًا لأن المخزن الخارجي هو ما يوفر الموثوقية والتوافر وقابلية التوسع والاتساق لتلك الحالة. في Service Fabric، ليس مطلوب من الخدمات تخزين حالتها خارجيًا. يهتم Service Fabric بهذه المتطلبات لكل من التعليمة البرمجية للخدمة وحالة الخدمة.
لنفترض أننا نريد كتابة خدمة تعالج الصور. للقيام بذلك، تأخذ الخدمة صورة وسلسلة التحويلات التي يجب إجراؤها على تلك الصورة. تقوم هذه الخدمة بإرجاع وحدة استماع للاتصالات (لنفترض أنها واجهة برمجة التطبيقات للويب) يعرض واجهة برمجة تطبيقات مثل ConvertImage(Image i, IList<Conversion> conversions). عندما تتلقى طلبًا، تقوم الخدمة بتخزينه في IReliableQueue، وإرجاع بعض المعرّفات إلى العميل حتى يتمكن من تتبع الطلب.
في هذه الخدمة، RunAsync() يمكن أن تكون أكثر تعقيدًا. تحتوي الخدمة على حلقة داخل RunAsync() تسحب الطلبات من IReliableQueueوتنفذ التحويلات المطلوبة. يتم تخزين النتائج في IReliableDictionary بحيث عندما يعود العميل يمكنه الحصول على صوره المحولة. لضمان عدم فقدان الصورة حتى في حالة حدوث فشل ما، ستنسحب هذه الخدمة الموثوقة من قائمة الانتظار، وتنفذ التحويلات، ثم ستخزن النتيجة كلها في عملية واحدة. في هذه الحالة، تتم إزالة الرسالة من قائمة الانتظار ويتم تخزين النتائج في قاموس النتائج فقط عند اكتمال التحويلات. بدلًا من ذلك، يمكن للخدمة سحب الصورة من قائمة الانتظار وتخزينها على الفور في مخزن بعيد. هذا يقلل من مقدار الحالة التي يتعين على الخدمة إدارتها، ولكنه يزيد من التعقيد لأن الخدمة يجب أن تحتفظ ببيانات التعريف اللازمة لإدارة المخزن البعيد. مع أي من النهجين، إذا حدث أي فشل، سيظل الطلب في قائمة الانتظار في انتظار معالجته.
على الرغم من أن هذه الخدمة تبدو وكأنها خدمة .NET نموذجية، إلا أن الفرق هو أن هياكل البيانات المستخدمة (IReliableQueueو IReliableDictionary) يتم توفيرها بواسطة Service Fabric، وهي موثوقة للغاية ومتوفرة بنسبة عالية ومتسقة.
متى تستخدم واجهات برمجة تطبيقات الخدمات الموثوقة
فكر في استخدام واجهات برمجة تطبيقات الخدمات الموثوقة إذا:
- كنت تريد أن تكون التعليمة البرمجية للخدمة (والحالة حسب اختيارك) متوفرة بشكل كبير وموثوقًا بها للغاية.
- كنت تحتاج إلى ضمانات العمليات عبر وحدات متعددة من الحالة (على سبيل المثال، الأوامر وعناصر سطر الأمر).
- يمكن نمذجة حالة التطبيق بشكل طبيعي على أنها قواميس وقوائم انتظار موثوقة.
- يجب أن تكون التعليمات البرمجية للتطبيقات أو حالتك متوفرة بشكل كبير مع عمليات قراءة وكتابة بزمن انتقال منخفض.
- يحتاج تطبيقك إلى التحكم في تزامن العمليات المتداولة أو دقتها عبر واحدة أو أكثر من المجموعات الموثوقة.
- كنت تريد إدارة الاتصالات أو التحكم في نظام التقسيم لخدمتك.
- تحتاج التعليمات البرمجية الخاصة بك إلى بيئة وقت تشغيل خالية من مؤشرات الترابط.
- يحتاج التطبيق الخاص بك إلى إنشاء أو تدمير القواميس أو قوائم الانتظار الموثوقة أو الخدمات بأكملها بشكل ديناميكي في وقت التشغيل.
- تحتاج إلى التحكم برمجيًا في ميزات النسخ الاحتياطي والاستعادة التي يوفرها Service Fabric لحالة خدمتك.
- يحتاج تطبيقك إلى الاحتفاظ بمحفوظات التغيير لوحدات الحالة الخاصة به.
- تريد تطوير أو استهلاك موفري حالات مخصصين تم تطويرهم من قبل جهات خارجية.