في الجزء الأول من مقالتي
، تحدثت عن كيف أنشأنا في Badoo الإصدار الأول من نظام التصحيح. باختصار ، كنا بحاجة إلى إيجاد طريقة لإصلاح الخلل الخطير عند الإنتاج مباشرةً ، ويمكن لجميع المطورين الوصول إليه. ومع ذلك ، فإن الإصدار الأول لم يخلو من عيوبه: استخدمنا طريقة تخطيط غريبة ، والتي لم تضمن ذرة تخطيط التصحيحات واتساق الشفرة.
في هذا الجزء من المقالة ، سأتحدث عن طريقة جديدة لوضع الكود الذي توصلنا إليه عند محاولة حل مشاكلنا ، وكيف تم تحويل نظام التصحيح لدينا.
الصورة: المصدرالحل الشامل - مجموعة النشر متعددة الجوانب
بعد مراجعة أخرى لنظام Jura الخاص بنا ، ذكر
youROCK Nasretdinov أن لديه فكرة عن كيفية حل جميع مشاكلنا. كل ما طلبه كان الكثير من الوقت لإعادة تشكيل نظام التخطيط. هذه هي الطريقة التي ظهر بها مفهوم مجموعة النشر المتعددة الأطراف ، أو ، لدى عامة الناس ، MDK (قارنها جورا مع طرق أخرى لتخطيط الشفرة في
تقريره عن HighLoad ++ ).
تم تصميم النظام الجديد لتغيير إجراء التخطيط لدينا. بالنسبة لأولئك الذين لم يقرؤوا الجزء الأول من المقالة ، سأخبرك باختصار كيف تبدو عملية النشر: أولاً نجمع جميع الملفات الضرورية في دليل واحد ، ثم نحفظ ونسلم حالة الدليل إلى الخوادم.
قبل عصر MDK ، استخدمنا أجهزة حظر (أي صور نظام الملفات) تسمى حلقات للتخزين والتسليم. تم نسخ الدليل إلى حلقة فارغة ، وأرشفته وإرساله إلى الخوادم.
في النظام الجديد ، لا نقوم بإصدار الدليل بأكمله ، ولكن كل ملف على حدة بحيث يرتبط إصدار الملف بوضوح بمحتوياته. للأدلة هناك خرائط (خرائط) - ملفات خاصة يتم فيها تسجيل نسخ من جميع الملفات في الدليل. تم أيضًا إصدار هذه البطاقات ، ويبدو كل شيء مثل هذا:
تبدو مألوفة؟ هذه هي الطريقة التي يتم ترتيب الأشياء بها في Git (يمكنك القراءة عنها
هنا ، ولكن هذا ليس ضروريًا لفهم المقالة).
للإصدار ، نستخدم الأحرف الثمانية الأولى من تجزئة MD5 (من تمثيلها السداسي العشري ، على وجه الدقة) ، المأخوذة من محتويات الملف. تتم كتابة هذا الإصدار في نهاية اسم الملف أو في بداية اسم الخريطة (بحيث يمكنك تمييز ملف الخريطة عن خريطة الإصدار التي تم إنشاؤها):
إصدار الكود هو نسخة الخريطة من الدليل الجذر www. من أجل العثور على الخريطة الحالية ، لدينا رابط رمزي (symlink) الحالي.
لماذا لا تستخدم بوابة؟على الرغم من حقيقة أن MDK تقترض جزئيا الأفكار من Git ، إلا أن لديهم بعض الاختلافات. الشيء الأكثر أهمية هو كيفية تخزين الملفات في دليل العمل (أي على الأجهزة). إذا قام Git بتخزين إصدار واحد فقط من الإصدار الحالي ، فإن MDK يحتفظ بجميع الإصدارات المتاحة من الملفات هناك. في نفس الوقت ، تشير خريطة ارتباط الحالية واحدة فقط إلى النسخة الحالية من الكود ، والتي تستخدم التحميل التلقائي في عملها والتي يمكن تغييرها تلقائيًا. للمقارنة ، يستخدم Git
git-checkout لتغيير الإصدار ، والذي يغير الملفات بدوره وليس ذريًا.
بناء باستخدام MDK
مطلوب MDK لحفظ حالة الدليل في نهاية التجميع. للقيام بذلك ، لدينا مكان خاص ، والذي أطلقنا عليه اسم المستودع ، - مستودع لجميع إصدارات الملفات ذات القيمة بالنسبة لنا (أي ، قد نرغب في تحليلها). عندما تكون المحتويات الجديدة للدليل جاهزة ، نقوم بحساب نسخ جميع الملفات الموجودة فيه ونبلغ المستودعات المفقودة.
التخطيط باستخدام MDK
أثناء التخطيط على كل خادم من الخوادم المستقبلة ، نقوم بتشغيل برنامج نصي يتحقق مما إذا كانت جميع الملفات الضرورية موجودة على الخادم ويطلب الملفات المفقودة من المستودع. يمكننا فقط تحويل الإصدار إلى إصدار جديد عن طريق تغيير الرابط الحالي.
كيف يجب أن تحل مشاكلنا
كان من المفترض أنه إذا تم تغيير عدد قليل من الملفات في الإصدار الجديد ، فإن تجميعه وتخطيطه باستخدام النظام الجديد يجب أن يكون على الأقل قابل للمقارنة في الوقت المناسب مع تخطيط التصحيح كملفات منفصلة. إذا كان الأمر كذلك ، فسنقوم بإنشاء كل إصدار جديد لكل تصحيح.
تنفيذ MDK
يحتوي MDK على عيب واحد: على الأجهزة النهائية ، يجب أن يكون اسم كل ملف نسخته. هذا ما يسمح لك بتخزين العديد من إصدارات ملف واحد في دليل في وقت واحد ، لكنه لا يسمح لك بتضمين user.php من الكود - يجب عليك تحديد إصدار معين. أضف إلى ذلك الأخطاء المتنوعة التي يمكن أن تبقى في كود نظام التخطيط ، خوارزمية التخطيط الجديدة ، التي كانت أكثر تعقيدًا من القديمة ، وسيصبح من الواضح لماذا قررنا تنفيذ النظام الجديد في خطوات صغيرة. بدأنا حرفياً بخادم أو خادمين وقمنا بتوسيع قائمتهم تدريجياً ، وتصحيح المشاكل التي تنشأ في نفس الوقت.
بالنظر إلى أن التحول إلى نظام جديد كان يجب أن يستغرق الكثير من الوقت ، كان علينا أن نفكر في كيفية عمل التصحيحات الخاصة بنا خلال الفترة الانتقالية. في ذلك الوقت ، ولتخطيط التصحيحات ، استخدمنا أداة mscp ذاتية الكتابة ، والتي وضعت الملفات واحدة تلو الأخرى. علمناها استبدال الملفات الحالية على الخوادم باستخدام MDK مقدمًا ، لكننا لم نتمكن من إضافة ملف جديد إلى هذه الخوادم (لأنني اضطررت إلى تغيير خريطة الملف). لم أكن أرغب في تقديم بعض الحلول المتوسطة المعقدة للغاية - لأننا كنا ذاهبين إلى مستقبل مشرق ، حيث لا توجد حاجة إلى mscp. ونتيجة لذلك ، كان علي أن أتحمل هذه المشكلة. بشكل عام ، خلال الفترة الانتقالية ، تمكن المطورون من المعاناة ، ولكن يبدو لنا الآن أنه يستحق ذلك.
لا تثق بأحد
الصورة: المصدرمن المحتمل أن يكون السؤال منطقيًا ، ولكن هل سيكون هناك تصادم بين الإصدارات في MDK (أي حالة يتم فيها تعيين نفس الملف لملفين مختلفين)؟
في الواقع ، نحن محميون جيدًا من هذا النوع من الأخطاء.
{ }.{} الملفات مثل هذا:
{ }.{} ، مما يعني أنه يجب أن يتطابق أكثر من ثمانية أحرف حتى يحدث خطأ.
ولكن بمجرد أن حدث خطأ ما. بعد الحساب التالي ، لاحظنا عددًا متزايدًا من الأخطاء برمز HTTP 404 (لم يتم العثور على الملف). أظهر تحقيق صغير أن بعض الملفات الثابتة كانت مفقودة. اتضح أننا وضعنا خريطة ثابتة قديمة جدًا ونعطي روابط لملفات لا يجب أن تكون موجودة بالفعل على الخوادم. ولكن من أين أتت هذه البطاقة؟ في الجزء الأول من المقالة ، لاحظت أن الثابت يتحلل بعملية منفصلة ، وأن خريطة الإصدار فقط تترك مع رمز PHP. عندما ننشئ إصدارًا جديدًا من MDK ، فإننا نبلغ المستودعات المفقودة بالملفات ، والتي لا يتم حذف أي شيء منها (هناك مساحة كبيرة ، لا مانع لدينا). وكثيراً ما نقدم أفضل ما يمكن للتدريج ، وبالتالي فإن خريطة الإصدار الثابتة هي واحدة من تلك الملفات التي تتغير أكثر من غيرها. كل هذا أدى إلى حقيقة أننا واجهنا تصادمًا. بعد التحقق من الإصدار ، قررت MDK أن كل شيء على ما يرام ، لأن ملفًا من هذا الإصدار موجود بالفعل ، ووضعه على الخوادم. من الجيد أننا اكتشفنا الخطأ بسرعة.
الآن ، بالإضافة إلى الإصدار ، نتحقق من حجم الملف: إذا كان هو نفسه في المستودع ، فمن المرجح أنه الملف نفسه. في أسوأ الأحوال ، سيكون لدينا قصة لمقال جديد.
MDK - عيد الميلاد اللص
الصورة: المصدروأريد أن أخبركم عن خطأ آخر ، لأنه على الأقل مضحك. من السهل تخمين أنه كان لدينا عملية تنظيف الإصدارات القديمة من الملفات على خوادم الوجهة. في محاولة لحل إحدى المشكلات بسرعة ، اتخذنا قرارًا مصيريًا: حدد فترة التنظيف على يوم واحد (بدلاً من سبعة ، كما كان من قبل). عملت - وذهبت المشكلة. لقد عشنا لفترة من الوقت.
في حوالي الساعة الخامسة من صباح يوم الأحد ، رن هاتف في غرفة نومي ، ورن جهاز المراقبة عند الاتصال: "النصوص لا تعمل بالنسبة لنا. يقولون أنك تعرف ما هو الأمر ". بالنسبة لي ، بدا وكأنه "في المكتب ، احترقت العصارة. يقولون أنك تعرف ما هو الأمر ". لم أكن أعرف سوى مبادئ إطار البرمجة النصية لدينا من المقالات والقصص ، ولم يكن لدي أي "علاقات شخصية" معه ، والأكثر من ذلك ، لم أصلحه أبداً. لكنني صعدت إلى الخوادم لمعرفة ما كان يحدث ، ووجدت أن المشكلة كانت حقًا "في جانبنا": ببساطة لم يكن هناك رمز على الخوادم.
لقد حمّلت الرمز مرة أخرى - وقد نجحت. بالمناسبة ، اتضح أن الخطأ بدائي: يوم السبت ، لم يتم وضع نسخة جديدة واحدة من MDK ، ولم يقم برنامج التنظيف ، كما اتضح ، بأي فحوصات لعدم حذف الإصدار الحالي. ونتيجة لذلك ، قام في الخامسة صباحًا (وفقًا لجدول زمني) بحذف الرمز من جميع الخوادم. بعد هذه القصة ، أدركنا أنه مع الإعدادات القديمة ، ستظهر في أيام العطل 7 أيام ، على سبيل المثال ، في أيام رأس السنة الجديدة ، فقط في ليلة عيد الميلاد. "ولد المسيح - ذهب الكود" - لفترة طويلة كنا نسمع هذه النكتة.
نظام التصحيح الجديد
في النهاية ، قدمنا نظام تخطيط جديد - وحان الوقت لإعادة نظام التصحيح. لم تعد هناك حاجة إلى mscp ولا حاجة لتجنب إنشاء إصدارات جديدة. أولاً ، قمنا بتغيير دورة حياة الرقعة. الآن ، بعد تأكيد التغييرات ، يعود إلى المطور ، الذي يتخذ قرارًا عندما يكون التصحيح جاهزًا للحساب. ينقر على زر النشر ، وبعد ذلك نضيف التصحيح لإتقان ، وإنشاء ونشر إصدار جديد من MDK. لم تعد مشاركة المطور في هذه المرحلة مطلوبة.
لقد حققنا سرعة تخطيط جيدة للغاية: تصل التغييرات إلى الخوادم في دقيقة واحدة حرفيا. للقيام بذلك ، ومع ذلك ، كان علينا أن نلجأ إلى حيلتين: على سبيل المثال ، ما زلنا لا ننشئ إحصاءات أو ترجمات - بدلاً من ذلك ، نأخذ الإصدار من آخر بنية متحللة. وبسبب هذا ، نحافظ على قيود على التصحيحات لملفات JS و CSS.
التجارب
تمكنا حقا من حل جميع المشاكل التي كانت لدينا من قبل. لم تعد بحاجة إلى التفكير في كيفية تشكيل التغييرات بشكل صحيح ، والتي لن تسبب صعوبات في تخطيط الملف تلو الآخر - فقط لا تلمس الإحصاءات ، وسيعمل كل شيء.
ولكن ظهرت صعوبة جديدة. في السابق ، سمحنا للمطورين بنشر تغييراتهم على خادم واحد أو أكثر ، فقط للتأكد من أن كل شيء سيعمل معهم. مع النظام الجديد ، اختفت هذه الميزة ، لأن النسخة الرئيسية أصبحت الآن الإصدار الحالي لجميع الخوادم ، دون استثناء.
الصورة: المصدروبسبب هذا ، ظهر متطلب جديد لنظام التصحيح: أنت بحاجة إلى القدرة على التحقق من تغييراتك على عدد صغير من الخوادم دون إضافة تغييرات إلى الرئيسية. أطلقنا على تجارب الوظائف الجديدة.
بالنسبة للمطور ، تبدو العملية على هذا النحو: بعد تلقي الترقية ، تصبح صفحة جديدة متاحة في واجهة نظام التصحيح حيث يمكنك تحديد الخوادم التي تريد التجربة عليها. يمكن أن تكون مجموعة من الخوادم أو خادم واحد أو أي مجموعة سيفهمها نظامنا. يقوم النظام بنشر التصحيح وإخطار المطور. في الوقت نفسه ، يظهر على الصفحة سجل لأحدث الأخطاء من الخوادم المتأثرة.
نحن لا نقيد المطورين بأي شكل من الأشكال ؛ يمكنهم إنشاء تجارب على الخوادم نفسها. يمكن للمرء تجربة مجموعة 10٪ ، والآخر على المجموعة بأكملها.
أصبح هذا ممكنًا بسبب حقيقة أن لدينا "نسخة من التصحيحات" التي افتقرنا إليها كثيرًا. هذا إصدار قد يكون نظريًا فريدًا لكل خادم. يبدو أن سلسلة من المعرفات مفصولة بفواصل ، على سبيل المثال ، "32،45،79". هذا يعني أنه يجب أن يكون لدى الخادم كافة التغييرات من المعالج والتصحيحات المرقمة 32 و 45 و 79. لكل إصدار من هذا النوع ، نقوم بإنشاء نسختنا الخاصة من MDK. نأخذ أحدث التغييرات من الفرع الرئيسي ، ثم نقوم بتطبيق كل بقع على التوالي. إذا نشأ تعارض أثناء إنشاء أحد الإصدارات ، فإننا ببساطة نلغي تجربة أحدث التصحيح ونُخطر المطور.
الملفات التي تم إنشاؤها
منذ اليوم الأول من وجود نظام التصحيح ، ذهبنا إلى الحيلة: رفضنا إنشاء ثابت بحيث تصل التغييرات إلى الخوادم في أسرع وقت ممكن. بالطبع ، أردنا حقًا الحصول على فرصة لتغيير كود JS بنفس الطريقة التي نغير بها كود PHP ، لكن كل محاولات بناء هذه العملية باءت بالفشل.
منذ حوالي ستة أشهر ، عدنا مرة أخرى إلى هذه المشكلة. الغرض: أنت بحاجة إلى تغيير الإحصائيات ، ولكن لا يمكنك التضحية بسرعة تخطيط كود PHP. المشكلة الرئيسية: يستغرق التجميع الكامل ثماني دقائق. ماذا تفعل
عليك المساومة. بدأنا بحقيقة أنه لا يمكن وضع كود JS كجزء من التجارب. من المفترض أن يوفر ذلك الكثير من الوقت: ما عليك سوى إبقاء إصدار واحد من الإحصاءات ثابتًا بدلاً من إنشاء العشرات من الإصدارات المختلفة لمجموعات مختلفة من الأجهزة. لكنها لا تزال طويلة. ماذا يمكنك حفظه؟ لم نكتشف كيفية تقليل الوقت ، لكننا قررنا أنه لن تكون هناك مشكلة إذا لم يحظر التجميع تخطيط كود PHP.
بدأنا في توليد الإحصائيات بشكل غير متزامن. مع التغييرات على ملفات JS أو CSS ، نبدأ عملية منفصلة تنشئ خريطة جديدة للإصدارات الثابتة. تتحقق عملية تجميع كود PHP في بداية العمل لمعرفة ما إذا كانت هناك خريطة ثابتة جديدة ، وإذا كانت هناك واحدة ، تلتقطها وتضعها على جميع الخوادم. هل قمت بحل المشكلة؟ عمليا. مع هذا النهج ، ذهبنا إلى قيود جديدة: لا يمكنك تغيير كود JS و PHP في تصحيح واحد ، لأننا نحلل هذه التغييرات بشكل غير متزامن ولا يمكننا ضمان أنها ستكون على الأجهزة في نفس الوقت.
الملخص
نحن سعداء للغاية بالتحديث. لم يكن الأمر سهلاً بالنسبة لنا ، ولكنه جعل نظامنا أكثر موثوقية. عثر المطورون على تطبيق بديل للتجارب: معهم يمكنك بسهولة جمع سجلات محددة من زوج من الخوادم دون إضافة تغييراتك إلى الرئيسية.
لا تزال لدينا أفكار لتحسين النظام ، والتي لم يتم تنفيذها حتى الآن. على سبيل المثال ، نريد إعادة عملية إنشاء التصحيح وإضافة القدرة على تغيير ملفات JS في نفس وقت الرمز الرئيسي للتخلص من أحدث القيود.
ننشر كل يوم حوالي 60 تصحيحًا ، وأحيانًا يكون هناك عدة مرات أكثر ، على سبيل المثال ، أثناء تطوير بعض الوظائف المتاحة فقط للمختبرين حتى الآن. يمر حوالي ثلث البقع بالتجارب قبل وضعها. في المجموع ، خلال وجود النظام ، كان لدينا حوالي 46000 بقع للسيد.