04 يونيو 2025·8 دقيقة
لماذا يكون التوسع الأفقي أصعب من التوسع العمودي
التوسع العمودي عادةً مجرد إضافة CPU/RAM. التوسع الأفقي يحتاج تنسيقًا، تقسيمًا للبيانات، ضمان الاتساق، والمزيد من العمل التشغيلي — لماذا هو أصعب.
التوسع العمودي عادةً مجرد إضافة CPU/RAM. التوسع الأفقي يحتاج تنسيقًا، تقسيمًا للبيانات، ضمان الاتساق، والمزيد من العمل التشغيلي — لماذا هو أصعب.
التوسع يعني "التعامل مع المزيد دون الانهيار". ذلك "المزيد" قد يكون:
عند الحديث عن التوسع، يحاول الناس عادة تحسين واحد أو أكثر من هذه النقاط:
معظم هذا يعود إلى فكرة واحدة: التوسع العمودي يحافظ على إحساس "النظام الواحد"، بينما التوسع الأفقي يحول نظامك إلى مجموعة من الآلات المستقلة المتنسقة — وهنا تنفجر صعوبات التنسيق.
يعني جعل آلة واحدة أقوى. تحتفظ بنفس البنية الأساسية لكن ترفع مواصفات الخادم (مزيد من أنوية CPU، مزيد من RAM، أقراص أسرع، عرض نطاق أعلى).
فكر فيه مثل شراء شاحنة أكبر: لا يزال لديك سائق واحد ومركبة واحدة، لكنها تحمل أكثر.
يعني إضافة المزيد من الآلات أو النسخ وتقسيم العمل عبرها — غالبًا خلف موازن تحميل. بدلًا من خادم أقوى واحد، تشغل عدة خوادم تعمل معًا.
هذا مثل استخدام عدة شاحنات: يمكنك نقل شحنات أكثر لكن الآن لديك جدولة، توجيه، وتنسيق لتدبيرها.
المحفزات الشائعة تشمل:
الفرق فرق؛ الفرق أن الفرق عادةً ما يزيد السعة أولا لأنه سريع (ترقية الصندوق)، ثم يتوسع أفقياً عندما تصل الآلة الواحدة إلى حدودها أو عندما تحتاج إلى توافر أعلى. البُنى الناضجة تخلط بين الاثنين: عقد أكبر ومزيد من العقد حسب عنق الزجاجة.
التوسع العمودي جذّاب لأنه يبقي نظامك في مكان واحد. في عقدة واحدة عادةً ما يوجد مصدر واحد للحقيقة للحالة المحلية والذاكرة. عملية واحدة تملك الكاش في الذاكرة، قائمة المهام، مخزن الجلسات (إن كانت في الذاكرة)، والملفات المؤقتة.
على خادم واحد، معظم العمليات مباشرة لأن التنسيق بين العقد قليل أو منعدم:
عند التوسع عموديًا، تسحب مقابض مألوفة: أضف CPU/RAM، استخدم تخزينًا أسرع، حسّن الفهارس، اضبط الاستعلامات والإعدادات. لا تحتاج إلى إعادة تصميم كيفية توزيع البيانات أو كيفية اتفاق العقد المتعددة على "ما يحدث تاليًا".
التوسع العمودي ليس "مجانيًا" — لكنه يبقي التعقيد محصورًا.
في النهاية تصل إلى حدود: أكبر نُسخة يمكنك استئجارها، عوائد متناقصة، أو منحنى تكلفة حاد في الطرف الأعلى. كما قد تتحمل مخاطرة توقف أكبر: إذا فشلت الآلة الكبيرة أو احتاجت لصيانة، يذهب جزء كبير من النظام معها ما لم تكن أضفت تكرارًا.
عند التوسع أفقيًا، لا تحصل فقط على "مزيد من الخوادم". تحصل على مزيد من الجهات المستقلة التي يجب أن تتفق على من هو مسؤول عن كل قطعة عمل، ومتى، وباستخدام أي بيانات.
في آلة واحدة، التنسيق غالبًا ضمني: مساحة ذاكرة واحدة، عملية واحدة، مكان واحد للبحث عن الحالة. مع العديد من الآلات، يصبح التنسيق ميزة يجب تصميمها.
الأدوات والأنماط الشائعة تشمل:
أخطاء التنسيق نادرًا ما تبدو كتعطل واضح. غالبًا ترى:
تظهر هذه المشكلات عادةً فقط تحت حمل حقيقي، أثناء النشر، أو عند حدوث إخفاقات جزئية (عقدة بطيئة، مقطع يقطّع الحزم، منطقة واحدة تعاني). يبدو النظام سليمًا — حتى يتعرض للضغط.
عند التوسع، غالبًا لا يمكنك الاحتفاظ بكل بياناتك في مكان واحد. تقسمها عبر الآلات (شاردات) حتى يمكن لعدة عقد تخزين وبدء الخدمة بشكل متوازي. هذا التقسيم هو المكان الذي تبدأ فيه التعقيدات: كل قراءة وكتابة تعتمد على "أي شارد يحتوي هذا السجل؟"
التقسيم بنطاق (range partitioning) يجمع البيانات حسب مفتاح مرتب (مثلاً: المستخدمون A–F على شارد 1، G–M على شارد 2). بديهي ويدعم استعلامات النطاق جيدًا ("عرض الطلبات من الأسبوع الماضي"). العيب هو الحمل غير المتساوي: إذا أصبح نطاق واحد شائعًا، يصبح الشارد عنق زجاجة.
التجزئة (hash partitioning) تمرّر المفتاح عبر دالة هاش وتوزع النتائج عبر الشاردات. يوزع الحركة بشكل أكثر تساويًا لكنه يجعل استعلامات النطاق أصعب لأن السجلات المرتبطة متناثرة.
إضافة عقدة وتريد استخدامها — يعني ذلك نقل بعض البيانات. إزالة عقدة (مخططًا أو بسبب فشل) وتعويضها يعني أن شاردات أخرى تتولى المهمة. إعادة التوازن قد تُشغّل نقلًا كبيرًا، تسخين الكاش، وانخفاضات مؤقتة في الأداء. خلال النقل تحتاج لمنع القراءات القديمة والكتابات الموجهة خطأ.
حتى مع التجزئة، حركة المرور الحقيقية ليست موزعة بالتساوي. حساب مشهور، منتج شائع، أو أنماط وصول زمنية قد تركز القراءات/الكتابات على شارد واحد. شارد ساخن قد يحدد سقف معدل التدفق للنظام كله.
الشاردينغ يُدخل مسؤوليات مستمرة: الحفاظ على قواعد التوجيه، تشغيل الترحيلات، تنفيذ backfills بعد تغييرات المخطط، والتخطيط للانقسامات/الدمج دون كسر العملاء.
عند التوسع أفقيًا، لا تضيف فقط خوادم أكثر — بل تضيف نسخًا أكثر من تطبيقك. الجزء الصعب هو الحالة: أي شيء يَتذكّره تطبيقك بين الطلبات أو أثناء تنفيذ العمل.
إذا سجل المستخدم الدخول على الخادم A لكن الطلب التالي يصل إلى الخادم B، هل يعرف B من هو؟
تسرّع الكاش الأمور، لكن عدة خوادم تعني عدة كاشات. الآن تتعامل مع:
مع عدة عمال، قد تُنفَّذ المهام مرتين ما لم تصمم لها. عادة تحتاج إلى قائمة انتظار، استئجارات/أقفال، أو منطق مهام idempotent حتى لا يحدث "إرسال فاتورة" أو "سحب بطاقة" مرتين — خصوصًا أثناء إعادة المحاولات وإعادة التشغيل.
مع عقدة واحدة (أو قاعدة بيانات أولية واحدة)، عادةً يوجد "مصدر حقيقي واحد للحقيقة". عند التوسع، تنتشر البيانات والطلبات عبر الآلات، والحفاظ على تزامن الجميع يصبح همًا مستمرًا.
الاتساق النهائي غالبًا أسرع وأرخص على نطاق واسع، لكنه يقدّم حالات طرفية مفاجئة.
مشكلات شائعة تشمل:
لا يمكنك القضاء على الفشل، لكن يمكنك التصميم لتحمّل الضرر:
معاملة عبر خدمات (طلب + مخزون + دفع) تتطلب اتفاق أنظمة متعددة. إذا فشل أحد الخطوات في منتصف الطريق، تحتاج إلى إجراءات تعويضية وحساب دقيق. سلوك "الكل أو لا شيء" الكلاسيكي صعب عند فشل الشبكات والعقد بشكل مستقل.
استخدم الاتساق القوي للأشياء التي يجب أن تكون صحيحة: المدفوعات، أرصدة الحسابات، جِدَولات المخزون، حجز المقاعد. للبيانات الأقل أهمية، الاتساق النهائي غالبًا مقبول.
عند التوسع عموديًا، كثير من "النداءات" تكون استدعاءات دوال داخل نفس العملية: سريعة ومتوقعة. عند التوسع أفقيًا، نفس التفاعل يصبح نداءً شبكيًا — يضيف زمنًا، تذبذبًا، وأنماط فشل يجب أن يتعامل معها الكود.
نداءات الشبكة لها وقت ثابت (تسلسل/تسلسل بايت، انتظار، قفزات) وزمن متغير (الازدحام، التوجيه، جار مزعج). حتى إذا كان متوسط الكمون جيدًا، فإن الكمون الذائلي (tail latency) يمكن أن يهيمن على تجربة المستخدم لأن تباطؤ اعتمادية واحدة يعيق الطلب كله.
سعة النطاق وفقد الحزم تصبح أيضًا قيودًا: عند معدلات طلب عالية، الحمولة الصغيرة تتراكم، وإعادة الإرسال تزيد الحمل بصمت.
بدون مهلات زمنية، تتراكم النداءات البطيئة والخيوط تُعلق. بوجود مهلات زمنية وإعادة محاولات، يمكنك التعافي — حتى تضخم الإعادات الحمولة.
نمط فشل شائع هو عاصفة الإعادات: أحد الخلفيات يتباطأ، العملاء ينتهون مهلاتهم ويعيدون المحاولة، الإعادات تزيد الحمولة، والخلفية تبطأ أكثر.
إعادة المحاولات الآمنة عادةً تتطلب:
مع نسخ متعددة، يحتاج العملاء لمعرفة أين يرسلون الطلبات — عبر موازن تحميل أو اكتشاف خدمة مع موازنة جانب العميل. في كلتا الحالتين تضيف أجزاء متحركة: فحوصات صحة، تفريغ اتصالات، توزيع حركة غير متساوية، وخطر التوجيه إلى نسخة نصف مكسورة.
لمنع انتشار التحميل الزائد، تحتاج ضغطًا عكسيًا: قوائم انتظار محدودة، قواطع دوائر، وتحديد معدلات. الهدف هو الفشل السريع والمتوقع بدلًا من السماح لتباطؤ صغير أن يتحول لحادث شامل.
التوسع العمودي يميل إلى الفشل بطريقة مباشرة: آلة أكبر لا تزال نقطة واحدة. إذا تباطأت أو تعطل، التأثير واضح.
التوسع الأفقي يغير الحساب. مع العديد من العقد، من الطبيعي أن تكون بعض الآلات غير صحية بينما الأخرى بخير. النظام "متاح"، لكن المستخدمين قد يرون أخطاء، صفحات بطيئة، أو سلوك غير متسق. هذا هو الفشل الجزئي ويصبح الحالة الافتراضية التي تصمم لها.
في إعداد موزع، تعتمد الخدمات على خدمات أخرى: قواعد بيانات، كاشات، قوائم انتظار، واجهات API خارجية. مشكلة صغيرة قد تنتشر:
للبقاء على قيد الحياة من الفشل الجزئي، تضيف أنظمة التكرار:
هذا يزيد التوفر لكنه يقدّم حالات طرفية: split-brain، نسخ قديمة، وقرارات عند عدم الوصول للأصوات.
الأنماط الشائعة تشمل:
مع آلة واحدة، "قصة النظام" تعيش في مكان واحد: سجلات واحدة، رسم بياني CPU واحد، عملية واحدة للتفتيش. مع التوسع الأفقي، القصة مشتتة.
كل عقدة إضافية تضيف تدفقًا آخر من السجلات، المقاييس، والتتبعات. الجزء الصعب ليس جمع البيانات — بل ربطها. خطأ في الدفع قد يبدأ على عقدة ويب، ينادي خدمتين، يصطدم بكاش، ويقرأ من شارد محدد، تاركًا أدلة في أماكن وتوقيتات مختلفة.
المشكلات تصبح انتقائية أيضًا: عقدة واحدة بها إعداد خاطئ، شارد واحد ساخن، منطقة واحدة بها كمون أعلى. التصحيح قد يبدو عشوائيًا لأن النظام "يعمل عادةً".
التتبُّع الموزع مثل إرفاق رقم تتبع لطلب. معرّف الارتباط هو هذا الرقم؛ تمرره عبر الخدمات وتدونه في السجلات حتى تستطيع سحب معرّف واحد ورؤية الرحلة كاملة.
مزيد من المكونات عادةً يعني مزيدًا من التنبيهات. بدون ضبط، تتعرض الفرق لإرهاق التنبيهات. استهدف تنبيهات قابلة للفعل توضح:
مشكلات السعة تظهر غالبًا قبل الأعطال. راقب إشارات التشبع مثل CPU، الذاكرة، عمق القوائم، واستخدام مجموعات الاتصالات. إن ظهر التشبع على مجموعة فرعية فقط من العقد، فاشك في الموازنة، الشاردينغ، أو انجراف التكوين — لا تظن فورًا "مزيد من الحركة".
عند التوسع أفقيًا، النشر لم يعد "استبدال صندوق واحد". هو تنسيق تغييرات عبر العديد من الآلات مع إبقاء الخدمة متاحة.
النشر الأفقي غالبًا ما يستخدم تحديثات تدريجية (استبدال العقد تدريجيًا)، كيناري (إرسال نسبة صغيرة من الحركة للإصدار الجديد)، أو أزرق/أخضر (تبديل الحركة بين بيئتين مكتملتين). تقلل هذه من نطاق الضرر لكنها تضيف متطلبات: تحويل الحركة، فحوصات الصحة، تفريغ الاتصالات، وتعريف ما يكفي للمضي قدمًا.
أثناء أي نشر تدريجي، تعمل إصدارات قديمة وجديدة جنبًا إلى جنب. هذا التفاوت يعني أن نظامك يجب أن يتحمل سلوكًا مختلطًا:
الواجهات البرمجية تحتاج توافقًا خلفيًا/أماميًا، ليس فقط صحة. تغييرات مخطط قاعدة البيانات يجب أن تكون إضافة عند الإمكان (أضف أعمدة قابلة لأن تكون null قبل جعلها مطلوبة). تنسيقات الرسائل يجب أن تكون مهيأة للنسخ لتسمح للمستهلكين بقراءة كلا الحدثين القديم والجديد.
التراجع عن الكود سهل؛ التراجع عن البيانات ليس كذلك. إذا حذف ترحيل حقولًا أو أعاد كتابة بيانات، قد يتعطل الكود القديم أو يتعامل مع السجلات بشكل خاطئ. تساعد ترحيلات "توسيع/تقييد": انشر كودًا يدعم كلا المخططين، حرّك البيانات، ثم أزل المسارات القديمة لاحقًا.
مع العديد من العقد، إدارة التكوين جزء من النشر. عقدة واحدة بإعداد قديم، أو أعلام ميزات خاطئة، أو بيانات اعتماد منتهية قد تُنتج أخطاء متقطعة وصعبة الاستنساخ.
قد يبدو التوسع الأفقي أرخص على الورق: العديد من النُسخ الصغيرة كلٌ بسعر ساعة منخفض. لكن التكلفة الإجمالية ليست فقط الحوسبة. إضافة عقد يعني أيضًا المزيد من الشبكات، المراقبة، التنسيق، ووقت أكثر للحفاظ على التناسق.
التوسع العمودي يركّز الإنفاق في عدد أقل من الأجهزة — غالبًا أقل مضيفين لتصحيح الأمن، وكلائهم، سجلات لإرسال، ومقاييس للقراءة.
مع التوسع الأفقي، سعر الوحدة قد يكون أقل، لكنك غالبًا تدفع مقابل:
لمعالجة الطفرات بأمان، غالبًا تعمل الأنظمة الموزعة بنصف طاقتها. تحتفظ بقدرة احتياطية عبر طبقات متعددة (ويب، عمال، قواعد بيانات، كاش)، مما قد يعني دفع مقابل سعة غير مستغلة عبر عشرات أو مئات النسخ.
التوسع الأفقي يزيد عبء الاستدعاء على الفريق ويتطلب أدوات ناضجة: ضبط التنبيهات، كتب التشغيل، تدريبات على الحوادث، وتمارين الطوارئ. الفرق تقضي وقتًا على حدود الملكية (من يملك أي خدمة؟) وتنسيق الحوادث.
النتيجة: "أرخص لكل وحدة" قد تكون أغلى إجماليًا عند احتساب وقت الناس، مخاطر التشغيل، والعمل المطلوب لجعل العديد من الآلات تتصرف كنظام واحد.
الاختيار ليس مجرد سعر. إنه شكل عبء العمل ومقدار التعقيد التشغيلي الذي يمكن لفريقك تحمله.
ابدأ بشكل عبء العمل:
مسار شائع ومعقول:
العديد من الفرق تبقي قاعدة البيانات عموديًا (أو عنقوديًا خفيفًا) بينما توسع طبقة التطبيقات عديمة الحالة أفقيًا. هذا يحد من ألم الشاردينغ بينما يسمح بزيادة سريعة لسعة الويب.
أنت أقرب عندما يكون لديك مراقبة وتنبيهات سليمة، تعافٍ مختبر، اختبارات تحميل، ونشرات قابلة للتكرار مع تراجع آمن.
الكثير من ألم التوسع ليس مجرد "هندسة" — إنه حلقة التشغيل: التكرار الآمن، النشر الموثوق، والتراجع السريع عندما تختلف الواقع مع الخطة.
إذا كنت تبني تطبيقات ويب أو باكند أو موبايل وتريد التحرك بسرعة دون فقدان السيطرة، يمكن أن يساعدك Koder.ai في تصميم ونشر أسرع بينما تتخذ قرارات التوسع هذه. هو منصة vibe-coding حيث تبني التطبيقات عبر دردشة، مع بنية وكيل agent-based تحت الغطاء. عمليًا هذا يعني أنك تستطيع:
بما أن Koder.ai يعمل عالميًا على AWS، يمكنه أيضًا دعم نشرات في مناطق مختلفة لمراعاة الكمون وقيود نقل البيانات — مفيد عندما يصبح التوفر متعدد المناطق جزءًا من قصة التوسع لديك.
التوسع العمودي يعني جعل الجهاز الواحد أقوى (مزيد من CPU/RAM/قرص أسرع). التوسع الأفقي يعني إضافة المزيد من الأجهزة وتوزيع العمل بينها.
التوسع العمودي غالبًا ما يبدو أبسط لأن التطبيق لا يزال يتصرف كـ "نظام واحد"، بينما التوسع الأفقي يجبرك على جعل عدة أنظمة تتنسيق وتحافظ على الاتساق.
بمجرد أن يكون لديك عدة عقد، تحتاج إلى تنسيق صريح:
آلية الجهاز الواحد تتجنب الكثير من مشكلات الأنظمة الموزعة افتراضيًا، لذا التوسع الأفقي يضيف طبقة تعقيد كبيرة.
هو الوقت والطقس المنطقي الذي ينفق لجعل عدة آلات تتصرف كنظام واحد:
حتى لو كانت كل عقدة بسيطة، يصبح سلوك النظام أصعب في الفهم عند الضغط ووجود فشل.
التقسيم (الشاردينغ) يوزع البيانات عبر عقد حتى لا يخزن أو يخدم جهاز واحد كل شيء. الصعوبة تكمن في:
كما يزيد العمل التشغيلي (التجهيزات، الترقيعات، خرائط الشارد).
الحالة هي أي شيء يتذكره التطبيق بين الطلبات أو أثناء تقدم العمل (جلسات، كاش في الذاكرة، ملفات مؤقتة، تقدم الوظائف).
مع التوسع الأفقي، قد تصل الطلبات إلى خوادم مختلفة، لذا عادة تحتاج إلى تخزين حالة مشترك (مثل Redis أو قاعدة بيانات) أو تقبل حلول مثل الجلسات الملتصقة (sticky sessions) مع المقايضات الخاصة بها.
إذا كان عدة عمال قادرين على التقاط نفس المهمة (أو تتم إعادة المحاولة)، قد ينتهي بك الأمر بمضاعفة العمل (شحن مرتين، إرسال بريد مزدوج).
تدابير شائعة:
الاتساق القوي يعني أنه بمجرد نجاح عملية كتابة، يرى كل القُرّاء القيمة الأحدث فورًا. الاتساق النهائي يعني أن التحديثات ستنتشر مع الوقت، وقد يرى بعض القُرّاء قيمًا قديمة لفترة قصيرة.
استخدم الاتساق القوي للبيانات الحرجة (مدفوعات، أرصدة، الجرد). يمكن قبول الاتساق النهائي لبيانات أقل حساسية (تحليلات، توصيات).
في النظام الموزع، المكالمات تصبح مكالمات شبكية — تظهر الكمون، التذبذب، وحالات الفشل.
قواعد أساسية:
الفشل الجزئي يعني أن بعض المكونات تكون معطلة أو بطيئة بينما بقية النظام تعمل. النظام يكون "متاحًا" لكنه قد ينتج أخطاء أو استجابات بطيئة أو سلوك غير متسق.
الاستجابة تتضمن التكرار، الأصوات (quorums)، نشر عبر مناطق، قواطع الدارات (circuit breakers)، وتدهور محسوب (graceful degradation) ليمنع الانتشار التتابعي للفشل.
الأدلة متفرقة: سجلات ومقاييس وتتبع على عُقد مختلفة.
خطوات عملية: