إشعال شبكة الخدمة - إعادة التشغيل

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

لنبدأ بما هو Apache Ignite بشكل عام. هذه قاعدة بيانات عبارة عن مخزن موزع للمفتاح/القيمة مع دعم SQL والمعاملات والتخزين المؤقت. بالإضافة إلى ذلك، يتيح لك Ignite نشر الخدمات المخصصة مباشرة في مجموعة Ignite. يتمتع المطور بإمكانية الوصول إلى جميع الأدوات التي يوفرها Ignite - هياكل البيانات الموزعة والمراسلة والبث والحوسبة وشبكة البيانات. على سبيل المثال، عند استخدام Data Grid، تختفي مشكلة إدارة بنية تحتية منفصلة لتخزين البيانات، ونتيجة لذلك، تختفي التكاليف العامة الناتجة.

باستخدام Service Grid API، يمكنك نشر خدمة ببساطة عن طريق تحديد نظام النشر، وبالتالي الخدمة نفسها في التكوين.

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

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

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

الآن بعد أن اكتشفنا جمال Service Grid، فلنتحدث عن تاريخ تطورها.

ما كان من قبل

يعتمد التنفيذ السابق لـ Service Grid على ذاكرة التخزين المؤقت لنظام المعاملات المنسوخة من Ignite. تشير كلمة "ذاكرة التخزين المؤقت" في Ignite إلى التخزين. أي أن هذا ليس شيئًا مؤقتًا، كما قد تظن. على الرغم من أنه يتم نسخ ذاكرة التخزين المؤقت وأن كل عقدة تحتوي على مجموعة البيانات بأكملها، إلا أنها تحتوي على تمثيل مقسم داخل ذاكرة التخزين المؤقت. ويرجع ذلك إلى تحسين التخزين.

ماذا حدث عندما أراد المستخدم نشر الخدمة؟

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

ما لا يناسبنا

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

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

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

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

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

مشاكل

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

هذه مجرد واحدة من المشاكل التي يمكن جمعها في قائمة منفصلة:

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

وهذا ليس كل شيء.

حل

كهدف، اخترنا النهج المبني على الأحداث مع تنفيذ عملية الاتصال باستخدام الرسائل. تطبق Ignite بالفعل مكونين يسمحان للعقد بإعادة توجيه الرسائل فيما بينها - communication-spi وdiscovery-spi.

يسمح Communication-spi للعقد بالتواصل مباشرة وإعادة توجيه الرسائل. إنها مناسبة تمامًا لإرسال كميات كبيرة من البيانات. يتيح لك Discovery-spi إرسال رسالة إلى جميع العقد في المجموعة. في التنفيذ القياسي، يتم ذلك باستخدام طوبولوجيا الحلقة. هناك أيضًا تكامل مع Zookeeper، وفي هذه الحالة يتم استخدام طوبولوجيا النجمة. نقطة أخرى مهمة جديرة بالملاحظة هي أن Discovery-SPI يوفر ضمانات بأن الرسالة سيتم تسليمها بالتأكيد بالترتيب الصحيح لجميع العقد.

دعونا نلقي نظرة على بروتوكول النشر. يتم إرسال جميع طلبات المستخدم للنشر وإلغاء النشر عبر Discovery-SPI. وهذا يعطي ما يلي الضمانات:

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

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

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

1. تقوم كل عقدة بحساب التوزيع بشكل مستقل بفضل وظيفة التعيين الحتمية الجديدة.
2. تقوم العقد بإنشاء رسالة بنتائج النشر وإرسالها إلى المنسق.
3. يقوم المنسق بتجميع كافة الرسائل وإنشاء نتيجة عملية النشر بأكملها، والتي يتم إرسالها عبر Discovery-SPI إلى جميع العقد في المجموعة.
4. عند تلقي النتيجة، تنتهي عملية النشر، وبعد ذلك تتم إزالة المهمة من قائمة الانتظار.

تصميم جديد يحركه الحدث: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java

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

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

ماذا سيحدث بعد

الآن عن الخطط. يتم إكمال أي تغيير كبير في مشروع Ignite كمبادرة لتحسين Ignite، تسمى IEP. تحتوي إعادة تصميم شبكة الخدمة أيضًا على IEP - برنامج التعليم الفردي رقم 17 بعنوان ساخر "تغيير الزيت في شبكة الخدمة". لكن في الواقع، لم نغير زيت المحرك، بل المحرك بأكمله.

قمنا بتقسيم المهام في برنامج التعليم الفردي (IEP) إلى مرحلتين. الأولى هي مرحلة رئيسية، والتي تتكون من إعادة صياغة بروتوكول النشر. لقد تم تضمينه بالفعل في البرنامج الرئيسي، ويمكنك تجربة شبكة الخدمة الجديدة، والتي ستظهر في الإصدار 2. وتشمل المرحلة الثانية العديد من المهام الأخرى:

• إعادة الانتشار الساخنة
• إصدار الخدمة
• زيادة التسامح مع الخطأ
• عميل رقيق
• أدوات لرصد وحساب المقاييس المختلفة

أخيرًا، يمكننا تقديم المشورة لك بشأن Service Grid لبناء أنظمة عالية التوفر ومتسامحة مع الأخطاء. كما ندعوكم لزيارتنا في قائمة المطورين и قائمة المستخدم شارك خبرتك. إن تجربتك مهمة حقًا للمجتمع؛ فهي ستساعدك على فهم المكان الذي يجب أن تتحرك فيه بعد ذلك، وكيفية تطوير المكون في المستقبل.

المصدر: www.habr.com