🥇 خرطوشة أداة التحكم: تجزئة الواجهة الخلفية لوا في ثلاثة أسطر

نحن في Mail.ru Group لدينا Tarantool - هذا خادم تطبيق في Lua ، وهو أيضًا قاعدة بيانات مجمعة (أو العكس؟). إنه سريع ورائع ، لكن إمكانيات خادم واحد لا تزال غير محدودة. التحجيم العمودي ليس حلاً سحريًا أيضًا ، لذلك لدى Tarantool أدوات للقياس الأفقي - وحدة vshard [1]. يسمح لك بتقسيم البيانات عبر خوادم متعددة ، ولكن عليك العبث بها لإعدادها وتثبيت منطق الأعمال.

بشرى سارة: لقد جمعنا المخاريط (على سبيل المثال [2], [3]) وقدم إطار عمل آخر من شأنه أن يبسط بشكل كبير حل هذه المشكلة.

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

وما هي المشكلة بالضبط؟

لدينا الرتيلاء ، ولدينا فاشارد - ما الذي تريده أكثر من ذلك؟

أولاً ، إنها مسألة راحة. يتم تكوين تكوين vshard عبر جداول Lua. لكي يعمل نظام موزع لعمليات Tarantool المتعددة بشكل صحيح ، يجب أن يكون التكوين هو نفسه في كل مكان. لا أحد يريد أن يفعل ذلك يدويًا. لذلك ، يتم استخدام جميع أنواع البرامج النصية وأنظمة Ansible والنشر.

يقوم Cartridge بإدارة تكوين vshard بنفسه ، ويقوم بذلك بناءً على نفسه التكوين الموزع الخاص. في الأساس ، هو ملف YAML بسيط ، يتم تخزين نسخة منه في كل مثيل من Tarantool. يكمن التبسيط في حقيقة أن الإطار نفسه يراقب تكوينه ويضمن أنه هو نفسه في كل مكان.

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

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

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

الميزات الرئيسية لخرطوشة Tarantool:

التنظيم العنقودي الآلي ؛
توسيع وظائف التطبيق بأدوار جديدة ؛
قالب تطبيق للتطوير والنشر ؛
تجزئة تلقائية مدمجة ؛
التكامل مع إطار اختبار Luatest ؛
إدارة الكتلة باستخدام WebUI و API ؛
أدوات التعبئة والتغليف والنشر.

مرحبا بالعالم!

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

$ tarantoolctl rocks install cartridge-cli
$ export PATH=$PWD/.rocks/bin/:$PATH

سيؤدي هذان الأمران إلى تثبيت أدوات سطر الأوامر المساعدة ويسمحان لك بإنشاء تطبيقك الأول من القالب:

$ cartridge create --name myapp

وهذا ما حصلنا عليه:

myapp/
├── .git/
├── .gitignore
├── app/roles/custom.lua
├── deps.sh
├── init.lua
├── myapp-scm-1.rockspec
├── test
│   ├── helper
│   │   ├── integration.lua
│   │   └── unit.lua
│   ├── helper.lua
│   ├── integration/api_test.lua
│   └── unit/sample_test.lua
└── tmp/

هذا مستودع git يحتوي على "Hello، World!" طلب. دعنا نحاول تشغيله على الفور ، بعد تثبيت التبعيات (بما في ذلك إطار العمل نفسه):

$ tarantoolctl rocks make
$ ./init.lua --http-port 8080

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

تطوير التطبيقات

فقط تخيل أننا نصمم مشروعًا يجب أن يتلقى البيانات وحفظها وإنشاء تقرير مرة واحدة يوميًا.

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

لا يزال هذا الرسم البياني لا يعكس بدقة ما سننشئه في المشروع ، لأن المكونات تبدو مجردة. ما زلنا بحاجة إلى رؤية كيف يتم عرض هذا على Tarantool الحقيقي - دعنا نجمع مكوناتنا حسب العمليات.

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

في مرحلة التصميم ، كان من الملائم العمل مع ثلاثة مكونات ، لكن بصفتي مطورًا ، أثناء كتابة التعليمات البرمجية ، لا أريد التفكير في تشغيل ثلاث مثيلات من Tarnatool. أحتاج إلى إجراء الاختبارات والتحقق من تهجئة البوابة بشكل صحيح. أو ربما أريد أن أظهر ميزة لزملائي. لماذا يجب علي نشر ثلاث مثيلات؟ هكذا ولد مفهوم الأدوار. الدور عبارة عن وحدة luash عادية ، يتم إدارة دورة حياتها بواسطة Cartridge. في هذا المثال ، هناك أربعة منهم - البوابة ، جهاز التوجيه ، التخزين ، المجدول. قد يكون هناك المزيد في مشروع آخر. يمكن تشغيل جميع الأدوار في عملية واحدة ، وسيكون ذلك كافياً.

وعندما يتعلق الأمر بالنشر في التدريج أو الإنتاج ، فسنقوم بتعيين مجموعة أدوار لكل عملية Tarantool اعتمادًا على إمكانيات الأجهزة:

إدارة الطوبولوجيا

يجب تخزين المعلومات حول مكان تشغيل الأدوار في مكان ما. وهذا "مكان ما" هو تكوين موزع ، والذي ذكرته بالفعل أعلاه. أهم شيء فيه هو طوبولوجيا الكتلة. فيما يلي 3 مجموعات نسخ من 5 عمليات Tarantool:

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

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

حياة الأدوار

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

function init()
function validate_config()
function apply_config()
function stop()

كل دور له وظيفة init. يتم استدعاؤه مرة واحدة إما عند تمكين الدور أو عند إعادة تشغيل Tarantool. هناك من الملائم ، على سبيل المثال ، تهيئة box.space.create ، أو يمكن أن يبدأ المجدول بعض ألياف الخلفية التي ستؤدي العمل على فترات زمنية معينة.

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

مكالمات الكتلة validate_config и apply_config في كل مرة يتغير التكوين الموزع. عندما يتم تطبيق التكوين من خلال التزام من مرحلتين ، يتحقق نظام المجموعة من أن كل دور جاهز لقبول هذا التكوين الجديد ويبلغ المستخدم بالخطأ إذا لزم الأمر. عندما يتفق الجميع على أن التكوين طبيعي ، فإن ملف apply_config.

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

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

نقطة أخرى مهمة هي ضمان التسامح مع الخطأ. تستخدم Cartridge بروتوكول SWIM لمراقبة الصحة [4]. باختصار ، تتبادل العمليات "الشائعات" مع بعضها البعض عبر UDP - تخبر كل عملية جيرانها بآخر الأخبار ، ويستجيبون. إذا لم يأت الجواب فجأة ، يبدأ تارانتول في الاشتباه في وجود خطأ ما ، وبعد فترة يقرأ الموت ويبدأ في إخبار الجميع حول هذا الخبر.

بناءً على هذا البروتوكول ، تنظم Cartridge معالجة تلقائية للفشل. تراقب كل عملية بيئتها ، وإذا توقف القائد فجأة عن الاستجابة ، فيمكن للنسخة المتماثلة أن تتولى دورها ، وتقوم Cartridge بتكوين أدوار التشغيل وفقًا لذلك.

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

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

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

أدوات النشر

لقد وعدت بإظهار كيف تساعد Cartridge في نشر التطبيقات. لتسهيل الحياة على الآخرين ، حزم إطار العمل حزم RPM:

$ cartridge pack rpm myapp -- упакует для нас ./myapp-0.1.0-1.rpm
$ sudo yum install ./myapp-0.1.0-1.rpm

تحتوي الحزمة المثبتة على كل ما تحتاجه تقريبًا: كلاً من التطبيق وتبعيات luash المثبتة. سيصل Tarantool أيضًا إلى الخادم باعتباره اعتمادًا على حزمة RPM ، وخدمتنا جاهزة للإطلاق. يتم ذلك من خلال systemd ، ولكن عليك أولاً كتابة بعض التهيئة. كحد أدنى ، حدد URI لكل عملية. ثلاثة تكفي لمثال.

$ sudo tee /etc/tarantool/conf.d/demo.yml <<CONFIG
myapp.router: {"advertise_uri": "localhost:3301", "http_port": 8080}
myapp.storage_A: {"advertise_uri": "localhost:3302", "http_enabled": False}
myapp.storage_B: {"advertise_uri": "localhost:3303", "http_enabled": False}
CONFIG

هناك فارق بسيط مثير للاهتمام هنا. بدلاً من تحديد منفذ البروتوكول الثنائي فقط ، نحدد العنوان العام الكامل للعملية ، بما في ذلك اسم المضيف. هذا ضروري حتى تعرف العقد العنقودية كيفية الاتصال ببعضها البعض. إنها فكرة سيئة أن تستخدم 0.0.0.0 كـ advertise_uri ، يجب أن يكون عنوان IP العام ، وليس مقبس الربط. بدونها ، لن يعمل شيء ، لذلك لن تسمح لك Cartridge ببساطة بتشغيل عقدة بإعلان إعلان غير صحيح.

الآن بعد أن أصبح التكوين جاهزًا ، يمكنك بدء العمليات. نظرًا لأن وحدة systemd المعتادة لا تسمح ببدء أكثر من عملية واحدة ، يتم تثبيت التطبيقات الموجودة على الخرطوشة بواسطة ما يسمى. الوحدات المنبثقة التي تعمل مثل هذا:

$ sudo systemctl start myapp@router
$ sudo systemctl start myapp@storage_A
$ sudo systemctl start myapp@storage_B

في التكوين ، حددنا منفذ HTTP الذي يخدم كارتريدج واجهة الويب عليه - 8080. دعنا نذهب إليه ونرى:

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

اسكب كوبًا من مشروبك المفضل واسترخي بعد أسبوع عمل طويل. يمكن تشغيل التطبيق.