جوهر أطر عمل الويب

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

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

1. لماذا يجب فهم تطور البنية؟

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

اختيار بنية الواجهة الخلفية هو نفس الشيء.

منذ نشأة الإنترنت وحتى الآن، مرت بنية الواجهة الخلفية بالعديد من التحولات الكبرى. كل تحول لم يكن من أجل "مطاردة الجديد"، بل لحل مشاكل محددة كانت تواجهها في ذلك الوقت:

الحقبة	المشكلة الأساسية	تطور البنية
1990s	كيفية تشغيل موقع ويب	الخوادم الفعلية
2000s	الكود يصبح فوضوياً، كيف ننظمه	البنية الأحادية + MVC
2010s	النظام ضخم جداً، كيف نتوسع ونتعاون	الخدمات المصغرة + الحاويات
2020s	كيفية تقليل تكاليف وتعقيد التشغيل	Serverless + السحابة الأصلية

📊 ماذا يمكنك أن ترى من الجدول؟

لنفسر هذا الجدول سطراً بسطر:

1990s ← 2000s: من "مجرد التشغيل" إلى "الحاجة للصيانة". تحولت المواقع من صفحات ثابتة إلى تطبيقات ديناميكية، وازداد حجم الكود بشكل هائل، مما تطلب طرقاً أفضل للتنظيم.

2000s ← 2010s: من "الجهاز الواحد" إلى "الموزع". انفجر عدد المستخدمين، وأصبح الخادم الواحد غير قادر على التحمل، مما استدعى تقسيم النظام والتوسع الأفقي.

2010s ← 2020s: من "التشغيل الذاتي" إلى "الخدمات السحابية". الحاويات والخدمات المصغرة قوية لكن تكاليف تشغيلها مرتفعة جداً، Serverless يجعل المطورين يركزون فقط على منطق الأعمال.

الدرس الأساسي: تطور البنية ليس لعبة اختيار تقنيات، بل هو عملية حل مشاكل حقيقية. لكل مرحلة سيناريوهاتها المناسبة، لا توجد "أفضل بنية"، بل "البنية الأنسب".

معنى فهم تطور البنية:

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

🏗️Backend Architecture EvolutionUnderstand 30 years of architecture evolution through a restaurant analogy

1990s

🏠

Small family workshop

Physical server

2000s

🏢

Large central kitchen

Monolith

2010s

🏭

Specialized division

Microservices

2020s+

🍽️

Delivery platform

Serverless

🏠

Home kitchen

🍽️ Restaurant scenario

One cook works in a small kitchen and personally buys ingredients, washes, cuts, cooks, and serves. When customers increase, everyone has to queue.

💻 Backend mapping

One physical server handles every request: receiving HTTP requests, reading files, executing CGI scripts, and returning responses. CPU and memory are limited, so extra requests queue up.

⚡ Core pain points

Single-machine bottleneck: too many customers overwhelm the cook
Vertical scaling is expensive: buying a bigger machine is like buying a bigger kitchen
Single point of failure: if the cook is unavailable, the restaurant closes

💡Core idea:Architecture evolves to solve the pain points of the previous era, while introducing new complexity. There is no best architecture, only the architecture that best fits the context.

2. عصر الخوادم الفعلية (1990s)

2.1 ما هو الخادم الفعلي؟

في بدايات الإنترنت، كانت الواجهة الخلفية عبارة عن خادم فعلي (جهاز كمبيوتر حقيقي) موضوع في غرفة خوادم.

💡 شرح مبسط

الخادم الفعلي يشبه جهاز الكمبيوتر المكتبي في منزلك، لكنه:

يعمل 24 ساعة × 7 أيام دون توقف
موضوع في مركز بيانات متخصص (يحتوي على تكييف، وإمدادات طاقة UPS، ونظام إطفاء حريق)
لديه نطاق ترددي أسرع (ألياف بصرية بجودة المؤسسات)
لديه عنوان IP عام ثابت (يمكن للعالم كله الوصول إليه)

هذا يشبه الفرق بين منزلك والمطعم: منزلك تطبخ فيه أحياناً، أما المطعم فهو مطبخ احترافي يعمل طوال اليوم بمعدات أكثر احترافية.

2.2 الخصائص الأساسية

نشر على جهاز واحد: جميع التطبيقات تعمل على جهاز فعلي واحد
تشغيل يدوي: يتطلب تركيباً يدوياً، وتوصيل كابلات، وتثبيت أنظمة
توسع رأسي: عند عدم كفاية الأداء، لا يمكن سوى شراء أجهزة أقوى

🔧 التوسع الرأسي مقابل التوسع الأفقي

التوسع الرأسي (Scale Up): ترقية مواصفات الخادم الواحد (معالج أقوى، ذاكرة أكبر، قرص أسرع).

التوسع الأفقي (Scale Out): إضافة المزيد من الخوادم وجعلها تعمل معاً.

تشبيه:

التوسع الرأسي: تحويل مطعم صغير إلى مطعم كبير بديكور فاخر، لكن بطاهٍ واحد فقط
التوسع الأفقي: فتح سلسلة فروع، كل فرع حجمه ليس كبيراً، لكن لديك 100 فرع

المزايا والعيوب:

التوسع الرأسي بسيط، لكن له سقف (الخوادم الفائقة باهظة الثمن ولها حدود)
التوسع الأفقي غير محدود نظرياً، لكنه يتطلب حل مشاكل تناسق البيانات

2.3 نقاط الألم

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

🖥️Physical Server Era DemoObserve the processing bottleneck of early CGI servers

👤 User browser

🖥️ CGI server

Waiting for requests

💡Core idea:Process-level isolation improves stability, but it also creates heavy performance overhead.

2.4 مزايا وعيوب عصر الخوادم الفعلية

