في التعليقات
على مقالتنا الأخيرة ، كان هناك العديد من الأسئلة حول التقنيات التي نستخدمها. في هذه المقالة ، أنا - Igor Mosyagin ، مطور البحث والتطوير في Lamoda - سأخبرهم عنها. تحت الخفض ، ستجد قائمة شاملة باللغات والأدوات والمنصات والتقنيات التي مرت بين أيدينا. الواجهة الأمامية والخلفية وقاعدة البيانات ووسطاء الرسائل وذاكرة التخزين المؤقت والمراقبة والتطوير والموازنة هي سرد مفصل لما نستخدمه اليوم وما تخلينا عنه.
أنا وزملائي على استعداد للمناقشة في التعليقات أو في جناح الشركة في HighLoad ++ 2018.
شاهد الرادار بشكل كبير ومفصل هنا.كما قلنا من قبل ، هناك عدد كبير من التقنيات والأدوات المختلفة المشاركة في Lamoda. وهذه ليست مصادفة. خلاف ذلك ، لا يمكننا التعامل مع الحمل! لدينا مستودع آلي كبير. يخدم مركز الاتصال لدينا 500 موظف ، وتسمح لنا العمليات التي أنشأناها بالاتصال بالعميل في غضون 5 دقائق بعد تقديم الطلب. تعمل خدمة التوصيل لدينا على فترات 15 دقيقة. ولكن بالإضافة إلى أنظمتنا الخاصة ، لدينا تكامل B2B مع المتاجر الأخرى عبر الإنترنت. مع مجموعة متنوعة من المهام ومتطلبات مثل هذه الأعمال الديناميكية مثل التجارة الإلكترونية ، فإن نمو المجموعة التقنية أمر لا مفر منه ، لأننا نريد حل كل مشكلة باستخدام التقنيات الأكثر ملاءمة. التنوع أمر لا مفر منه. سنتحدث عن الممثلين الرئيسيين لمجموعتنا أدناه. لكن لنبدأ بالآليات التي تسمح لنا بعدم الضياع في هذا التنوع.
أساسيات الهندسة المعمارية
نحن نتحرك بنشاط نحو هندسة الخدمات الصغيرة. لقد تم بالفعل بناء معظم الأنظمة وفقًا لهذه الإيديولوجية - قبل عامين مررنا بمرحلة انتقالية مع مشاكلنا وحلولها. لكننا لن نتطرق إلى تفاصيل هذه العملية - تقرير من Andrey Evsyukov "
ميزات الخدمات الدقيقة على سبيل المثال من منصة e-Com " سيخبرنا الكثير عن هذا.
من أجل عدم تفاقم التنوع التكنولوجي ، أدخلنا "ديكتاتورية الممارسات المثبتة" ، والتي بموجبها يوصى مبدعو الرقاقات الجديدة باستخدام تلك التقنيات والأدوات المستخدمة بالفعل في مكان ما في الشركة. تتواصل معظم الخدمات مع بعضها البعض من خلال واجهة برمجة التطبيقات (نستخدم تعديلنا للإصدار الثاني من معيار JSONRPC) ، ولكن عندما يسمح منطق الأعمال بذلك ، نستخدم أيضًا ناقل البيانات للتفاعل.
استخدام التقنيات الأخرى غير محظور. ومع ذلك ، يجب اختبار أي فكرة جديدة في لجنة معمارية تم إنشاؤها خصيصًا ، والتي تضم قادة المناطق الرئيسية.
بالنظر إلى الاقتراح التالي ، إما أن تعطي اللجنة الضوء الأخضر للتجربة ، أو تقدم نوعًا من الاستبدال من المكدس الحالي. بالمناسبة ، يعتمد هذا القرار إلى حد كبير على الظروف الحالية في العمل. على سبيل المثال ، إذا جاء فريق عشية بيع الجمعة السوداء وأعلن أنه سيقدم التكنولوجيا في الإنتاج التي لم تسمع بها اللجنة من قبل ، فمن المرجح أن يتم رفضها. من ناحية أخرى ، يمكن إعطاء نفس التجربة الضوء الأخضر إذا تم إدخال تقنية أو أداة جديدة في ظروف عمل أقل خطورة ، وسيبدأ التنفيذ باختبار خارج الإنتاج.
لجنة الهندسة مسؤولة أيضًا عن الحفاظ على رادار التكنولوجيا ، وإجراء التغييرات اللازمة كل 2-3 أشهر. أحد أغراض هذا المورد هو إعطاء الفرق فكرة عن نوع الخبرة التي تمتلكها الشركة بالفعل.
ولكن دعنا ننتقل إلى الأكثر إثارة للاهتمام - لتحليل قطاعات رادارنا.
تجدر الإشارة إلى أننا نستخدم تفسيرًا غير قياسي قليلاً لفئات اعتماد التكنولوجيا:
- ADOPT - التقنيات والأدوات التي يتم تنفيذها واستخدامها بنشاط ؛
- تجربة - التقنيات والأدوات التي اجتازت بالفعل مرحلة الاختبار وتستعد للعمل مع الإنتاج (أو حتى العمل هناك بالفعل) ؛
- التقييم - أدوات التجربة التي يتم تقييمها حاليًا والتي لا تؤثر بعد على الإنتاج. بمشاركتهم ، يتم تنفيذ مشاريع الاختبار فقط ؛
- HOLD - في هذه الفئة لدينا خبرة ، ولكن يتم استخدام الأدوات المذكورة فقط بدعم من الأنظمة الحالية - لم يتم إطلاق مشاريع جديدة عليها.
التنمية
PHP - Python - Go
اللغة الأولى التي نريد التركيز عليها هي PHP. اليوم لا تحل سوى جزء من مهام الواجهة الخلفية للمتجر ، وفي البداية عملت الخلفية بالكامل على PHP. مع تصاعد الأعمال على الواجهة الأمامية ، أصبح نقص السرعة والإنتاجية ملحوظًا - في ذلك الوقت استخدمنا PHP 5 ، لذلك استبدلت Python (2.x الأول ، ثم 3.x). ومع ذلك ، تسمح لك PHP بكتابة نماذج أعمال غنية ، لذلك ظلت هذه اللغة في المكتب الخلفي لأتمتة العمليات التشغيلية المختلفة ، على وجه الخصوص ، التكامل مع متاجر الطرف الثالث عبر الإنترنت أو خدمات التسليم ، بالإضافة إلى أتمتة استوديو المحتوى الذي يرسم بطاقات المنتجات. نحن الآن نستخدم PHP 7. في PHP قمنا بكتابة العديد من المكتبات للاستخدام الداخلي: التكامل والأغلفة على بنيتنا التحتية ، طبقة التكامل بين الخدمات ، المساعدين المعاد استخدامهم. تم نقل الدفعة الأولى من المكتبات إلى المصادر المفتوحة على موقع
github.com ، وسيصل الباقي ، "الأكثر نضجًا" ، قريبًا. كان أحد الأجهزة الأولى عبارة عن آلة حالة ، والتي تتواجد في جميع التطبيقات تقريبًا ، وتتأكد من ذلك مع الطلب قبل إرسال جميع الإجراءات اللازمة.
بمرور الوقت ، أصبحت Python أيضًا غير كافية لخلفية المتجر. نفضل الآن استخدام Go الأكثر إنتاجية وخفة الوزن.
ربما كان الانتقال إلى Go تغييرًا مهمًا ، لأنه وفر الكثير من الأجهزة والموارد البشرية - زادت الكفاءة بشكل ملحوظ. كان أول من قام بأول المشاريع على Go هو RnD ، ولم يرغبوا في التعامل مع القيود التقنية لـ Python. ثم في فريق التطوير المتنقل كان هناك أشخاص على دراية به وترقيته إلى الإنتاج. من تقديمهم ، أجرينا الاختبارات وكانوا راضين أكثر عن النتيجة. في حالات منفصلة ، بعد إعادة كتابة جزء من المشروع من Python إلى Go ، انخفض تحميل عقد الكتلة بشكل ملحوظ. على سبيل المثال ، سمحت لنا إعادة كتابة محرك حساب الخصم للسلة من Python to Go بمعالجة 8 مرات أكثر من الطلبات بنفس قدرات الأجهزة ، وتم تقليل متوسط وقت استجابة API بمقدار 25 مرة. على سبيل المثال أصبح Go أكثر كفاءة من Python (إذا قمت بكتابته بشكل صحيح) ، حتى إذا لم يكن مناسبًا جدًا للمطور.
نظرًا لأن تطوير الأجهزة المحمولة يجب أن يتفاعل مع العشرات من واجهات برمجة التطبيقات الداخلية ، تم إنشاء مُنشئ تعليمات برمجية ، وفقًا لوصف خدمة واجهة برمجة التطبيقات (وفقًا لمواصفات Swagger) ، يمكن للعميل أن يولد على Go. لذا بدأت خدمة On on Go تتوافق تدريجيًا مع الخدمات والأدوات الحالية ، خاصةً تلك التي خلقت "عنق الزجاجة" للحمل. بالإضافة إلى جعل الحياة أسهل لمطور الخلفية المحمول ، قمنا بتبسيط الاتفاقيات الداخلية التالية حول كيفية تطوير واجهات برمجة التطبيقات ، وكيفية تسمية الطرق ، وكيفية تمرير المعلمات ، وما شابه ذلك. وقد جعل هذا التوحيد تطوير وتنفيذ الخدمات الجديدة أسهل لجميع الفرق.
اليوم ، يتم استخدام Go بالفعل في كل مكان تقريبًا - في جميع التفاعلات في الوقت الفعلي مع المستخدمين - في الواجهة الخلفية للموقع وتطبيقات الهاتف المحمول ، بالإضافة إلى الخدمات التي ترتبط بها. وحيث لا توجد حاجة للمعالجة والاستجابة السريعة ، على سبيل المثال ، في مهام التفاعل مع مستودع البيانات ، تظل Python ، حيث لا يوجد لها ما يساوي مهام معالجة البيانات (على الرغم من وجود اختراق Go هنا).
كما ترون على الرادار ، لدينا جافا في الأصل. يتم استخدامه في نظام إدارة المستودعات (WMS) ، مما يساعد على جمع الطلبات بسرعة. حتى الآن ، لدينا مجموعة قديمة إلى حد ما هناك ونموذج معماري قديم - دوران مترابط على Wildfly 10 و 8 Java Hotspot ، وهناك أيضًا عميل عن بُعد وغني على
Netbeans Application Platform (يتم الآن نقل هذه الوظيفة إلى الويب). هنا ، في ترسانتنا ، لدينا مخازن قياسية للشركة وحتى المراقبة الخاصة بنا. لسوء الحظ ، لم نعثر على أداة يمكنها تصور عمل المستودع والعمليات المهمة عليه بشكل جيد (عندما يكون هناك قسم مثقل على سبيل المثال) ، وقمنا بعمل هذه الأداة بأنفسنا.
نستخدم Python كلغة رئيسية لتعلم الآلة: فنحن نبني أنظمة التوصيات ونصنف الكتالوج ، ونصحح الأخطاء المطبعية في استعلامات البحث ، ونحل أيضًا المشكلات الأخرى بالتزامن مع Spark على مجموعة Hadoop (PySpark). تساعدنا Python في أتمتة حساب المقاييس الداخلية واختبار AB.
تطوير الواجهة الأمامية والجوال
تمت كتابة الواجهة الأمامية لمتجر سطح المكتب عبر الإنترنت ، بالإضافة إلى مواقع الجوال ، باستخدام جافا سكريبت. الآن تنتقل الواجهة الأمامية تدريجيًا إلى مواصفات ES6 ، وإنشاء مشاريع جديدة وفقًا لها. نستخدم vue.js كإطار عمل رئيسي ، لكننا سنتناوله بمزيد من التفصيل في قسم الأدوات.
تطوير التطبيقات للمنصات المحمولة هي وحدة منفصلة في الشركة ، والتي تشمل مجموعات الواجهة الخلفية ، بالإضافة إلى تطبيقات Android و iOS مع مكدسات وأدوات التكنولوجيا الخاصة بها ، والتي ، بسبب اختلافات المنصة ، بعيدة عن التوحيد عبر الوحدة بأكملها.
لمدة عامين حتى الآن ، كل تطوير Android الجديد قيد التنفيذ على Kotlin ، مما يسمح لنا بكتابة كود أكثر إيجازًا ومفهومًا. من بين الميزات الأكثر استخدامًا ، يتصل مطورو البرامج لدينا: البث الذكي ، والفئات المختومة ، ووظائف الامتداد ، والبناء الآمن لأنواع (DSL) ، ووظيفة stdlib.
يجري تطوير نظام iOS على Swift ، الذي حل محل Objective-C.
لغات خاصة
لا يقتصر نطاق مهام Lamoda على تطوير "عرض" لمنصات مختلفة ، على التوالي ، لدينا عدد من اللغات التي يتم استخدامها فقط داخل أنظمتهم ، وتعمل بشكل جيد هناك ، ولكن لن يتم تنفيذها في أجزاء أخرى من البنية التحتية:
- R - يستخدم لمعالجة البيانات وإعداد التقارير النصية في إطار ذكاء الأعمال (BI). إنه ليس قيد الإنتاج ولم يعد يستخدم في المهام الجديدة ، ولكن لا يزال لدينا عدد من هذه البرامج النصية. لحل مشاكل R ، أدركنا أن هذه اللغة ليست للتطبيقات المحملة بشكل كبير. في المهام الجديدة ، نستخدم Python وتقنيات أخرى غير متوافقة مع R.
- سكالا - يستخدم من قبل مكتب التطوير في فيلنيوس لتطوير نظام أتمتة مركز الاتصال. مبدئيًا ، تمت كتابة هذا النظام بلغة PHP ، ولكن أثناء الانتقال إلى بنية الخدمات الصغيرة ، تمت إعادة كتابة عدد من المكونات في Scala. أيضًا ، يكتب فريق هندسة البيانات وظائف Spark.
- TypeScript الذي ننظر إليه. يتم تنفيذ التسليم بالفعل بمساعدته ، وفي المستقبل سنستخدم TypeScript + vue.js على الواجهة الأمامية.
- يتم استخدام Lua لتكوين nginx (عبر واجهة برمجة تطبيقات nginx) ، وفي مشروعات أخرى ، لن يتم ذلك ولن يكون كذلك أبدًا.
- نحن شركة أزياء ونتبع الموضة للبرمجة الوظيفية. على سبيل المثال ، تمت كتابة محاكي جهاز فرز في أحد مستودعاتنا في Haskell.
إدارة البيانات
DBMS ، البحث عن البيانات وتحليلها
مثل العديد من قواعد البيانات الأكثر تنوعًا التي قمنا بتطبيقها على PostgreSQL - يتم استخدامها حيثما كانت هناك حاجة إلى قواعد البيانات العلائقية ، على سبيل المثال ، لتخزين دليل. من السهل جدًا العثور على متخصصين في هذه التكنولوجيا ، بالإضافة إلى العديد من الخدمات المختلفة المتاحة.
بالطبع ، PostgreSQL ليست نظام إدارة قواعد البيانات الوحيد الذي يمكن العثور عليه في البنية التحتية لتكنولوجيا المعلومات لدينا. في بعض الأنظمة القديمة ، على سبيل المثال ، يتم استخدام MySQL ، بينما يحتوي WMS على القليل من MongoDB. ومع ذلك ، بالنسبة للأحمال العالية والقياس (مع مراعاة بقية مجموعتنا التكنولوجية) ، فإننا لا نستخدمها في المشاريع الجديدة. بشكل عام ، PostgreSQL هو كل شيء لدينا.
يظهر Aerospike أيضًا على الرادار. استخدمناها بنشاط كبير ، ولكن بعد ذلك تغيرت اتفاقية الترخيص للمنتج ، لذلك تبين أن النسخة "الخاصة بنا" تم قطعها قليلاً. ومع ذلك ، الآن نظرنا إليه مرة أخرى. ربما سنعيد النظر في موقفنا تجاه الأداة وسنستخدمها بشكل أكثر نشاطًا. يتم الآن استخدام Aerospike في خدمة التجميع لأحداث مشاهدة الصفحة وعمل المستخدم مع السلة ، وكذلك في خدمة الحماية الاجتماعية ("أضاف 5 أشخاص هذا المنتج إلى المفضلة هذا الأسبوع"). الآن نحن نقدم توصيات أكثر حدة بشأن ذلك.
يستخدم Apache Solr للبحث عن بيانات الإنتاج. في موازاة ذلك ، نستخدم أيضًا البحث المرن. كلا الحلين مفتوح المصدر ، ولكن إذا كان في وقت سابق ، عندما كنا ننفذ البحث للتو ، كان لدى Apache Solr بالفعل الإصدار الثالث أو الرابع وكان يتطور بنشاط ، ولم يكن لـ مرونة البحث حتى الإصدار الأول المستقر - كان من السابق لأوانه استخدامه في الإنتاج. لقد تغيرت الأدوار الآن - من الأسهل بكثير العثور على حلول للبحث المرن ، وقد وصل إلينا أشخاص جدد يجيدون إعداده. ومع ذلك ، في حثنا لدينا Solr ، ولن ننتقل إلى حل آخر على الأقل حتى الجمعة السوداء 2018.
مقارنة بين ديناميكيات استعلامات البحث Apache Solr (الأزرق) و ElasticSearch (red) ، وفقًا لمؤشرات Googleيحدث تحليل البيانات في العديد من الأنظمة ، على وجه الخصوص ، نستخدم بنشاط Apache Hadoop. في الوقت نفسه ، يتم استخدام عمود DBMS في عمود Vertica لتخزين بيانات البيانات (التي يبلغ حجمها الإجمالي حوالي 4 تيرابايت). تم بناء التقارير المالية والتشغيلية والتجارية على هذه المعارض. بالنسبة للعديد من مهام ETL ، استخدمنا Luigi سابقًا ، ولكننا الآن ننتقل إلى Apache Airflow. نستخدم أيضًا Pentaho للتخزين الارتباطي ، حيث يوجد حوالي ألف مهمة ETL منتظمة.
يتم تنفيذ جزء من التحليل وإعداد البيانات للأنظمة الأخرى في Spark. في بعض الأماكن ، هذه ليست أداة تحليلية فحسب ، بل هي أيضًا جزء من هندسة لامدا الخاصة بنا.
تلعب أنظمة ERP دورًا مهمًا في البنية التحتية لتكنولوجيا المعلومات: Microsoft Dynamics AX و 1 C. كنظام DBMS ، يتم استخدام Microsoft SQL Server. وللبلاغ ، مكوناته ، مثل خدمات التحليل وخدمات التقارير.
التخزين المؤقت
للتخزين المؤقت نستخدم Redis. في السابق ، تم تنفيذ هذه المهمة بواسطة MemCached ، ولم يكن من الممكن استخدامها كمخزن قيمة رئيسية مع تفريغ دوري إلى القرص ، لذلك تخلينا عنها.
قوائم انتظار الرسائل
بصفتنا وسيطًا للأحداث ، نستخدم أداتين في وقت واحد - Apache Kafka و RabbitMQ.
Apache Kafka هي أداة تسمح لنا بمعالجة عشرات الآلاف من الرسائل في أنظمة مختلفة حيث يلزم المراسلة. يتم نشر مجموعات Kafka المنفصلة لبعض الأجزاء المحملة بشكل كبير من النظام - على سبيل المثال ، لأحداث المستخدم أو التسجيل (كان لدينا
تقرير جيد
عن تسجيل الدخول في Highload ++ 2017 ). يسمح لك Kafka بالتعامل مع 6000 ألف رسالة مجمعة في الثانية مع الحد الأدنى من استخدام الحديد.
في الأنظمة الداخلية ، نستخدم RabbitMQ للإجراءات المؤجلة.
المنصات والبنية التحتية
التسليم المستمر
للنشر ، يتم استخدام Kubernetes ، والتي حلت محل حزمة Nomad + Consul من Hashicorp. عمل المكدس السابق بشكل سيء للغاية مع ترقيات الأجهزة. عندما قام فريق Ops بتغيير الخوادم المادية التي كانت تدور فيها العقد وتم تخزين الحاويات ، تم كسرها وتعطلها بشكل دوري ، ولا تريد أن ترتفع. لم يكن هناك نسخة مستقرة في ذلك الوقت. علاوة على ذلك ، لم نستخدم الأحدث في ذلك الوقت - 0.5.6 ، والتي لا تزال بحاجة إلى التحديث. تتطلب الترقية إلى الإصدار التجريبي الأخير بعض العمل. لذلك ، تقرر التخلي عنها والتحول إلى Kubernetes الأكثر شعبية.
الآن لا يزال Nomad و Consul يستخدمان في ضمان الجودة ، ولكن في المستقبل يجب عليه أيضًا الانتقال إلى Kubernetes.
لتنفيذ التسليم المستمر ، يتم استخدام حاويات Docker ، التي هاجرنا إليها قبل عامين. بالنسبة لخدماتنا المحملة للغاية (سلة ، كتالوج ، موقع ويب ، نظام إدارة الطلبات) ، فإن القدرة على التقاط بعض الحاويات الإضافية للخدمة بسرعة أمر مهم ، لذلك لدينا حاويات في كل مكان. و Docker هي واحدة من أكثر طرق الحاويات شيوعًا ، لذا فإن وجودها على الرادار منطقي تمامًا.
كخادم بناء وتكامل مستمر ، يتم نشر Bamboo ، ويتم استخدامه مع Jira و Bitbucket (مكدس قياسي).
يذكر جينكينز أيضًا في الرادار. لقد جربناه ، لكننا لن نجره إلى مشاريع جديدة. إنها أداة رائعة ، ولكنها لا تتناسب مع مجموعتنا لأن لدينا Bamboo بالفعل.
يتم تجميع حاويات أرصفة البامبو التي يتم جمعها في المستودع تحت سيطرة Artifactory.
إدارة العمليات والموازنة
نستخدم NGINX Plus ، ولكن ليس من حيث الموازنة ، لأن مقاييسه ليست كافية لمهامنا. لا يمكنه القول ، على سبيل المثال ، أي طلب غالبًا ما يتم توجيهه أو يتجمد. لذلك ، يتم استخدام HAProxy لموازنة الحمل. يمكن أن يعمل بسرعة وكفاءة بالاشتراك مع nginx ، دون تحميل المعالج والذاكرة. بالإضافة إلى ذلك ، المقاييس التي نحتاجها موجودة هنا من خارج الصندوق - يمكن لـ HAproxy إظهار الإحصائيات حسب العقد ، وعدد الاتصالات في الوقت الحالي ، ومدى انشغال النطاق الترددي وأكثر من ذلك بكثير.
يتم استخدام UWSGI لتشغيل تطبيقات Python المتزامنة. تم استخدام Php-fpm كمدير عمليات في جميع خدمات PHP.
المراقبة
نستخدم Prometheus لجمع المقاييس من تطبيقاتنا والأجهزة المضيفة (الأجهزة الافتراضية) ، بالإضافة إلى
قاعدة بيانات السلاسل الزمنية للتطبيق . نقوم بجمع السجلات ، لهذا نستخدم مكدس ELK ، كنظام تنبيه نستخدم Icinga ، والذي تم تكوينه لكل من ELK و Prometheus. ترسل تنبيهات إلى البريد والرسائل القصيرة. تتلقى خدمة الدعم 6911 نفس التنبيهات وتقرر جذب المهندسين المناوبين.
تشارك Prometheus في كل مكان تقريبًا ، ولهذا لدينا مكتبات لجميع اللغات ، والتي تسمح باستخدام بضعة أسطر من التعليمات البرمجية لربط مقاييسها بالمشروع. على سبيل المثال ، تتوفر مكتبة لـ PHP
في Open Source ).
لعرض نتائج المراقبة بشكل مرئي في شكل لوحات تحكم جميلة ، يتم استخدام Grafana. بشكل أساسي ، نقوم بجمع جميع لوحات المعلومات من Prometheus ، على الرغم من أن أنظمة أخرى يمكن أن تكون بمثابة مصادر في بعض الأحيان.
للكشف عن الأخطاء وتجميعها تلقائيًا ، نستخدم Sentry ، الذي تم دمجه مع Jira ويجعل من السهل بدء تعقب المهام لكل من مشكلات الإنتاج. إنه يعرف كيف يلتقط الخطأ ببعض التراجع والمعلومات الإضافية ، لذا فمن المناسب الظهور لأول مرة.
يتم جمع الإحصائيات الخاصة بكود طلبات السحب التي تم إنشاؤها باستخدام SonarQube.
أطر وأدوات
أثناء تطوير البنية التحتية لتكنولوجيا المعلومات في Lamoda ، قمنا بتجربة ما يقرب من ثلاثين من الأدوات المختلفة ، لذا فإن هذه الفئة هي الأكثر "واسعة النطاق" على رادارنا. حتى الآن ، يتم استخدامها بنشاط:
- Symfony 3.x ، ومؤخرًا - Symfony 4.x - للتطوير في PHP ؛
- Django ومحرك القالب Jinja لتطوير Python. بالمناسبة ، يتم استخدام Jinja ، بما في ذلك ، للتكوين في Ansible ؛
- قارورة - للخدمات الداخلية (مع Django) ، ولكن في الإنتاج لا نسحبها ؛
- الربيع - في تطوير جافا ؛
- Bootstrap - لمجموعة متنوعة من الأدوات الداخلية في تطوير الويب (لوحة المشرف ، لوحات المعلومات محلية الصنع ، إلخ) ؛
- مسج - لتطوير شبيبة ؛
- OpenAPI (Swagger) - لتوثيق جميع خدمات API ، بما في ذلك التي يتم استخدامها لإنشاء التعليمات البرمجية أعلاه على Go ؛
- Webpack - لتغليف JS وتقليل CSS ؛
- السيلينيوم - لاختبار الواجهة الأمامية ؛
- كما تستخدم WireMock و JMeter و Allure وغيرها في الاختبار ؛
- Ansible - لإدارة التكوين ؛
- كيبانا - لتصور نتائج البحث في ElasticSearch.
أود التحدث عن تطوير جافا سكريبت بشكل منفصل. لدينا ، مثل الكثيرين ، مجال كامل من التجارب.
يستخدم موقع JavaScript إطارًا مكتوبًا ذاتيًا. في الواجهة الأمامية ، في إطار المهام غير المهمة للأعمال ، تم إجراء التجارب باستخدام أطر عمل مختلفة - Angular، ReactJS، vue.js. في "سباق التسلح" هذا ، يبدو أن vue.js ، الذي تم استخدامه في الأصل في نظام التشغيل الآلي لاستوديو المحتوى ، يبدو رائدًا ، والآن يأتي تدريجياً في كل مكان.في البقايا الجافة
إذا حاولنا وصف كل هذا التنوع باختصار ، فإننا نكتب في GO و PHP و Java و JavaScript ، ونحتفظ بقواعد بيانات على PostgreSQL ، وننشرها على Docker و Kubernetes.بالطبع ، لا يمكن وصف الحالة الموصوفة للمكدس التكنولوجي بأنها نهائية. نحن نطور باستمرار ، ومع زيادة الحمل ، يجب تغيير فئات الحلول المناسبة ، وهي في حد ذاتها مهمة مثيرة للاهتمام. في الوقت نفسه ، أصبح منطق الأعمال أكثر تعقيدًا ، لذلك علينا باستمرار البحث عن أدوات جديدة. إذا كنت ترغب في مناقشة موضوع لماذا اخترت هذه الأداة وليس أداة أخرى ، نرحب بالتعليق.