موازنة الأحمال والبوابات

🎯 السؤال الأساسي

عندما لا يستطيع خادم واحد تحمل الحمل، كيف يمكن توزيع حركة المرور "بذكاء" على عدة نسخ من الخادم؟ موازنة الأحمال هي "المُوزِّع" في الأنظمة الموزعة الحديثة. تقدم هذه المقالة فهمًا عميقًا لفلسفة تصميم موازنة الأحمال وممارساتها الهندسية من خلال أمثلة واقعية (طابور الدفع في متجر شاي الحليب، فرز الطرود، توجيه حركة المرور).

---

1. لماذا "موازنة الأحمال"؟

1.1 البدء بحالة حقيقية: تطور بنية موقع ويب

واجهت شركة ناشئة مشاكل أداء خطيرة أثناء النمو السريع لقاعدة مستخدميها:

استعراض المشهد:

المرحلة الأولى: خادم واحد
المستخدم → الخادم (1 نواة، 2 جيجابايت RAM)
       ↓
    1000 مستخدم نشط يوميًا → وقت الذروة: 1000 وصول متزامن
       ↓
المشكلة: CPU عند 100%، استجابة بطيئة، أعطال متكررة

⚠️ المشكلة القاتلة للخادم الواحد

• عنق الزجاجة في الأداء: CPU عند 100%، زمن الاستجابة > 5 ثوانٍ
• نقطة فشل واحدة: إذا تعطل الخادم، يصبح الموقع بأكمله غير متاح
• صعوبة التوسع: التوسع الرأسي فقط (إضافة CPU، ذاكرة)، وهو مكلف ومحدود

البنية المُحسَّنة (بعد إدخال موازنة الأحمال):

المرحلة الثانية: عدة خوادم + موازنة أحمال
المستخدم → موازن الأحمال (Nginx)
       ↓
     ├→ الخادم 1 (1 نواة، 2 جيجابايت RAM)
     ├→ الخادم 2 (1 نواة، 2 جيجابايت RAM)
     └→ الخادم 3 (1 نواة، 2 جيجابايت RAM)

✨ النتائج بعد التحسين

• تحسين الأداء: 3 خوادم تعالج بالتوازي، زمن الاستجابة < 1 ثانية
• توافر عالٍ: إذا تعطل خادم واحد، تستمر الخوادم الأخرى في الخدمة
• توسع أفقي: تحتاج المزيد من الأداء؟ فقط أضف المزيد من الخوادم

1.2 تشبيه موازنة الأحمال من الحياة اليومية

طابور الدفع في متجر شاي الحليب

تخيل أنك افتتحت متجر شاي حليب شهير:

• طابور دفع واحد: يصطف العملاء، من في الخلف ينفد صبره، تقييمات سيئة
• 3 طوابير دفع: يوزع الموظفون العملاء على طوابير مختلفة، تزيد الكفاءة 3 أضعاف

موازن الأحمال هو "مُوزِّع طوابير الدفع":

• المستخدم (العميل) → يطلب الخدمة
• موازن الأحمال (المُوزِّع) → يوزع الطلبات على خوادم مختلفة
• الخادم (طابور الدفع) → يعالج الطلب

负载均衡器类型

从四层到七层，从硬件到软件的演进

传统架构单点

🖥️

Web Server

负载: 95% 🔥

→

负载均衡架构分布式

⚖️L4 Load Balancer

🖥️

S1

🖥️

S2

🖥️

S3

📦四层负载均衡 (L4)

工作原理

基于传输层信息（IP地址+端口）进行流量分发。不关心应用层内容，只做"快递分拣"，因此性能极高。

典型产品

LVS (Linux Virtual Server)HAProxy (TCP模式)AWS NLBAzure Load Balancer

适用场景

• 需要极高吞吐量的场景
• TCP/UDP流量分发
• 不需要内容识别的场景
• 微服务间通信

性能对比一览

类型

处理层

性能

灵活性

成本

硬件负载均衡

L4/L7

$$$$$

四层负载均衡

L4 (传输层)

$$

七层负载均衡

L7 (应用层)

$$$

软件负载均衡

L4/L7

$

---

2. ما هي موازنة الأحمال؟

2.1 موازنة الأحمال من الطبقة الرابعة (L4): تنظر فقط إلى رقم العنوان

تعمل في طبقة النقل (TCP/UDP)، تمامًا مثل عامل التوصيل الذي ينظر فقط إلى رقم عنوانك (عنوان IP + رقم المنفذ)، دون أن يهتم بما تفعله في منزلك.

الخصائص:

• سرعة فائقة: تقوم فقط بإعادة توجيه بسيطة للعناوين، دون تحليل محتوى الحزم
• حالات الاستخدام: اتصالات قواعد البيانات، ذاكرة التخزين المؤقت Redis، خوادم الألعاب ذات الاتصالات الطويلة
• المنتجات الممثلة: LVS (Linux Virtual Server)، AWS NLB، Azure Load Balancer

مبدأ العمل

طلب العميل → موازن أحمال L4 → الخادم الخلفي
              ↓
         ينظر فقط إلى IP + Port
              ↓
         إعادة توجيه سريعة (دون فك محتوى الحزمة)

2.2 موازنة الأحمال من الطبقة السابعة (L7): فحص محتوى الطرد

تعمل في طبقة التطبيق (HTTP/HTTPS)، تمامًا مثل عامل التوصيل الذي لا ينظر فقط إلى رقم العنوان، بل يفتح الطرد لفحص المحتوى، ويقرر كيفية التوصيل بناءً على المحتوى.

الخصائص:

• توجيه ذكي: يمكنه التوجيه بدقة بناءً على مسار URL، رؤوس HTTP، ملفات تعريف الارتباط (Cookie)، إلخ
• وظائف متقدمة: إنهاء SSL، التخزين المؤقت للمحتوى، الضغط، جدار الحماية WAF
• حالات الاستخدام: تطبيقات الويب، بوابات API، بنية الخدمات المصغرة
• المنتجات الممثلة: Nginx، HAProxy، AWS ALB، Envoy

مبدأ العمل

طلب العميل → موازن أحمال L7 → تحليل محتوى HTTP
              ↓
         فحص URL، Header، Cookie
              ↓
         توجيه ذكي إلى خادم محدد

2.3 مقارنة بين L4 و L7

البعد	موازنة أحمال الطبقة الرابعة (L4)	موازنة أحمال الطبقة السابعة (L7)
طبقة العمل	طبقة النقل (TCP/UDP)	طبقة التطبيق (HTTP/HTTPS)
أساس القرار	عنوان IP + رقم المنفذ	URL، Header، Cookie، Body
سرعة المعالجة	سريعة جدًا (معالجة على مستوى النواة)	سريعة (تحليل على مستوى المستخدم)
ثراء الوظائف	إعادة توجيه أساسية	إنهاء SSL، تخزين مؤقت، ضغط، WAF
الحالات النموذجية	قواعد البيانات، الألعاب، الاتصالات الطويلة	تطبيقات الويب، بوابات API، الخدمات المصغرة
المنتجات الممثلة	LVS، AWS NLB	Nginx، HAProxy، AWS ALB

---

3. المشكلة الأساسية الأولى: كيف نتجنب استمرار الخوادم "المعطلة" في استقبال العملاء؟

3.1 الفحص الصحي: لا تدع الخوادم "المريضة" تُثقل النظام

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

الفحص الصحي (Health Check) هو "الحارس" الذي يمنع حدوث ذلك. يقوم "بفحص" كل خادم بشكل دوري، وإذا اكتشف خادمًا "مريضًا" يزيله فورًا من قائمة الانتظار، وعندما "يتعافى" يعيده مرة أخرى.

3.2 الفحص الصحي النشط مقابل الفحص الصحي السلبي

الفحص الصحي النشط (Active Health Check): موازن الأحمال "يطرق الباب" بنشاط ليسأل الخادم "هل ما زلت موجودًا؟"