البعد	التقييم
المزايا	تحكم كامل في العتاد، أداء قابل للتوقع؛ لا توجد تكاليف افتراضية؛ عزل فيزيائي للبيانات، أمان عالٍ
العيوب	دورة شراء طويلة (أسابيع)؛ استثمار أولي كبير (CapEx)؛ استخدام منخفض للموارد؛ صعوبة في التوسع
السيناريوهات المناسبة	الأنظمة المالية الأساسية، الأنظمة الحكومية السرية، السيناريوهات ذات المتطلبات الصارمة لسيادة البيانات

💡 CapEx مقابل OpEx

CapEx (Capital Expenditure): الإنفاق الرأسمالي، استثمار مبلغ كبير مرة واحدة لشراء العتاد.

OpEx (Operating Expenditure): الإنفاق التشغيلي، الدفع حسب الاستخدام (مثل الخوادم السحابية).

تشبيه:

CapEx: شراء منزل، تدفع ملايين مرة واحدة، ثم تدفع رسوم الخدمات الشهرية فقط
OpEx: استئجار منزل، تدفع الإيجار شهرياً، دون الحاجة لدفع مبلغ كبير مرة واحدة

الدرس من عصر السحابة: Serverless والخدمات السحابية تمكن المزيد من الشركات من التحول من CapEx إلى OpEx، مما يخفض عتبة بدء المشاريع.

3. عصر البنية الأحادية (2000s)

3.1 ما هي البنية الأحادية؟

مع ظهور أطر العمل (Rails / Django / Spring)، بدأ الجميع في وضع كل الوظائف في تطبيق واحد.

💡 شرح مبسط

البنية الأحادية (Monolith) تشبه مولاً تجارياً ضخماً:

قسم الملابس، قسم الطعام، قسم الأجهزة الإلكترونية كلها في نفس المبنى
جميع الموظفين يعملون في نظام إدارة واحد
إذا انقطع التيار الكهربائي عن المبنى كله، تتوقف جميع الأقسام عن العمل

بالمقارنة، الخدمات المصغرة تشبه شارعاً تجارياً: كل متجر يعمل بشكل مستقل، وإغلاق متجر واحد لا يؤثر على المتاجر الأخرى.

🏢Monolithic Architecture DemoObserve how a monolithic application handles requests

Monolithic application process

👤

User module

Healthy

📦

Order module

Healthy

💳

Payment module

Healthy

🏭

Inventory module

Healthy

🗄️

Shared database

💡Core idea:All modules run in the same process and share memory. If one module crashes, the entire process may go down.

3.2 الخصائص الأساسية

مستودع كود واحد: جميع وحدات الوظائف في نفس المشروع
قاعدة بيانات مشتركة: جميع الوحدات تشترك في نفس قاعدة البيانات
نشر موحد: التطبيق كله يُحزم ويُنشر كوحدة واحدة

3.3 المزايا

تطوير بسيط: مشروع واحد ينجز كل الوظائف
نشر مريح: رمي حزمة كبيرة على الخادم ويكفي
تصحيح سهل: تشغيل محلي يكفي لتصحيح جميع الوظائف

3.4 نقاط الألم: تأثير الانهيار المتسلسل

تخيل أن طباخ "تقطيع الخضار" جرح يده بالخطأ (خطأ برمجي في الكود)، فيضطر المطبخ كله للتوقف لمعالجة الجرح، مما يؤدي إلى عدم حصول أي زبون على الطعام.

هذا هو أكبر خطر في البنية الأحادية: ضعف العزل.

🚨 حالة انهيار حقيقية

عرض يوم العزاب (11.11) لشركة تجارة إلكترونية:

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

لو تم استخدام الخدمات المصغرة:

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

3.5 مزايا وعيوب البنية الأحادية والسيناريوهات المناسبة

البعد	التقييم
المزايا	تطوير بسيط، لا حاجة للتفكير في تعقيدات الأنظمة الموزعة؛ تصحيح مريح، تشغيل محلي يكفي لتصحيح كل الوظائف؛ نشر بسيط، حزمة واحدة تكفي للتشغيل؛ إدارة سهلة للمعاملات، قاعدة بيانات محلية تضمن ACID
العيوب	ترابط عالٍ للكود، تضخم الكود مع نمو الأعمال؛ حزمة تقنية واحدة، صعوبة في الترقية الجزئية؛ صعوبة في التوسع، لا يمكن سوى التوسع الكلي؛ ضعف عزل الأعطال، خطأ في وحدة واحدة يؤثر على النظام كله؛ كفاءة تعاون منخفضة للفرق، العديد من الأشخاص يعدلون على نفس الكود
السيناريوهات المناسبة	التحقق من MVP للشركات الناشئة، الفرق الصغيرة (<10 أشخاص)، الأعمال البسيطة نسبياً، السيناريوهات التي تتطلب سرعة التسليم أكثر من قابلية التوسع
السيناريوهات غير المناسبة	الفرق الكبيرة التي تعمل بالتوازي، الحاجة لنشر متكرر لوحدات مختلفة، السيناريوهات التي تحتاج فيها بعض الوحدات للتوسع المستقل

🎯 نصيحة للمبتدئين

إذا كنت تتعلم تطوير الواجهة الخلفية، أنصحك بشدة بالبدء من البنية الأحادية:

تعلم المشي أولاً: افهم HTTP، قواعد البيانات، بنية MVC الأساسية
ثم فكر في الجري: عندما يواجه مشروعك فعلاً مشاكل في قابلية التوسع، فكر في الخدمات المصغرة
تجنب الإفراط في التصميم: "الخدمات المصغرة" في كثير من الشركات هي في الواقع "خدمات أحادية موزعة"، وهي أصعب في الصيانة

مسار التعلم:

المرحلة 1: اكتب تطبيقاً أحادياً كاملاً باستخدام Spring Boot / Django / Rails
المرحلة 2: عندما تواجه اختناقات في الأداء، حاول تقسيم خدمة أو اثنتين
المرحلة 3: عندما يتجاوز حجم الفريق 50 شخصاً ويصبح النظام معقداً فعلاً، انتقل إلى الخدمات المصغرة الكاملة

