مشاركة عبر

النُهج المعمارية للرسائل في حلول متعددة المستأجرين

  • مقالة

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

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

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

الرسائل ونقاط البيانات والأحداث المنفصلة

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

حدث

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

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

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

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

الرسائل

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

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

سيناريوهات مقدمة كمثال

فيما يلي قائمة ببعض أمثلة السيناريوهات متعددة المستأجرين للرسائل ونقاط البيانات والأحداث المنفصلة:

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

الاعتبارات والمتطلبات الرئيسية

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

المقياس‬

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

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

توفر بعض عروض الخدمة، مثل طبقة Azure Service Bus Premium، عزلاً للموارد على مستوى وحدة المعالجة المركزية والذاكرة بحيث يتم تشغيل حمل عمل كل عميل بشكل منفصل. تسمى حاوية المورد هذه وحدة المراسلة. يتم تخصيص وحدة مراسلة واحدة على الأقل لكل مساحة اسم متميزة. يمكنك شراء 1 أو 2 أو 4 أو 8 أو 16 وحدة مراسلة لكل مساحة اسم ناقل خدمة Microsoft Azure. يمكن أن يمتد حمل عمل واحد أو كيان واحد عبر وحدات رسائل متعددة، ويمكنك تغيير عدد وحدات المراسلة حسب الضرورة. والنتيجة هي أداء يمكن التنبؤ به وقابل للتكرار للحل المستند إلى ناقل خدمة Microsoft Azure الخاص بك. لمزيد من المعلومات، راجع ناقل خدمة Microsoft Azure Premium وطبقات المراسلة القياسية. وبالمثل، تسمح لك مستويات أسعار مراكز الأحداث بتغيير حجم مساحة الاسم، بناءً على الحجم المتوقع للأحداث الواردة والصادرة. على سبيل المثال، يتم دفع فاتورة العرض المميز من خلال وحدات المعالجة (PUs)، والتي تتوافق مع حصة من الموارد المعزولة (وحدة المعالجة المركزية والذاكرة والتخزين) في البنية الأساسية. سيعتمد الاستيعاب الفعال معدل النقل لكل PU على العوامل التالية:

  • عدد المنتجين والمستهلكين
  • حجم البيانات الأساسية
  • عدد الأقسام
  • معدل طلب Egress
  • استخدام التقاط مراكز الأحداث، سجل المخطط، وغيرها من الميزات المتقدمة

لمزيد من المعلومات، راجع نظرة عامة على مراكز الأحداث Premium.

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

على سبيل المثال، يمكن نشر نظام مراسلة لمستأجر معين أثناء عملية التزويد باستخدام أداة بنية أساسية كتعليمية (IaC) مثل قوالب JSON ل Terraform أو Bicep أو Azure Resource Manager (ARM) ونظام DevOps مثل Azure DevOps أو GitHub Actions. لمزيد من المعلومات، راجع الأساليب البنيوية لتوزيع الحلول المتعددة المستأجرين وتكوينها.

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

القدرة على التنبؤ بالأداء والموثوقية

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

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

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

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

وبالمثل، عند استضافة نظام المراسلة الخاص بك على مجموعة Kubernetes، ضع في اعتبارك استخدام محددات العقد والتلوث لجدولة تنفيذ البودات الخاصة به على مجموعة عقدة مخصصة، لا تتم مشاركتها مع أحمال العمل الأخرى، لتجنب مشكلة الجار الصاخب. عند توزيع نظام مراسلة إلى مجموعة AKS الزائدة عن المنطقة، استخدم قيود انتشار طوبولوجيا القرنة للتحكم في كيفية توزيع البودات عبر مجموعة AKS الخاصة بك بين نطاقات الفشل، مثل المناطق ومناطق التوفر والعقد. عند استضافة نظام مراسلة تابع لجهة خارجية على AKS، استخدم مقياس Kubernetes التلقائي لتوسيع نطاق عدد العقد العاملة ديناميكياً عند زيادة نسبة استخدام الشبكة. باستخدام Horizontal Pod Autoscaler والتحجيم التلقائي لمجموعة AKS، يتم تعديل أحجام العقد والقاعدة ديناميكياً في الوقت الحقيقي، لمطابقة حالة نسبة استخدام الشبكة ولتجنب فترات التوقف التي تسببها مشكلات السعة. لمزيد من المعلومات، راجع توسيع نطاق مجموعة تلقائياً لتلبية متطلبات التطبيق في خدمة Azure Kubernetes (AKS). ضع في اعتبارك استخدام Kubernetes Even-Driven Autoscaling (KEDA)، إذا كنت تريد زيادة عدد البودات الخاصة بنظام الرسائل المستضافة على Kubernetes، مثل RabbitMQ أو Apache ActiveMQ، بناءً على طول قائمة انتظار معينة. باستخدام KEDA، يمكنك زيادة حجم أي حاوية في Kubernetes، بناءً على عدد الأحداث التي تحتاج إلى المعالجة. على سبيل المثال، يمكنك استخدام KEDA لتوسيع نطاق التطبيقات بناءً على طول قائمة انتظار Azure Service Busأو قائمة انتظار RabbitMQأو قائمة انتظار ActiveMQ. لمزيد من المعلومات حول KEDA، راجع مقياس تلقائي يعتمد على الأحداث في Kubernetes.

