في 26 فبراير ، عقدنا اجتماع Apache Ignite GreenSource ، حيث أجرى المساهمون المفتوحون المصدر لمشروع
Apache Ignite . حدث هام في حياة هذا المجتمع هو إعادة هيكلة مكون
Ignite Service Grid ، والذي يسمح لك بنشر خدمات micros مخصصة مباشرة في نظام Ignite.
تحدث فيشيسلاف درادور ، كبير مطوري ياندكس ومساهم أباتشي إيجنيت لأكثر من عامين ، عن هذه العملية الصعبة في الاجتماع.
بادئ ذي بدء ، ما هو Apache Ignite بشكل عام. هذه قاعدة بيانات عبارة عن مستودع مفتاح / قيمة موزع مع دعم SQL والمعاملات وذاكرة التخزين المؤقت. بالإضافة إلى ذلك ، يتيح لك Ignite نشر خدمات المستخدم مباشرة في نظام Ignite. يصبح المطور متاحًا لجميع الأدوات التي يوفرها Ignite - هياكل البيانات الموزعة ، المراسلة ، التدفق ، حساب وشبكة البيانات. على سبيل المثال ، عند استخدام "شبكة البيانات" ، تختفي مشكلة إدارة بنية أساسية منفصلة لمستودع البيانات ، ونتيجة لذلك ، تختفي النفقات العامة الناتجة عن ذلك.
باستخدام Service Grid API ، يمكنك نشر خدمة عن طريق تحديد نظام النشر ببساطة في التكوين ، وبالتالي الخدمة نفسها.
عادةً ما يكون نمط النشر مؤشراً على عدد الحالات التي يجب نشرها على عقد نظام المجموعة. هناك نوعان من أنماط النشر النموذجية. الأول هو Cluster Singleton: في أي وقت في الكتلة ، سيتم ضمان مثيل واحد من خدمة المستخدم. والثاني هو عقدة Singleton: يتم نشر مثيل واحد من الخدمة على كل عقدة من الكتلة.
يمكن للمستخدم أيضًا تحديد عدد مثيلات الخدمة في المجموعة بأكملها وتحديد تقدير لتصفية العقد المناسبة. في هذا السيناريو ، ستحسب شبكة الخدمة نفسها التوزيع الأمثل لنشر الخدمات.
بالإضافة إلى ذلك ، هناك ميزة مثل Affinity Service. التقارب هي وظيفة تحدد علاقة المفاتيح بالأقسام وعلاقة الأطراف بالعقد في الهيكل. باستخدام المفتاح ، يمكنك تحديد العقدة الأساسية التي يتم تخزين البيانات عليها. وبالتالي ، يمكنك ربط الخدمة الخاصة بك بالمفتاح وذاكرة التخزين المؤقت لوظيفة التقارب. إذا تغيرت وظيفة التقارب ، فستحدث إعادة تشغيل تلقائية. لذلك ستوضع الخدمة دائمًا بجوار البيانات التي ينبغي لها معالجتها ، وبالتالي تقلل من النفقات العامة للوصول إلى المعلومات. مثل هذا المخطط يمكن أن يسمى نوعًا من الحوسبة المتقاربة.
الآن وبعد أن اكتشفنا جمال شبكة الخدمة ، سنخبرك بتاريخ تطورها.
ما كان من قبل
اعتمد التطبيق السابق لشبكة الخدمة على ذاكرة التخزين المؤقت للنظام المتماثل للمعاملات. كلمة "ذاكرة التخزين المؤقت" في Ignite تعني التخزين. هذا ليس شيئًا مؤقتًا كما تعتقد. على الرغم من حقيقة أن ذاكرة التخزين المؤقت قابلة للتكرار وأن كل عقدة تحتوي على مجموعة البيانات بأكملها ، يوجد داخل ذاكرة التخزين المؤقت طريقة عرض مقسمة. هذا بسبب تحسين التخزين.
ماذا حدث عندما أراد المستخدم نشر الخدمة؟
- جميع العقد في الكتلة اشتركت في تحديث البيانات في المستودع باستخدام آلية الاستعلام المستمر المدمجة.
- قامت العقدة البادئة بموجب معاملة تمت قراءتها بإنشاء سجل في قاعدة البيانات يتضمن تكوين الخدمة ، بما في ذلك المثيل المسلسل.
- عند تلقي إشعار بسجل جديد ، قام المنسق بحساب التوزيع بناءً على التكوين. تتم كتابة الكائن الناتج مرة أخرى إلى قاعدة البيانات.
- تقرأ العقد معلومات حول التوزيع الجديد والخدمات المنشورة إلى
إذا لزم الأمر.
ما لم يناسبنا
في مرحلة ما ، توصلنا إلى نتيجة: من المستحيل العمل مع الخدمات. كان هناك عدة أسباب.
إذا حدث خطأ ما أثناء النشر ، فيمكنك معرفة ذلك فقط من سجلات العقدة التي حدث فيها كل شيء. لم يكن هناك سوى نشر غير متزامن ، لذلك بعد إعادة التحكم من طريقة النشر إلى المستخدم ، استغرق الأمر بعض الوقت الإضافي لبدء الخدمة - وفي ذلك الوقت لم يتمكن المستخدم من التحكم في أي شيء. لتطوير "شبكة الخدمة" بشكل أكبر ، ورؤية ميزات جديدة ، وجذب مستخدمين جدد وجعل الحياة أسهل للجميع ، تحتاج إلى تغيير شيء ما.
عند تصميم شبكة خدمة جديدة ، أردنا أولاً وقبل كل شيء تقديم ضمان نشر متزامن: بمجرد عودة المستخدم للتحكم من API ، يمكنه استخدام الخدمات على الفور. أردت أيضًا إعطاء البادئ الفرصة لمعالجة أخطاء النشر.
بالإضافة إلى ذلك ، أردت تسهيل التنفيذ ، أي الابتعاد عن المعاملات وإعادة التوازن. على الرغم من حقيقة أن ذاكرة التخزين المؤقت قابلة للنسخ المتماثل ولا يوجد توازن ، كانت هناك مشاكل أثناء عملية النشر الكبيرة مع العديد من العقد. عند تغيير الهيكل ، تحتاج العقد إلى تبادل المعلومات ، ومع نشر كبير ، يمكن لهذه البيانات أن تزن كثيرًا.
عندما كانت الطبولوجيا غير مستقرة ، كان المنسق بحاجة إلى إعادة حساب توزيع الخدمات. وبشكل عام ، عندما يتعين عليك التعامل مع المعاملات وفقًا لطوبولوجيا غير مستقرة ، فقد يؤدي ذلك إلى أخطاء يصعب التنبؤ بها.
المشاكل
ما التغيرات العالمية دون المصاحبة للمشاكل؟ أول هذه التغيرات في الطوبولوجيا. يجب أن تفهم أنه في أي وقت ، وحتى في وقت نشر الخدمة ، يمكن للعقدة أن تدخل كتلة أو تخرج منها. علاوة على ذلك ، إذا دخلت العقدة الكتلة وقت النشر ، فسيكون من الضروري نقل جميع المعلومات المتعلقة بالخدمات إلى العقدة الجديدة باستمرار. ونحن نتحدث ليس فقط حول ما تم نشره بالفعل ، ولكن أيضًا عن عمليات النشر الحالية والمستقبلية.
هذه مجرد واحدة من المشكلات التي يمكن وضعها في قائمة منفصلة:
- كيفية نشر الخدمات التي تم تكوينها بشكل ثابت عند بدء العقدة؟
- عقدة الخروج من الكتلة - ماذا لو كانت خدمات المضيف المضيف؟
- ماذا تفعل إذا تغير المنسق؟
- ماذا تفعل إذا أعاد العميل الاتصال بالكتلة؟
- هل أحتاج إلى معالجة طلبات التنشيط / إلغاء التنشيط وكيف؟
- ولكن ماذا لو أطلقوا على ذاكرة التخزين المؤقت المدمرة ، ولدينا خدمات تقارب مرتبطة بها؟
وهذا ليس كل شيء.
قرار
كهدف ، اخترنا نهج Event Driven مع تنفيذ عمليات الاتصال باستخدام الرسائل. قام Ignite بالفعل بتطبيق مكونين يسمحان للعقد بإعادة توجيه الرسائل فيما بينها - communication-spi و discovery-spi.
الاتصال spi يسمح العقد للتواصل وإعادة توجيه الرسائل مباشرة. انها مناسبة تماما لإرسال كميات كبيرة من البيانات. يتيح لك Discovery-spi إرسال رسالة إلى جميع العقد في المجموعة. في التنفيذ القياسي ، يتم ذلك وفقًا لطوبولوجيا الطوق. هناك أيضًا تكامل مع Zookeeper ، وفي هذه الحالة يتم استخدام طوبولوجيا النجمة. هناك نقطة مهمة أخرى تجدر الإشارة إليها: اكتشاف spi يضمن تسليم الرسالة بالترتيب الصحيح لجميع العقد.
النظر في بروتوكول النشر. يتم إرسال جميع طلبات المستخدم للنشر والتوزيع عبر discovery-spi. وهذا يعطي
الضمانات التالية:
- سيتم تلقي الطلب بواسطة كافة العقد في الكتلة. سيتيح لك ذلك متابعة معالجة الطلب عند تغيير المنسق. وهذا يعني أيضًا أنه في رسالة واحدة ، ستحتوي كل عقدة على جميع البيانات التعريفية الضرورية ، مثل تكوين الخدمة والمثيل التسلسلي الخاص بها.
- يسمح لك أمر تسليم الرسالة الصارم بحل تعارضات التكوين والطلبات المتنافسة.
- نظرًا لأن إدخال العقدة في الهيكل يتم معالجته أيضًا بواسطة discovery-spi ، فكل البيانات اللازمة للعمل مع الخدمات ستصل إلى العقدة الجديدة.
عند استلام الطلب ، تقوم العقد الموجودة في نظام المجموعة بالتحقق من صحتها وتشكيل مهام للمعالجة. يتم وضع هذه المهام في قائمة الانتظار ثم معالجتها في مؤشر ترابط آخر بواسطة عامل منفصل. يتم تنفيذ ذلك بهذه الطريقة ، لأن النشر قد يستغرق وقتًا طويلًا وتأخير دفق اكتشاف باهظ التكلفة غير مقبول.
تتم معالجة جميع الطلبات من قائمة الانتظار من قبل مدير النشر. لديه عامل خاص يقوم بسحب مهمة من قائمة الانتظار هذه وتهيئتها لبدء النشر. بعد ذلك ، تحدث الإجراءات التالية:
- تحسب كل عقدة التوزيع بشكل مستقل بفضل وظيفة التعيين الحتمية الجديدة.
- تشكل العقد رسالة مع نتائج النشر وإرسالها إلى المنسق.
- يقوم المنسق بتجميع كافة الرسائل وإنشاء نتيجة لعملية النشر بأكملها ، والتي يتم إرسالها عبر اكتشاف spi إلى كافة العقد في الكتلة.
- عند استلام النتيجة ، تكتمل عملية النشر ، وبعد ذلك تتم إزالة المهمة من قائمة الانتظار.
تصميم جديد يستند إلى الحدث: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.javaفي حالة حدوث خطأ في وقت النشر ، تتضمن العقدة على الفور هذا الخطأ في الرسالة ، والذي يرسله إلى المنسق. بعد تجميع الرسائل ، سيكون لدى المنسق معلومات حول جميع الأخطاء أثناء النشر وسيرسل هذه الرسالة عبر اكتشاف - spi. ستتوفر معلومات الخطأ على أي عقدة في الكتلة.
وفقًا لهذه الخوارزمية ، تتم معالجة جميع الأحداث المهمة في شبكة الخدمة. على سبيل المثال ، يعد تغيير الهيكل أيضًا رسالة اكتشاف spi. وبشكل عام ، عند مقارنته بما كان عليه ، فقد أصبح البروتوكول خفيفًا جدًا وموثوقًا به. بقدر التعامل مع أي موقف أثناء النشر.
ماذا سيحدث بعد ذلك
الآن عن الخطط. يتم تنفيذ أي تطور رئيسي في مشروع Ignite كمبادرة لتحسين Ignite ، ما يسمى IEP. تحتوي إعادة تصميم شبكة الخدمة أيضًا على IEP -
IEP رقم 17 باسم المزاح "تغيير الزيت في شبكة الخدمة". لكن في الواقع ، لم نغير الزيت في المحرك ، ولكن المحرك بأكمله.
قسمنا المهام في IEP إلى مرحلتين. المرحلة الأولى هي مرحلة رئيسية ، والتي تتمثل في تغيير بروتوكول النشر. تم سكبها بالفعل في المعالج ، يمكنك تجربة شبكة الخدمة الجديدة ، والتي ستظهر في الإصدار 2.8. تتضمن المرحلة الثانية العديد من المهام الأخرى:
- redeep الساخنة
- خدمة الإصدار
- زيادة المرونة
- العميل رقيقة
- أدوات لرصد وحساب المقاييس المختلفة
أخيرًا ، يمكن أن ننصحك بشبكة الخدمة لإنشاء أنظمة توفر عالية التحمل للأخطاء. ندعوك أيضًا إلى
قائمة dev و
قائمة المستخدمين لمشاركة تجربتك. تجربتك مهمة حقًا للمجتمع ، وسوف تساعدك على فهم إلى أين تتجه ، وكيفية تطوير المكون في المستقبل.