3.6 الحزمة التقنية للبنية الأحادية

اللغة/الإطار	الخصائص	الشركات الممثلة
Java + Spring	الخيار الأول للتطوير المؤسسي، منظومة متكاملة	علي بابا، JD.com
PHP + Laravel/ThinkPHP	تطوير سريع، مناسب للمشاريع الصغيرة والمتوسطة	فيسبوك المبكر، Weibo
Python + Django/Flask	كفاءة تطوير عالية، مناسب للنماذج الأولية السريعة	Instagram، Pinterest
Ruby on Rails	الاصطلاحات فوق التكوين، المفضل لدى الشركات الناشئة	GitHub، Twitter (المبكر)
Node.js + Express	لغة موحدة للواجهة الأمامية والخلفية، مناسب لسيناريوهات I/O المكثفة	Netflix، Uber

4. الحاويات والخدمات المصغرة (2010s)

4.1 لماذا نحتاج الخدمات المصغرة؟

نقاط الألم في البنية الأحادية تفجرت في عقد 2010:

الكود ضخم جداً: مشروع بملايين الأسطر من الكود، الموظف الجديد يحتاج شهراً ليفهمه
النشر بطيء جداً: بناء واحد يستغرق 30 دقيقة، والنشر يكون بحذر شديد
التعاون صعب جداً: 100 مطور يعدلون على نفس المشروع، تعارضات الكود تحدث يومياً
التوسع مكلف جداً: تحتاج فقط لتوسيع "خدمة الدردشة"، لكن يجب نسخ التطبيق بأكمله

الفكرة الأساسية للخدمات المصغرة: تقسيم التطبيق الكبير إلى خدمات صغيرة متعددة، كل خدمة:

تُطور بشكل مستقل، وتُنشر بشكل مستقل
لديها قاعدة بياناتها الخاصة
تتواصل عبر API

🐳Docker Containerization DemoSee how containers let applications be packaged once and run anywhere

Traditional deployment

App A

Dependency library v1.0

Operating system

Physical server

Docker containers

App A

Dependency v1.0

App B

Dependency v2.0

Docker Engine

Host operating system

Physical server

📦

Environment consistency

Development, testing, and production environments stay consistent.

🚀

Fast deployment

Second-level startup, image distribution, and rolling updates without downtime.

📊

Resource isolation

CPU and memory limits keep multiple applications from interfering with each other.

🔄

Version management

Versioned images support rollback and gradual rollout.

💡Core idea:Containerization lets applications be built once and run anywhere, solving environment consistency and fast deployment problems.

💡 ما هو Docker؟

Docker يشبه "حاويات الشحن":

كل حاوية تحتوي على بضائع مستقلة (كود + مكتبات + بيئة تشغيل)
أينما تُنقل (إلى أي خادم)، افتح الحاوية وابدأ العمل مباشرة
لا تقلق بشأن "هذا الجهاز ليس عليه Python 3.9" أو "ذاك الجهاز ينقصه مكتبة معينة"

تشبيه:

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

القيمة الأساسية: "ابنِ مرة واحدة، وشغل في كل مكان".

4.2 الخط الزمني للحزمة التقنية

📚Technology Stack Evolution TimelineMainstream technology stacks in each era

🖥️Physical server era1990s

Web servers

ApacheNginxIIS

Backend languages

PerlPHPASP

Databases

MySQLPostgreSQLOracle

Deployment

FTPSSHManual

🏢Monolith2000s

Backend frameworks

SpringDjangoRailsLaravel

Frontend tech

jQueryBootstrapJSP

Databases

MySQLRedisMongoDB

Build tools

MavenGradleAnt

🏭Microservices2010s

Containers

DockerKubernetesHelm

Service frameworks

Spring CloudgRPCDubbo

Data stores

RedisMongoDBKafkaES

Observability

PrometheusGrafanaJaeger

☁️Serverless2020s+

Function compute

LambdaVercelCloudflare

BaaS

SupabaseFirebaseAuth0

Frontend frameworks

Next.jsNuxtSvelteKit

Databases

PlanetScaleNeonTurso

4.3 بنية الخدمات المصغرة

لحل مشاكل البنية الأحادية، قسمنا المطبخ الكبير إلى مطابخ صغيرة متعددة (خدمات):

خدمة مخصصة للمستخدمين
خدمة مخصصة للطلبات
خدمة مخصصة للدفع

🏭 Microservices Architecture Demo

Observe how independent services collaborate and communicate

👤User serviceHealthy

Port:8081

Database:MySQL

Dependencies:None

📦Order serviceHealthy

Port:8082

Database:PostgreSQL

Dependencies:User service

💳Payment serviceHealthy

Port:8083

Database:MongoDB

Dependencies:User service, Order service

🏭Inventory serviceHealthy

Port:8084

Database:Redis

Dependencies:Order service

Service-to-service communication flow

User service

Verify user identity

Order service

Create order record

Inventory service

Check stock quantity

Payment service

Process payment request

Order service

Update order status

4.4 تنسيق Kubernetes

عندما يصل عدد الحاويات إلى المئات والآلاف، نحتاج إلى "نظام إدارة ميناء":

Kubernetes (K8s): مسؤول عن ترتيب الحاويات على الأجهزة المناسبة (جدولة، توسيع/تقليص، تحديث متدرج)
Service Mesh: مسؤول عن قواعد المرور بين الخدمات (الانصهار، تحديد المعدل، إعادة المحاولة، المراقبة)

☸️ Kubernetes Orchestration Demo

Observe how K8s schedules containers, balances load, and recovers from failures

Control Plane

🌐

API Server

Unified cluster entry point

🗄️

etcd

Distributed key-value store

📋

Scheduler

Pod scheduler

🎮

Controller

Controller manager

Worker Nodes

