تحرير

مشاركة عبر

تكامل المؤسسة باستخدام وسيط الرسائل والأحداث

Azure Event Grid
Azure Service Bus

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

بناء الأنظمة

قد تتضمن الأنظمة الخلفية المشار إليها في هذا التصميم أنظمة البرامج كخدمة (SaaS) وخدمات Azure وخدمات الويب الموجودة في مؤسستك.

بنية مرجعية لتكامل المؤسسة باستخدام قوائم الانتظار والأحداث

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

‏‏سير العمل‬

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

يضيف هذا الإصدار من البنية مكونين يساعدان في جعل النظام أكثر موثوقية وقابلية للتوسع:

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

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

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

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

التوصيات

تنطبق التوصيات الموضحة في تكامل المؤسسة الأساسي على هذه البنية.

ناقل الخدمة

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

عند إنشاء تطبيق منطقي لاستهلاك رسائل ناقل خدمة Microsoft Azure، نوصي باستخدام نموذج الدفع المدعوم مع تكامل Event Grid. غالباً ما يكون أكثر فعالية من حيث التكلفة، لأن تطبيق المنطق لا يحتاج إلى استطلاع رأي ناقل خدمة Microsoft Azure. لمزيد من المعلومات، راجع نظرة عامة على تكامل Azure Service Bus to Event Grid. حالياً، ناقل خدمة Microsoft Azure Premium tier مطلوبة لإشعارات شبكة الأحداث.

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

Event Grid

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

الاعتبارات

تنفذ هذه الاعتبارات ركائز Azure Well-Architected Framework، وهو عبارة عن مجموعة من المبادئ التوجيهية التي يمكن استخدامها لتحسين جودة حمل العمل. لمزيد من المعلومات، يرجى مراجعةMicrosoft Azure Well-Architected Framework.

الموثوقيه

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

الأمان

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

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

حيث لا يتوفر معرف Microsoft Entra، يمكنك استخدام توقيع الوصول المشترك (SAS). يمكنك منح مستخدم الوصول إلى موارد ناقل خدمة Microsoft Azure بحقوق معينة باستخدام مصادقة SAS.

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

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

أمن الشبكة

يجب مراعاة أمان الشبكة طوال التصميم.

  • يمكن ربط Service Bus Premium بنقطة نهاية خدمة الشبكة الفرعية للشبكة الظاهرية (VNet)، وتأمين مساحة الاسم لقبول نسبة استخدام الشبكة فقط من الشبكات الظاهرية المعتمدة. بالإضافة إلى ذلك، استخدم نقاط النهاية الخاصة لتأمين نسبة استخدام الشبكة الظاهرية لحركة المرور الخاصة عبر Private Link.
  • يمكن تكوين Logic Apps Standard وPremium Logic Apps لقبول نسبة استخدام الشبكة الواردة من خلال نقاط النهاية الخاصة وإرسال نسبة استخدام الشبكة الصادرة من خلال تكامل VNet.
  • توفر APIM العديد من الخيارات لتأمين الوصول إلى مثيل APIM وواجهات برمجة التطبيقات باستخدام شبكة Azure الظاهرية. راجع وثائق استخدام شبكة ظاهرية مع Azure API Management لإجراء مراجعة شاملة للخيارات. يتم أيضا دعم نقاط النهاية الخاصة.

تحسين التكلفة

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

بشكل عام، استخدم حاسبة أسعار Azure لتقدير التكاليف. فيما يلي بعض الاعتبارات الأخرى.

API Management

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

بالنسبة لأحمال العمل الخفيفة للاستخدام، ضع في اعتبارك مستوى الاستهلاك، وهو خيار منخفض التكلفة بلا خادم. تتم فوترة مستوى الاستهلاك لكل استدعاء API، بينما تتم فوترة المستويات الأخرى في الساعة.

Logic Apps

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

طوابير ناقل خدمة Microsoft Azure والموضوعات والاشتراكات

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

يتم تضمين قوائم انتظار ناقل خدمة Microsoft Azure في جميع المستويات (المستويات الأساسية والقياسية والمتميزة). بينما تتوفر اشتراكات وموضوعات ناقل خدمة Microsoft Azure في المستويات القياسية والمتميزة. لمزيد من المعلومات، راجع أسعار Azure Service Bus.

Event Grid

تستخدم Event Grid نموذجاً بلا خادم. يتم احتساب الفواتير على أساس عدد العمليات (تنفيذ الأحداث). تتضمن العمليات دخول الأحداث إلى المجالات أو الموضوعات والمطابقات المتقدمة ومحاولات التسليم ومكالمات الإدارة. استخدام ما يصل إلى 100000 عملية مجاني.

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

لمزيد من المعلومات، راجع قسم التكلفة في Microsoft Azure Well-Architected Framework.

التميز التشغيلي

توفر البنية المرجعية الأساسية للتكامل المؤسسي إرشادات حول أنماط DevOps، والتي تتوافق مع ركيزة التميز التشغيلي لإطار العمل المصمم جيدا.

يعد أتمتة عمليات الاسترداد قدر الإمكان مكونا لا يتجزأ من التميز التشغيلي. مع مراعاة الأتمتة، يمكنك دمج Azure Log Monitoring مع Azure Automation لأتمتة تجاوز الفشل لموارد ناقل خدمة Microsoft Azure. راجع الرسم التخطيطي في وثائق تدفق تجاوز الفشل للحصول على مثال لمنطق التشغيل التلقائي لبدء تجاوز الفشل.

كفاءة الأداء

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

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

يمكن العثور على مزيد من التوصيات لناقل خدمة Microsoft Azure في أفضل الممارسات لتحسين الأداء باستخدام مراسلة ناقل خدمة Microsoft Azure.

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

لمزيد من المعلومات، راجع وثائق ناقل خدمة Microsoft Azure: