أود أن أشارك قصتي حول تطبيق الهجرة المتراصة في الخدمات الصغيرة. من فضلك ، ضع في اعتبارك أنه كان خلال عام 2012 - 2014. إنه نسخة من العرض الذي قدمته في dotnetconf (RU) . سأشارك قصة حول تغيير كل جزء من البنية التحتية.

وصف المشروع

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

• يسمح بتدهور أداء النظام.
• قد تكون بعض أجزاء البنية التحتية لدينا معطلة لمدة 30 دقيقة.
• في حالة وقوع كارثة ، قد يكون التوقف بضعة أيام.

الزواحف

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

لم تكن مشكلة التوقف في برامج الزحف ، لذلك كان من السهل حقًا توسيع نطاقها:

• أتمتة الحكم.
• إضافة مقاييس العمل.
• اجمع الأخطاء.

مسقل

كانت قاعدة البيانات الخاصة بنا حوالي 1 تيرابايت.

مجموعة MsSQL

كانت هناك طرق مختلفة لكيفية إنشاء كتلة:

1. النسخ المتطابق SQL.
2. نظام مجموعة تجاوز الفشل في Windows - لم يكن الأمر كذلك لأنه لم يكن هناك san / Nas.
3. AlwaysOn - كان جديدًا تمامًا بالنسبة لنا ولم تكن لدينا خبرة في ذلك ، لذلك ، لم يكن الأمر كذلك بالنسبة لنا.

نتيجة لذلك ، قررنا استخدام 1st. أود أن أشير إلى أننا لم نستخدم الشاهد بسبب وضع المزامنة ، لذلك أنشأنا برامج نصية للسيد التبديل التلقائي -> الرقيق والعبد اليدوي -> الرئيسي.

MsSQL برفومنس

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

قائمة انتظار الرسائل

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

WEB

يتكون جزء الويب من جزأين: المحتوى الثابت والمحتوى الديناميكي للمستخدم.

ثابت على شبكة الإنترنت

كان جزء ثابت WEB من البنية التحتية حوالي 2TB ، كان عليه:

• تخزين الصور.
• تحويل الصور.
• الزحف أصل الصورة والمحاصيل إذا لزم الأمر.

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

موازن الويب

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

1. موازن الأجهزة - كان مكلفاً للغاية بالنسبة لنا.
2. IIS & ARR - كان الأمر معقدًا جدًا بحيث لا يمكن دعمه.
3. Nginx - كانت جيدة بما فيه الكفاية ، ومع ذلك ، واجهنا بعض المشاكل مع الفحوصات الصحية.
4. هابروكسي - كان حلا مع واحد أصغر النفقات العامة.

لقد اخترنا الطريقة الرابعة. كنا نوازن بين haproxy بواسطة DNS جولة روبن والمستخدمين بواسطة ملف تعريف الارتباط.

مونجودب

بعد بضعة أشهر ، واجهنا أن أداء SQL لم يكن جيدا بما فيه الكفاية مرة أخرى. كانت مشكلة معقدة ، ومع ذلك ، بعد محادثات طويلة قررنا اختيار التيسر وقسم التسامح من نظرية CAP . نتيجة لذلك ، قمنا بتطبيق مجموعة MongoDB (التقسيم والنسخة المتماثلة). كانت هناك تجربة مثيرة للاهتمام: كيفية إنشاء نسخة احتياطية MongoDB ، وكيفية ترقية والكثير من الأخطاء MongoDB.

النسخ الاحتياطي والمراقبة

طبقنا القاعدة 3-2-1:

• على الأقل 3 نسخة.
• على الأقل 2 أنواع تخزين مختلفة.
• يجب تخزين نسخة واحدة على الأقل في مكان ما بالخارج.

أيضا ، قمنا بإنشاء واختبار خطة التعافي من الكوارث. يمكنك أن تقرأ عن المراقبة هنا .

تحديثات التطبيقات

كما ترون ، البنية التحتية لم تكن سهلة مثل الفطيرة. كان علينا تحديثه بطريقة ما. بدا التحديث عارضة مثل:

1. القيام ببعض التحضير.
2. ركض الهجرة.
3. تحديث تطبيقات الويب.
4. تحديث التطبيقات الخلفية.

كانت جميع الخطوات المنطقية متطابقة لبيئات التدريج / preprod / productions ، ومع ذلك ، فقد كانت مختلفة قليلاً في التفاصيل. لذلك ، أنشأنا البرامج النصية PowerShell مع OOP السحر. لقد كانت عملية مستمرة لتحسين بنية CI / CD الخاصة بنا.

الخاتمة

لقد كانت قصة مذهلة حول نقل 3 أجهزة كمبيوتر سطح مكتب إلى بنية تحتية موثوقة. التحلي بالصبر والقيام الخطط.

PS

• dotnetconf (RU) .
• الشرائح (RU)
• فيديو (RU)
• هو crosspost