• يرسل طلبات فحص دورية (مثل HTTP /health، TCP ping)
• إذا انتهت مهلة الاستجابة أو أُعيد رمز خطأ، يُعتبر غير صحي
• الميزة: نتائج الفحص دقيقة وموثوقة
• العيب: يولّد حركة فحص إضافية

الفحص الصحي السلبي (Passive Health Check): موازن الأحمال "يراقب" استجابات حركة المرور الحقيقية

• يحصي زمن استجابة الطلبات الفعلية ومعدل الأخطاء
• إذا فشل عدة مرات متتالية، يُعتبر غير صحي
• الميزة: لا يولّد حركة مرور إضافية
• العيب: يحتاج إلى عينة كافية من الحركة لإصدار الحكم

جدول إعدادات العتبات

المؤشر	عتبة الصحة	عتبة عدم الصحة	شرح
رمز حالة HTTP	200-399	400+ أو انتهاء المهلة	4xx/5xx تعتبر فشلًا
اتصال TCP	تم بنجاح	انتهاء مهلة الاتصال	التحقق من إمكانية الوصول إلى المنفذ
زمن الاستجابة	< 500 مللي ثانية	> 2000 مللي ثانية	عادةً ما تُضبط مهلة الانتهاء بين 2-5 ثوانٍ
عدد مرات الفشل المتتالي	-	3 مرات	لتجنب الحكم الخاطئ بسبب التقلبات اللحظية
فترة الفحص	-	5 ثوانٍ	التكرار المفرط يزيد الحمل

💡 حفرة يجب الانتباه لها: عتبات حساسة جدًا

قام فريق بضبط عتبة زمن الاستجابة للفحص الصحي عند 100 مللي ثانية، بينما كان متوسط زمن استجابة تطبيقهم يتراوح بين 80-120 مللي ثانية. وكانت النتيجة أن الخوادم كانت تُوسم بشكل متكرر على أنها "غير صحية"، مما تسبب في تنقل حركة المرور ذهابًا وإيابًا بين الصحية وغير الصحية، وانخفض معدل التوفر الإجمالي للنظام بالفعل.

الممارسة الصحيحة: يجب ضبط العتبة عند 2-3 أضعاف زمن استجابة P99، لإفساح مساحة كافية للتقلبات الطبيعية.

---

4. المشكلة الأساسية الثانية: كيف نضمن أن "العميل المنتظم" يجد دائمًا نفس "أمين الصندوق"؟

4.1 استمرارية الجلسة: دع "العميل المنتظم" يجد دائمًا نفس "أمين الصندوق"

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

استمرارية الجلسة (Session Persistence/Sticky Session) هي الحل لهذه المشكلة: ضمان أن طلبات نفس المستخدم تُوجَّه دائمًا إلى نفس الخادم الخلفي.

会话保持机制

Cookie、IP哈希与粘性会话的技术对比

应用场景：

👤

用户A

🍪

👥

用户B

🍪

👨‍💼

用户C

🍪

请求

↓

⚖️负载均衡器

🍪

Cookie 插入

通过HTTP Cookie保持会话

会话映射表

sess_abc123→Server 1

sess_def456→Server 2

sess_ghi789→Server 1

↓

🖥️

Server 1

10.0.1.10

✓

选中

🖥️

Server 2

10.0.1.11

✓

🖥️

Server 3

10.0.1.12

✗

↑

🍪Set-Cookie 响应头

SERVERID=srv001; Path=/; HttpOnly

三种会话保持机制对比

🍪Cookie 插入

✓不受客户端IP变化影响

✓首次请求即可保持会话

✗客户端需支持Cookie

✗存在Cookie被禁用的风险

#️⃣IP Hash

✓无需客户端支持任何机制

✓无状态，LB重启不影响会话

✗客户端IP变化会丢失会话

✗难以做到真正的负载均衡

📝粘性会话

✓结合Cookie和IP两种方式优势