🖥️Node-1Running

CPU:

45%

Memory:

60%

Running Pods: 5

🖥️Node-2Running

CPU:

30%

Memory:

40%

Running Pods: 3

🖥️Node-3Pending

CPU:

Memory:

Running Pods: 0

💡 Kubernetes core concepts

Pod: The smallest deployment unit. A Pod can contain one or more containers.
Deployment: Manages Pod replica count and rolling updates.
Service: Provides stable network access and load balancing.
Scheduler: Automatically schedules Pods to suitable nodes based on resource needs and policies.

💡 ما هو "التنسيق"؟

التنسيق (Orchestration) يشير إلى نظام الإدارة التلقائية لعدد كبير من الحاويات.

تشبيه:

بدون K8s: تدير 100 حاوية يدوياً، أي حاوية تتعطل تعيد تشغيلها يدوياً، أي خدمة يزيد حملها تضيف أجهزة يدوياً
مع K8s: تخبره "أريد أن تعمل 10 نسخ من هذه الخدمة دائماً"، وسيقوم تلقائياً بـ:
- أي خادم موارده كافية، يرسل الحاوية إليه
- الحاوية تتعطل، يعيد تشغيلها تلقائياً
- الحمل يزيد، يوسع تلقائياً إلى 20 نسخة
- عند تحديث الكود، تحديث متدرج (إيقاف نسخة قديمة، تشغيل نسخة جديدة، استبدال واحدة تلو الأخرى)

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

4.5 مزايا وعيوب الخدمات المصغرة والحاويات

البعد	التقييم
المزايا	نشر مستقل للخدمات، إمكانية استخدام حزم تقنية مختلفة؛ عزل الأعطال، انهيار خدمة واحدة لا يؤثر على النظام كله؛ توسع حسب الطلب، توسيع منفصل للخدمات ذات الحمل العالي؛ تعاون ودي بين الفرق، فرق مختلفة مسؤولة عن خدمات مختلفة؛ مستودع كود أصغر، أسهل في الفهم والصيانة
العيوب	تعقيد عالٍ للأنظمة الموزعة (تأخير الشبكة، المعاملات الموزعة، اكتشاف الخدمات)؛ تكاليف تشغيل عالية، تحتاج فريق DevOps محترف؛ صعوبة في التصحيح، المشاكل قد تحتاج لتتبع عبر خدمات متعددة؛ صعوبة ضمان تناسق البيانات؛ متطلبات معقدة للبنية التحتية للنشر والمراقبة
السيناريوهات المناسبة	الفرق الكبيرة (>50 شخصاً)، الأعمال المعقدة التي تحتاج لتطور مستقل للوحدات، بعض الوحدات تحتاج لتوسع مستقل، الحاجة لحزم تقنية متعددة اللغات، الأنظمة ذات متطلبات التوفر العالي
السيناريوهات غير المناسبة	الفرق الصغيرة، الأعمال البسيطة، الحمل المنخفض والمستقر، عدم وجود فريق تشغيل محترف

⚠️ فخاخ الخدمات المصغرة

الفخ 1: الخدمات الأحادية الموزعة

قسمت إلى 10 خدمات مصغرة، لكنها مترابطة بشكل وثيق:

الخدمة A تستدعي الخدمة B، والخدمة B تستدعي الخدمة C، والخدمة C تستدعي الخدمة A
لتعديل وظيفة واحدة، تحتاج لتعديل 5 خدمات في نفس الوقت
عند النشر، يجب النشر بترتيب معين، وإلا يبلغ النظام عن أخطاء

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

الفخ 2: الإفراط في التقسيم

تقسيم وظيفة من 100 سطر كود إلى خدمة مستقلة:

10 خدمات، كل منها 100 سطر كود فقط
تكاليف الاتصال بين الخدمات (تسلسل/إلغاء تسلسل الشبكة) أثقل من منطق الأعمال الفعلي
تكاليف التشغيل تنفجر: نشر، مراقبة، جمع سجلات لـ 10 خدمات

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

4.6 الحزمة التقنية للخدمات المصغرة

الفئة	التقنية/الأداة	الدور
الحاويات	Docker, containerd	تغليف وعزل التطبيقات
التنسيق والجدولة	Kubernetes, Docker Swarm	إدارة الحاويات والتوسع/التقليص التلقائي
اكتشاف الخدمات	Consul, etcd, ZooKeeper	تسجيل واكتشاف الخدمات
بوابة API	Kong, Zuul, Envoy	مدخل موحد، توجيه، تحديد المعدل
مركز التكوين	Apollo, Nacos, Spring Cloud Config	إدارة مركزية للتكوين
المراقبة والإنذار	Prometheus, Grafana, ELK	مراقبة المؤشرات وتحليل السجلات
تتبع الطلبات	Jaeger, Zipkin, SkyWalking	تتبع الطلبات الموزعة
شبكة الخدمات	Istio, Linkerd	حوكمة المرور والأمان

5. عصر Serverless والسحابة الأصلية (2020s+)

5.1 لماذا نحتاج Serverless؟

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

هل المطبخ كبير بما يكفي؟ (توسيع الخوادم)
ماذا لو انقطع التيار الكهربائي؟ (التوفر العالي)
كيف ندير الحاويات الكثيرة؟ (تكاليف التشغيل)

⚡ Serverless Architecture Demo

Observe on-demand function execution and automatic scaling

🔐

User login

Cold

📦

Order processing

Cold

🖼️

Image processing

Cold

💾

Data backup

Cold

Auto-scaling status

Concurrent requests:0

Running instances:0

Cold starts:0

Traffic simulator

💡 Serverless core traits

On-demand execution: Functions run only when invoked, so idle functions do not create runtime cost.
Automatic scaling: Scale automatically from zero to thousands of instances without manual intervention.
Cold start: The first call after a long idle period may have extra latency and may need warm-up strategies.
Event driven: Respond to HTTP requests, message queues, scheduled tasks, and other event sources.