العزل

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

  • يمكن للمستأجرين المتعددين مشاركة نفس كيانات المراسلة، مثل قوائم الانتظار والموضوعات والاشتراكات في نفس نظام المراسلة. على سبيل المثال، يمكن أن يتلقى تطبيق متعدد المستأجرين رسائل تحمل بيانات لمستأجرين متعددين، من قائمة انتظار واحدة Azure Service Bus. يمكن أن يؤدي هذا الحل إلى مشاكل الأداء وقابلية التوسع. إذا قام بعض المستأجرين بإنشاء عدد أكبر من الطلبات مقارنة بالآخرين، فقد يتسبب ذلك في تراكم الرسائل. يمكن أن تؤدي هذه المشكلة، المعروفة أيضاً باسم مشكلة الجوار الصاخب، إلى تدهور اتفاقية مستوى الخدمة من حيث زمن الوصول لبعض المستأجرين. تكون المشكلة أكثر وضوحاً إذا كان تطبيق المستهلك يقرأ ويعالج الرسائل من قائمة الانتظار، واحدة تلو الأخرى، بترتيب زمني صارم، وإذا كان الوقت اللازم لمعالجة رسالة يعتمد على عدد العناصر في الحمولة. عند مشاركة واحد أو أكثر من موارد قائمة الانتظار عبر مستأجرين متعددين، يجب أن تكون البنية الأساسية للرسائل وأنظمة المعالجة قادرة على استيعاب نسبة استخدام الشبكة المتوقعة المستندة معدل النقل إلى متطلبات النطاق والمعدل نقل. هذا النهج البنيوي مناسب تماماً لتلك السيناريوهات حيث يتبنى حل متعدد المستأجرين مجموعة واحدة من عمليات العمال، من أجل تلقي ومعالجة وإرسال الرسائل لجميع المستأجرين.
  • يشترك العديد من المستأجرين في نفس نظام المراسلة ولكنهم يستخدمون موارد مختلفة للموضوع أو قائمة الانتظار. يوفر هذا الأسلوب أفضل عزل وأفضل حماية للبيانات بتكلفة أعلى، وزيادة التعقيد التشغيلي، وخفة الحركة لأنه يتعين على مسؤولي النظام توفير عدد أكبر من موارد قائمة الانتظار ومراقبتها والحفاظ عليها. يضمن هذا الحل تجربة متسقة ويمكن التنبؤ بها لجميع المستأجرين، من حيث الأداء واتفاقيات مستوى الخدمة، لأنه يمنع أي مستأجر من خلق ازدحام الذي يمكن أن يؤثر على المستأجرين الآخرين.
  • يتم استخدام نظام مراسلة منفصل ومخصص لكل مستأجر. على سبيل المثال، يمكن أن يستخدم حل متعدد المستأجرين مساحة اسم Azure Service Bus مميزة لكل مستأجر. يوفر هذا الحل أقصى درجة من العزلة، مع زيادة التعقيد والتكلفة التشغيلية. يضمن هذا النهج أداءً ثابتاً ويسمح بضبط نظام المراسلة، بناءً على احتياجات المستأجر المحددة. عند إعداد مستأجر جديد، بالإضافة إلى نظام مراسلة مخصص بالكامل، قد يحتاج تطبيق التوفير أيضاً إلى إنشاء هوية مُدارة منفصلة أو مدير خدمة مع أذونات RBAC المناسبة للوصول إلى مساحة الاسم المنشأة حديثاً. على سبيل المثال، عندما تتم مشاركة مجموعة Kubernetes بواسطة مثيلات متعددة لنفس تطبيق SaaS، واحد لكل مستأجر، وكل منها يعمل في مساحة اسم منفصلة، فقد يستخدم كل مثيل تطبيق مبدأ خدمة مختلفاً أو هوية مُدارة للوصول إلى نظام مراسلة مخصص. في هذا السياق، يمكن أن يكون نظام المراسلة عبارة عن خدمة PaaS مُدارة بالكامل، مثل مساحة الاسم Azure Service Bus أو نظام مراسلة مستضاف بواسطة Kubernetes، مثل RabbitMQ. عند حذف مستأجر من النظام، يجب على التطبيق إزالة نظام المراسلة وأي مورد مخصص تم إنشاؤه مسبقاً للمستأجر. العيب الرئيسي لهذا النهج هو أنه يزيد من التعقيد التشغيلي ويقلل من خفة الحركة، خاصة عندما ينمو عدد المستأجرين بمرور الوقت.

