تحتوي هذه المقالة على بعض الأنماط الشائعة لمساعدة المهندسين على العمل مع الخدمات واسعة النطاق التي يمكن لملايين المستخدمين الوصول إليها.
في تجربة المؤلف، هذه ليست قائمة شاملة، ولكن في الواقع فعال نصيحة. لذلك، دعونا نبدأ.
مترجمة مع الدعم .
مستوى اول
التدابير المذكورة أدناه سهلة التنفيذ نسبيًا ولكن لها تأثير كبير. إذا لم تجربها من قبل، فسوف تفاجأ بالتحسينات الكبيرة.
البنية التحتية كرمز
الجزء الأول من النصيحة هو تنفيذ البنية التحتية كرمز. هذا يعني أنه يجب أن يكون لديك طريقة برمجية لنشر البنية التحتية بأكملها. قد يبدو الأمر معقدًا، ولكننا في الواقع نتحدث عن الكود التالي:
نشر 100 جهاز افتراضي
- مع أوبونتو
- 2 جيجابايت من ذاكرة الوصول العشوائي لكل منهما
- سيكون لديهم الكود التالي
- مع هذه المعلمات
يمكنك تتبع التغييرات التي تطرأ على البنية الأساسية لديك والعودة إليها سريعًا باستخدام التحكم في الإصدار.
يقول الحداثي بداخلي أنه يمكنك استخدام Kubernetes/Docker للقيام بكل ما سبق، وهو على حق.
بالإضافة إلى ذلك، يمكنك توفير التشغيل الآلي باستخدام Chef أو Puppet أو Terraform.
التكامل المستمر والتسليم
لإنشاء خدمة قابلة للتطوير، من المهم أن يكون لديك مسار بناء واختبار لكل طلب سحب. حتى لو كان الاختبار بسيطًا جدًا، فسيضمن على الأقل أن الكود الذي تنشره يتم تجميعه.
في كل مرة في هذه المرحلة تجيب على السؤال: هل سيقوم تجميعي بتجميع الاختبارات واجتيازها، هل هذا صحيح؟ قد يبدو هذا بمثابة حد منخفض، لكنه يحل الكثير من المشاكل.
ليس هناك أجمل من رؤية هذه القراد
بالنسبة لهذه التقنية، يمكنك تقييم Github أو CircleCI أو Jenkins.
موازن الأحمال
لذلك، نريد تشغيل موازن التحميل لإعادة توجيه حركة المرور وضمان التحميل المتساوي على جميع العقد أو استمرار الخدمة في حالة الفشل:
عادةً ما يقوم موازن التحميل بعمل جيد في توزيع حركة المرور. أفضل الممارسات هي المبالغة في التوازن بحيث لا يكون لديك نقطة فشل واحدة.
عادةً، يتم تكوين موازنات التحميل في السحابة التي تستخدمها.
RayID أو معرف الارتباط أو UUID للطلبات
هل سبق لك أن واجهت خطأ في التطبيق تظهر لك رسالة مثل هذه: "هناك خطأ ما. احفظ هذا المعرف وأرسله إلى فريق الدعم لدينا"?
المعرف الفريد أو معرف الارتباط أو RayID أو أي من الأشكال المختلفة هو معرف فريد يسمح لك بتتبع الطلب طوال دورة حياته. يتيح لك هذا تتبع مسار الطلب بالكامل في السجلات.
يقوم المستخدم بتقديم طلب إلى النظام A، ثم يتصل A بالنظام B، الذي يتصل بـ C، ويخزنه في X، ثم يتم إرجاع الطلب إلى A
إذا كنت تريد الاتصال عن بعد بالأجهزة الافتراضية ومحاولة تتبع مسار الطلب (وربط المكالمات التي يتم إجراؤها يدويًا)، فسوف تصاب بالجنون. وجود معرف فريد يجعل الحياة أسهل بكثير. يعد هذا أحد أسهل الأشياء التي يمكنك القيام بها لتوفير الوقت مع نمو خدمتك.
المستوى المتوسط
النصيحة هنا أكثر تعقيدًا من النصائح السابقة، لكن الأدوات الصحيحة تجعل المهمة أسهل، وتوفر عائدًا على الاستثمار حتى للشركات الصغيرة والمتوسطة.
التسجيل المركزي
تهانينا! لقد قمت بنشر 100 جهاز افتراضي. في اليوم التالي، يأتي الرئيس التنفيذي ويشكو من خطأ تلقاه أثناء اختبار الخدمة. إنه يُبلغ عن المعرف المقابل الذي تحدثنا عنه أعلاه، ولكن سيتعين عليك البحث في سجلات 100 جهاز للعثور على الجهاز الذي تسبب في التعطل. ويجب العثور عليها قبل عرض الغد.
في حين أن هذا يبدو وكأنه مغامرة ممتعة، فمن الأفضل التأكد من أن لديك القدرة على البحث في جميع المجلات في مكان واحد. لقد قمت بحل مشكلة مركزية السجلات باستخدام الوظيفة المضمنة في مكدس ELK: فهي تدعم جمع السجلات القابلة للبحث. سيساعد هذا حقًا في حل مشكلة العثور على مجلة معينة. كمكافأة، يمكنك إنشاء مخططات وأشياء ممتعة أخرى من هذا القبيل.
وظيفة مكدس ELK
وكلاء المراقبة
الآن بعد أن أصبحت الخدمة قيد التشغيل، تحتاج إلى التأكد من أنها تعمل بسلاسة. أفضل طريقة للقيام بذلك هي تشغيل عدة عملاءوالتي تعمل بالتوازي وتتحقق من عملها وتنفيذ العمليات الأساسية.
عند هذه النقطة عليك التحقق من ذلك يبدو البناء قيد التشغيل جيدًا ويعمل بشكل جيد.
بالنسبة للمشاريع الصغيرة والمتوسطة، أوصي بـ Postman لمراقبة وتوثيق واجهات برمجة التطبيقات. ولكن بشكل عام، أنت فقط تريد التأكد من أن لديك طريقة لمعرفة وقت حدوث انقطاع التيار الكهربائي وإخطارك بذلك في الوقت المناسب.
التحجيم التلقائي اعتمادا على الحمل
انه بسيط جدا. إذا كانت لديك طلبات خدمة جهاز افتراضي وكان استخدام الذاكرة يقترب من 80%، فيمكنك إما زيادة موارده أو إضافة المزيد من الأجهزة الافتراضية إلى المجموعة. يعد التنفيذ التلقائي لهذه العمليات ممتازًا لتغييرات الطاقة المرنة تحت الحمل. ولكن يجب عليك دائمًا توخي الحذر بشأن مقدار الأموال التي تنفقها ووضع حدود معقولة.
مع معظم الخدمات السحابية، يمكنك تكوينها للتوسع تلقائيًا باستخدام المزيد من الخوادم أو خوادم أكثر قوة.
نظام التجربة
إحدى الطرق الجيدة لنشر التحديثات بأمان هي أن تتمكن من اختبار شيء ما على 1% من المستخدمين لمدة ساعة. لقد رأيتم، بالطبع، مثل هذه الآليات أثناء عملها. على سبيل المثال، يعرض فيسبوك أجزاء من الجمهور بلون مختلف أو يغير حجم الخط لمعرفة كيفية إدراك المستخدمين للتغييرات. وهذا ما يسمى اختبار أ/ب.
وحتى إطلاق ميزة جديدة يمكن البدء به كتجربة ومن ثم تحديد كيفية إصدارها. يمكنك أيضًا الحصول على القدرة على "تذكر" التكوين أو تغييره بسرعة بناءً على الوظيفة التي تسبب تدهور خدمتك.
المستوى المتقدم
فيما يلي بعض النصائح التي يصعب تنفيذها. من المحتمل أنك ستحتاج إلى المزيد من الموارد، لذا فإن الشركة الصغيرة أو المتوسطة الحجم ستواجه صعوبة في إدارة هذا الأمر.
عمليات النشر باللون الأزرق والأخضر
هذا ما أسميه طريقة "إيرلانج" في الكشف. أصبح Erlang مستخدمًا على نطاق واسع عندما ظهرت شركات الهاتف. بدأ استخدام Softswitches لتوجيه المكالمات الهاتفية. كان الغرض الرئيسي من البرنامج الموجود على هذه المفاتيح هو عدم إسقاط المكالمات أثناء ترقيات النظام. لدى Erlang طريقة رائعة لتحميل وحدة جديدة دون تعطل الوحدة السابقة.
تعتمد هذه الخطوة على وجود موازن التحميل. لنتخيل أن لديك الإصدار N من برنامجك، ثم تريد نشر الإصدار N+1.
أنت نستطيع ما عليك سوى إيقاف الخدمة وطرح الإصدار التالي في الوقت الذي يناسب المستخدمين لديك والحصول على بعض وقت التوقف عن العمل. ولكن لنفترض أن لديك حقا شروط SLA الصارمة. لذا، فإن SLA 99,99% يعني أنه يمكنك عدم الاتصال بالإنترنت فقط بنسبة 52 دقيقة في السنة.
إذا كنت تريد حقًا تحقيق مثل هذه المؤشرات، فأنت بحاجة إلى عمليتي نشر في نفس الوقت:
- الذي هو الآن (ن) ؛
- الإصدار التالي (ن+1).
يمكنك إخبار موازن التحميل بإعادة توجيه نسبة من حركة المرور إلى الإصدار الجديد (N+1) أثناء مراقبة الانحدارات بشكل فعال.
لدينا هنا نشر N أخضر يعمل بشكل جيد. نحن نحاول الانتقال إلى الإصدار التالي من هذا النشر
أولاً نرسل اختبارًا صغيرًا لمعرفة ما إذا كان نشر N+1 الخاص بنا يعمل مع كمية صغيرة من حركة المرور:
وأخيرًا، لدينا مجموعة من عمليات الفحص التلقائية التي نقوم بإجرائها في النهاية حتى اكتمال النشر. اذا أنت جدا جدا كن حذرًا، يمكنك أيضًا حفظ نشر N الخاص بك إلى الأبد للتراجع السريع في حالة الانحدار السيئ:
إذا كنت تريد الانتقال إلى مستوى أكثر تقدمًا، فاسمح لكل شيء في عملية النشر ذات اللون الأزرق والأخضر بالعمل تلقائيًا.
كشف الشذوذ والتخفيف التلقائي
نظرًا لأن لديك تسجيلًا مركزيًا وجمعًا جيدًا للسجلات، يمكنك بالفعل تحديد أهداف أعلى. على سبيل المثال، التنبؤ بشكل استباقي بالفشل. يتم تتبع الوظائف على الشاشات والسجلات ويتم إنشاء مخططات مختلفة - ويمكنك التنبؤ مسبقًا بالخطأ الذي سيحدث:
بمجرد اكتشاف الحالات الشاذة، تبدأ في فحص بعض القرائن التي توفرها الخدمة. على سبيل المثال، قد يشير الارتفاع المفاجئ في حمل وحدة المعالجة المركزية (CPU) إلى فشل محرك الأقراص الثابتة، في حين قد يشير الارتفاع المفاجئ في الطلبات إلى أنك بحاجة إلى الارتقاء. يتيح لك هذا النوع من البيانات الإحصائية جعل الخدمة استباقية.
باستخدام هذه الرؤى، يمكنك التوسع في أي بُعد وتغيير خصائص الأجهزة وقواعد البيانات والاتصالات والموارد الأخرى بشكل استباقي وتفاعلي.
هذا كل شيء!
ستوفر عليك قائمة الأولويات هذه الكثير من المشكلات إذا كنت تقوم برفع خدمة سحابية.
يدعو مؤلف المقال الأصلي القراء إلى ترك تعليقاتهم وإجراء التغييرات. يتم توزيع المقالة كمصدر مفتوح، وسحب الطلبات من قبل المؤلف .
ماذا تقرأ حول الموضوع:
المصدر: www.habr.com