✓支持会话复制和故障转移

✗实现复杂，需要应用支持

✗会话复制带来性能开销

4.2 مقارنة بين ثلاث آليات لاستمرارية الجلسة

الآلية	مبدأ التنفيذ	الميزات	العيوب	حالات الاستخدام
إدراج Cookie	يُدرج موازن الأحمال Cookie في الاستجابة، وتحمله الطلبات اللاحقة	لا يتأثر بتغير IP، يحافظ على الجلسة من أول طلب	يحتاج العميل لدعم Cookie، قد يُعطَّل	سلة التسوق في التجارة الإلكترونية، الحفاظ على حالة تسجيل الدخول
تجزئة IP	حساب تجزئة (Hash) لعنوان IP للعميل، وربطه بخادم محدد	لا يحتاج دعمًا من العميل، بدون حالة	تغير IP يؤدي لفقدان الجلسة، صعوبة التوزيع المتساوي	بيئات بدون Cookie، WebSocket
جدول الجلسات اللاصقة	يحتفظ موازن الأحمال بجدول يربط الجلسات بالخوادم	يدعم نسخ الجلسات ونقل الفشل	يستهلك ذاكرة موازن الأحمال، يحتاج مزامنة إضافية	السيناريوهات ذات متطلبات التوافر العالي الصارمة

💡 توصيات الاستخدام

• إدراج Cookie: الخيار الموصى به أولاً، توافق جيد
• تجزئة IP: فقط للحالات الخاصة مثل WebSocket
• جدول الجلسات اللاصقة: يُستخدم مع Cookie لتوفير قدرة نقل الفشل

---

5. المشكلة الأساسية الثالثة: كيف نحقق النشر بدون توقف؟

5.1 النشر الأزرق-الأخضر: نشر بدون توقف "بتبديل زر واحد"

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

蓝绿部署

零停机发布的经典策略，两套环境瞬间切换

🔵

蓝环境

v1.0.0

100% 流量

🟢

绿环境

v1.1.0

0% 流量

用户流量

👤

👤

👤

👤

👤

↓

⚖️

负载均衡器

当前指向: 🔵 蓝环境

↓

🔵蓝环境v1.0.0

🖥️B1●

🖥️B2●

🖥️B3●

流量:100%

生产环境

🟢绿环境v1.1.0

🖥️G1●

🖥️G2●

🖥️G3●

流量:0%

待命

蓝绿部署流程

1

绿环境部署

在绿环境部署新版本，进行冒烟测试

→

2

切换流量

将负载均衡器指向绿环境，流量瞬间切换

→

3

监控观察

观察绿环境运行状态，确认无异常

→

4

蓝环境升级

在蓝环境部署新版本，为下次切换做准备

蓝绿部署优缺点

✅优点

• 零停机时间：流量切换在毫秒级完成，用户无感知
• 快速回滚：发现问题可立即切回原环境，风险可控
• 完整的预发布测试：新环境可完整测试后再接管流量
• 数据一致性：无需处理新旧版本同时运行时的兼容问题

❌缺点

• 资源成本高：需要同时维护两套完整环境，服务器成本翻倍
• 数据库兼容性挑战：如果涉及数据库Schema变更，需要特别处理兼容性
• 预热问题：新环境启动后可能需要时间预热缓存、连接池等
• 不适合有状态服务：对于长连接、会话保持要求高的场景处理复杂

سير العمل:

1. الحالة الأولية: البيئة الزرقاء تشغّل v1.0 (الإنتاج)، البيئة الخضراء في وضع الاستعداد.
2. نشر الإصدار الجديد: نشر v1.1 في البيئة الخضراء، وإجراء اختبار دخان داخلي.
3. تبديل حركة المرور: توجيه موازن الأحمال إلى البيئة الخضراء، تنتقل حركة المرور فورًا إلى v1.1.
4. المراقبة: مراقبة حالة تشغيل البيئة الخضراء، والتأكد من عدم وجود أي خلل.
5. الاحتفاظ بالإصدار القديم: تبقى البيئة الزرقاء على v1.0 لفترة (مثل 24 ساعة)، كتأمين للتراجع السريع.

✨ تحليل المزايا والعيوب

المزايا	العيوب
✅ وقت توقف صفري، التبديل يتم بالميلي ثانية	❌ تكلفة موارد عالية، تحتاج لصيانة بيئتين في نفس الوقت
✅ تراجع سريع، عند اكتشاف مشكلة يتم التحويل فورًا للبيئة الأصلية	❌ تغييرات مخطط قاعدة البيانات تحتاج معالجة خاصة للتوافق
✅ يمكن اختبار البيئة الجديدة بشكل كامل قبل استقبال حركة المرور	❌ غير مناسبة للخدمات ذات الحالة (مثل اتصالات WebSocket الطويلة)

5.2 النشر الكناري: استراتيجية التدرج "بخطوات صغيرة وسريعة"

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

金丝雀发布

灰度发布策略，小流量先行验证新版本

流量分配比例拖动滑块调整新旧版本流量占比

稳定版 v1.0.090%

金丝雀 v1.1.010%

实时流量模拟 总请求: 0 | 稳定版: 0 | 金丝雀: 0

用户请求

→

负载均衡器

⚖️

Canary:10%

→

后端服务

稳定版 v1.0.0

📦S1

📦S2

📦S3

金丝雀 v1.1.0

🧪C1

🧪C2

金丝雀发布最佳实践

📊渐进式放量

• 1% → 5% → 10% → 25% → 50% → 100%
• 每个阶段观察至少15-30分钟
• 关键指标：错误率、延迟、吞吐量

🎯精准用户选择

• 内部员工/测试用户先行
• 按地域：选择特定区域用户
• 按用户属性：VIP用户或普通用户
• 按设备类型：iOS/Android/Web

🛡️自动回滚机制

• 错误率超过阈值自动回滚
• P99延迟异常触发告警
• 关键业务指标下降自动回滚
• 一键回滚：30秒内恢复旧版本

📈监控与指标

• 基础设施：CPU、内存、磁盘、网络
• 应用指标：QPS、错误率、延迟分布
• 业务指标：转化率、订单量、收入
• 用户体验：页面加载时间、交互延迟

الفكرة الأساسية:

1. حركة مرور صغيرة أولاً: توجيه 1% من حركة المرور إلى خوادم الإصدار الجديد أولاً.
2. مراقبة المؤشرات: مراقبة مستمرة لمعدل الخطأ، وزمن الاستجابة، والمؤشرات الرئيسية للأعمال.
3. زيادة تدريجية: إذا كان كل شيء طبيعيًا، تتم زيادة النسبة تدريجيًا إلى 5%، 10%، 25%، 50%، 100%.
4. تراجع سريع: بمجرد اكتشاف أي خلل، يتم تحويل كل حركة المرور فورًا إلى الإصدار القديم.

💡 مزايا النشر الكناري

الميزة	الشرح
🎯 مخاطر تحت السيطرة	حتى لو كان الإصدار الجديد به خطأ فادح، فإنه يؤثر فقط على عدد قليل من المستخدمين
📊 تحقق حقيقي	التحقق في بيئة إنتاج حقيقية، أكثر موثوقية من بيئة الاختبار
🚀 تكرار سريع	يمكن للفريق نشر ميزات جديدة بشكل متكرر بثقة أكبر
💰 صديق للموارد	لا يحتاج لإعداد بيئتين كاملتين مثل النشر الأزرق-الأخضر

---

6. المشكلة الأساسية الرابعة: كيف نجعل النظام "يتنفس" بنفسه؟

6.1 التوسع والانكماش التلقائي: اجعل النظام مثل مطعم "بجدولة مرنة"

تخيل أنك تفتح مطعمًا:

• ذروة الغداء: تحتاج 10 نوادل، لكن في الساعة 3 بعد الظهر تحتاج فقط 2
• إذا استمررت بـ 10 طوال الوقت: تكلفة العمالة تنفجر
• إذا استمررت بـ 2 فقط: زبائن الذروة لا يتحملون الانتظار، ويغادرون جميعًا

التوسع والانكماش التلقائي (Auto Scaling) يجعل النظام مثل مطعم "بجدولة مرنة" — يضيف خوادم تلقائيًا عند الازدحام، ويخفضها تلقائيًا عند الهدوء.

自动扩缩容

基于CPU、内存、QPS的智能弹性伸缩

扩容指标：

实时监控 实时

💻CPU使用率

45%

扩容阈值: 70%缩容阈值: 30%

🧠内存使用率

60%

扩容阈值: 75%缩容阈值: 40%

⚡QPS

650req/s

扩容阈值: 1000/s目标: 800/s

🖥️运行实例

3个实例

最小: 2最大: 10

1

2

3

4

5

6

7

8

9

10

扩缩容历史最近 5 次操作

📈

扩容: 2 → 3 实例

CPU使用率超过70%

10:23

📉

缩容: 4 → 3 实例

CPU使用率低于30%

09:15

📈

扩容: 3 → 4 实例

QPS达到1000/s

08:42

📈

扩容: 2 → 3 实例

内存使用率超过75%

07:30

📉

缩容: 5 → 4 实例

流量下降

06:20

自动扩缩容最佳实践

⏱️

冷却时间

设置适当的冷却时间（通常3-5分钟），避免扩缩容操作过于频繁导致的震荡

📊

多指标综合

不要依赖单一指标，结合CPU、内存、QPS、连接数等多维度进行综合判断

🎯

目标利用率

设置合理的资源目标利用率（如70%），预留足够的缓冲应对突发流量

⚡

快速扩容

扩容操作应该比缩容更激进，确保系统能快速应对流量增长

6.2 اختيار مؤشرات التوسع

جوهر التوسع والانكماش التلقائي هو الإجابة على سؤال: متى يجب إضافة الآلات؟ ومتى يجب تخفيضها؟

مؤشرات القرار الشائعة:

المؤشر	عتبة التوسع	عتبة الانكماش	حالات الاستخدام
استخدام CPU	> 70%	< 30%	التطبيقات كثيفة الحوسبة
استخدام الذاكرة	> 75%	< 40%	التطبيقات كثيفة الذاكرة
QPS (طلبات في الثانية)	> 1000/ثانية	< 400/ثانية	بوابات API، خدمات الويب
عدد الاتصالات	> 5000	< 1000	قواعد البيانات، طوابير الرسائل
مؤشرات أعمال مخصصة	حسب العمل	حسب العمل	سيناريوهات أعمال محددة

💡 "حفر" واستراتيجيات التوسع و"حلولها"

الحفرة 1: التوسع بطيء جدًا، موجة حركة المرور أسقطت النظام بالفعل

خلال حملة ترويجية لتجارة إلكترونية، تم ضبط التوسع عند CPU > 80%، لكن جمع المراقبة كان بتأخير دقيقة واحدة، وتشغيل نسخة جديدة يحتاج 3 دقائق. والنتيجة أن حركة المرور جاءت بسرعة كبيرة، ولم يكتمل التوسع بعد، وكانت الخوادم قد انهارت بالفعل.

الحل:

• التوسع المسبق: توقع ذروة حركة المرور بناءً على البيانات التاريخية، وابدأ التوسع قبل 30 دقيقة
• عتبات متعددة المستويات: ضبط 60% تحذير (بدء تسخين النسخ الجديدة)، 70% توسع رسمي، 80% توسع طارئ
• توسع سريع: استخدام النشر بالحاويات، تشغيل النسخ الجديدة في 30 ثانية (مقابل 3-5 دقائق للآلات الافتراضية)

الحفرة 2: التوسع مفرط، تكلفة متفجرة

