اختيار طريقة نشر نسخة جديدة دون كسر الخدمة

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

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

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

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

التحديث المتداول: استبدال خادم واحد في كل مرة

التحديث المتداول هو الاستراتيجية الأكثر استخدامًا. الفكرة بسيطة: بدلاً من استبدال جميع الخوادم مرة واحدة، تستبدلها واحدًا تلو الآخر أو في دفعات صغيرة.

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

الميزة الكبيرة هنا هي أنك لا تحتاج إلى خوادم إضافية. أنت تعيد استخدام نفس البنية التحتية. التكلفة ضئيلة لأنك لا تقوم بتجهيز بيئات مكررة.

هذا ما يبدو عليه التحديث المتداول في ملف Kubernetes Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    spec:
      containers:
        - name: app
          image: my-app:2.0.0

يضمن هذا التكوين إنشاء Pod جديد واحد فقط في كل مرة (maxSurge: 1) وعدم إيقاف أي Pods قديمة حتى يصبح الجديد جاهزًا (maxUnavailable: 0). يتم التحديث Pod تلو الآخر، مع الحفاظ على توفر الخدمة طوال الوقت.

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

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

النشر الأزرق/الأخضر: بيئتان كاملتان

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

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

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

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

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

النشر الكناري: الاختبار على مجموعة صغيرة أولاً

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

تراقب تلك المجموعة الصغيرة لبعض الوقت. إذا ظل معدل الخطأ طبيعيًا، وأوقات الاستجابة جيدة، ولم يبلغ أحد عن مشاكل، تزيد النسبة. ربما إلى 20 بالمائة. ثم 50 بالمائة. ثم 100 بالمائة.

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

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

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

اختيار الاستراتيجية المناسبة

لا توجد استراتيجية واحدة أفضل. كل واحدة تناسب موقفًا مختلفًا.

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

flowchart TD A[أي استراتيجية نشر؟] --> B{هل يمكنك تحمل بنية تحتية مزدوجة؟} B -->|نعم| C{هل تحتاج استرجاع فوري؟} B -->|لا| D{هل التغيير متوافق مع الإصدارات السابقة؟} C -->|نعم| E[النشر الأزرق/الأخضر] C -->|لا| F{هل لديك مراقبة في الوقت الفعلي؟} F -->|نعم| G[النشر الكناري] F -->|لا| E D -->|نعم| H[التحديث المتداول] D -->|لا| I{هل لديك مراقبة في الوقت الفعلي؟} I -->|نعم| G I -->|لا| E

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

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

الكناري هو الأكثر حذرًا. استخدمه عندما تريد مراقبة تأثير التغيير قبل الالتزام به. يتطلب مراقبة جيدة وعملية لاتخاذ قرار بشأن متى تزيد النسبة.

تبدأ العديد من الفرق بالتحديثات المتداولة وتنتقل إلى الأزرق/الأخضر أو الكناري مع ازدياد أهمية تطبيقهم ونمو قاعدة مستخدميهم. الاستراتيجية التي تختارها اليوم لا يجب أن تكون هي نفسها التي تستخدمها إلى الأبد.

قائمة تحقق عملية قبل الاختيار

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

ما هو الأكثر أهمية

الاستراتيجية ليست الجزء الصعب. الجزء الصعب هو فهم سلوك تطبيقك أثناء الانتقال. هل يتعامل مع تشغيل نسختين في نفس الوقت؟ هل يمكنه تحمل فترة قصيرة من عقود API المختلطة؟ هل لديك القدرة على المراقبة لاكتشاف المشاكل قبل أن يبلغ عنها المستخدمون؟

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

النشر لا يتعلق بنقل البتات من مكان إلى آخر. إنه يتعلق بإبقاء مستخدميك سعداء بينما تحسن المنتج. الاستراتيجية الصحيحة تجعل ذلك ممكنًا. الخاطئة تجعله مؤلمًا.