Get best of the week

البنية التحتية الغذائية: كيف ندعم Tanuki



لإعادة صياغة شخصية تاريخية مشهورة ، فإن أهم الخدمات بالنسبة لنا هو التسليم. ماذا سنفعل في الوضع الحالي بدون لفات أو بيتزا في المنزل؟ لا أريد أن أتخيل. حدث ذلك منذ عامين قبلنا بدعم إحدى أكبر الشبكات - Tanuki . الجمهور الشهري للموقع حوالي مليون شخص. إنه الآن في عام 2020. في عام 2018 ، عندما بدأ تانوكي التعاون معنا ، كان أصغر مرتين. لقد حرصنا على الانتقال غير المؤلم إلى مركز بيانات جديد وقمنا بإعادة تصميم البنية التحتية بالكامل - وبفضل ذلك ، أصبح الموقع والتطبيقات في الواقع قادرة على تحمل الحمل الزائد دون مشاكل.

في بعض الأحيان ، نأسف بشدة لأننا بعيدًا جغرافيًا عن أقرب مطعم Tanuki: وإلا ، فإن كل نجاحاتنا (والمآسي الصغيرة) ستشوش بفائف لذيذة.

بشكل عام ، نريد اليوم أن نخبرك قصة دعم أحد أكبر مشاريع الويب في "صناعة الضيافة" المحلية.

التقينا في نهاية مارس 2018.

لقد مر يوم المرأة العالمي منذ فترة طويلة ، لكن الرجال تعاملوا للتو مع عواقبه. كل شيء عادي جدًا: عشية 8 مارس ، زادت حركة المرور بشكل حاد ، ولم يكن الموقع متاحًا لفترة طويلة. حقا طويلة ، وليس بضع ساعات. لأن حركة المرور لم تتدفق من خلال الموقع الرئيسي فحسب ، بل أتت أيضًا من التطبيق (متوفر لنظامي التشغيل Android و iOS) ، بالإضافة إلى مجمعي المحتوى (Yandex. Food ، Delivery Club ، Zaka-Zaka).

ما رأيناه


من الناحية الفنية ، تبين أن المشروع معقد للغاية:

  • الموقع عبارة عن تطبيق رد فعل مع SSR (التقديم من جانب الخادم).
  • تطبيقات الهاتف المحمول - لـ iOS / Android.
  • API - تعمل جميع التطبيقات معها.
  • الأنظمة الخارجية ، بما في ذلك معالجة الطلبات.


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

تتكون مجموعة قاعدة البيانات من خادمين مع نسخ رئيسي / رئيسي ، حيث تم إجراء التبديل في حالة حدوث فشل على مستوى الشبكة بسبب IP العائم. عملت جميع تطبيقات الكتابة مع عنوان IP هذا ، في حين كان هناك عبيد MySQL للقراءة الموجودة على كل خادم خلفية - حيث عمل التطبيق ، وفقًا لذلك ، مع localhost.

رأينا في الاستقبال المشاكل التالية:

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

بعد المراجعة الأولية للخوادم المقبولة للمراقبة ، بدأنا بتشكيل خريطة طريق عملية. في البداية ، تم تحديد مجالين رئيسيين للعمل:
  1. استقرار التطبيقات.
  2. تنظيم بيئة تطوير مريحة لواجهة برمجة التطبيقات والموقع الجديد.

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

بادئ ذي بدء ، قررنا التخلي عن IP العائم لصالح خادم وكيل ، حيث سيتم التحكم في المنبع بين الأسياد ، حيث استخدمنا nginx كوكيل لـ MySQL. الخطوة الثانية هي تخصيص خادمين منفصلين للعبيد. كما تم تنظيم العمل معهم من خلال خادم وكيل. ومنذ إعادة التنظيم ، نسينا المشاكل المرتبطة بالعمل مع قاعدة البيانات.

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

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

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

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

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

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

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

"أكثر فظاعة من نارين ..."


بعد حل المهام المعقدة للغاية ، ولكن مع ذلك ، أخبرنا Tanuki بما أرادوا قوله لفترة طويلة: "دعنا نتحرك!"

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

