يدخل كل تطبيق أعمال ناجح تقريبًا عاجلاً أم آجلاً إلى مرحلة تتطلب التوسع الأفقي. في كثير من الحالات، يمكنك ببساطة بدء مثيل جديد وتقليل متوسط التحميل. ولكن هناك أيضًا حالات أقل تافهة نحتاج فيها إلى التأكد من أن العقد المختلفة تعرف بعضها البعض وتوزع عبء العمل بعناية.
اتضح أنه محظوظ جدًا إرلانغ، الذي اخترناه بسبب تركيبه اللطيف والضجيج المحيط به، يتمتع بالدرجة الأولى . من الناحية النظرية، يبدو هذا تافهًا تمامًا:
يتم تمرير الرسائل بين العمليات على العقد المختلفة، وكذلك بين الروابط والشاشات، بشكل شفاف […]
في الممارسة العملية، كل شيء أكثر تعقيدا قليلا. وزعت إرلانغ تم تطويره عندما كانت كلمة "حاوية" تعني صندوقًا حديديًا كبيرًا للشحن، وكانت كلمة "عامل الإرساء" مجرد مرادف لعمال التحميل والتفريغ. في IP4 كان هناك العديد من العناوين غير المأهولة، وكانت انقطاعات الشبكة عادةً ما تحدث بسبب مضغ الفئران للكابل، وتم قياس متوسط وقت تشغيل نظام الإنتاج على مدار عقود.
الآن أصبحنا جميعًا مكتفيين ذاتيًا بشكل لا يصدق، ومعبأين، وموزعين إرلانغ في بيئة يتم فيها توزيع عناوين IP الديناميكية وفقًا لمبدأ العشوائية الكبيرة، ويمكن أن تظهر العقد وتختفي حسب نزوة الذراع الأيسر للمجدول. لتجنب أكوام التعليمات البرمجية النمطية في كل مشروع يتم تشغيله إرلانغ، لمكافحة البيئة المعادية، المساعدة مطلوبة.
لاحظ: وأنا على علم بأن هناك . إنه رائع حقًا، فهو يحتوي على أكثر من ألف نجمة، والمؤلف مشهور في المجتمع، وكل ذلك. إذا كانت الطرق التي تقدمها هذه الحزمة لإنشاء وصيانة المجموعة كافية بالنسبة لك، فأنا سعيد من أجلك. ولسوء الحظ، أنا بحاجة إلى أكثر من ذلك بكثير. أريد التحكم في الإعداد بالتفصيل وألا أكون متفرجًا خارجيًا في مسرح إعادة تنظيم المجموعة.
متطلبات
ما كنت أحتاجه شخصيًا هو مكتبة تتولى إدارة المجموعة وتتمتع بالخصائص التالية:
- عمل شفاف مع قائمة العقد المشفرة والاكتشاف الديناميكي من خلال الخدمات إرلانغ;
- رد اتصال يعمل بكامل طاقته لكل تغيير في الهيكل (العقدة هناك، العقدة هنا، عدم استقرار الشبكة، الانقسامات)؛
- واجهة شفافة لإطلاق مجموعة بأسماء طويلة وقصيرة، كما هو الحال مع
:nonode@nohost; - دعم Docker خارج الصندوق، دون الحاجة إلى كتابة تعليمات برمجية للبنية التحتية.
هذا الأخير يعني أنه بعد أن اختبرت التطبيق محليًا في :nonode@nohostأو في بيئة موزعة بشكل مصطنع باستخدام ، أريد فقط أن أركض docker-compose up --scale my_app=3 وانظر كيف يتم تنفيذ ثلاث مثيلات في عامل الإرساء دون أي تغييرات في التعليمات البرمجية. أريد أيضًا تطبيقات تابعة مثل mnesia - عندما تتغير البنية، يقومون بإعادة بناء المجموعة خلف الكواليس مباشرة دون أي ركلة إضافية من التطبيق.
الدير لم يكن المقصود منها أن تكون مكتبة قادرة على القيام بكل شيء بدءًا من دعم المجموعة وحتى صنع القهوة. وهي ليست حلاً سحرياً يهدف إلى تغطية جميع الحالات المحتملة، أو أن تكون حلاً أكاديمياً كاملاً بالمعنى الذي يقوله المنظرون من CS وضعت في هذا المصطلح. تم تصميم هذه المكتبة لتخدم غرضًا واضحًا للغاية، ولكنها تؤدي مهمتها غير الكبيرة على أكمل وجه. سيكون هذا الهدف هو توفير الشفافية الكاملة بين بيئة التطوير المحلية وبيئة مرنة موزعة مليئة بالحاويات المعادية.
النهج المختار
الدير تم تصميمه ليتم تشغيله كتطبيق، على الرغم من أن المستخدمين المتقدمين يمكنهم العمل مع تجميع وصيانة المجموعة يدويًا عن طريق التشغيل المباشر Cloister.Manager في شجرة المشرف على التطبيق الهدف.
عند تشغيله كتطبيق، تعتمد المكتبة على config، والذي يقرأ منه القيم الأساسية التالية:
config :cloister,
otp_app: :my_app,
sentry: :"cloister.local", # or ~w|n1@foo n2@bar|a
consensus: 3, # number of nodes to consider
# the cluster is up
listener: MyApp.Listener # listener to be called when
# the ring has changedالمعلمات أعلاه تعني حرفيا ما يلي: الدير تستخدم لتطبيق OTP :my_app، الاستخدامات اكتشاف خدمة إرلانج لتوصيل العقد، على الأقل ثلاثة، و MyApp.Listener الوحدة النمطية (التنفيذ ) تم تكوينه لتلقي إشعارات حول تغييرات الهيكل. يمكن العثور على وصف تفصيلي للتكوين الكامل في .
مع هذا التكوين، التطبيق الدير سوف ، تأخير عملية بدء التطبيق الرئيسي حتى يتم التوصل إلى الإجماع (ثلاث عقد متصلة ومتصلة، كما في المثال أعلاه.) وهذا يمنح التطبيق الرئيسي الفرصة لافتراض أنه عند البدء، تكون المجموعة متاحة بالفعل. كلما تغيرت الهيكلية (سيكون هناك الكثير منها، لأن العقد لا تبدأ بشكل متزامن تمامًا)، سيتم استدعاء المعالج . في أغلب الأحيان نقوم بتنفيذ إجراء عندما نتلقى رسالة حالة %Cloister.Monitor{status: :up}مما يعني: "مرحبًا، تم تجميع المجموعة."
في معظم الحالات، التثبيت consensus: 3 هو الأمثل لأنه حتى لو توقعنا اتصال المزيد من العقد، فسيتم تنفيذ رد الاتصال status: :rehashing → status: :up على أي عقدة تمت إضافتها أو إزالتها حديثًا.
عند البدء في وضع التطوير، تحتاج فقط إلى الضبط consensus: 1 и الدير سوف يتخطى بسعادة انتظار تجميع المجموعة عندما يرى ذلك :nonode@nohostأو :node@hostأو :[email protected] - اعتمادًا على كيفية تكوين العقدة (:none | :shortnames | :longnames).
إدارة التطبيقات الموزعة
تتضمن التطبيقات الموزعة التي لا توجد في فراغ عادةً تبعيات موزعة، مثل mnesia. من السهل علينا التعامل مع إعادة التكوين من نفس رد الاتصال on_state_change/2. هنا، على سبيل المثال، وصف تفصيلي لكيفية إعادة التكوين mnesia على الطاير في .
الميزة الرئيسية للاستخدام الدير هو أنه يقوم بجميع العمليات اللازمة لإعادة بناء المجموعة بعد تغيير الهيكل تحت الغطاء. يعمل التطبيق ببساطة في بيئة موزعة معدة بالفعل، مع جميع العقد المتصلة، بغض النظر عما إذا كنا نعرف عناوين IP وبالتالي أسماء العقد مقدمًا، أو تم تعيينها/تغييرها ديناميكيًا. لا يتطلب هذا أي إعدادات خاصة لتكوين عامل الإرساء، ومن وجهة نظر مطور التطبيقات، لا يوجد فرق بين التشغيل في بيئة موزعة أو التشغيل في بيئة محلية. :nonode@nohost. يمكنك قراءة المزيد عن هذا في .
على الرغم من أن المعالجة المعقدة للتغيرات الهيكلية ممكنة من خلال التنفيذ المخصص MyApp.Listener، قد تكون هناك دائمًا حالات حافة حيث تثبت قيود المكتبة وتحيزات التكوين أنها حجر الزاوية في التنفيذ. لا بأس، فقط خذ ما ورد أعلاه libcluster، وهو أكثر الأغراض العامة، أو حتى التعامل مع المجموعة ذات المستوى المنخفض بنفسك. الهدف من مكتبة التعليمات البرمجية هذه ليس تغطية كل السيناريوهات المحتملة، ولكن استخدام السيناريو الأكثر شيوعًا دون ألم غير ضروري أو نسخ ولصق مرهق.
ملاحظة: في هذه المرحلة من النص الأصلي كانت هناك عبارة "تجميع سعيد!"، وعرضت عليّ خدمة ياندكس، التي أترجم بها (لست مضطرًا إلى تصفح القواميس بنفسي)، خيار "تجميع سعيد!" وربما يكون من المستحيل تصور ترجمة أفضل، خاصة في ضوء الوضع الجيوسياسي الحالي.
المصدر: www.habr.com