هل فكرت يوما ما بالتقدم إلى شركة برمجية كبيرة مثل غوغل، مايكروسوفت، فيس بوك أو غيرها، ووجدت عبارة "مقابلة تصميم النظام - System design interview"؟

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

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

مفهوم تصميم النظام

يعبر تصميم النظام عن عملية تعريف مكونات النظام (components)، وحداته (modules)، بياناته (data) وواجهاته (interfaces) بطريقة تلبي متطلبات النظام (الوظيفية وغير الوظيفية). [ويكيبيديا]

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

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

أنواع المتطلبات في النظم

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

١) متطلبات وظيفية (functional requirements)

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

٢) متطلبات غير وظيفية (non-functional requirements)

وهي الخواص الأخرى التي نريد توافرها في النظام، مثلاً في حالة فيس بوك، يمكن ان تكون بعض المتطلبات غير الوظيفية كالتالي:

• يجب أن يتم تنفيذ أي طلب خلال اقل من ثانية
• يجب أن يكون الموقع قادر على الاحتفاظ ببيانات، صور، محادثات المستخدمين لمدة ١٠ سنوات على الأقل
• يجب أن يكون اي منشور جديد متوفر للآخرين خلال اقل من 5 ثوان من نشره
• يجب أن يكون الموقع (فيس بوك) متوفر 100% من الوقت لجميع المستخدمين، وأن لا تحدث الانقطاعات عند نشر الكود الجديد، او القيام بالصيانة، وغير ذلك.

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

مكونات النظم

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

اليك بعض أنواع المكونات التي نتعامل معها أثناء تصميم النظم البرمجية:

• انظمة تخزين البيانات (قواعد البيانات العلائقية مثل MySql  او انظمة البيانات غير العلائقية مثلا Cassandra, Elastic Search وغيرها)
• عملية التحكم بمرور الطلبات Routing، وموازنة الحمل Load Balancing
• انظمة تخزين البيانات المؤقتة Caching مثل Redis, Memcached
• انظمة توزيع المحتوى CDNs
• انظمة نقل الرسائل Message Bus وقوائم الانتظار Queuing وغيرها الكثير..

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

لماذا نحتاج الى تصميم الأنظمة؟

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

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

١) الموثوقية (Reliability) والتوافرية (Availability)

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

٢) قابلية التوسع (Scalability)

سنتحدث عنها بالتفصيل في الفقرة التالية، لكن باختصار تعني قدرة النظام على التعامل مع الزيادة في حمل العمل (workload) بأساليب بسيطة عادة ما تقتصر على أضافة موارد (hardware/resources) الى النظام، بدون اجراء تعديلات في معمارية النظام او بنيته.

٣) قابلية الصيانة (Maintainablilty)

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

سنتكلم الآن عن قابلية التوسع قليلا، على اعتبار النقاط الأخرى واضحة، ولأن قابلية التوسع قد تكون أحد اهم الاسباب التي تحدد شكل النظام وتصميمه، 

قابلية التوسع (Scalability)

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

نقول عن نظام أنه قابل للتوسع (Scalable) اذا كان من السهل معالجة الزيادة في الحمل من خلال إضافة موارد جديدة الى النظام فقط.

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

هل يمكن معاجلة الحمل المتزايد (ازدياد عدد المستخدمين، بالتالي عدد الرسائل) من خلال اضافة موارد جديدة الى النظام (مثلا: اضافة سيرفرات جديدة، اضافة قواعد بيانات جديدة، وغير ذلك) من بدون إعادة هيكلة النظام؟

اذا كان الجواب نعم، نقول ان النظام (او تصميم النظام المتبع) قابل للتوسع (scalable).

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

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

في جميع الاحوال، يمكننا التمييز بين نوعين من قابلية التوسع

• قابلية التوسع شاقوليّا (Vertical Scaling) ويعني توسيع النظام لمعالجة الحمل الزائد من خلال زيادة قدرات كل سيرفر (او الة افتراضية)، مثلا: زيادة قوة المعالجات، او زيادة حجم الذاكرة RAM المستخدم، او زيادة سعة قاعدة البيانات.
• قابلية التوسع أفقيا (Horizontal Scaling) ويعني توسيع النظام لمعالجة الحمل الزائد من خلال زيادة عدد وحدات التخديم (المخدمات مثلا)، او عدد الآلات الافتراضية، او زيادة مخدمات قاعدة البيانات.

الاسلوب الثاني (التوسع الافقي) قد يكون الامثل في كثير من الحالات، لان الاسلوب الأول له حدود وغير عملي أحيانا، وحدوده قد تكون الحدود التقنية (مثلا لا يمكن ويادة سرعة المعالج فوق حد معين) او الكلفة الباهظة (تخيل مثلا الحاجة الى ذاكرة RAM بحجم 2 تيرا بايت). في حين أن اضافة سيرفرات جديدة إلى النظام قد يكون بالأمر اليسير.

مثال عملي: تصميم موقع لرفع الملفات

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

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

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

مما سبق، نلاحظ اننا نحتاج الى المكونات الأساسية التالية في موقعنا على الأقل

١- مخدم ويب (web server)

ليقوم بتلقي طلبات المستخدمين وتوجيهها الى لغة البرمجة المستخدمة لمعالجتها، كما ويقوم بتخديم ملفات المستخدمين. هناك العديد من الخيارات الممكنة للتقنيات التي يمكن استخدامها هنا، وكمثال، يمكنك استخدام Apache server مع PHP كلغة برمجة، او nodejs و express server او غير ذلك من التقنيات.

٢- قاعدة بيانات (database)

 لتخزين معلومات المستخدمين، مثلا جدول المستخدمين، جدول يحتوي معلومات المرفقات المرفوعة، ومساراتها.. وكمثال يمكننا استخدام MySql server.

٣- مكان لتخزين الملفات

لتخزين الملفات المرفوعة من قبل المستخدمين.

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

1) تصميم أولي لموقع رفع الملفات

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

عيوب النظام

على أية حال، يمكن لهذا التصميم أن يعاني العديد من المشاكل مع زيادة الحمل، وزيادة الحمل قد تحدث باي من الاشكال التالية

1. زيادة حجم الملفات المخزنة على السيرفر، بحيث لا يمكن استيعاب المزيد..
2. زيادة عدد الطلبات الى المخدم، بحيث لا يستطيع المخدم معالجتها كلها (للمخدمات سعة محدودة تختلف من مخدم لاخر، وتعتمد بشكل رئيسي على زمن معالجة الطلب الواحد، وقدرة المخدم على المعالجة المتوازية، لكن في كل الاحوال، السعة ستكون محدودة).
3. زيادة الحمل على قاعدة البيانات، والذي يؤثر ايضا على عدد الطلبات التي يستطيع المخدم معالجتها، على اعتبار قاعدة البيانات في هذا التصميم "عنق زجاجة".

وغير ذلك الكثر من الأسباب المحتملة..

2) تصميم ثانٍ محسّن من خلال عزل تخزين الملفات

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

لكن يمكننا زيادة التخزين الى حد معين، بعد ذلك ستصبح هذه العملية مكلفة للغاية، ومعرّضة للمخاطر، فان تلف التخزين الوحيد الموجود سيؤدي الى فقدان كافة البيانات.

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

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

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

من الخيارات الممكنة للتخزين، استخدام خدمة تخزين خارجية سحابية، مثلا خدمة Amazon S3 Storage. مثل هذه الخدمات تقوم تلقائيا بضمان توافرية البيانات، تكرارها (لتجنب الضياع)، قابلية التوسع، التوافرية الجغرافية (تكرار البيانات في عدة مراكز بيانات لتخديمها من المركز الاقرب للمستخدم) وغيرها الكثير، لانها مبنية فوق انظمة معقدة ومصممة بعناية شديدة.

من الحلول الاخرى لمشاركة التخزين بين مجموعة من السرفرات هو استخدام نظام بيانات شبكي (Network File System - NFS).. كذلك له محاسنه وعيوبه الخاصة.. لن نتطرق أي حل الأفضل، ودعنا نفترض أننا قررنا استخدام خدمة تخزين سحابية.

عيوب النظام

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

3) تصميم ثالث محسّن من خلال زيادة مخدمات الويب وعزل قاعدة البيانات

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