إن هجرة أي نظام ، ناهيك عن النظام المعقد ، هي عملية تتطلب تخطيطًا واسعًا وموارد كبيرة.

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

ثم أطلقنا جميع خدمات البنية التحتية - التسجيل و CI / CD. A القنصليسمح بتنظيم خدمة ملائمة وسهلة الإدارة وموثوقة إلى حد ما للتفاعل بين تطبيقات العميل.

تم ترحيل قواعد البيانات التالية و Redis ووسيط الصف - RabbitMQ. كان من المهم تنظيم كل شيء حتى يتم تسجيلهم بشكل صحيح في بروتوكول اكتشاف الخدمة ، والذي بدوره ، يسيطر على تشغيل DNS. لاحظ أن التطبيقات لم تعمل مباشرة مع قاعدة البيانات ، ولكن من خلال Haproxy ، مما يسمح لك بالتوازن والموازنة بين قواعد البيانات والتبديل في حالة الفشل.

في المرحلة التحضيرية ، لم يرتفع تكرار قاعدة البيانات بين مراكز البيانات. كان علي فقط نقل النسخ الاحتياطية. بعد ذلك ، بدأنا في تكوين التطبيقات مباشرة ، وهذا هو تنظيم جميع التفاعلات من خلال DNS الداخلي - التفاعل بين التطبيق وقاعدة البيانات / Redis / RabbitMQ / الخدمات الخارجية (على سبيل المثال ، خدمات الطلب). بطبيعة الحال ، في نفس المرحلة ، تم ربط جميع آليات CI / CD على الفور - ثم نشأ تغيير ثان في الهندسة المعمارية. في السابق ، لم يكن من الممكن تغيير إعدادات التطبيق من خلال الواجهة - فقط من خلال تحرير الملفات مباشرة في وحدة التحكم. على الفور ، قدمنا ​​حلاً يتيح لك إدارة الإعدادات بسهولة - من خلال واجهة الويب. كان يعتمد على قبو Hashicorp (عمل القنصل كخلفية له) ، مما سمح لنا ببناء آليات ملائمة لإدارة متغيرات البيئة.

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

في السابق ، تم تنظيم النسخ المتماثلة الضرورية من DC القديم إلى الجديد. وتم التبديل إلى نافذة العمل المتفق عليها.

كيف تبدو البنية التحتية الآن





  • كل حركة المرور تذهب إلى الموازن. تنتقل حركة المرور إلى واجهة برمجة التطبيقات من تطبيق Tanuki (على Android / iOS) ليس مباشرةً ، ولكن من خلال Qrator.
  • على الخادم الثابت هو الموقع الرئيسي لمشروع tanuki.ru ، وهو خادم به صفحات مقصودة.
  • تتكون مجموعة الواجهة الخلفية الآن من خوادم: الواجهة الأمامية ، والثابتة ، وخوادم التطبيقات.

مخطط تمرير
الأمر يمر الأمر المستلم عبر Qrator (على الفور نقوم بتصفية الهجمات) ويصل إلى واجهة برمجة التطبيقات. ثم يذهب إلى Raiden لتسليم الطلب ، ويذهب إلى Redis ويذهب إلى nginx ، وبعد ذلك يغادر إلى قاعدة البيانات.

ما الذي تغير للعميل


  • موثوقية النظام: لوحظت مشاكل في يوليو 2019 - لم يتم إصدار الأوامر في غضون ساعة. لكن ذلك كان قبل التحرك العالمي. ولم يلاحظ بعد ذلك وقوع حوادث رئيسية.
  • حياة المطورين: لديهم بيئة تطوير مريحة ، CI / CD.
  • التسامح مع الخطأ: البنية التحتية تتحمل الآن الكثير من حركة المرور. على سبيل المثال ، خلال العطلات ، بلغ RPS ذروته عند 550 وحدة.

ماذا بعد


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

قضية أخرى مهمة هي استخدام الموارد وخفض تكلفة صيانة النظام.

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

More articles:


All Articles