تشير بنية الخلفية إلى كيفية هيكلة الواجهة الخلفية لتطبيق الويب الخاص بك. تحدد بنية الخلفية كيفية تواصل أجزاء التطبيق مع بعضها البعض لمعالجة الطلبات الواردة وإنشاء الردود. عند إنشاء تطبيق ويب، حدد بنية خلفية بناءً على متطلباتك وعواملك المحددة، بما في ذلك التكلفة (سواء المستمرة أو على نطاق واسع)، وتعقيد تطبيقك، وأهداف التوسيع، وخبرة فريقك.
بالنسبة إلى تطبيقات الويب التي تعتمد على المحتوى تحديدًا، مثل التجارة الإلكترونية أو الصحف أو المدونات، تشمل المتطلبات المهمة اتساق البيانات والأداء، خاصةً مع نمو التطبيق على نطاق عالمي وقد يتم توزيعه بشكل أكبر. بالنسبة إلى تطبيقات الويب التي تعتمد على المحتوى، تُعدّ مساحة تخزين البيانات التي يستخدمها تطبيقك مهمة للغاية وتتناقش بمزيد من التفصيل في دليل تخزين البيانات. لتجاوز بُنى التطبيقات النموذجية، واستضافة المحتوى وإتاحة الوصول إليه، يعدّ أمرًا بالغ الأهمية عند تحسين أداء التطبيق. تعرَّف على مزيد من المعلومات حول اختيار استراتيجية الاستضافة المناسبة وتحسين تطبيقك في دليل الاستضافة.
إذا كانت لديك خلفية حالية لتطبيق ويب، ففكر في حدود البنية الحالية. على سبيل المثال، عندما يتوسع التطبيق ويتزايد الطلب على أدائه وزيادة الموثوقية، فكر في ما إذا كان يجب إعادة هيكلة أجزاء من تطبيقك أو نقلها إلى بنية مختلفة أكثر ملاءمة للنطاق المتزايد. على سبيل المثال، تسمح لك البُنى الأساسية المختلطة (أو المستنِدة إلى سُحب إلكترونية متعدّدة) بتحويل بعض أعباء العمل إلى السحابة قبل إجراء عملية نقل كاملة. من الضروري أيضًا مراعاة التكلفة والوقت والمخاطر التي تنطوي عليها عملية الانتقال هذه.
هندسة متجانسة
تحتوي البنية المتجانسة على هيكل موحّد، مع دمج جميع مكونات التطبيق بإحكام في قاعدة تعليمات برمجية واحدة. يتم إنشاء التطبيق بالكامل كوحدة واحدة مستقلة. البنية المتجانسة متعددة المستويات، حيث تنجز طبقات مختلفة من التطبيق مهامًا محددة.
الطبقات البنيوية
- واجهة المستخدم (UI)، التي تتضمن مكونات لعرض ميزات التطبيق، عادةً ما تكون تطبيقًا مستندًا إلى الويب أو سطح مكتب يتفاعل مع المستخدمين.
- منطق التطبيق هو المكان الذي تكمن فيه الوظيفة الأساسية.ويحتوي هذا الجزء من قاعدة الرموز البرمجية على القواعد والعمليات الحسابية والعمليات التي تحدِّد طريقة عمل التطبيق.
- تحتوي طبقة الوصول إلى البيانات على دوال لقراءة البيانات وكتابتها والترجمة بين هياكل بيانات التطبيق ومخطط قاعدة البيانات. تكون هذه الطبقة مسؤولة عن التفاعل مع قاعدة بيانات التطبيق أو تخزين البيانات.
- قاعدة البيانات هي المكان الذي يخزن فيه التطبيق بياناته. عادةً ما تكون هناك قاعدة بيانات واحدة تخزن جميع بيانات التطبيق، بما في ذلك بيانات المستخدم والتكوينات وغيرها من المعلومات.
- تتعامل مكونات البرمجيات الوسيطة مع مهام مثل المصادقة وتوجيه الطلبات والتحقق من صحة البيانات. تساعد هذه المكونات في إدارة تدفق البيانات والطلبات.
- تحتوي بعض التطبيقات المتجانسة على نقاط تكامل مع الخدمات الخارجية أو واجهات برمجة التطبيقات. تسمح هذه النقاط للتطبيق بالتفاعل مع خدمات الجهات الخارجية أو مصادر البيانات أو الأنظمة الأخرى.
عادةً ما تكون الطبقات الهيكلية جزءًا من قاعدة تعليمات برمجية واحدة. يحتوي قاعدة الترميز هذه على التطبيق بالكامل وعادة ما يتم تنظيمها في أدلة ووحدات وفئات. يعمل المطورون على أجزاء مختلفة من قاعدة التعليمات البرمجية لإنشاء التطبيق وصيانته. ومع ذلك، عادةً ما يتم نشر التطبيق بالكامل كوحدة واحدة. عند إجراء تحديثات أو تغييرات، تتم إعادة نشر التطبيق بالكامل.
التحديات المحتملة
- مع زيادة حجم التطبيقات المتجانسة، تميل قاعدة التعليمات البرمجية إلى أن تصبح معقدة ويصعب صيانتها. قد يؤدي ذلك إلى دورات تطوير طويلة وصعوبة في فهم قاعدة التعليمات البرمجية بالكامل.
- قد يكون نشر التغييرات على تطبيق متجانس محفوفًا بالمخاطر لأن التغييرات التي يتم إجراؤها في جزء واحد من الرمز قد تؤثر عن غير قصد في أجزاء أخرى من التطبيق. وقد يؤدي ذلك إلى إنشاء عملية نشر طويلة وعرضة للأخطاء.
- قد يكون من الصعب توسيع نطاق التطبيقات المتجانسة نظرًا لنشرها كوحدة واحدة. يجب عليك توسيع نطاق التطبيق بالكامل حتى إذا واجه مكون واحد فقط الطلب الذي زاد الطلب.
- غالبًا ما تعتمد التطبيقات المتجانسة على حزمة تقنية أو لغة برمجة واحدة، وقد تكون قدرتك على استخدام أفضل أداة لمهمة محددة داخل التطبيق محدودة.
- حتى خلال فترات انخفاض الطلب، تتطلب التطبيقات المتجانسة موارد كبيرة للتشغيل. وتزداد تكاليف الصيانة أيضًا مع مرور الوقت الذي يشهده التطبيق، حيث يصبح من الصعب تحديث التطبيق وتصحيحه بدون التسبب في حدوث تراجع.
- غالبًا ما يتم تنظيم فرق التطوير التي تعمل على التطبيقات المتجانسة حول التطبيق بأكمله، ويؤدي ذلك إلى فرق أكبر وتنسيق أكثر تعقيدًا بين أعضاء الفريق.
الاستخدام المقترَح
تكون الهياكل المتجانسة مناسبة عندما يكون للتطبيق متطلبات متواضعة ويكون فريق التطوير صغيرًا. ومع زيادة حجم التطبيق من حيث التعقيد والانتشار، أو عندما تتطلب أجزاء مختلفة من التطبيق تكنولوجيا أو استراتيجيات نشر مختلفة، يمكن أن تصبح البُنى الأساسية المتجانسة أقل مرونة وتصبح أكثر صعوبة في صيانتها.
يمكنك إنشاء وإدارة أجهزة افتراضية يمكنها تشغيل تطبيقات متجانسة على Compute Engine. ويمكنك التحكم بشكل كامل في أنظمة التشغيل والبرامج وإدارة هذه الأجهزة الافتراضية لتشغيل التطبيق المتجانس.
باستخدام خدمة النظام الأساسي كخدمة، مثل App Engine، يمكنك إنشاء تطبيقك وتشغيله على بنية أساسية مُدارة بالكامل تتكيّف تلقائيًا مع الطلبات.
إذا كان تطبيقك المتجانس وحيًا، يمكنك تشغيله باستخدام Google Kubernetes Engine (GKE) أو تشغيل Cloud Run. يمكن استخدام خدمات مثل Cloud SQL أو Cloud Spanner لتخزين البيانات للتطبيقات المتجانسة. ضع في اعتبارك مجموعة من الخدمات والأنظمة بناءً على المتطلبات المحددة لتطبيقك.
هندسة بدون خادم
باستخدام البنية بدون خادم، يمكنك إنشاء التطبيقات وتشغيلها بدون إدارة الخوادم المادية أو الافتراضية. يدير مقدّم خدمات السحابة الإلكترونية تلقائيًا البنية الأساسية وإمكانية التوسيع وتخصيص الموارد حتى يتمكّن المطوّرون من التركيز على كتابة الرمز البرمجي لتطبيقاتهم. يمكن للبُنى الأساسية بدون خادم تبسيط التطوير وتقليل النفقات العامة التشغيلية وتحسين التكاليف من خلال التخلّص من الحاجة إلى صيانة الخوادم. وهي مناسبة تمامًا للخدمات الصغيرة، ومعالجة البيانات في الوقت الفعلي، وتطبيقات الويب ذات أعباء العمل المتغيرة، ومعالجة الأحداث.
بُنى إلكترونية بدون خوادم مستندة إلى الأحداث
تُعد البُنى الأساسية بدون خادم قائمة على الأحداث نوعًا محددًا من هندسة الحوسبة بدون خادم والتي تعتمد على الأحداث أو المشغلات لبدء تنفيذ الدوال أو الخدمات الدقيقة. تتواصل مكونات النظام من خلال الأحداث، ويتم استدعاء الدوال استجابةً للأحداث. وغالبًا ما تعتمد على التواصل غير المتزامن حيث يتم تشغيل الدوال بواسطة الأحداث، ثم معالجتها بشكل مستقل، وقد ينتج عنها أحداث تؤدي بعد ذلك إلى تشغيل الإجراءات اللاحقة. هذا النوع من البنية بدون خادم هو خيار جيد لإنشاء أنظمة قابلة للتطوير ومتجاوبة وغير مرتبطة ببعضها.
تتيح لك دوال Google Cloud ودوال Cloud لمنصة Firebase إنشاء وظائف مستندة إلى الأحداث ونشرها في بيئة مُدارة بالكامل وبدون خادم. تتيح لك هذه الخدمة تنفيذ الرموز استجابة لأحداث وعوامل تشغيل مختلفة، بما في ذلك طلبات HTTP ورسائل Cloud Pub/Sub وتغييرات Google Cloud Storage وتعديلات "قاعدة بيانات Firebase في الوقت الفعلي"، بدون الحاجة إلى إدارة البنية الأساسية. تشمل الميزات الرئيسية توفير اللغات المتعددة، وقابلية التوسّع، والفوترة الدقيقة، وعمليات الدمج مع منتجات خارجية، والتسجيل والمراقبة الفعّالين، والدمج مع خدمات Google وFirebase الأخرى.
يمكن أن تكون البُنى الأساسية بدون خادم فعّالة من حيث التكلفة للعديد من حالات الاستخدام، خاصةً للتطبيقات ذات أعباء العمل المختلفة واحتياجات التطوير السريع وحركة المرور غير المتوقعة. تعتمد الموثوقية على مقدّم خدمات السحابة الإلكترونية، مع اتفاقيات مستوى الخدمة (SLA) المطبَّقة لضمان أداء محدد وأهداف خاصة بالموثوقية. يجب عليك تقييم حالة الاستخدام الخاصة والمتطلبات لتحديد ما إذا كانت البنية بدون خادم هي الخيار الأفضل لديك.
شحن بالحاويات
تسمح الحاويات بتجميع التطبيقات وتبعياتها في حاويات خفيفة الوزن ومتنقلة. وهي توفر بيئة تطبيقات متسقة تدعم التطوير والنشر عبر الأنظمة والأنظمة الأساسية المختلفة. توفر بعض الأنظمة الأساسية التي لا تعتمد على خوادم إمكانية تشغيل أعباء العمل المتنقلة. يمكن أن يكون تشغيل الحاويات داخل بيئة بدون خادم مفيدًا عندما يكون لديك أعباء عمل معقدة أو حالة لا يمكن التعبير عنها كدوال أساسية. وهي توفر المرونة من حيث دعم اللغة وبيئات وقت التشغيل.
Cloud Run هو نظام أساسي للحوسبة بدون خادم يسمح للمطوّرين بنشر التطبيقات القائمة في حاويات وتشغيلها في بيئة مُدارة بالكامل. وهي توفّر طريقة مباشرة لإنشاء التطبيقات ونشرها وتوسيع نطاقها بدون إدارة البنية الأساسية الأساسية. ويناسب مجموعة كبيرة من تطبيقات الويب والخدمات الدقيقة، لا سيّما التطبيقات التي تتضمّن أعباء عمل متغيرة، كما أنّها تقدّم فوائد من ناحية حزمة التطبيقات واتّساقها.
بُنى الخدمات المصغّرة
يتم تقسيم التطبيقات إلى أجزاء صغيرة غير مترابطة وتنفذ ميزات أو إمكانات مميزة. وقد تتواصل هذه الخدمات من خلال رسائل غير متزامنة أو قنوات قائمة على الأحداث أو بشكل مباشر من خلال عرض واجهة. يتم تطوير كل خدمة واختبارها وقياسها بشكل مستقل في حاويتها، والتي غالبًا ما تتم إدارتها من خلال خدمة تنسيق، مثل Kubernetes، أو نشرها باستخدام نظام أساسي مُدار، مثل Cloud Run.
عادةً ما تستفيد عمليات نشر الخدمات الصغيرة أيضًا من نموذج التطبيق بدون خادم من خلال عدم الاعتماد على خادم مركزي.
يمكن أن يؤدي فصل تطبيق إلى خدمات مستقلة إلى تبسيط أي نظام معقد. يمكن للحدود والأهداف المحددة جيدًا تسريع التطوير وتحسين الصيانة. يمكن تطوير كل خدمة مصغَّرة بشكل مستقل باستخدام أطر العمل أو الأدوات الأكثر فعالية. غالبًا ما يتم التعامل مع التواصل بين الخدمات باستخدام الفعاليات، أو مراسلات النشر، أو مسارات الرسائل، أو مكالمات الإجراءات عن بُعد مثل gRPC.
لتنظيم المهام داخل بنية الخدمة الصغيرة، ضع في اعتبارك استخدام إطار عمل يدعم الأنظمة الأساسية التي تستهدفها، وعمق كافٍ للمهام وأنواع مهام سير العمل التي تنظمها، بالإضافة إلى التعامل مع الأخطاء والقياس عن بُعد لتصحيح الأخطاء. تشمل الخيارات الرائجة ConCONNECTor أو العروض من مقدّم خدمات السحابة الإلكترونية مثل Google Workflows.
قد يكون تطوير التطبيقات المستندة إلى الخدمات الصغيرة أمرًا معقدًا وصيانتها بسبب طبيعتها الموزعة والحاجة إلى الاتصال داخل الخدمة. لذلك، تعد إدارة عمليات النشر والمراقبة والتسجيل أكثر تعقيدًا من خيارات البنية الأخرى. ولأنّ الموثوقية تعتمد على بنية الخدمات الفردية، قد توفّر الطبيعة الموزَّعة مرونة إضافية، خاصةً إذا تم تفعيل المراقبة والقياس عن بُعد وتفعيلهما إذا لزم الأمر.
مقارنة بين البنى المختلفة لخلفيات تطبيقات الويب القائمة على المحتوى
يقارن الجدول التالي بين البُنى الأساسية والمتطلبات الرئيسية لخلفية تطبيق ويب يستند إلى المحتوى.
| هندسة متجانسة | بنيات لا تعتمد على خادم وقائمة على الأحداث | بُنى خدمات مصغَّرة بدون خادم | |
|---|---|---|---|
| التعقيد والصيانة |
|
|
|
| قابلية التوسع والأداء |
|
|
|
| المرونة والاستراتيجيات الاحتياطية |
|
|
|
| الخبرة في التطوير |
|
|
|
| التكلفة |
|
|
|
معرفة المزيد حول بُنى الخلفية لتطبيقات الويب التي تعتمد على المحتوى
إليك بعض الموارد لمعرفة المزيد حول بنى تطبيقات الويب القائمة على المحتوى، بما في ذلك كيفية نقل تطبيقك إلى بنية مختلفة:
- تعرَّف على المزيد من المعلومات عن بُنى الواجهة الخلفية لتطبيقات الويب غير المترابطة، بما في ذلك تطبيقات الويب المتدرجة والمتدرجة بدون خوادم.