في حديثي ، تذكرت تطور Python في الشركة: من الخدمات الأولى المعبأة في حزم ديب وتنتشر على المعدن العاري ، إلى مستودع أحادي معقد مع نظام البناء الخاص به والسحابة. المزيد في القصة سيكون Django و Flask و Tornado و Docker و PyCharm و IPv6 وغيرها من الأشياء التي واجهناها على مر السنين.
- دعني أحدثك عن نفسي. جئت إلى Yandex في عام 2008. في البداية قمت بخدمات المحتوى ، وخاصة Yandex.Afisha. لقد كتبت هناك في Python ، أعادنا كتابة الخدمة من Perl وتقنيات المرح الأخرى.
ثم تحولت إلى الخدمات الداخلية. تم تحويل قسم الخدمات الداخلية تدريجيًا إلى إدارة واجهات البحث والخدمات للمؤسسات. لقد مر وقت طويل ، من مطور بسيط ، نمت إلى رأس تطوير بيثون لوحدتنا ، حوالي 30 شخصًا.
نقطة مهمة: الشركة كبيرة جدًا ، ولا يمكنني التحدث باسم Yandex. أتواصل بالطبع مع الزملاء من الأقسام الأخرى ، وأعرف كيف يعيشون. ولكن في الأساس يمكنني فقط التحدث عن قسمنا ، عن منتجاتنا. سيركز تقريري على هذا. أحيانًا أقول لك إنهم يفعلون ذلك وذاك في مكان آخر في ياندكس. لكنها لن تكون في كثير من الأحيان.
يتم استخدام Python في العديد من الأماكن في الشركة: أي تقنية ، أي تكديس تكنولوجيا ، أي لغة. كل ما يتبادر إلى الذهن هو في مكان ما في الشركة ، إما كتجربة أو أي شيء آخر. وفي أي خدمة من خدمات Yandex ، سيكون هناك بالتأكيد Python في مكون واحد أو آخر.
كل ما سأخبرك به هو تفسيري للأحداث. أنا لا أتظاهر بأنني موضوعية مائة بالمائة. كل هذا مر من خلال يدي ، كان ملونًا عاطفيًا. كل خبرتي شخصية للغاية.
كيف سيتم هيكلة التقرير؟ لتسهيل إدراك المعلومات ، ولكي أقول ، قررت تقسيم التطور بأكمله من عام 2007 حتى حول اللحظة الحالية إلى عدة عصور. سيتم تنظيم التقرير بدقة من خلال هذه العصور. العصر يعني نوعًا من التغيير الجذري في البنية التحتية أو نهج التنمية. إذا تغيرت البنية التحتية للحديد لدينا وفي نفس الوقت قمنا بتغيير كيفية تطوير الخدمات ، وما هي الأدوات التي نستخدمها ، فهذه حقبة. من الواضح أنني اضطررت إلى التكيف قليلاً. من الواضح أن كل شيء لم يحدث بشكل متزامن ، وكانت هناك فجوات بين هذه التغييرات ، لكنني حاولت ملاءمة كل شيء في إطار زمني واحد ، فقط لجعله أكثر إحكاما.
ما هي العهود التي امتلكناها؟ هنا أيضًا ، كل شيء له حقوق طبع ونشر ، جميع الأسماء لي. العصر الأول يسمى "الحديد" ، حيث بدأنا عندما جئت إلى الشركة. لأن كل شيء تغير قليلاً. أصبح العصر "حديد + venv". علاوة على ذلك سأكشف ما هو مخفي وراء هذه الأسماء. أولاً ، أريد أن أعطيك دليلاً حول ما سأخبرك به.
العصر التالي هو "حاويات" ، كل شيء أكثر أو أقل وضوحًا هنا. العصر الذي نتحرك فيه الآن هو "التجمع الثنائي" ، وسأخبرك عنه أيضًا.
كيف سيتم هيكلة كل عصر؟ هذا مهم أيضًا ، لأنني أردت أن أقوم بسرد إيقاعي ، بحيث يكون كل قسم منظمًا بشكل صارم ويسهل فهمه. يتم وصف العصر بالبنية التحتية ، والأطر التي نستخدمها ، وكيف نعمل مع التبعيات ، ونوع بيئة التطوير التي لدينا ، وإيجابيات وسلبيات هذا النهج أو ذاك.
(وقفة فنية). أخبرتك المقدمة ، أخبرتك كيف سيتم هيكلة التقرير ، دعنا ننتقل إلى القصة نفسها.
العمر 1: حديد
أول خدمة بدأتها عندما انضممت إلى الشركة كانت تسمى "أين يذهب الجميع". كان القمر الصناعي Afisha ، أول خدمة Django كبيرة.
جريشا باكونوفبوبوكيمكنه أن يعرف لماذا قرر ذات مرة نقل Django إلى Yandex - بشكل عام ، حدث ذلك. بدأنا في تقديم الخدمات في Django.
جئت ، وقالوا لي: دعنا نفعل "أين يذهب الجميع". ثم كان هناك بالفعل نوع من القاعدة. لقد اتصلت ، واعتبرناها نوعًا من التجربة - هل ستنجح أم لا. كانت التجربة ناجحة. اتفق الجميع على أنه من الممكن إنشاء خدمات الويب في Yandex في Python و Django. غرامة! بنيتنا التحتية جاهزة لذلك ، الناس جاهزون ، والعالم جاهز أيضًا. دعنا نذهب ، دعونا نوزع Python و Django بشكل أكبر في جميع أنحاء الشركة. بدأنا في القيام بذلك. إعادة كتابة Yandex.Afisha ، الطقس. ثم - البرنامج التلفزيوني. ثم سار كل شيء مثل الضباب ، وبدأوا في إعادة كتابة كل شيء.
وبحلول ذلك الوقت ، بدت البنية التحتية لـ Yandex وكأنها تمت كتابة الخلفية بالكامل بشكل أساسي على المحترفين. من الواضح أن التحرك نحو Python أدى إلى تسريع التطوير كثيرًا في العديد من الأماكن ، وقد لقي هذا الأمر استقبالًا جيدًا من قبل الشركة والإدارة. دعونا نتحدث الآن عن البنية التحتية - حيث عملت هذه الخدمات ، وما كانت تدور حوله وكل ذلك.
كانت هذه آلات حديد ، ومن هنا جاء اسم هذه الحقبة. ما هي ماكينات الحديد؟ هم مجرد خوادم في مركز البيانات. هناك العديد من الخوادم ، يتم دمجها جميعًا في مجموعة من 15 جهازًا ، على سبيل المثال. ثم كان هناك 30 ، ثم 50 ، 100. وكل هذا على Debian أو Ubuntu. بحلول ذلك الوقت ، كنا قد هاجرنا من دبيان إلى أوبونتو. أطلقنا جميع التطبيقات من خلال عملية التهيئة القياسية. كان كل شيء قياسيًا ، كما حدث في ذلك الوقت. لتطبيقاتنا للتواصل على خادم الويب ، استخدمنا بروتوكول FastCGI ومكتبة flup. إذا كنت تستخدم Python لفترة طويلة ، فربما سمعت به. لكن الآن ، أنا متأكد من أنك لا تستخدمه ، لأنه عفا عليه الزمن وكان شيئًا غريبًا للغاية ، لقد عمل ببطء شديد.
في تلك اللحظة ، من الواضح ، لم يكن هناك Python ثالث ، كتبنا في Python 2.3. ثم هاجروا إلى 2.4. الأوقات البرية. لا أريد حتى أن أفكر فيها ، لأن اللغة والمجتمعات والنظام البيئي بدت مختلفة تمامًا ، على الرغم من أنها كانت رائعة أيضًا ، وقد جذبها الكثيرون في ذلك الوقت. أنا شخصياً غمرني في عالم Python - حتى على الرغم من خصوصياته وغرائبه ، كان من الواضح بالفعل أن Python هي تقنية واعدة ، يمكنك استثمار وقتك هناك.
نقطة مهمة: لم نستخدم nginx بعد ، ولم نعد نستخدم Apache بعد الآن ، ولكن استخدمنا خادم ويب يسمى Lighttpd. إذا كنت تقوم بعمل خدمات الويب لفترة طويلة ، فمن المحتمل أنك سمعت عنها أيضًا. في مرحلة ما ، كان يتمتع بشعبية كبيرة.
من الأطر ، استخدمنا بالفعل جانغو. بدأنا في تقديم خدمات كبيرة في Django. في مكان ما في الشركة كان CherryPy ، في مكان ما - Web.py. ربما سمعت عن هذه الأطر أيضًا. الآن هم ليسوا في الطليعة ، منذ فترة طويلة تم دفعهم إلى الوراء من قبل الأطر الأصغر والأكثر جرأة. ثم كان لديهم مكانة خاصة بهم ، ولكن في النهاية ماتوا عاجلاً أم آجلاً ، توقفنا عن فعل أي شيء عليهم. بدأوا يفعلون كل شيء في جانغو.
في هذه المرحلة ، انتشرت Python على نطاق واسع في الشركة لدرجة أنها امتدت خارج نطاق قسمنا: بدأت خدمات الويب في Python و Django في كل مكان في الشركة.
دعنا ننتقل إلى العمل مع التبعيات. ثم هناك شيء كنت على الأرجح واجهته أيضًا إذا أتيت للعمل في شركة كبيرة: تمتلك الشركة بالفعل بنية تحتية راسخة ، تحتاج إلى التكيف معها. كان لدى Yandex بنية أساسية deb ، ومستودعات داخلية لحزم deb. كان يعتقد أن مطور Yandex كان يعرف كيفية تجميع حزمة deb هذه. اضطررنا إلى الاندماج في هذا التدفق ، وجمعنا مشاريعنا في شكل حزم ديون كاملة ، ثم ، كحزمة ديون ، وضع كل هذا على الخوادم التي كنت أتحدث عنها ، ثم وضعناها في مجموعات في شكل حزم ديب.
نتيجة لذلك ، كل التبعيات والمكتبات ، نفس Django ، كان علينا أيضًا حزمها في حزم deb. للقيام بذلك ، قمنا بإنشاء بنيتنا التحتية الخاصة بنا ، ورفعنا المستودع الداخلي ، وتعلمنا كيفية القيام بذلك. هذا ليس نشاطًا أصليًا للغاية: إذا حاولت إنشاء RPM أو حزمة deb ، فأنت تعرف ذلك. العائد لكل ألف ظهور أبسط قليلاً ، فالديب أكثر تعقيدًا. ولكن كل نفس - لن تتمكن من القدوم من الشارع والبدء في القيام بذلك عند النقر. تحتاج إلى حفر قليلا.
لقد تم بناء حزم ديون لسنوات عديدة بعد ذلك. ويبدو لي أنه ليس كل من فعل هذا من أجل العمل يحتاج إلى فهم ما كان يحدث تحت غطاء المحرك. أخذوا ببساطة من بعضهم البعض ، ونسخ الفراغات ، والقوالب ، ولم يحفروا بعمق. لكن أولئك الذين حفروا ما يجري في الداخل أصبحوا مفيدين ومطلوبين للغاية: إذا لم يكن هناك شيء سيحدث فجأة ، ذهب الجميع إليهم للحصول على المشورة وطلبوا الفروق الدقيقة والمساعدة في تصحيح الأخطاء. لقد كان وقتًا ممتعًا لأنني كنت مهتمًا بمعرفة ما بداخله. وهكذا ، حصل على شعبية رخيصة بين الزملاء.
إلى جانب النظام البيئي للتبعيات ، هناك أيضًا عمل مع التعليمات البرمجية المشتركة. بالفعل في البداية كان هناك نمو هائل في عدد المشاريع ، وكان مطلوبًا للعمل مع التعليمات البرمجية المشتركة ، وإنشاء مكتبات مشتركة ، وما إلى ذلك. بدأنا القيام بهذا النوع من المصادر المفتوحة الداخلية. أجرينا المهام العامة للتفويض ، والعمل مع السجلات ، مع الأشياء الشائعة الأخرى ، وواجهات برمجة التطبيقات الداخلية ، والمستودعات الداخلية. لقد فعلنا كل هذا في شكل مكتبات ، ووضعناه في المستودع الداخلي. في البداية ، كانت هذه مستودعات SVN ، ثم GitHub الداخلية.
وفي النهاية قاموا بتعبئة كل هذه التبعيات ، كل هذه المكتبات أيضًا في حالة تحميل ، في مستودع واحد. من هذا ، تم تشكيل بيئة الحزمة هذه. إذا بدأت مشروعًا جديدًا ، فيمكنك وضع العديد من المكتبات هناك ، والحصول على قاعدة من الوظائف ، وإطلاق المشروع على الفور في البنية التحتية لـ Yandex. كانت مريحة للغاية.
كيف يبدو خادمنا النموذجي؟ بشكل كلاسيكي. هناك تبعيات النظام ، وهناك تبعيات وتطبيقات الثعبان. يتبع عدة أشياء من هذا. بادئ ذي بدء ، يجب أن يكون لجميع التطبيقات التي تعمل على نفس الخادم ، وبالتالي على نفس الكتلة ، نفس التبعيات. لأنه إذا قمت بتثبيت نظام حزمة ، فهو دائمًا من نفس الإصدار ، فلا يمكن أن يكون هناك العديد منها ، يجب عليك المزامنة.
عندما يكون هناك عدد قليل من المشاريع ، لا يزال من الممكن القيام بذلك بطريقة أو بأخرى. عندما يكون هناك الكثير ، يصبح كل شيء معقدًا للغاية. إنها مصنوعة من فرق مختلفة ، ويصعب عليهم الاتفاق. يرغب كل فريق في الترقية مبكرًا إلى بعض المكتبات أو يرغب في ترقية إطار العمل. ويجب على الجميع اتباع هذا. بمرور الوقت ، يخلق هذا الكثير من المشاكل. هذا دفعنا إلى التخلي عن مثل هذا المخطط ، والانتقال إلى الحقبة التالية. ولكن سأتحدث عنه بعد ذلك بقليل.
لنتحدث عن بيئة التطوير. ولكن هناك مثل هذا الفهم الموسع لبيئة التنمية. هذه هي الطريقة التي تأتي بها إلى العمل ، وكيف تكتب التعليمات البرمجية ، وكيف تقوم بتصحيحها ، وكيف تتعامل معها ، وأين تختبرها ، وكيف تقوم بتشغيلها ، وأين تجري الاختبارات وكل ذلك.
عندما انضممت إلى الشركة ، كنا جميعًا نعمل على خوادم التطوير عن بُعد. بمعنى ، لديك نوع من سطح المكتب ، على Windows أو Linux ، لا يهم. انتقل إلى الخادم البعيد حيث تم تثبيت دبيان الصحيح ، حيث تم توصيل مستودع الحزمة الصحيح. وأنت تعمل ، تشغيل vim ، Emacs ، كتابة التعليمات البرمجية ، القيام بالتصحيح.
إنها ليست مريحة للغاية ، ولكن بعد ذلك لم نكن نعرف حقًا حياة أخرى. أولئك الذين يحالفهم الحظ بما يكفي لامتلاك سطح مكتب Linux أو كمبيوتر محمول قد يحاولون القيام بذلك محليًا. ولكن لم تكن هناك تعليمات خاصة أيضًا ، لا شيء. مثل هذا الوقت الوحشي قليلا. قام أشخاص مميزون عاشوا في ذلك الوقت على نظامي التشغيل Windows و Mac وأرادوا التطوير محليًا برفع جهاز افتراضي ، بداخله Linux. كتبوا رمزًا داخل هذا الجهاز الافتراضي ، وأداروه. بتعبير أدق ، كتبوا الرمز على النظام المضيف ، وأطلقوا الرمز داخل الجهاز الظاهري وأعادوا بطريقة ما نظام الملفات بحيث تتم مزامنة كل شيء. كل هذا عمل بشكل سيء للغاية ، لكنه نجا بطريقة أو بأخرى.
ما هي إيجابيات وسلبيات هذا العصر ، هذا النهج في التنمية؟ في الواقع - السلبيات الصلبة:
- كما قلت ، كانت التجمعات العامة ضيقة.
- يجب أن يكون لجميع المشاريع في المجموعة نفس التبعيات.
- . , , Django . , . 15-20 . . , , — . X, . , . - , - , . . , , . .
- كانت ياندكس تعتمد على البنية التحتية لديبيان. دعمناها ، بنينا الحزم ، حافظنا على مستودع داخلي. وهذا ، بالطبع ، ليس جيدًا جدًا ، ولا مناسبًا جدًا ، وغير مرن جدًا. أنت تعتمد على أشياء غريبة لم تتم من أجل الشركة. Debian كحل مفتوح المصدر ، كتوزيع Linux ، تم مع ذلك لمهام أخرى.
لنتحدث أكثر عن جانغو. لماذا بدأنا في استخدامه؟ لقد فكرت قبل التقرير ، أثناء الجلوس على كرسي ، اتضح أنه قبل 11 عامًا تحدثت في مؤتمر في كييف حول نفس الموضوع "لماذا يجب أن أستخدم Django؟" ثم أحببتها بنفسي. لقد كنت مطورًا معجباً بقراءة الوثائق ، وعمل مشروعي الأول ، ويبدو له أن كل شيء ، الآن هذه الأداة عالمية لكل شيء ويمكنك ، حتى لا أعرف ، أن تدق المسامير عليها.
لكن الأمر استغرق وقت طويل. ما زلت أحب Django ، لا يزال يستخدم كثيرًا في قسمنا وفي الشركة بشكل عام. على سبيل المثال ، حتى قبل خريف عام 2018 ، كان لدى أليس Django في الواجهة الخلفية. الآن لم تعد موجودة ، ولكن من أجل البدء بسرعة ، اختارها زملاؤها. نظرًا لأن بعض المزايا لا تزال صالحة - نظام بيئي كبير ، لا يزال هناك العديد من المتخصصين. هناك كل البطاريات التي تحتاجها.
وهناك مرونة كافية. عندما تبدأ العمل مع Django لأول مرة ، يبدو لك أنه يحدّك كثيرًا ، ويربط بين يديك ، ويتطلب تدفقًا معينًا للعمل معه. ولكن إذا تعمقت كثيرًا ، فيمكن تعطيل العديد من الأشياء وتغييرها وتكوينها. وإذا كنت تستخدم هذا بمهارة ، يمكنك الحصول على جميع الأشياء الجيدة المرتبطة بإطار عمل Python الأكثر شيوعًا. يمكنك تجاوز جميع السلبيات. هناك أيضًا العديد منها ، ولكن يمكن إيقافها بطريقة أو بأخرى.
العمر 2: حديد + venv
انتهينا من الحديث عن هذه الحقبة. لقد انتهى عام 2011 ، انتقلنا إلى الحقبة التالية ، "Iron + venv". أنت تعرف بالفعل عن الأجهزة ، والآن تحتاج إلى معرفة ما حدث ، من أين يأتي اسم venv. الانحدار الغنائي: لم تنشأ venv لأن الأجهزة الافتراضية ظهرت. لماذا في الاقتباسات؟ لأننا بدأنا في تجربة جميع أنواع الأشياء الشبيهة بالحاويات مثل OpenVZ أو LXC. ثم كانت سيئة للغاية ، ليس مثل الآن. لم يطيروا معنا حقا. ما زلنا نعيش في مجموعات مشتركة ، لا يزال علينا أن نكون مع مشاريع أخرى جنبا إلى جنب على نفس الآلات. كنا نبحث عن حل.
على سبيل المثال ، لقد تحولنا من init إلى upstart systemd ، وبعد ذلك بقليل حصلنا على المرونة في تشغيل تطبيقاتنا. لقد تخلينا عن FastCGI وبدأنا في استخدام واجهة WSGI للتواصل مع خادم الويب أو HTTP. في هذه المرحلة ، كنا بالفعل نستخدم Python حديثًا تقريبًا ، كان النظام البيئي متطورًا بالفعل. تحولنا إلى nginx كخادم ويب ، بشكل عام ، لم يكن كل شيء سيئًا.
بدأنا أيضًا في تكييف أطر عمل جديدة لأنفسنا. على سبيل المثال ، بدأ استخدام Tornado. بالطبع ، بحلول ذلك الوقت ، ظهر Flask بالفعل ، بعد 2012 كان Flask عصريًا جدًا وشائعًا وهدد Django بالتخلص من قاعدة الأطر الشعبية في Python. وبالطبع ، بدأوا في استخدام الكرفس. لأنه عندما تنمو المشاريع ، ينمو عددهم ، يصبحون أكثر تحميلًا ، ويحلون المزيد من المشاكل ، ويعالجون المزيد من البيانات ، ثم تحتاج إلى إطار لتنفيذ المهام دون اتصال على مجموعة حوسبة كبيرة. بالطبع ، بدأنا في استخدام الكرفس لهذا الغرض. ولكن أكثر عن ذلك لاحقا.
ما تغير بشكل كبير هو العمل مع التبعيات. بدأنا في جمع بيئة افتراضية. في ذلك الوقت ، وصل مجتمع الثعبان إلى نقطة أنه من الممكن عدم وضع مكتبات الثعبان في النظام ، ولكن لإنشاء بيئة افتراضية ، ووضع جميع تبعيات الثعبان التي تحتاجها هناك ، وستكون هذه البيئة مستقلة تمامًا. يمكن أن يكون هناك العديد من البيئات الافتراضية على الجهاز. هذا عزلة ، إدمان مريح للغاية. ما زلت تستخدمه. وقمنا أيضًا بتكييف كل شيء. ونتيجة لذلك ، ماذا فعلنا؟ لقد أنشأنا بيئة افتراضية ووضعنا كل تبعيات الثعبان هناك ، وحزمها في حزمة deb وقمنا بالفعل بتدويرها إلى الخادم.
ونتيجة لذلك ، توقفت جميع المشاريع عن التدخل في بعضها البعض ، وتعتمد على تبعية الثعبان الشائعة في النظام ، ويمكنها بسهولة اختيار أي إصدار من الإطار أو المكتبة لاستخدامها. هذا مناسب جدا. حدثت تغييرات في الرمز المشترك أيضًا. نظرًا لأننا تخلينا جزئيًا عن البنية التحتية لـ Debian ، وعلى وجه الخصوص ، توقفنا عن تثبيت تبعيات الثعبان مع حزم deb ، فقد كنا بحاجة إلى شيء يمكننا من خلاله إلغاء تحميل جميع شفراتنا المشتركة والمكتبات المشتركة ومن أين يمكننا وضعها.
رابط من الشريحة
بحلول ذلك الوقت ، كان هناك بالفعل العديد من تطبيقات PyPI ، أي مستودع حزم بايثون ، تطبيقات مكتوبة ، على وجه الخصوص ، في Django. واخترنا واحد منهم. يطلق عليه Localshop ، إليك رابط... هذا المستودع لا يزال على قيد الحياة ، لديه بالفعل حوالي ألف حزمة داخلية. أي ، من حوالي 2011-2012 ، قامت شركة بحجم Yandex بتوليد حوالي ألف مكتبة مختلفة ، أدوات مساعدة مكتوبة في Python ، والتي يعتقد أنها يمكن إعادة استخدامها في مشاريع أخرى. يمكنك تقدير الحجم.
يتم نشر جميع المكتبات في هذا المستودع الداخلي. ثم من هناك يتم تثبيتها في Python ، أو هناك بنية تحتية آلية خاصة تحولها إلى دبيان. كل شيء أكثر أو أقل مؤتمت وملائم. توقفنا عن إهدار الكثير من الموارد للحفاظ على البنية التحتية لديبيان. عملت بشكل أو بآخر نفسها.
وهذه خطوة نوعية. هنا رسم تخطيطي مع ما كنت أتحدث عنه.
وهذا يعني أن التبعية للحيوانات الأليفة توقفت في النهاية عن كونها هي نفسها للجميع. لا يزال النظام موجودًا ، ولكن ليس كثيرًا. على سبيل المثال ، برنامج تشغيل لقاعدة بيانات ، محلل XML يتطلب ثنائيات النظام. بشكل عام ، في ذلك الوقت لم نتمكن من التخلص من هذه التبعيات.
كما تغيرت بيئة التطوير. منذ venv ، أصبحت البيئة الافتراضية متاحة وعملت في كل مكان في ذلك الوقت ، يمكننا بناء مشروعنا بشكل عام على أي منصة محلية. هذا جعل الحياة أسهل بكثير. لم تعد هناك حاجة للعبث مع دبيان بعد الآن ، فلا حاجة لعمل أجهزة افتراضية. يمكنك فقط استخدام أي نظام تشغيل ، مثل venv الظاهري ، ثم تثبيت شيء. وعملت.
ما هي مزايا هذا المخطط؟ نظرًا لأننا عشنا لفترة طويلة - ربما أكثر من ثلاث سنوات بقليل - مع هذا التكوين من المعلمات ، فقد أصبح من الأسهل العيش في مجموعات بيوت الشباب. انها حقا مريحة. أي أننا توقفنا اعتمادًا على هذه التحديثات العالمية لبعض Django في جميع أنحاء الشركة. يمكن تحديد الإصدارات المناسبة لنا بشكل أكثر دقة ، في كثير من الأحيان تحديث التبعيات الحرجة إذا تم إصلاح نقاط الضعف أو أي شيء آخر. وكانت هناك طريقة صحيحة للغاية ، لقد أحببناها وأنقذنا الكثير من كل شيء.
ولكن كانت هناك أيضًا عيوب. تبعيات النظام لا تزال شائعة. في بعض الأحيان أطلقت ، وأحيانًا اعترضت الطريق. مرة أخرى ، سوف أتجاوز نطاق قسمنا قليلاً وأخبرك عن الشركة. نظرًا لأن الشركة كبيرة ، فلا يواكب الجميع هذه العصور معنا. في ذلك الوقت ، استمرت الشركة في استخدام حزم الديون للعمل مع تبعيات التبعية. دعني أخبرك بمزيد من التفصيل لماذا بدأنا في استخدام هذه أو تلك الأطر. على وجه الخصوص ، تورنادو.
نحن بحاجة إلى إطار غير متزامن ، لدينا الآن مهام لذلك. لم يكن Python الثالث و Asyncio موجودًا حتى الآن ، أو كانا في حالة أولية ، ولم يكن استخدامهما موثوقًا بعد. لذلك ، حاولنا اختيار أي إطار غير متزامن لاستخدامه. كانت هناك عدة خيارات: جيفنت و الملتوية. على الأرجح ، كان هناك المزيد منهم ، لكننا اخترنا من بينها. تم استخدام Twisted بالفعل من قبل الشركة - على سبيل المثال ، تمت كتابة الواجهة الخلفية لـ Yandex.Taxi في Twisted. لكننا نظرنا إليهم وقررنا أن Twisted لا تبدو بيثونية ، حتى PEP-8 لا يتوافق. وجيفنت - هناك نوع من الاختراق مع كومة ثعبان في الداخل. دعونا نستخدم إعصار.
لم نأسف لذلك. ما زلنا نستخدم تورنادو في بعض الخدمات - في تلك الخدمات التي لم نعيد كتابتها بعد في بايثون الثالثة. أثبت الإطار على مر السنين أنه مضغوط وموثوق ويمكن الاعتماد عليه.
وبالطبع الكرفس. لقد أخبرت بالفعل جزئيا عن هذا. كنا بحاجة إلى إطار للتنفيذ الموزع للمهام المؤجلة. حصلنا عليه.
كان من الملائم جدًا أن يقدم الكرفس الدعم لمختلف الوسطاء. استخدمنا هذا ب بنشاط للمهام المختلفة في محاولة للعثور على وسيط صحيح أو آخر. في مكان ما كان مونغو ، في مكان ما SQS ، في مكان ما Redis. لكننا حاولنا الاختيار حسب الحاجة ونجحنا.
على الرغم من حقيقة أن هناك العديد من الشكاوى حول الكرفس ، وكيف يتم كتابتها بالداخل ، وكيفية تصحيحها ، ونوع تسجيل الدخول ، فإنها تعمل بالأحرى. لا يزال الكرفس مستخدمًا بنشاط في كل مشروع تقريبًا في قسمنا ، وعلى حد علمي ، خارج مشروعنا. الكرفس - يجب أن يكون. إذا كنت بحاجة إلى تنفيذ مؤجل للمهام ، فسيأخذ الجميع الكرفس. أو في البداية لا يأخذونها ، يحاولون أخذ شيء آخر ، ولكن بعد ذلك يأتون إلى الكرفس.
نذهب إلى الحقبة القادمة. نحن نقترب بالفعل من الوقت الحاضر ، أكثر حداثة. هنا يتحدث اسم العصر عن نفسه.
العمر 3: حاويات
حصلنا على سحابة متوافقة مع عامل الميناء داخليًا. في الداخل ، وليس وقت تشغيل عامل الميناء ، ولكن التطوير الداخلي. ولكن في الوقت نفسه ، يمكن نشر صور عامل الميناء هناك. لقد ساعدنا كثيرًا لأننا كنا قادرين على استخدام النظام الإيكولوجي بالكامل للأرصفة في التطوير والاختبار. يمكننا استخدام جميع أنواع الأشياء الجيدة ، وبعد ذلك ببساطة بعد استلام الصورة المختبرة ، قم بتحميلها على هذه السحابة. بدأت هناك وعملت كما يجب.
بحلول ذلك الوقت ، كنا مستقلين بالفعل عن نظام التشغيل الذي كان داخل الحاوية. يمكنك اختيار أي. بالطبع ، لم نستخدم الشياطين العادية ، ولكن ، على سبيل المثال ، مشرف. بعد ذلك ، تحول الجميع إلى uWSGI - اتضح أن uWSGI لا يعرف فقط كيفية تشغيل تطبيقات الويب الخاصة بك وتوفير واجهة لخادم الويب فيها. كما أنها مجرد شيء عام جيد لبدء العمليات.
ومع ذلك ، هناك تكوين غريب قليلاً ، ولكن بشكل عام ، فهو مناسب. تخلصنا من الجوهر غير الضروري وبدأنا في عمل كل شيء من خلال uWSGI. كما نستخدمه للتواصل مع خادم الويب. إن خصوصيات السحابة لدينا هي أنه لا يمكننا استخدام بروتوكول uWSGI للتواصل مع الموازن ، الذي يتم تمثيله عالميًا في السحابة ، كمكون. لكن هذا ليس مخيفا. داخل uWSGI ، يتم تنفيذ خادم HTTP بشكل جيد ، ويعمل بسرعة وموثوقية.
ماذا عن الأطر؟ ظهر إطار Falcon ، وقمنا بإعادة كتابة Alice نفسها مع Django على Falcon ، لأنه كان هناك عدد معين من apis - كان من الضروري بالنسبة لهم العمل بسرعة ، ولكن في نفس الوقت لم يكونوا معقدين للغاية.
أصبح Django في وقت ما زائدا عن الحاجة ، ومن أجل زيادة السرعة والتخلص من هذه التبعية الكبيرة ، مكتبة كبيرة ، قررنا إعادة كتابتها إلى Falcon.
وبالطبع غير متزامن. بدأنا بكتابة خدمات جديدة في بايثون الثالثة ، وإعادة كتابة الخدمات القديمة في بايثون الثالثة. يوجد فقط في قسمنا حوالي 30 خدمة مكتوبة بلغة Python. هذه 30 منتجًا كاملًا ، مع الواجهة الخلفية ، الواجهة الأمامية ، والبنية التحتية الخاصة بهم. ما تعالج البيانات التي تقدم خدمات لكل من المستهلكين الداخليين والخارجيين.
لكن الشركة ، كما تعلم ، لديها الآلاف من خدمات Python ، وهي مختلفة. هم على أطر مختلفة ، بيثون مختلفة ، أقدم وأحدث. تستخدم الشركة الآن جميع الأطر الحديثة التي تعرفها تقريبًا. جانغو ، قارورة ، فالكون ، شيء آخر ، غير متزامن - إعصار ، ملتوي ، غير متزامن. كل شيء مستخدم ومفيد.
دعونا نعود إلى هيكل العصر - كيف بدأنا العمل مع التبعيات.
كل شيء بسيط هنا. لا يمكننا الآن استخدام البيئة الافتراضية. لا نحتاج إلى حزم ديب. نحن فقط في وقت بناء الصورة مع وضع كل شيء نحتاجه. معزولة تماما. نحن لا نزعج أحدا. ومريحة للغاية. أي تبعيات للنظام ، يمكنك اختيار أي صورة أساسية لـ Debian ، Ubuntu ، أيا كان. نحن نحب. الحرية الكاملة.
لكن في الحقيقة ، الحرية الكاملة ، كما تعلمون ، لها جانب ثان. عندما يكون لديك شركة كبيرة ، وأكثر من ذلك عندما تريد الترويج لطرق وأساليب التطوير الشائعة ، وطرق الاختبار ، وطرق التوثيق - في هذه اللحظة ، تواجه حقيقة أن حديقة الحيوانات هذه ، من جهة ، تساعد في مكان ما. من ناحية أخرى ، على العكس من ذلك ، فإنه معقد. لا يستطيع بسهولة ، على سبيل المثال ، إدخال بعض المكتبة في جميع الخدمات ، لأن الخدمات مختلفة. لديهم إصدارات مختلفة من Python أو Django أو إطار عمل آخر. هذا يعقد الأمور. ولكن في النهاية ، بدأ الخادم النموذجي في الظهور بهذا الشكل.
نعم ، إنه خادم. لدينا حاويات مستقلة تماما. كل واحد منهم لديه بيئة نظام خاصة به ، وتدور تطبيقاتنا. مريح للغاية. ولكن كما قلت ، هناك عيوب.
دعنا نعود إلى عامل الميناء لفترة من الوقت. بدأنا في استخدام عامل الرصيف من أجل التنمية ، لقد ساعدنا كثيرًا.
Docker متاح لجميع المنصات. يمكنك اختبار واستخدام Docker-compose ، وإجراء سرب docker ، ومحاولة محاكاة بيئة الإنتاج الخاصة بك على مجموعات صغيرة لاختبار شيء ما. ربما تحميل الاختبار. بدأنا في استخدام هذا بنشاط.
كما أن Docker متكامل تمامًا مع جميع أنواع بيئات التطوير. على سبيل المثال ، أنا أتطور في PyCharm ، وكذلك معظم زملائي. هناك دعم مدمج لعمال الرصيف ، مع إيجابياته وسلبياته ، ولكن بشكل عام يعمل كل شيء.
لقد أصبحت مريحة للغاية ، لقد خطونا خطوة نوعية ، ونحن في هذه المرحلة نحن الآن. من السهل التطوير باستخدام عامل إرساء ، على الرغم من أن السحابة المستهدفة ، حيث سننشر تطبيقاتنا ، ليست فترة تشغيل Docker كاملة ، لديها بعض القيود. لكن هذا لا يمنعنا من استخدام Docker Engine محليًا وفي المهام ذات الصلة.
دعونا نقيم هذا العصر. الإيجابيات - عزل كامل ، وسلسلة أدوات ملائمة للتطوير ، وكما قلت ، دعم IDE.
هناك أيضا عيوب. Docker موجود في كل مكان ، ولكن إذا لم يكن Linux ، فإنه يعمل بشكل غريب بعض الشيء. مطورو Yandex الذين لديهم إرساء تثبيت MacBook لنظام التشغيل Mac. وهناك ميزات ، على سبيل المثال ، يعمل IPv6 بشكل غريب ، أو تحتاج إلى تعديله بطريقة أو بأخرى. وفي شركتنا ، IPv6 واسع الانتشار. لقد افتقرنا منذ فترة طويلة إلى عناوين IPv4 ، لذا فإن البنية التحتية الداخلية بأكملها مرتبطة إلى حد كبير بـ IPv6. وعندما لا يعمل IPv6 على الكمبيوتر المحمول أو داخل الرصيف ، الموجود على الكمبيوتر المحمول ، فأنت تعاني ولا تستطيع فعل أي شيء ، ثم علينا تجاوزه.
على الرغم من هذا ، نحن نحب عامل الرصيف كثيرًا. إنه فعال ولديه نظام بيئي جيد. يأتي الناس إلينا من الشارع ، نقول - هل يمكنك الرصيف؟ هم - نعم ، أستطيع. كل شيء على أكمل وجه. يأتي الشخص ويبدأ فعليًا في الاستفادة ، لأنه لا يحتاج إلى الخوض في كيفية البدء وكيفية تجميع المشروع ، وكيفية إجراء الاختبارات ، وكيفية النظر إلى الإنشاء ، وأي نوع من إخراج التصحيح. الإنسان يعرف كل شيء. هذا معيار فعلي في العالم الخارجي ، فهو يزيد من كفاءتنا ، ويمكننا توصيل الميزات بسرعة للمستخدمين ، وعدم إنفاق الأموال على البنية التحتية.
العمر 4: بناء ثنائي
لكننا نقترب بالفعل من العصر الأخير الذي ندخل فيه للتو. وهنا سوف أعود إلى بداية تقريري ، عندما قلت: أنت تأتي إلى شركة كبيرة ذات نهج البنية التحتية الخاصة بك. إنه نفس الشيء مع Yandex. إذا كانت البنية التحتية لديبيان في وقت سابق ، فهي مختلفة الآن. تمتلك الشركة مستودعًا واحدًا مترابطًا لبعض الوقت ، حيث يتم جمع جميع الرموز تدريجيًا. تم إنشاء آلية بناء ، وآلية اختبار موزعة ، ومجموعة من الأدوات وكل شيء لم نستخدمه بعد ، ولكننا بدأنا في استخدامه ، حولها. أي أن مشاريعنا في الثعبان تقوم أيضًا بزيارة هذا المستودع. نحاول أن نجمع بنفس الأدوات. ولكن نظرًا لأن هذه الأدوات الخاصة بمستودع واحد ، والتي تم شحذها بشكل أساسي في C ++ و Java و Go ، فهناك خصوصية هناك.
هذه هي الخصوصية. إذا كانت نتيجة تجميع مشروعنا الآن هي Docker Engine ، حيث يكمن رمز المصدر الخاص بنا بكل التبعيات ببساطة ، فإننا نصل إلى استنتاج مفاده أن نتيجة تجميع مشروعنا ستكون مجرد ثنائي. انها مجرد ثنائي ، حيث يوجد مترجم بيثون ، رمز وبيثون وكل التبعيات الضرورية الأخرى ، فهي مرتبطة بشكل ثابت.
يعتقد أنه يمكنك القدوم ، ورمي هذه العلبة على أي خدمة Linux ذات بنية متوافقة وستعمل. وهذا صحيح.
يبدو غير طبيعي بعض الشيء. معظم الناس في مجتمع الثعبان لا يفعلون ذلك ، وأنا متأكد من أنك لا تفعل ذلك. هذا له إيجابياته وسلبياته. الإيجابيات:
- . , , , , , . , . , , . .
- , , , . , , . , . , checkout , , . .
- , .
وبالطبع ، هناك ناقص: نظام بيئي مغلق. يحتاج الشخص من الخارج إلى الانغماس في كيفية عمل كل شيء ، ليخبر كيف يعمل. يجب أن يحاول ثم يصبح فعالا فقط. نحن فقط في بداية هذا الطريق. ربما ، إذا جئت إلى هذا المؤتمر في غضون عام أو عامين ، فيمكنني أن أخبرك كيف مررنا بهذا التحول. لكننا الآن متفائلون بشأن المستقبل ونطيع بعض قواعد الشركة الداخلية ، ونفضلها أكثر من عدمها ، لأننا سنحصل على الكثير من الأشياء الداخلية الجيدة.
الاستنتاجات
هم أكثر فلسفية. التقرير نفسه ليس تقنيًا بقدر ما هو فلسفي.
- التطور أمر لا مفر منه. إذا قمت بتقديم خدمة وتعيش لفترة طويلة ، فسوف تقوم بتطويرها ، وتطوير بنيتها التحتية ، بالطريقة التي تطورها بها.
- . , , , .
- . , Django, . , . , , , Django - , . , .
- Python-. , , -. , , . , , , , , : , . , .
الموضوع كبير جدا أخبرتك بإيجاز شديد عن كيف وماذا نفعل ، وكيف تطورت Python في بلدنا. يمكنك أن تأخذ كل عصر ، تأخذ كل نقطة على الشريحة وتحليلها بشكل أعمق. وهذا يكفي أيضًا لمدة 40 دقيقة - يمكنك التحدث لفترة طويلة جدًا عن التبعيات وعن المصادر المفتوحة الداخلية وعن البنية التحتية. أعطيت صورة نظرة عامة. إذا كان أي موضوع يحظى بشعبية كبيرة ، يمكنني الكشف عنه في الاجتماعات أو المؤتمرات القادمة. شكرا.