💡 Serverless لا يعني حقاً "لا توجد خوادم"

Serverless تعني "لست بحاجة لإدارة الخوادم"، وليس أنه لا توجد خوادم فعلياً.

تشبيه:

عصر الخوادم الفعلية: تشتري الأرض، تبني، تزين، توظف طهاة، تشتري مكونات... كل شيء بنفسك
عصر الخوادم السحابية: تستأجر مطعماً جاهزاً، لكن توظف الطهاة بنفسك وتدير العمليات
عصر Serverless: تحتاج فقط لتصميم القائمة، السحابة توفر مطبخاً مشتركاً، بطهاة محترفين، تطلب وهم يطبخون، تدفع لكل مرة

التغيير الأساسي:

سابقاً: شراء خادم ← تهيئة البيئة ← نشر الكود ← مراقبة ← توسيع ← صيانة
الآن: كتابة الكود ← رفع ← الدفع حسب الاستخدام

مثل تطبيقات التوصيل: لا تحتاج مطبخاً، فقط صمم القائمة، وهناك من يطبخ لك.

5.2 ما هو Serverless؟

Serverless = FaaS + BaaS

FaaS (Function as a Service، الوظيفة كخدمة):

تكتب دوالاً فقط (مثل "إرسال بريد ترحيبي عند تسجيل المستخدم")
مزود السحابة مسؤول عن تشغيل هذه الدالة، والتوسع/التقليص التلقائي
أمثلة نموذجية: AWS Lambda، علي بابا Function Compute

BaaS (Backend as a Service، الواجهة الخلفية كخدمة):

تسجيل الدخول ← Auth0 / Supabase Auth
الدفع ← Stripe
قاعدة البيانات ← Supabase / Firebase / DynamoDB
الرسائل ← Kafka / SQS

🎯 سيناريوهات Serverless المناسبة

أفضل السيناريوهات:

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

السيناريوهات غير المناسبة:

المهام طويلة الأمد: تحويل ترميز الفيديو (قد يستغرق ساعة، أقصى مدة تنفيذ للدالة عادة 15 دقيقة)
التطبيقات التي تحتاج زمن انتقال منخفض: التداول عالي التردد (تأخير البدء البارد قد يكون من عشرات المللي ثانية إلى عدة ثوانٍ)
الحاجة للتحكم الدقيق في الطبقة السفلى: ضبط نواة نظام التشغيل، الوصول المباشر لـ GPU

5.3 مزايا وعيوب Serverless والسحابة الأصلية

البعد	التقييم
المزايا	صفر تكاليف تشغيل، المطور يركز فقط على كود العمل؛ توسع وتقليص تلقائي، استجابة مثالية لذروات المرور؛ دفع حسب الاستخدام، تكلفة تقترب من الصفر عند عدم وجود حركة مرور؛ نشر سريع، دقائق للنشر عالمياً؛ توفر عالٍ مدمج، الخدمات السحابية تتعامل تلقائياً مع تجاوز الفشل
العيوب	تأخير البدء البارد (مئات المللي ثانية إلى عدة ثوانٍ)؛ قيود على مدة التشغيل (عادة 5-15 دقيقة)؛ صعوبة في التصحيح، صعوبة محاكاة البيئة السحابية محلياً بالكامل؛ خطر احتكار المزود؛ غير مناسب للمهام طويلة الأمد أو المكثفة حسابياً؛ التكلفة في سيناريوهات المرور العالي المستمر قد تتجاوز الحلول التقليدية
السيناريوهات المناسبة	معالجة مدفوعة بالأحداث (معالجة الصور، إشعارات الرسائل)؛ تطبيقات ذات حركة مد وجزر (صفحات الحملات، العروض الترويجية)؛ تحقق سريع للنماذج الأولية وMVP؛ واجهات API منخفضة التردد أو مهام خلفية؛ فرق صغيرة بدون فريق تشغيل متخصص
السيناريوهات غير المناسبة	تطبيقات تحتاج زمن انتقال منخفض مستمر؛ مهام حسابية طويلة الأمد؛ سيناريوهات حساسة للبدء البارد (تداول عالي التردد)؛ سيناريوهات تحتاج تحكماً دقيقاً في البنية التحتية

💰 مقارنة التكاليف: متى يكون Serverless أكثر تكلفة؟

السيناريو 1: وصول منخفض التردد

الخوادم التقليدية: 20 دولار/شهرياً (بغض النظر عن وجود زوار)
Serverless: مليون طلب × 0.0002 دولار/للطلب = 20 دولار (تدفع فقط عند وجود حركة مرور)
الخلاصة: السيناريوهات منخفضة التردد، Serverless أكثر توفيراً

السيناريو 2: وصول عالي التردد المستمر

الخوادم التقليدية: 20 دولار/شهرياً
Serverless: 100 مليون طلب × 0.0002 دولار/للطلب = 20,000 دولار
الخلاصة: السيناريوهات عالية التردد المستمرة، الخوادم التقليدية أكثر توفيراً

السيناريو 3: حركة المد والجزر

الخوادم التقليدية: للتعامل مع الذروة، تحتاج خادماً بـ 100 دولار/شهرياً (معدل استخدام الموارد في الأوقات العادية 10% فقط)
Serverless: 20 دولار وقت الذروة، وتقريباً 0 دولار في الأوقات العادية
الخلاصة: سيناريوهات حركة المد والجزر، Serverless يوفر التكاليف

الدرس: لا تنتقل لـ Serverless بشكل أعمى، يجب حساب التكاليف بناءً على خصائص حركة المرور الفعلية.

5.4 الحزمة التقنية ومنصات Serverless

