⏏️ ⛹🏾 👩🏽‍🔬 هندسة خادم العميل في الصور 👨🏻‍⚖️ 🕍 🎳

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

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

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

المحتوى

ما هو وكيف يعمل

هنا لدينا Vasya معين قرر شراء سيارة. كما هو الحال في الإعلانات - سريعة وقوية وجميلة! إنها تقف فقط مثل ذيل طائرة ، ولا تمتلك فازيا هذا النوع من المال.

بالطبع ، يمكن أن تحفر فازيا لعدة سنوات ، ثم تشتري سيارة. لكنك تريد هنا والآن! نعم ، وهناك حاجة إلى سيارة ...

وفاسيا لا تعرف كيف تدخر - حصلت على راتب ، اشترت الراتب الرئيسي ، دفعت للإسكان ، هذا كل شيء! يمكن إنفاق الباقي. لمثل هؤلاء الناس ، هناك بنوك حيث يمكنك أن تأتي وتأخذ المال على الائتمان.

بالطبع ، عندها سوف تبالغ في إعادتهم. الفائدة حصان. ولكن الآن يمكنك بالفعل شراء شيء باهظ الثمن.

فَسَّرَ فَسْيَا وَقَدَرَهُ وَقَالَ:: بَلْ

أَفْعَلْ! يمكنني دفع 100 روبل من راتبي إلى البنك ، ولكن لا يمكنني حفظه. سوف أنفقه.

لذلك ، يذهب Vasya إلى البنك ويقول:

- أنا Vasily Ivanov ، أريد قرض سيارة مقابل 1000 روبل.

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

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

الويب - افتح في المتصفح مثل google أو facebook
سطح المكتب - على جهاز كمبيوتر ، مثل كلمة أو آلة حاسبة

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

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

أدخلت كاتيا البيانات على العميل. ولكن عندما نقرت على "check" ، أرسل العميل طلبًا إلى الخادم:

- أعطني معلومات عن Vasya Ivanov!

أرسل الخادم طلبًا إلى قاعدة البيانات ، قاعدة البيانات:

- حدد * من العملاء حيث fio = 'Vasily Ivanov'. (أعطني كل المعلومات عن اسم "فاسيلي إيفانوف")

ردت القاعدة:

- هنا لديك كل ما وجدته.

أرجع الخادم هذه المعلومات إلى العميل:

وقد رسمها العميل بالفعل لـ Katya:

يبدو Katya:

- نعم ، تاريخ الائتمان جيد.

ويقترح على Vasya:

- من فضلك ، إذا كنت ترغب في الحصول على قرض ، فنحن مستعدون لتخصيص 1000 روبل لمدة 12 عامًا بنسبة 80 ٪ سنويًا. ترتيبها؟

يسر Vasya:

- نعم ، كل شيء يناسبني ، أعطني المزيد من المال ، وركضت خلف السيارة!
الجميع سعداء ، الجميع سعداء.

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

لماذا أحتاج إلى عميل

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

لماذا نحتاج إلى خادم

إنه أقوى ،

يمكن أن يكون هناك العديد من العملاء. في المثال مع البنك ، يمكن أن يكون لدينا 10 فروع في 10 مدن في روسيا ، ولكل فرع 10 وكلاء تشغيل. ألف كاتيك ، ولكل منها جهاز كمبيوتر منفصل.

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

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

لا يوجد تكرار التعليمات البرمجية

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

لا حاجة لتكرار الشفرة ، لأن كل المنطق الرئيسي يتم نقله إلى خادم أكثر قوة.

هذا أكثر أمانًا

، حيث يتم تخزين معلومات الخادم والخادم التي لا يمكن لعامل تشغيل بسيط الوصول إليها. :

بيانات العميل
معلومات عن امواله
القوائم السوداء للبنك
...

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

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

لماذا نحتاج إلى قاعدة

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

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

DB (قاعدة بيانات) - منتج برمجي منفصل يتيح لك:

جلب المعلومات بسرعة
حفظ المعلومات حتى عند إعادة تشغيل النظام.

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

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

مزايا العمارة

نلخص مزايا العمارة:

الخادم القوي أرخص من أكثر من 100 جهاز عميل قوي - إذا أردنا ألا يتباطأ التطبيق ، فنحن بحاجة إلى جهاز جيد. سيكون لديك واحد. أو القليل ، إذا كان الحمل كبيرًا ، ولكن من الواضح أنه أقل من عدد العملاء.
— , « » « , 100 ».
— . , .

لقد

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

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

فكيف يفهم العميل إلى أين يرسل الطلب إليه؟

يتم وضع موازن أمام الخوادم ، ويرسل العميل طلبًا هناك. بغض النظر عن عدد الخوادم التي تم وضعها في المجموعة ، فإن العميل غير مهتم. لها عنوان URL واحد - عنوان الموازن.

والآن يتلقى العميل طلبًا:

- أعطني جميع المعلومات عن Vasya Ivanov.

يقول الموازن:

- يا شباب ، طلب جديد! من هو الأقل تحميلا؟

الخادم الأول:

- لدي 5 طلبات في قائمة الانتظار.

ثانياً:

ولدي 2.

يرسل الموازن طلباً إلى الخادم الثاني.

يتم استخدام هذا المخطط لتطبيق محمّل للغاية - عندما يكون هناك العديد من الطلبات التي لا يمكن لخادم واحد التعامل معها.

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

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

يسمى هذا المخطط الاستعداد السريع - عندما يكون لدينا العديد من الخوادم التي تعمل بالتوازي ، ويوزع الموازن الحمل بينهما.

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

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

في هذا الوقت ، سيكون لدى المسؤولين الوقت للتعامل مع المشكلة على الخادم 1.

يتم استخدام مخطط الاحتياطي البارد عندما يكون خادم واحد قادرًا على تحمل الحمل وإعطاء سرعة جيدة. لكن التطبيق عمل نقدي وبسيط غير مقبول.

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

إعادة توجيه كل الحمل إلى الخادم 2
إيقاف الخادم 1
تحديث الخادم 1
نطلقه ونوجه الحمل بأكمله عليه
إيقاف الخادم 2
قم بتحديثه
أطلقنا
اقسم الحمل مرة أخرى (إذا كان احتياطيًا ساخنًا)

أي أن التطبيق لا يتوقف عن العمل على الإطلاق!

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

معدات

الخادم عالية التكلفة باهظة الثمن. هناك لا يمكنك وضع SSD عادي لجهاز كمبيوتر منزلي. لماذا ا؟ نظرًا لأن متطلبات الأجهزة للخوادم مختلفة تمامًا للأجهزة + هناك دعم لوظائف محددة:

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

- يوجد SSD بوجود مجموعة من المكثفات التي تخزن الطاقة في حالة انقطاع التيار الكهربائي ، بحيث يكون هناك وقت كافٍ لرمي البيانات من ذاكرة التخزين المؤقت DDR في الذاكرة غير المتقلبة ولا تنكسر البيانات.

SSD - قرص سريع العمل ، HDD - عادي. RAID - عندما قمنا بتوصيل أقراص N معًا ، وذاكرة التخزين المؤقت DDR هي ذاكرة الوصول العشوائي

بالإضافة إلى ذلك ، تتمتع حلول الخوادم عادة بضمان أطول بكثير: 5 سنوات ، وليس عامًا.

بالنسبة للسعر ، فإنها تختلف مرتين. على سبيل المثال ، SSD:

لجيجابايت المنزل يكلف 16.53r
لحفلة المؤسسة الخادم يكلف 32 روبل

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

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

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

بحاجة لتوظيف مسؤول النظامツ

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

ما يجب اختباره

لفهم ما يجب اختباره ، تحتاج إلى فهم ما يتعامل معه الشخص.

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

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

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

ومع ذلك ، إذا كان لديك حق الوصول إلى خادم التطبيق وقاعدة البيانات الخاصة به - يجدر التحقق منها أيضًا! حتى نتمكن من رؤية "علة المستقبل". على سبيل المثال:

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

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

- حسنًا ، ربما لم يتم تعبئتها.

وقد امتلأوا! مجرد إنقاذ عمل ملتوية. لذلك ، إذا كان لدينا صندوق أسود فقط ، فعلينا التحقق من "هل تم حفظ البيانات حقًا؟" تم الحفظ؟ افتح البطاقة في نافذة جديدة أو اتصل بالمعلومات من خلال طريقة API.

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

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

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

يقوم المختبر بفحص نقاط الضعف ثم يخبر الفريق:

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

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

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

مجموع

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

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

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

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

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

DB (قاعدة بيانات) - مستودع البيانات. هنا يمكنك البحث بسهولة عن المعلومات + تأكد من أنها ستبقى ، حتى إذا حدث أي شيء في التطبيق.

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

قد لا تكون هناك قاعدة منفصلة ، فإن البنية ستصبح ذات مستويين: خادم العميل. و هذا كل شيء!

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

PS - ابحث عن المزيد من المقالات المفيدة في مدونتي تحت العلامة "مفيدة"

هندسة خادم العميل في الصور