توسيع نطاق تطبيق الويب الخاص بك: الخطوات الأساسية

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

التحسين

يقترح Gearheart طرح الأسئلة التالية على نفسك:

• هل استعلامات قاعدة البيانات مثالية (شرح التحليل ، استخدام الفهارس)؟
• هل البيانات مخزنة بشكل صحيح (SQL مقابل NoSQL)؟
• يتم استخدام التخزين المؤقت؟
• لا توجد طلبات غير ضرورية إلى FS أو قاعدة البيانات؟
• هل خوارزميات معالجة البيانات مثالية؟
• هل إعدادات البيئة مثالية: Apache / Nginx ، MySQL / PostgreSQL ، PHP / Python؟

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

تحجيم

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

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

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

هندسة التطبيق

معظم تطبيقات الويب موزعة مسبقًا ، لأنه يمكن تقسيم بنيتها إلى ثلاث طبقات على الأقل: خادم الويب ، ومنطق الأعمال (التطبيق) ، والبيانات (قاعدة البيانات ، والثابت).

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

عنق الزجاجة

بالانتقال إلى مقياس النظام ، فإن أول شيء يجب فعله هو تحديد أي من الطبقات هو "عنق الزجاجة" ، أي أبطأ من بقية النظام. بادئ ذي بدء ، يمكنك استخدام أدوات مساعدة تافهة مثل top (htop) لتقييم استهلاك وحدة المعالجة المركزية / الذاكرة و df و iostat لتقييم استهلاك القرص. ومع ذلك ، فمن المستحسن توفير مضيف منفصل بمحاكاة حمل المعركة (باستخدام AB أو JMeter) ، حيث يمكنك وضع ملف تعريف للتطبيق باستخدام أدوات مساعدة مثل xdebug و oprofile وما إلى ذلك. يمكنك استخدام أدوات مساعدة مثل pgFouine لتحديد استعلامات قاعدة البيانات الضيقة (بالطبع ، من الأفضل القيام بذلك بناءً على السجلات من خادم المعركة).

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

تحجيم قاعدة البيانات

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

يمكنك تقليل الحمل على قاعدة البيانات بتقسيمها إلى عدة مضيفين. هناك صعوبة حادة في المزامنة بينهما ، والتي يمكن حلها من خلال تنفيذ مخطط السيد / العبد مع النسخ المتزامن أو غير المتزامن. بالنسبة إلى PostgreSQL ، يمكنك استخدام Slony-I للنسخ المتزامن و PgPool-II أو WAL (9.0) للنسخ المتماثل غير المتزامن. لحل مشكلة تقسيم طلبات القراءة والكتابة ، بالإضافة إلى موازنة الحمل بين العبيد ، يمكنك تكوين طبقة وصول خاصة لقاعدة البيانات (PgPool-II).

يمكن حل مشكلة تخزين كميات كبيرة من البيانات في حالة قواعد البيانات العلائقية عن طريق التقسيم ("التقسيم" في PostgreSQL) ، أو عن طريق نشر قاعدة البيانات على قاعدة بيانات موزعة مثل Hadoop DFS.

يمكنك أن تقرأ عن كلا الحلين في الكتاب الممتاز عن تكوين PostgreSQL.

1- ومع ذلك ، لتخزين كميات كبيرة من البيانات ، فإن أفضل حل هو التجزئة ، وهي ميزة متأصلة في معظم قواعد بيانات NoSQL (على سبيل المثال ، MongoDB).

2- علاوة على ذلك ، تعمل قواعد بيانات NoSQL بشكل عام بشكل أسرع من إخوانهم في SQL بسبب عدم وجود عبء لتحليل / تحسين الاستعلام ، والتحقق من سلامة بنية البيانات ، وما إلى ذلك. موضوع مقارنة قواعد البيانات العلائقية و NoSQL واسع جدًا ويستحق مقال منفصل.

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

تحجيم التعليمات البرمجية

• تعتمد تعقيدات قياس التعليمات البرمجية على عدد الموارد المشتركة التي يحتاجها مضيفوك لتشغيل التطبيق الخاص بك. هل ستكون مجرد جلسات أم ستحتاج إلى مشاركة ذاكرات التخزين المؤقت والملفات؟ في كلتا الحالتين ، فإن أول شيء يجب فعله هو تشغيل نسخ من التطبيق على مضيفين متعددين بنفس البيئة.
• بعد ذلك ، تحتاج إلى إعداد موازنة التحميل / الطلب بين هذه الأجهزة المضيفة. يمكنك القيام بذلك على TCP (HAProxy) أو HTTP (nginx) أو DNS.
• الخطوة التالية ، كما ذكر Gearheart ، هي إتاحة الملفات الثابتة وذاكرة التخزين المؤقت وجلسات تطبيق الويب على كل مضيف. بالنسبة للجلسات ، يمكنك استخدام خادم يعمل عبر الشبكة (على سبيل المثال ، Memcached). كخادم ذاكرة تخزين مؤقت ، من المنطقي استخدام نفس Memcached ، ولكن على مضيف مختلف بالطبع.
• يمكن تحميل الملفات الثابتة من بعض وحدات تخزين الملفات المشتركة عبر NFS / CIFS أو باستخدام FS (HDFS ، GlusterFS ، Ceph).

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

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