قامت شركة ناشئة بضبط استراتيجية توسع تلقائي مفرطة: التوسع عند CPU > 50%. والنتيجة أن تقلبًا طبيعيًا في الأعمال أدى إلى تشغيل التوسع، وتضخم عدد الخوادم من 5 إلى 30، وفاتورة السحابة في نهاية الشهر أرعبت المدير التقني.

الحل:

• ضبط فترة تبريد للتوسع: بعد توسع واحد، انتظر 5 دقائق على الأقل قبل التوسع مرة أخرى
• ضبط الحد الأقصى للنسخ: max = عدد النسخ الحالي × 2، لمنع التضخم اللامحدود
• التمييز بين القفزات والاتجاهات: التوسع فقط بعد 3 دورات متتالية تتجاوز العتبة، لتجنب القفزات اللحظية

الحفرة 3: الانكماش سريع جدًا، الآلات التي وُسِّعت للتو تنكمش فورًا

قام فريق بضبط الانكماش عند CPU < 30%. بعد التوسع، كانت حركة المرور لا تزال قيد المعالجة، وانخفض CPU مؤقتًا إلى 25%، مما أدى إلى تشغيل الانكماش. وبمجرد الانكماش، قفز CPU مرة أخرى إلى 80%، مما أدى إلى تشغيل التوسع — والنظام يهتز بعنف في دورة "توسع-انكماش-توسع".

الحل:

• انكماش أكثر تحفظًا: عتبة التوسع 70%، عتبة الانكماش 25%، مع وجود منطقة عازلة كافية بينهما
• فترة تبريد أطول للانكماش: بعد التوسع، انتظر 10 دقائق على الأقل قبل الانكماش
• انكماش تدريجي: خفض آلة واحدة فقط في كل مرة، وراقب قبل اتخاذ قرار بالاستمرار

---

7. عمليًا: كيف تختار موازن الأحمال؟

7.1 مقارنة بين موازنات الأحمال الرئيسية

الميزة	Nginx	HAProxy	Envoy	موازنات الأحمال السحابية
الموقع	وكيل عكسي/موازن أحمال عالي الأداء	موازن أحمال مفتوح المصدر	وكيل سحابي أصلي	موازن أحمال مُدار
الأداء	عالي جدًا (لغة C، مدفوع بالأحداث)	عالي (مدفوع بالأحداث)	عالي (C++/Rust)	عالي جدًا
ثراء الوظائف	موازنة أحمال أساسية، ملفات ثابتة، تخزين مؤقت	خوارزميات موازنة أحمال غنية	توجيه متقدم، مراقبة	وظائف شاملة
التكوين	ملف تكوين (nginx.conf)	ملف تكوين (haproxy.cfg)	API/ملف تكوين	لوحة تحكم UI
التوسعة	وحدات C/نصوص Lua	نصوص Lua	WASM/Filter	إضافات
حالات الاستخدام	موارد ثابتة، موازنة أحمال L7، إنهاء SSL	موازنة أحمال L7، توافر عالٍ	شبكة خدمات، سحابة متعددة	بداية سريعة

💡 توصيات الاختيار

شجرة القرار:

اختيار موازن الأحمال:
│
├─ تحتاج فقط موازنة أحمال L4 أساسية؟
│  ├─ نعم → LVS (مفتوح المصدر ومجاني) أو NLB السحابي
│  └─ لا → تابع
│
├─ تحتاج شبكة خدمات، نشر سحابي متعدد؟
│  ├─ نعم → Envoy
│  └─ لا → تابع
│
├─ تحتاج تكوينًا معقدًا جدًا وإضافات؟
│  ├─ نعم → HAProxy
│  └─ لا → تابع
│
├─ تحتاج أداءً عاليًا + تكوينًا بسيطًا؟
│  ├─ نعم → Nginx (الخيار الأول)
│  └─ تابع
│
├─ تريد إدارة مُدارة؟
│  ├─ نعم → موازنات الأحمال السحابية (AWS ALB، Alibaba SLB)
│  └─ Nginx ذاتي البناء

---

