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

فريق يستعد لنشر ميزة جديدة. تحديث خدمة API يمر بسلاسة - بضع ثوانٍ من الاستبدال التدريجي، بدون توقف. ثم يأتي تحديث العامل (Worker). شخص ما يضغط على زر النشر، وفجأة تختفي جميع مهام معالجة الصور المجدولة. الفريق يحدق في السجلات، مرتبكًا. "لقد نجح الأمر مع API. لماذا تعطل العامل؟"

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

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

خدمات API: تستمع دائمًا، متاحة دائمًا

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

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

flowchart TD A[كيف تتلقى الخدمة العمل؟] --> B[طلب] A --> C[قائمة انتظار] A --> D[جدولة] A --> E[تيار] B --> F[خدمة API] F --> G[تحديث تدريجي / أزرق-أخضر / كناري] C --> H[عامل] H --> I[إيقاف آمن بعد اكتمال المهمة] D --> J[مجدول] J --> K[منع التداخل، استخدام أقفال موزعة] E --> L[مستهلك] L --> M[تأكيد الإزاحة عند الإيقاف الآمن]

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

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

العمال: معالجة المهام، وليس الطلبات

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

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

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

يتوقع Deployment في Kubernetes أن يعمل إلى الأبد ويستخدم فحوصات الجاهزية لإدارة حركة المرور. على النقيض من ذلك، يعمل Job حتى الاكتمال ويستخدم restartPolicy: Never:

# خدمة API - تعمل إلى الأبد، تحتاج فحص جاهزية
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
      - name: api
        image: myapp/api:latest
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
---
# عامل - يعمل مهمة واحدة، ثم يخرج
apiVersion: batch/v1
kind: Job
metadata:
  name: image-resize-job
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: worker
        image: myapp/worker:latest
        command: ["process-queue"]

المجدولون: التوقيت هو كل شيء

يقوم المجدولون بتشغيل المهام وفقًا لجدول زمني. تنظيف البيانات القديمة في منتصف الليل. المزامنة مع نظام خارجي كل ساعة. إنشاء تقارير يومية في الساعة 6 صباحًا.

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

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

المستهلكون: مواكبة التيار

المستهلكون مشابهون للعمال، لكنهم يعالجون تيارًا مستمرًا من البيانات. يقرؤون من وسطاء الرسائل مثل Kafka أو RabbitMQ، ويعالجون الرسائل في الوقت الفعلي، وغالبًا ما يحتاجون إلى الحفاظ على موقعهم في التيار.

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

بالنسبة لـ CI/CD، هذا يعني أن النشر يجب أن يتعامل مع تأكيدات الإزاحة بعناية. إيقاف تشغيل المستهلك دون تأكيد الإزاحة الحالية يمكن أن يتسبب في إعادة معالجة الرسائل التي تمت معالجتها بالفعل. إعادة التشغيل من الإزاحة الخاطئة يمكن أن يتخطى الرسائل أو يعالجها مرتين. يحتاج خط الأنابيب إلى التنسيق مع وسيط الرسائل لضمان إيقاف آمن واستئناف.

الخدمات الداخلية: التبعيات المخفية

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

الخطر مع الخدمات الداخلية هو الأعطال المتتالية. تغيير صغير في خدمة مصادقة يمكن أن يكسر كل خدمة تستدعيها. استجابة بطيئة من خدمة تكوين يمكن أن تسبب مهلاً زمنية عبر النظام بأكمله.

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

قائمة مراجعة عملية لخطوط أنابيب خدمات الواجهة الخلفية

قبل تصميم خط أنابيب لأي خدمة واجهة خلفية، اطرح هذه الأسئلة:

  • كيف تتلقى هذه الخدمة العمل؟ (طلب، قائمة انتظار، جدولة، تيار)
  • هل يمكن إيقافها بأمان في منتصف المهمة؟ إذا كان الأمر كذلك، ماذا يحدث للمهمة؟
  • هل تحتفظ بأي حالة في الذاكرة لا يمكن استردادها؟
  • ماذا يحدث إذا قامت نسختان بتشغيل نفس المهمة في وقت واحد؟
  • ما هي الخدمات الأخرى التي تتعطل إذا تعطلت هذه الخدمة؟
  • كم من الوقت يمكن أن تكون هذه الخدمة غير متاحة قبل أن يلاحظ المستخدمون أو الأنظمة ذلك؟

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

الخلاصة

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

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