لأخذ العلم: موزع الحمل أو موازن الحمل (Load Balancer) هو مكون في النظام، يقوم بتلقي الطلبات وتوزيعها بشكل متساوٍ على مجموعة مخدمات (أو مكونات) أخرى في النظام، بغية تخفيف الحمل عن كل منها.

فكر مليا بهذا التصميم: يقوم موازن الحمل (Load Balancer) بتلقي طلبات المستخدمين، ويقوم بتوزيع هذه الطلبات على المخدمات بشكل عشوائي (يوجد عدة انواع لموزنات الحمل، دعنا نعتبر ان الموازنة تتم من خلال توزيع الطلبات بشكل عشوائي على المخدمات).

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

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

يمكننا استخدام مخدمات مختصة لاستضافة قاعدة البيانات. على سبيل المثال، (MySql cluster) حل شائع لهذه المشكلة. كما ويمكننا ايضا استخدام خدمة قاعدة بيانات مدارة (سحابية)، مثلا أمازون أيضا تقدم خدمة قاعدة بيانات، حيث تقوم بادارة مجموعة امور من بينها تكرار البيانات replication (لتسريع عمليات القراءة)، النسخ الاحتياطي، وغيرها الكثير.. ومثل هذه الخدمات سهلة التوسيع جدا.

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

الآن، يمكننا اضافة العدد الذي نرغب به من المخدمات بحيث يتلقى كل مخدم كمية أقل من الطلبات، بحيث يستطيع معالجتها.

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

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

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

دعنا نلقي نظرة سريعة على المتطلبات غير الوظيفية التي ذكرناها في بداية المقال، ونرى مدى تحقق كل منها في نظامنا

قابلية التوسع

نستطيع معالجة الحجم الزائد من الطلبات من خلال اضافة مخدمات ويب جديدة، كما ويمكننا معالجة الزيادة في حجم الملفات من خلال التحكم بخدمة تخزين الملفات المنفصلة (في حالة استخدام الخدمات السحابية، تكون هذه العملية في منتهى البساطة).

كذلك نستطيع معالجة الحمل الزائد على قاعدة البيانات بحسب تفاصيل تنفيذ قاعدة البيانات. مثلا، في حال استخدام MySql Cluster يمكننا ببساطة اضافة عقد جديدة للقراءة.

لأخذ العلم: في قواعد بيانات MySql، يمكن اتباع معمارية تدعى Primary/Secondary Architecture، تعتمد بشكل اساسي على حقيقة ان معظم التطبيقات تحتاج الى عدد كبير من عمليات القراءة، وعدد قليل من عمليات الكتابة، لذلك يتم تكوين نظام قاعدة البيانات من عدة مخدمات، احدها يدعى المخدم الرئيسي، تتم جميع عمليات الكتابة من خلاله، وبقية المخدمات تدعى المخدمات الثانوية، حيث تقوم بنسخ البيانات من المخدم الرئيسي وجعلها متاحة لتتم عمليات القراءة من خلالها. يسمح هذا التصميم بزيادة قدرة نظام قاعدة البيانات على معالجة كميات كبيرة من عمليات القراءة.

قابلية التوسع من وجهة نظر اقتصادية

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

التوافرية والموثوقية

حتى ولو تعطل احد مخدمات الويب، هناك مخدمات اخرى تنوب عنه. توافرية قاعدة البيانات تعتمد بشدة على التصميم المعتمد، لكن في حال استخدام الخدمات السحابية، عادة تتم ادارة التوافرية من قبل مخدم قاعدة البيانات، وفي حال تطبيق Primary/Secondary Architecture، عمليات القراءة يمكن أن تتم من خلال اي مخدم، وفي حال فشل المخدم الرئيسي، يمكن انتخاب اي مخدم ثانوي كمخدم رئيسي جديد بحيث يبقى النظام متوافرا، وموثوقا.

قابلية الصيانة

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

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

في الختام

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

لا تقلق اذا ما صادفتك مصطلحات لم تعرف معناها تماما، سنقوم في الأيام القادمة بكتابة المزيد من المقالات لتوضيح مفاهيم النظم وتصميمها، واعطاء العديد من الأمثلة.

لا تتردد بطرح أي أسئلة او استفسارات من خلال التعليقات.

دريد عبد الله

تم تصميم الرسوم التوضيحية باستخدام النسخة المجانية من Lucidchart