8. الخلاصة: التفكير الأساسي في موازنة الأحمال

8.1 مراجعة المبادئ الأساسية

المبدأ	المعنى	نقاط الممارسة الأساسية
تقسيم الطبقات	L4 لـ "فرز الطرود" (سريع لكن بسيط)	L4 لقواعد البيانات والألعاب؛ L7 للويب و API
التكرار	نقطة الفشل الواحدة هي عدو البنية	تحسين التوافر من خلال نسخ متعددة، نشر متعدد المناطق
التدرج	لا تنشر الإصدارات الجديدة "دفعة واحدة"	النشر الأزرق-الأخضر لتحقيق صفر توقف؛ النشر الكناري لمخاطر تحت السيطرة
المرونة	يجب أن "يتنفس" النظام مثل الكائن الحي	توسع تلقائي عند الازدحام، وانكماش تلقائي عند الهدوء

8.2 قائمة تدقيق التصميم

قبل إدخال موازنة الأحمال، اسأل نفسك الأسئلة التالية:

• [ ] هل هناك حقًا حاجة لموازنة الأحمال؟ (هل أداء الآلة الواحدة غير كافٍ حقًا)
• [ ] اختيار L4 أم L7؟ (حسب سيناريو العمل)
• [ ] كيف نتعامل مع استمرارية الجلسة؟ (Cookie، تجزئة IP، جدول الجلسات)
• [ ] كيف ننفذ الفحص الصحي؟ (نشط، سلبي، ضبط العتبات)
• [ ] كيف نحقق النشر بدون توقف؟ (أزرق-أخضر، كناري)
• [ ] كيف نحقق المرونة؟ (مؤشرات التوسع والانكماش، فترة التبريد، الحد الأقصى للنسخ)

---

9. جدول المصطلحات

المصطلح	الإنجليزية	الشرح
موازن الأحمال	Load Balancer	جهاز أو برنامج يوزع حركة المرور على عدة خوادم خلفية
موازنة أحمال L4	L4 Load Balancing	موازنة أحمال بناءً على طبقة النقل (TCP/UDP)
موازنة أحمال L7	L7 Load Balancing	موازنة أحمال بناءً على طبقة التطبيق (HTTP/HTTPS)
الفحص الصحي	Health Check	آلية لفحص الحالة الصحية للخوادم الخلفية بشكل دوري
استمرارية الجلسة	Session Persistence	ضمان توجيه طلبات نفس المستخدم دائمًا إلى نفس الخادم
الجلسة اللاصقة	Sticky Session	تسمية أخرى، مرادفة لـ Session Persistence
النشر الأزرق-الأخضر	Blue-Green Deployment	استراتيجية نشر بدون توقف بتبديل بيئتين
النشر الكناري	Canary Release	استراتيجية نشر تدريجي بالتحقق من حركة مرور صغيرة أولاً
التوسع والانكماش التلقائي	Auto Scaling	زيادة أو تقليل عدد الخوادم تلقائيًا بناءً على الحمل
التوسع الأفقي	Horizontal Scaling	زيادة عدد الخوادم لتحسين قدرة المعالجة
التوسع الرأسي	Vertical Scaling	تحسين تكوين الآلة الواحدة (CPU، ذاكرة) لتحسين قدرة المعالجة
متعدد المناطق	Multi-Region	نشر الخدمات في مناطق جغرافية متعددة
نشط-نشط	Active-Active	عدة مناطق تقدم الخدمة للخارج في وقت واحد
نشط-احتياطي	Active-Standby	منطقة واحدة فقط تقدم الخدمة، والأخرى في وضع الاستعداد
مزامنة البيانات	Data Replication	آلية نسخ البيانات عبر المناطق
RTO	Recovery Time Objective (RTO)	هدف وقت الاسترداد، المدة الزمنية المطلوبة لاستعادة النظام بعد العطل
RPO	Recovery Point Objective (RPO)	هدف نقطة الاسترداد، كمية البيانات المفقودة المقبولة بعد عطل النظام