راجع الاعتبارات والملاحظات الإضافية التالية:

  • إذا احتاج المستأجرون إلى استخدام مفتاحهم الخاص لتشفير الرسائل وفك تشفيرها، فيجب أن يوفر الحل متعدد المستأجرين خيار اعتماد مساحة اسم منفصلة لـ Azure Service Bus Premium لكل مستأجر. لمزيد من المعلومات، راجع تكوين المفاتيح المُدارة من قِبل العميل لتشفير بيانات Azure Service Bus في بيانات ثابتة.
  • إذا احتاج المستأجرون إلى مستوى عالٍ من المرونة واستمرارية الأعمال، فيجب أن يوفر الحل متعدد المستأجرين القدرة على توفير مساحة اسم ناقل خدمة Microsoft Azure Premium مع تمكين الإصلاح بعد كارثة الجغرافية ومناطق التوفر. لمزيد من المعلومات، راجع التعافي الجغرافي من الكوارث باستخدام ناقل خدمة Microsoft Azure.
  • عند استخدام موارد قائمة انتظار منفصلة أو نظام مراسلة مخصص لكل مستأجر، من المعقول اعتماد مجموعة منفصلة من العمليات العاملة لكلٍّ منها، لزيادة مستوى عزل البيانات وتقليل تعقيد التعامل مع كيانات المراسلة المتعددة. يمكن لكل مثيل من نظام المعالجة أن يتبنى بيانات اعتماد مختلفة، مثل سلسلة اتصال أو مدير خدمة أو هوية مُدارة، من أجل الوصول إلى نظام المراسلة المخصص. يوفر هذا النهج مستوى أمان أفضل وعزلاً بين المستأجرين، ولكنه يتطلب تعقيداً متزايداً في إدارة الهوية.

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

  • يتلقى التطبيق المستند إلى الحدث أحداثاً من مستأجرين متعددين، عبر مثيل واحد مراكز الأحداث مشترك. يوفر هذا الحل مستوى عالياً من المرونة، لأن إعداد مستأجر جديد لا يتطلب إنشاء مورد مخصص لاستيعاب الأحداث، ولكنه يوفر مستوى منخفضاً من حماية البيانات، لأنه يدمج الرسائل من مستأجرين متعددين في نفس بنية البيانات.
  • يمكن للمستأجرين اختيار مركز أحداث مخصص أو موضوع Kafka لتجنب مشكلة الجار الصاخب ولتلبية متطلبات عزل البيانات الخاصة بهم، عندما لا يجب اختلاط الأحداث بأحداث المستأجرين الآخرين، من أجل الأمان وحماية البيانات.
  • إذا كان المستأجرون بحاجة إلى مستوى عالٍ من المرونة واستمرارية الأعمال، فيجب أن يوفر المستأجر المتعدد القدرة على توفير مساحة اسم مراكز الأحداث Premium، مع تمكين الإصلاح بعد كارثة الجغرافية ومناطق التوفر. لمزيد من المعلومات، راجع مراكز الأحداث- استرداد البيانات من الكوارث الجغرافية.
  • يجب إنشاء مراكز الأحداث المخصصة، مع تمكين Event Hubs Capture، للعملاء الذين يحتاجون إلى أرشفة الأحداث إلى حساب Azure Storage، لأسباب والتزامات الامتثال التنظيمي. لمزيد من المعلومات، راجع تسجيل الأحداث من خلال مراكز الأحداث Azure في تخزين Azure Blob أو تخزين Azure Data Lake Storage.
  • يمكن لتطبيق متعدد المستأجرين إرسال إعلامات إلى أنظمة داخلية وخارجية متعددة باستخدام Azure Event Grid. في هذه الحالة، يجب إنشاء اشتراك Event Grid منفصل لكل تطبيق للمستهلك. إذا كان تطبيقك يستخدم مثيلات Event Grid متعددة لإرسال إعلامات إلى عدد كبير من المؤسسات الخارجية، ففكر في استخدام نطاقات الأحداث، والتي تسمح للتطبيق بنشر الأحداث إلى آلاف الموضوعات، مثل حدث لكل مستأجر. لمزيد من المعلومات، راجع التعرُّف على مجالات الأحداث لإدارة موضوعات شبكة الأحداث.