الفئة	التقنية/المنصة	الخصائص
منصات FaaS	AWS Lambda	أول خدمة FaaS، المنظومة الأكثر نضجاً
	Azure Functions	تكامل عالٍ مع سحابة مايكروسوفت، صديقة لـ .NET
	Google Cloud Functions	تكامل عميق مع خدمات GCP
	علي بابا Function Compute	منظومة محلية متكاملة، تحسين جيد للبدء البارد
	تينسنت Cloud Function	تكامل مع منظومة WeChat
	Vercel/Netlify Functions	صديقة لمطوري الواجهة الأمامية، نشر على الحافة
خدمات BaaS	Firebase	حل الواجهة الخلفية للموبايل من Google
	Supabase	بديل مفتوح المصدر لـ Firebase مع PostgreSQL
	AWS Amplify	منصة تطوير تطبيقات الموبايل والويب من AWS
أدوات النشر	Serverless Framework	نشر متعدد السحابات، مجتمع نشط
	Terraform	البنية التحتية ككود
	Pulumi	تعريف البنية التحتية بلغات البرمجة

6. مقارنة مراحل البنية ودليل الاختيار

6.1 مقارنة شاملة لتطور البنية

🏗️Architecture Evolution ComparisonCore architectural traits across four eras

🖥️

Physical server

1990s

Single node

🏢

Monolith

2000s

Centralized

🏭

Microservices

2010s

Distributed

☁️

Serverless

2020s+

No server ops

🏢

Monolith (2000s)

🏗️ Architecture traits

Single codebase and unified stack
Shared database and transactional consistency
Unified deployment and whole-system release
In-process communication without network overhead

✅ Advantages

Simple development and onboarding
Convenient local testing
Simple deployment as one package

❌ Pain points

Tight coupling makes small changes risky
Single stack makes new technology hard to introduce
Large teams become hard to coordinate

🔧 Typical technologies

Spring/Django/RailsTomcat/GunicornMySQL/PostgreSQLMaven/Gradle

💡Core idea:Architecture evolves to solve prior pain points, while also introducing new complexity.

البعد	الخوادم الفعلية	البنية الأحادية	الخدمات المصغرة + الحاويات	Serverless
حجم الفريق	1-5 أشخاص	5-50 شخصاً	50-500 شخصاً	1-20 شخصاً
تعقيد النشر	عالٍ جداً	منخفض	عالٍ جداً	منخفض جداً
تكاليف التشغيل	عالية	متوسطة	عالية جداً	منخفضة
قابلية التوسع	ضعيفة	توسع رأسي محدود	توسع أفقي ممتاز	توسع تلقائي
مرونة الحزمة التقنية	لا يوجد	واحدة	متنوعة	محدودة
البدء البارد	لا يوجد	لا يوجد	وقت بدء الحاوية	يوجد تأخير
السيناريوهات المناسبة	أنظمة قديمة، متطلبات امتثال خاصة	شركات ناشئة، أعمال بسيطة	شركات إنترنت كبيرة، أعمال معقدة	تحقق سريع، مدفوع بالأحداث

6.2 شجرة قرار اختيار التقنية

ابدأ الاختيار
    │
    ├─ هل لدى الفريق موظفو تشغيل محترفون؟
    │   ├─ نعم ← فكر في الخدمات المصغرة أو الخوادم الفعلية
    │   └─ لا ← تابع التقييم
    │
    ├─ هل تحتاج لنشر سريع للتحقق من الفكرة؟
    │   ├─ نعم ← Serverless أو البنية الأحادية
    │   └─ لا ← تابع التقييم
    │
    ├─ حجم الفريق > 50 شخصاً؟
    │   ├─ نعم ← فكر في الخدمات المصغرة
    │   └─ لا ← تابع التقييم
    │
    ├─ هل لحركة المرور خصائص ذروة وانخفاض واضحة؟
    │   ├─ نعم ← Serverless
    │   └─ لا ← البنية الأحادية (موصى بها للشركات الناشئة)
    │
    └─ متطلبات خاصة (امتثال، أنظمة قديمة)؟
        └─ نعم ← الخوادم الفعلية

🎯 نصيحة للمبتدئين في اختيار التقنية

إذا كنت مطوراً أو فريقاً صغيراً:

المرحلة 0 (التعلم): تشغيل تطبيق أحادي محلياً، فهم HTTP، قواعد البيانات، البنية الأساسية
المرحلة 1 (MVP): نشر التطبيق الأحادي على خادم سحابي (مثل علي بابا ECS، AWS EC2)
المرحلة 2 (النمو): عندما يتجاوز الفريق 10 أشخاص وتصبح الأعمال معقدة، فكر في تقسيم خدمة أو اثنتين
المرحلة 3 (النضج): عندما يتجاوز الفريق 50 شخصاً وتصل الحركة للملايين، انتقل كلياً للخدمات المصغرة

المبدأ الأساسي: لا تبدأ بالخدمات المصغرة مباشرة، هذا "تحسين مبكر". دع البنية تتطور مع نمو الأعمال.

6.3 البنية الموصى بها للسيناريوهات المختلفة

السيناريو الأول: مطور مستقل/مشروع جانبي

البنية الموصى بها: Serverless (Vercel/Netlify) أو تطبيق أحادي
السبب: تكاليف تشغيل شبه معدومة، دفع حسب الاستخدام، نشر سريع
أمثلة الحزمة التقنية: Next.js + Vercel + Supabase

السيناريو الثاني: تحقق MVP لشركة ناشئة

البنية الموصى بها: بنية أحادية + خادم سحابي
السبب: سرعة تطوير عالية، الفريق يركز على منطق الأعمال بدلاً من البنية التحتية
أمثلة الحزمة التقنية: Spring Boot / Django / Rails + RDS + ECS

السيناريو الثالث: شركة نامية (فريق 10-50 شخصاً)

البنية الموصى بها: بنية أحادية معيارية أو خدمات مصغرة خفيفة
السبب: بدء مواجهة مشاكل ترابط الكود، لكن لا حاجة بعد لتعقيد الخدمات المصغرة الكامل
أمثلة الحزمة التقنية: Spring Cloud / Go Micro + Kubernetes

السيناريو الرابع: شركة إنترنت كبيرة

البنية الموصى بها: خدمات مصغرة + شبكة خدمات + بنية المنصة الوسطى
السبب: حجم فريق كبير، أعمال معقدة، حاجة لإيقاع نشر وحزم تقنية مستقلة
أمثلة الحزمة التقنية: إطار RPC مخصص + Istio + منصة PaaS مبنية ذاتياً

السيناريو الخامس: تطبيقات مدفوعة بالأحداث/ذات حركة مد وجزر

البنية الموصى بها: Serverless + ناقل أحداث
السبب: تقلب كبير في حركة المرور، حاجة لتحسين تكاليف قصوى وتوسع/تقليص تلقائي
أمثلة الحزمة التقنية: AWS Lambda + API Gateway + EventBridge

7. ملخص ومسار التعلم

7.1 النقاط الأساسية

تطور بنية الواجهة الخلفية، في جوهره، هو القيام بـ الجمع والطرح:

العصر	البنية	ما يفعله المطور	ما يفعله فريق التشغيل
العصر الفعلي	جهاز واحد	كتابة السكريبتات، نشر يدوي	صيانة غرفة الخوادم والعتاد
العصر الأحادي	كتلة واحدة	كتابة كل منطق الأعمال	صيانة عدة خوادم كبيرة
عصر الخدمات المصغرة	تقسيم	التركيز على عمل واحد	صيانة كتلة K8s (مرهقة جداً!)
Serverless	دوال	كتابة الدوال الأساسية فقط	شرب الشاي (مزود السحابة يتولى كل شيء)

الرؤية الأساسية:

تطور البنية ليس "استبدال التقنيات القديمة بالجديدة"، بل تغير في السيناريوهات المناسبة
لا يوجد حل سحري، لكل بنية حدودها المناسبة
اختيار البنية يجب أن يراعي: حجم الفريق، تعقيد الأعمال، خصائص حركة المرور، قدرة التشغيل

7.2 توصيات مسار التعلم

حسب مرحلتك المهنية، نوصي بمسارات التعلم التالية:

المرحلة الأولى: بناء الأساس (0-1 سنة)

الهدف: فهم مفاهيم الواجهة الخلفية الأساسية، القدرة على تطوير تطبيق أحادي بشكل مستقل

إتقان لغة خلفية واحدة (Java/Python/Go اختر واحدة)
تعلم بروتوكول HTTP وتصميم RESTful API
إتقان قواعد البيانات العلائقية (MySQL/PostgreSQL)
فهم أساسيات التخزين المؤقت (Redis)
تعلم Git وأوامر Linux الأساسية
مشروع عملي: إكمال تطبيق CRUD ببنية أحادية (مثل نظام مدونة، قائمة مهام)

المرحلة الثانية: توسيع القدرات (1-3 سنوات)

الهدف: فهم الأنظمة الموزعة، القدرة على المشاركة في تطوير الخدمات المصغرة

تعلم معمق لبنية الخدمات المصغرة واستراتيجيات التقسيم
إتقان أساسيات Docker و Kubernetes
تعلم طوابير الرسائل (Kafka/RabbitMQ)
فهم المعاملات الموزعة والتناسق
إتقان المراقبة والسجلات (Prometheus/ELK)
مشروع عملي: تقسيم تطبيق أحادي إلى 3-5 خدمات مصغرة، ونشرها باستخدام Docker

المرحلة الثالثة: التعمق الاحترافي (3-5 سنوات)

الهدف: القدرة على تصميم أنظمة كبيرة، وامتلاك مهارات اختيار التقنيات

فهم معمق لبنية السحابة الأصلية (Service Mesh، Serverless)
إتقان تخطيط السعة وضبط الأداء
فهم بنية التوفر المتعدد وتصميم التعافي من الكوارث
تعلم DDD (التصميم الموجه بالمجال)
تنمية مهارات الحكم التقني والتفكير المعماري
مشروع عملي: تصميم بنية نظام تدعم ملايين المستخدمين، تتضمن التوفر العالي، التوسع المرن، وغيرها من الحلول

7.3 موارد التعلم المستمر الموصى بها

كتب:

《Designing Data-Intensive Applications》(DDIA) - قراءة أساسية للأنظمة الموزعة
《Cloud Native Patterns》
《Building Microservices》
《Domain-Driven Design》

موارد عبر الإنترنت:

وثائق البنية الرسمية لـ AWS/Azure/علي بابا
وثائق مشاريع CNCF (Cloud Native Computing Foundation)
مدونات تقنية للشركات الكبرى (Netflix Tech Blog، قناة علي بابا التقنية، إلخ)

8. جدول المصطلحات (Glossary)

المصطلح	الاسم الكامل	الشرح
Backend	-	نظام جانب الخادم، مسؤول عن معالجة منطق الأعمال وتخزين البيانات والواجهات الخارجية
CGI	Common Gateway Interface	تقنية صفحات ويب ديناميكية مبكرة، تعالج الطلبات عبر السكريبتات وتعيد النتائج
Monolith	-	البنية الأحادية، تغليف كل منطق الأعمال في تطبيق واحد
Microservices	-	بنية الخدمات المصغرة، تقسيم الأعمال إلى خدمات مستقلة متعددة
Container	-	تقنية الحاويات، تغليف التطبيق واعتمادياته في وحدة محمولة
K8s	Kubernetes	منصة تنسيق الحاويات، للجدولة والتوسع/التقليص وحوكمة الحاويات
Service Mesh	-	شبكة الخدمات، مسؤولة عن حوكمة الاتصال بين الخدمات المصغرة والمراقبة والأمان
Serverless	-	الحوسبة بدون خادم، المطور يكتب الدوال فقط، والمنصة تشغلها وتوسعها/تقلصها تلقائياً
BaaS	Backend as a Service	خدمات خلفية سحابية جاهزة (مصادقة، قاعدة بيانات، دفع، إلخ)
CI/CD	Continuous Integration / Delivery	التكامل المستمر والتسليم المستمر، أتمتة عمليات الاختبار والنشر
Observability	-	القابلية للمراقبة، استخدام السجلات/المؤشرات/التتبع لفهم حالة تشغيل النظام

