أنظمة خلفية تتحمل الضغط وتحفظ اتساق البيانات وتصمد أمام الأعطال
تتناول هندسة الأنظمة الخلفية قلب المنصة: نموذج مجال العمل، وقاعدة البيانات، والمهام التي تجري في الخلفية، وطوابير الرسائل، والتخزين المؤقت، والخدمات التي تربط ذلك كله. وهي الخيار المناسب حين يعالج منتجك أموالاً أو طلبات أو بيانات أجهزة استشعار أو أحمال عمل مشابهة، يكون فيها الحجم كبيراً، وتجري الخطوات بشكل غير متزامن، ويكون لضياع عملية أو تكرارها عواقب حقيقية.
نبدأ بنموذج البيانات وحالات الفشل، لأن تغيير أي منهما لاحقاً مكلف. ونعتمد افتراضياً نظاماً واحداً مقسّماً إلى وحدات، ولا نفصل خدمات مستقلة إلا حيث يتطلب ذلك التوسع أو حدود الفرق. ونصمم العمليات بحيث لا يغيّر تكرارها النتيجة، ونزوّد الطوابير بمعالجة للرسائل المتعثرة، ونختبر النظام قبل الإطلاق تحت حركة استخدام واقعية، فتكون حدوده معروفة مسبقاً، لا مفاجأة تُكتشف لاحقاً.
نمذجة المجال والبيانات
نصمم مخططات البيانات والقيود والفهارس وحدود المعاملات على أساس طريقة عمل شركتك، مع ملفات ترحيل تُطبَّق بأمان على قاعدة البيانات وهي قيد التشغيل.
بنية قائمة على الأحداث
خدمات تتواصل عبر Kafka أو RabbitMQ، مع نمط صندوق الصادر، ومعالِجات لا يتأثر عملها بتكرار الرسالة، وطوابير للرسائل المتعثرة، فلا تضيع رسالة ولا تُطبَّق مرتين.
المعالجة في الخلفية
طوابير للمهام وأدوات للجدولة ومحركات لسير العمل تتولى الأعمال الطويلة، مثل استيراد البيانات ودورات الفوترة والإشعارات، مع إعادة المحاولة بفواصل زمنية متزايدة، ورؤية واضحة لحالة كل مهمة.
الأداء والتخزين المؤقت
نحلل خطط تنفيذ الاستعلامات، ونضيف الفهارس، ونخزّن المسارات الأكثر استخداماً مؤقتاً في Redis، ونضيف نسخاً للقراءة من قاعدة البيانات حيث يلزم، ونقيس كل تغيير قبله وبعده مقارنةً بخط أساس.
مسارات البيانات الفورية
نستقبل البيانات المتدفقة ونحوّلها ونوصلها إلى لوحات البيانات الحية والتتبع والتنبيهات، مع ضبط تدفقها عند الضغط، فتُبطئ موجة البيانات المفاجئة المسار بدلاً من أن تعطّله.
تحديث الأنظمة القديمة
نستبدل الأنظمة القديمة جزءاً بعد جزء خلف واجهة ثابتة، وننقل البيانات على مراحل، ونقارن النسختين في بيئة التشغيل الفعلية قبل إيقاف القديمة.
ما تتسلمه منا
- الشيفرة المصدرية للخدمات الخلفية
- مخطط قاعدة البيانات وملفات الترحيل
- سجلات قرارات البنية التقنية
- اختبارات الوحدات والتكامل والحمل
- نتائج اختبارات الحمل والحدود المقيسة
- إعدادات الطوابير وعمليات المعالجة في الخلفية
- التتبع والسجلات وقواعد التنبيه
- دليل تشغيل للمهندسين المناوبين
طريقة عملنا
- 01
نمذجة مجال العمل
نراجع مع فريقك قواعد العمل وأحجام البيانات ومتطلبات الاتساق، ثم ندوّن الكيانات والأحداث والعمليات التي لا يجوز أن تضيع أو تتكرر أبداً.
- 02
تحديد البنية
نختار حدود الخدمات والتخزين والمراسلة والاستضافة، ونسجل كل اختيار في سجل قرار قصير يذكر البدائل التي درسناها والمفاضلة التي قبلناها، ليفهم المهندسون الذين يأتون بعدنا أسباب كل قرار.
- 03
البناء جزءاً بعد جزء
نسلّم مساراً كاملاً واحداً في كل مرة، من الطلب إلى قاعدة البيانات إلى الحدث، ومعه الاختبارات والتتبع. وننشر كل جزء في بيئة الاختبار ونراجعه قبل أن نبدأ التالي.
- 04
الاختبار تحت الضغط
قبل الإطلاق نجري اختبارات الحمل والأعطال، ومنها تحويل قاعدة البيانات إلى نسختها البديلة وتوقف أحد الطوابير عن العمل، ثم نوثّق الحدود التي قسناها ونشاركها معك. وعلى هذه النتائج نبني إعدادات السعة والتنبيهات التي نضبطها.
التقنيات التي نستخدمها
| المجال | التقنيات |
|---|---|
| لغات البرمجة | Node.js، TypeScript، Python، Go |
| البيانات | PostgreSQL، MySQL، MongoDB، Redis |
| المراسلة | Apache Kafka، RabbitMQ، Amazon SQS، gRPC |
| التشغيل | Docker، Kubernetes، OpenTelemetry، k6، AWS Lambda |
نظامك الخلفي يتعثر كلما زاد الاستخدام
تنتهي مهلة الطلبات في ساعات الذروة، وتتراكم المهام في الخلفية، ولا يعرف أحد على وجه اليقين لماذا حُفظ السجل نفسه مرتين. كان النظام يعمل جيداً بحجم الاستخدام عند الإطلاق، أما الآن فيحتاج إلى نموذج بيانات أوضح، وطوابير سليمة، وسعة مقيسة قبل مرحلة النمو التالية.
- معالجة المدفوعات والطلبات
- استقبال كميات كبيرة من البيانات
- الأنظمة الخلفية لمنصات البرمجيات كخدمة (SaaS) متعددة العملاء
- تقسيم نظام أحادي بطيء
- التكامل مع أنظمة تخطيط موارد المؤسسات (ERP)
- التتبع المباشر والإشعارات
أسئلة شائعة
هل نبني خدمات مصغّرة أم نحتفظ بنظام أحادي؟
يخدم النظام الأحادي حسن البنية معظم المنتجات مدة أطول مما يُتوقع عادةً. فهو أسهل في النشر والاختبار والفهم، وحدود الوحدات الواضحة داخله تُبقي خيار التقسيم متاحاً لاحقاً. أما الخدمات المصغّرة فتصبح منطقية حين تتفاوت أجزاء النظام كثيراً في حاجتها إلى التوسع، أو حين تحتاج فرق منفصلة إلى إصدار تحديثاتها باستقلال، أو حين يتطلب أحد المكونات تقنية مختلفة. ونوصي بأقل عدد من الخدمات يحل المشكلة الفعلية.
أي لغة تنصحون بها: Node.js أم Python أم Go؟
نختار بحسب طبيعة العمل ومن سيتولى صيانة الشيفرة. فـNode.js مع TypeScript يناسب المنتجات التي تتشارك تعريفات أنواع البيانات والمهندسين مع واجهة أمامية مبنية بـReact. وPython يناسب معالجة البيانات وكل ما يقترب من تعلّم الآلة. أما Go فيناسب الخدمات التي تتعامل مع عدد كبير من العمليات المتزامنة وتحتاج إلى زمن استجابة منخفض جداً. وإن كانت لدى فريقك خبرة عميقة في إحداها، فهذا يفوق عادةً أهمية الفروق التقنية.
هل يمكنكم معالجة مشكلات الأداء في نظام خلفي نشغّله حالياً؟
نعم. نبدأ بإضافة التتبع وتسجيل الاستعلامات، لأن التخمين في مسائل الأداء يخطئ في الغالب. وحين تتوفر القياسات نعالج أكبر مصادر الكلفة، وهي عادةً فهارس ناقصة، واستعلامات تتكرر داخل الحلقات البرمجية، وأعمال تُنفَّذ داخل الطلب وكان مكانها الطابور، وغياب التخزين المؤقت. ونتحقق من كل إصلاح بمقارنته بخط الأساس. ثم نعرض عليك ما وجدناه وما تبقى قبل أن نقترح أي إعادة هيكلة أكبر.
كيف تحافظون على اتساق البيانات بين الخدمات والطوابير؟
نُبقي البيانات المترابطة بقوة في قاعدة بيانات واحدة ومعاملة واحدة كلما أمكن ذلك. وحين يتحتم أن يعبر العمل حدود خدمة أو طابور، نستخدم نمط صندوق الصادر، فلا تُنشر الرسالة إلا إذا ثُبّت التغيير في قاعدة البيانات، ونصمم كل معالج للرسائل بحيث لا يُحدث وصول الرسالة نفسها مرة ثانية أي أثر إضافي. كما تقارن مهام المطابقة بين الأنظمة وفق جدول زمني، وتطلق تنبيهاً عند أي اختلاف.
كيف يُحدَّد نطاق مشروع النظام الخلفي وجدوله الزمني؟
يعتمد الاثنان على حجم مجال العمل، والتكاملات المطلوبة، والحمل الذي يجب أن يتحمله النظام، لذلك لا نقدّم سعراً قبل أن نفهم هذه العناصر. وبعد استشارة تحديد النطاق المجانية، نُعدّ عرضاً يحدد ما سنبنيه، والمراحل الرئيسية، والافتراضات، وجدولاً زمنياً واضحاً. ولا يبدأ العمل إلا بعد أن توافق على هذا العرض، ونناقش أي تغيير في النطاق بوضوح عند ظهوره.