تعقيد التنفيذ

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

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

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

تعقيد الإدارة والعمليات

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

  • قد تخطط لاستضافة نظام المراسلة الذي يستخدمه تطبيقك في مجموعة مخصصة من الأجهزة الظاهرية، واحدة لكل مستأجر. إذا كان الأمر كذلك، فكيف تخطط لتوزيع هذه الأنظمة وترقيتها ومراقبتها وتوسيع نطاقها؟
  • وبالمثل، إذا قمت بتجميع واستضافة نظام المراسلة الخاص بك في مجموعة Kubernetes مشتركة، فكيف تخطط لتوزيع أنظمة المراسلة الفردية وترقيتها ومراقبتها وتوسيع نطاقها؟
  • افترض أنك تشارك نظام مراسلة عبر مستأجرين متعددين. كيف يمكن للحل الخاص بك جمع قياسات الاستخدام لكل مستأجر والإبلاغ عنها أو تقليل عدد الرسائل التي يمكن لكل مستأجر إرسالها أو تلقيها؟
  • عندما يستفيد نظام المراسلة الخاص بك من خدمة PaaS، مثل ناقل خدمة Azure، يجب عليك طرح السؤال التالي:
    • كيف يمكنك تخصيص مستوى الأسعار لكل مستأجر، بناءً على الميزات ومستوى العزلة (المشتركة أو المخصصة) التي يطلبها المستأجر؟
    • كيف يمكنك إنشاء إدارة الهوية وتعيين دور Azure لكل مستأجر لتعيين الأذونات المناسبة فقط لكيانات المراسلة، مثل قوائم الانتظار والموضوعات والاشتراكات التي يمكن للمستأجر الوصول إليها؟ لمزيد من المعلومات، راجع مصادقة هوية مدارة باستخدام معرف Microsoft Entra للوصول إلى موارد ناقل خدمة Azure.
  • كيف ستقوم بترحيل المستأجرين، إذا كانوا بحاجة إلى الانتقال إلى نوع مختلف من خدمة المراسلة، أو توزيع مختلف، أو منطقة أخرى؟

التكلفة

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

مناهج وأنماط يجب مراعاتها

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

نمط الخوادم المخصصة للتوزيع

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

نظام الرسائل المشتركة

قد تفكر في توزيع نظام مراسلة مشترك، مثل Azure Service Bus، ومشاركته عبر جميع المستأجرين لديك.

رسم تخطيطي يوضح نظام مراسلة مشترك واحد متعدد المستأجرين لجميع المستأجرين.

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

ومع ذلك، عند مشاركة مورد أو بنية أساسية كاملة عبر مستأجرين متعددين، ضع في اعتبارك التحذيرات التالية:

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

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

نمط التقسيم

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

رسم تخطيطي يوضح نظام مراسلة مقسم. يحتوي نظام مراسلة واحد على قوائم الانتظار للمستأجرين A وB، والآخر يحتوي على قوائم انتظار للمستأجر C.

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

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

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

تطبيق متعدد المستأجرين مع نظام مراسلة مخصص لكل مستأجر

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

رسم تخطيطي يوضح أنظمة مراسلة مختلفة لكل مستأجر.

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

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

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

نمط المواقع الجغرافية

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

رسم تخطيطي يوضح نمط Geode، مع نشر أنظمة المراسلة عبر مناطق متعددة تتزامن معا.

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

المساهمون

تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.

الكاتب الرئيسي:

مساهمون آخرون:

الخطوات التالية

لمزيد من المعلومات حول أنماط تصميم الرسائل، راجع الموارد التالية: