أساسيات تصميم الأنظمة

اللبنات الأساسية لأي نظام

18 دقيقة الدرس 8 من 10

اللبنات الأساسية لأي نظام

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

المكونات الخمسة الأساسية

قبل الغوص في التفاصيل، انظر كيف تتضافر هذه المكونات في تطبيق ويب نموذجي ثقيل القراءة:

كيف تتكامل المكونات الخمسة الأساسية في تطبيق ويب نموذجي.

١. موازن الحمل (Load Balancer)

يجلس موازن الحمل أمام مجموعة من الخوادم ويوزّع الطلبات الواردة بحيث لا يصبح أي خادم عنق الزجاجة. كذلك يعمل كنقطة دخول عامة وحيدة تُخفي البنية الداخلية عن العملاء.

الطبقة الرابعة (النقل): يوجّه الطلبات بناءً على IP/المنفذ — سريع جدًا لكنه لا يستطيع فحص محتوى الطلب.
الطبقة السابعة (التطبيق): يوجّه حسب URL أو الترويسات أو الكوكيز — يدعم التوجيه بالمسار وإنهاء SSL.
خوارزميات التوزيع: round-robin، أقل اتصال، IP-hash (جلسات لاصقة)، موزونة.

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

أمثلة حقيقية: AWS ALB (طبقة 7)، AWS NLB (طبقة 4)، Nginx، HAProxy، Cloudflare.

٢. ذاكرة التخزين المؤقت (Cache)

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

Cache-aside (التحميل الكسول): يتحقق التطبيق من الكاش أولًا؛ عند الفشل يقرأ من قاعدة البيانات ويخزّن النتيجة. الأكثر شيوعًا.
Write-through: تُكتب البيانات في الكاش وقاعدة البيانات في آنٍ واحد. الكاش دائمًا محدّث لكن ذلك يزيد زمن استجابة الكتابة.
Write-behind: تُكتب البيانات في الكاش فقط، وتُحدَّث قاعدة البيانات بشكل غير متزامن. كتابة سريعة جدًا مع خطر فقدان البيانات عند تعطل الكاش.

ضع مدة انتهاء صلاحية (TTL) على كل إدخال في الكاش. بدون انتهاء صلاحية ستقدّم بيانات قديمة إلى الأبد. 5–60 ثانية شائعة للبيانات المتغيرة، وساعات أو أيام للبيانات المستقرة (كقوائم المنتجات).

المقاييس الرئيسية: معدل الإصابة (استهدف أكثر من 90% على المسارات الساخنة)، سياسة الإخلاء (LRU هو الاختيار الآمن الافتراضي). أمثلة حقيقية: Redis، Memcached، Varnish.

انهيار الكاش (Cache Stampede): عند انتهاء صلاحية إدخال شائع، تُطلق مئات الطلبات المتزامنة ضربةً واحدة على قاعدة البيانات. تجنّب ذلك بالانتهاء الاحتمالي المبكر، أو قفل mutex عند إعادة الحساب، أو قفل موزّع عبر Redis SETNX.

٣. قاعدة البيانات (Database)

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

العلائقية (SQL): ضمانات ACID قوية، لغة استعلام غنية، الأفضل للبيانات المنظمة ذات العلاقات المعقدة. PostgreSQL، MySQL، Aurora.
الوثائقية (NoSQL): مخطط مرن، قابلية توسع أفقي، مناسبة للبيانات الهرمية/JSON. MongoDB، DynamoDB، Firestore.
النسخ المقروءة (Read Replicas): نسخة احتياطية من القاعدة الأساسية تخدم عمليات القراءة. تمتص 80-95% من حركة البيانات في التطبيقات الثقيلة بالقراءة مع تأخير نسخ صغير (أقل من 100 ميلي ثانية عادةً).
التجزئة (Sharding): تقسيم البيانات أفقيًا عبر عدة عقد قاعدة بيانات. يزيد معدل الكتابة بشكل كبير لكنه يضيف تعقيدًا تشغيليًا كبيرًا.

لا تُجزّئ قبل الأوان. معظم الأنظمة التي جزّأت مبكرًا ندمت على ذلك. ابدأ بقاعدة أساسية مع نسخة مقروءة. لجأ إلى التجزئة فقط عند وجود دليل واضح على أن عقدة واحدة لا تستطيع مواكبة حجم الكتابة.

٤. قائمة الانتظار (Message Queue)

قائمة الانتظار تفصل المكوّن الذي ينتج وحدة عمل عن المكوّن الذي يعالجها. يُرسل المنتج رسالة ويعود فورًا؛ تعالجها مستهلك واحد أو أكثر بشكل غير متزامن في الخلفية.

هذا مفيد عند وجود:

أحمال متفجرة: موجة مفاجئة من 10,000 طلب تغيير حجم صورة لا تُغرق الخدمة — تمتص قائمة الانتظار الموجة والعمال يستنزفونها بتمهّل.
مهام طويلة: إرسال البريد الإلكتروني، ترميز الفيديو، توليد PDF — كل ما هو بطيء جدًا لإتمامه بشكل متزامن في طلب HTTP.
الموثوقية: إذا تعطّل المستهلك، لا تضيع الرسالة — تبقى في قائمة الانتظار وتُعاد المحاولة.

صمّم للتوافرية (Idempotency). قد يُسلَّم نفس الرسالة أكثر من مرة (الافتراضي في معظم قوائم الانتظار هو at-least-once). يجب أن يتعامل مستهلكك مع التسليم المكرر بأمان — مثلًا بالتحقق من إنجاز العمل مسبقًا قبل البدء فيه مجددًا.

أمثلة حقيقية: Apache Kafka (تدفق الأحداث)، Amazon SQS (قوائم موثوقة بسيطة)، RabbitMQ (pub-sub/التوجيه)، Celery (قائمة مهام لـ Python/PHP).

٥. شبكة توصيل المحتوى (CDN)

شبكة CDN هي شبكة موزعة عالميًا من خوادم الحافة (نقاط الوجود - PoPs) تُخزّن المحتوى مؤقتًا وتقدّمه من موقع جغرافي قريب من المستخدم. بدلًا من جلب كل مستخدم حزمة JavaScript بحجم 1 ميغابايت من خادمك الأصلي في Virginia، يحصل مستخدم في طوكيو عليها من نقطة وجود تبعد 20 ميلي ثانية.

تقديم الأصول الثابتة: الصور، CSS، JS، الخطوط — الاستخدام الأساسي. ترويسات Cache-Control تُخبر الـ CDN بمدة الاحتفاظ بالملف.
تسريع المحتوى الديناميكي: شبكات CDN الحديثة (Cloudflare، Fastly) يمكنها تخزين ردود API مؤقتًا بـ TTL قصير، أو توجيه الطلبات الديناميكية عبر شبكات عمود فقري محسّنة.
حماية DDoS: تمتص عقد الحافة الهجمات الحجمية قبل أن تصل إلى خادمك الأصلي.

تخدم عقد حافة CDN الأصول المخزّنة مؤقتًا من نقاط وجود قريبة. فقط عند فشل الكاش يتنقل الطلب إلى الخادم الأصلي.

أمثلة حقيقية: Cloudflare، AWS CloudFront، Fastly، Akamai.

كيف تختار: الحكمة العملية

عند تصميم نظام ووصولك إلى عنق زجاجة، اسأل نفسك:

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

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