جوهر أطر عمل الويب ​

1. لماذا يجب فهم تطور البنية؟ ​

Home kitchen

🍽️ Restaurant scenario

💻 Backend mapping

⚡ Core pain points

2. عصر الخوادم الفعلية (1990s) ​

2.1 ما هو الخادم الفعلي؟ ​

2.2 الخصائص الأساسية ​

2.3 نقاط الألم ​

2.4 مزايا وعيوب عصر الخوادم الفعلية ​

3. عصر البنية الأحادية (2000s) ​

3.1 ما هي البنية الأحادية؟ ​

3.2 الخصائص الأساسية ​

3.3 المزايا ​

3.4 نقاط الألم: تأثير الانهيار المتسلسل ​

3.5 مزايا وعيوب البنية الأحادية والسيناريوهات المناسبة ​

3.6 الحزمة التقنية للبنية الأحادية ​

4. الحاويات والخدمات المصغرة (2010s) ​

4.1 لماذا نحتاج الخدمات المصغرة؟ ​

Traditional deployment

Docker containers

4.2 الخط الزمني للحزمة التقنية ​

4.3 بنية الخدمات المصغرة ​

🏭 Microservices Architecture Demo

Service-to-service communication flow

4.4 تنسيق Kubernetes ​

☸️ Kubernetes Orchestration Demo

💡 Kubernetes core concepts

4.5 مزايا وعيوب الخدمات المصغرة والحاويات ​

4.6 الحزمة التقنية للخدمات المصغرة ​

5. عصر Serverless والسحابة الأصلية (2020s+) ​

5.1 لماذا نحتاج Serverless؟ ​

⚡ Serverless Architecture Demo

💡 Serverless core traits

5.2 ما هو Serverless؟ ​

5.3 مزايا وعيوب Serverless والسحابة الأصلية ​

5.4 الحزمة التقنية ومنصات Serverless ​

6. مقارنة مراحل البنية ودليل الاختيار ​

6.1 مقارنة شاملة لتطور البنية ​

Monolith (2000s)

🏗️ Architecture traits

✅ Advantages

❌ Pain points

🔧 Typical technologies

6.2 شجرة قرار اختيار التقنية ​

6.3 البنية الموصى بها للسيناريوهات المختلفة ​

السيناريو الأول: مطور مستقل/مشروع جانبي ​

السيناريو الثاني: تحقق MVP لشركة ناشئة ​

السيناريو الثالث: شركة نامية (فريق 10-50 شخصاً) ​

السيناريو الرابع: شركة إنترنت كبيرة ​

السيناريو الخامس: تطبيقات مدفوعة بالأحداث/ذات حركة مد وجزر ​

7. ملخص ومسار التعلم ​

7.1 النقاط الأساسية ​

7.2 توصيات مسار التعلم ​

المرحلة الأولى: بناء الأساس (0-1 سنة) ​

المرحلة الثانية: توسيع القدرات (1-3 سنوات) ​

المرحلة الثالثة: التعمق الاحترافي (3-5 سنوات) ​

7.3 موارد التعلم المستمر الموصى بها ​

8. جدول المصطلحات (Glossary) ​

جوهر أطر عمل الويب

1. لماذا يجب فهم تطور البنية؟

2. عصر الخوادم الفعلية (1990s)

2.1 ما هو الخادم الفعلي؟

2.2 الخصائص الأساسية

2.3 نقاط الألم

2.4 مزايا وعيوب عصر الخوادم الفعلية

3. عصر البنية الأحادية (2000s)

3.1 ما هي البنية الأحادية؟

3.2 الخصائص الأساسية

3.3 المزايا

3.4 نقاط الألم: تأثير الانهيار المتسلسل

3.5 مزايا وعيوب البنية الأحادية والسيناريوهات المناسبة

3.6 الحزمة التقنية للبنية الأحادية

4. الحاويات والخدمات المصغرة (2010s)

4.1 لماذا نحتاج الخدمات المصغرة؟

4.2 الخط الزمني للحزمة التقنية

4.3 بنية الخدمات المصغرة

4.4 تنسيق Kubernetes

4.5 مزايا وعيوب الخدمات المصغرة والحاويات

4.6 الحزمة التقنية للخدمات المصغرة

5. عصر Serverless والسحابة الأصلية (2020s+)

5.1 لماذا نحتاج Serverless؟

5.2 ما هو Serverless؟

5.3 مزايا وعيوب Serverless والسحابة الأصلية

5.4 الحزمة التقنية ومنصات Serverless

6. مقارنة مراحل البنية ودليل الاختيار

6.1 مقارنة شاملة لتطور البنية

6.2 شجرة قرار اختيار التقنية

6.3 البنية الموصى بها للسيناريوهات المختلفة

السيناريو الأول: مطور مستقل/مشروع جانبي

السيناريو الثاني: تحقق MVP لشركة ناشئة

السيناريو الثالث: شركة نامية (فريق 10-50 شخصاً)

السيناريو الرابع: شركة إنترنت كبيرة

السيناريو الخامس: تطبيقات مدفوعة بالأحداث/ذات حركة مد وجزر

7. ملخص ومسار التعلم

7.1 النقاط الأساسية

7.2 توصيات مسار التعلم

المرحلة الأولى: بناء الأساس (0-1 سنة)

المرحلة الثانية: توسيع القدرات (1-3 سنوات)

المرحلة الثالثة: التعمق الاحترافي (3-5 سنوات)

7.3 موارد التعلم المستمر الموصى بها

8. جدول المصطلحات (Glossary)