نمط بنية Web-Queue-Worker

Azure App Service

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

Logical diagram of Web-Queue-Worker architecture style.

تشمل المكونات الأخرى التي يتم دمجها بشكل شائع في هذه البنية ما يلي:

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

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

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

متى تستخدم هذه البنية

عادةً ما يتم تنفيذ بنية Web-Queue-Worker باستخدام خدمات الحساب المدارة، إما Azure App Service أو Azure Cloud Services.

ضع في الاعتبار نمط البنية هذا من أجل:

  • التطبيقات ذات المجال البسيط نسبيًا.
  • التطبيقات مع بعض مهام سير العمل طويلة الأجل أو عمليات الدفعات.
  • عندما تريد استخدام الخدمات المُدارة، بدلاً من البنية الأساسية كخدمة (IaaS).

المزايا

  • بنية بسيطة نسبيًا يسهل فهمها.
  • سهولة التوزيع والإدارة.
  • الفصل الواضح بين الشواغل.
  • يتم فصل الواجهة الأمامية عن العامل عن طريق المراسلة غير المتزامنة.
  • يمكن تغير سعة الواجهة الأمامية والعامل بشكل مستقل.

التحديات

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

أفضل الممارسات

Web-Queue-Worker على خدمة Azure App Service

يوضح هذا القسم بنية Web-Queue-Worker الموصى بها التي تستخدم خدمة Azure App Service.

Physical diagram of Web-Queue-Worker architecture style.

قم بتنزيل ملف Visio لهذه البنية.

‏‏سير العمل‬

  • يتم تنفيذ الواجهة الأمامية كتطبيق ويب Azure App Service ، ويتم تنفيذ العامل كتطبيق Azure Functions . كل من تطبيق الويب والتطبيق الوظيفي مرتبطان بخطة خدمة التطبيقات التي توفر مثيلات الجهاز الظاهري.

  • يمكنك استخدام قوائم انتظار ناقل خدمة Azure أو Azure Storage لقائمة انتظار الرسائل. (يظهر الرسم البياني قائمة انتظار تخزين Azure.)

  • يخزن Azure Cache for Redis حالة الجلسة والبيانات الأخرى التي تحتاج إلى وصول زمن انتقال منخفض.

  • يتم استخدام Azure CDN لتخزين المحتوى الثابت مؤقتا مثل الصور أو CSS أو HTML.

  • للتخزين، اختر تقنيات التخزين التي تناسب احتياجات التطبيق. يمكنك استخدام تقنيات تخزين متعددة (ثبات متعدد اللغات). لتوضيح هذه الفكرة، يعرض الرسم التخطيطي قاعدة بيانات Azure SQL وAzure Cosmos DB.

لمزيد من المعلومات، راجع البنية المرجعية لتطبيق ويب App Service وكيفية إنشاء تطبيقات الأعمال المستندة إلى الرسائل باستخدام NServiceBus ناقل خدمة Azure.

اعتبارات أخرى

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

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

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

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

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