DomiraTechnology & Digital Development استشارة مجانية

معمارية الخلفية: قرارات تحدد سقف نظامك قبل أن تكتب سطرا

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

فهرس المقالة
  1. فصل الطبقات
  2. المهام الخلفية
  3. التصميم للفشل
  4. الحالة والجلسات
  5. تجنب الهندسة الزائدة
خلاصة سريعة
  • افصل منطق العمل عن الإطار وقاعدة البيانات — هو الأصل الباقي.
  • المهام الطويلة تنفذ في الخلفية لا داخل نداء المستخدم.
  • صمم للفشل: كل نداء خارجي قد يتأخر أو يسقط.
  • لا تبن لحجم لن تبلغه — الهندسة الزائدة تكلفة اليوم.

فصل الطبقات

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

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

المهام الخلفية

  • إرسال البريد والرسائل — لا تجعل المستخدم ينتظر مزود الرسائل.
  • توليد التقارير والملفات الكبيرة.
  • معالجة الصور والملفات المرفوعة.
  • المزامنة مع أنظمة خارجية بطيئة أو غير موثوقة.
  • المهام المجدولة: التذكيرات، والفوترة الدورية، والتنظيف.

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

التصميم للفشل

  1. مهلة زمنية لكل نداء خارجي — النداء بلا مهلة يجمد النظام عند تعطل الطرف الآخر.
  2. إعادة محاولة بفواصل متزايدة للأخطاء العابرة، لا لكل خطأ.
  3. قاطع دائرة يوقف النداء مؤقتا عند فشل متكرر بدل مضاعفة الضغط.
  4. عمليات قابلة للتكرار بلا أثر مضاعف — فالرسالة قد تصل مرتين.
  5. تدهور متدرج: عطل خدمة ثانوية لا يسقط الصفحة كلها.

الحالة والجلسات

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

تجنب الهندسة الزائدة

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

أسئلة شائعة

متى نحتاج طابور مهام؟

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

كيف نستعد للتوسع بلا مبالغة؟

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

هل نستعمل ذاكرة تخزين مؤقت؟

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

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