استخدام وسيط الرسائل والأحداث لدمج أنظمة المؤسسة
تستند هذه البنية إلى بنية تكامل المؤسسة الأساسية ولكنها تتضمن كيفية دمج الأنظمة الخلفية للمؤسسة. تستخدم هذه البنية وسطاء الرسائل والأحداث لفصل الخدمات لمزيد من قابلية التوسع والموثوقية. تأكد من أنك على دراية بالتصمين والمكونات في بنية التكامل الأساسية. توفر هذه العناصر معلومات أساسية حول المكونات الأساسية لهذه البنية.
بناء الأنظمة
تتضمن الأنظمة الخلفية التي يشير إليها هذا التصميم أنظمة البرامج كخدمة (SaaS) وخدمات Azure والخدمات المستندة إلى الرسائل وخدمات الويب الموجودة في مؤسستك.
قم بتنزيل ملف Visio لهذه البنية.
تفاصيل السيناريو
تعتمد البنية السابقة على بنية تكامل المؤسسة الأساسية الأبسط التي تستخدم Azure Logic Apps لتنسيق مهام سير العمل مباشرة مع الأنظمة الخلفية وتستخدم Azure API Management لإنشاء كتالوجات واجهات برمجة التطبيقات.
يضيف هذا الإصدار من البنية مكونين يساعدان في جعل النظام أكثر موثوقية وقابلية للتوسع:
Azure Event Grid هي خدمة لتوجيه الأحداث. ويستخدم نموذج أحداث النشر والاشتراك .
تستخدم هذه البنية اتصالا غير متزامن عبر وسيط رسائل بدلا من إجراء مكالمات مباشرة ومتزامنة إلى الخدمات الخلفية. يوفر الاتصال غير المتزامن المزايا التالية:
يستخدم نمط تسوية التحميل المستند إلى قائمة الانتظار لمعالجة الاندفاعات في أحمال العمل عبر تسوية التحميل
يستخدم نمط Publisher-Subscriber بحيث يمكنك بث الرسائل إلى عدة مستهلكين
يتعقب تقدم مهام سير العمل طويلة الأمد بشكل موثوق، حتى عندما تتضمن خطوات متعددة أو تطبيقات متعددة
يساعد على فصل التطبيقات
يتكامل مع الأنظمة القائمة على الرسائل الموجودة
يوفر القدرة على وضع الرسائل في قائمة الانتظار عندما لا يتوفر نظام خلفي
استخدم Event Grid بحيث يمكن للمكونات المختلفة في النظام التفاعل مع الأحداث عند حدوثها، بدلا من الاعتماد على الاستقصاء أو المهام المجدولة. على غرار قائمة انتظار الرسائل والموضوعات، تساعد Event Grid على فصل التطبيقات والخدمات. إذا نشر تطبيق أو خدمة أحداثا، يتم إعلام أي مشتركين مهتمين. يمكنك إضافة مشتركين جدد دون تحديث المرسل.
تدعم العديد من خدمات Azure إرسال الأحداث إلى Event Grid. على سبيل المثال، يمكن للتطبيق المنطقي الاستماع إلى حدث ما عند إضافة ملفات جديدة إلى متجر blob. ينشئ هذا النمط مهام سير عمل تفاعلية حيث يؤدي تحميل ملف أو وضع رسالة في قائمة انتظار إلى بدء سلسلة من العمليات. قد تعمل العمليات بالتوازي أو في تسلسل معين.
التوصيات
ضع في اعتبارك التوصيات التالية. لمزيد من التوصيات، راجع بنية تكامل المؤسسة الأساسية.
ناقل الخدمة
يحتوي ناقل خدمة Microsoft Azure على نموذجين للتسليم، نموذج السحب ونموذج الدفع المنقل:
نموذج السحب: يستقصي المتلقي باستمرار الرسائل الجديدة. إذا كنت بحاجة إلى إدارة قوائم انتظار وأوقات استقصاء متعددة، فقد يكون الاستقصاء غير فعال. ولكن يمكن لهذا النموذج تبسيط البنية الخاصة بك لأنه يزيل المكونات الإضافية ووثبة البيانات.
نموذج الدفع Proxied: يشترك المتلقي في البداية في نوع حدث معين في موضوع Event Grid. عند توفر رسالة جديدة، يقوم ناقل خدمة Microsoft Azure برفع حدث وإرساله من خلال Event Grid. ثم يقوم هذا الحدث بتشغيل المتلقي لسحب الدفعة التالية من الرسائل من ناقل خدمة Microsoft Azure. يسمح هذا النموذج للأنظمة بتلقي الرسائل في الوقت الفعلي تقريبا ولكن دون استخدام الموارد للاستقصاء المستمر عن الرسائل الجديدة. تستخدم هذه البنية مكونات إضافية يجب توزيعها وإدارتها وتأمينها.
عند إنشاء سير عمل Standard Logic Apps الذي يستهلك رسائل ناقل خدمة Microsoft Azure، نوصي باستخدام مشغلات الموصل المضمنة لناقل خدمة Microsoft Azure. يقوم الموصل المضمن بتشغيل تجريد معظم تكوين نموذج السحب دون إضافة تكلفة إضافية. توفر هذه الإمكانية التوازن الصحيح بين التكلفة وإدارة مساحة السطح والأمان لأن الموصل يتكرر باستمرار داخل محرك وقت تشغيل Logic Apps. لمزيد من المعلومات، راجع مشغلات الموصل المضمنة لناقل خدمة Microsoft Azure.
استخدم وضع PeekLock للوصول إلى مجموعة من الرسائل. عند استخدام PeekLock، يمكن لتطبيق المنطق تنفيذ خطوات للتحقق من صحة كل رسالة قبل إكمال الرسالة أو التخلي عنها. يمنع هذا الأسلوب فقدان الرسائل العرضية.
Event Grid
عند تشغيل مشغل Event Grid، فهذا يعني أن حدثا واحدا على الأقل حدثا واحدا . على سبيل المثال، عندما يحصل تطبيق المنطق على مشغل Event Grid لرسالة ناقل خدمة Microsoft Azure، قد يكون هناك العديد من الرسائل المتاحة لمعالجتها.
الاعتبارات
تنفذ هذه الاعتبارات ركائز Azure Well-Architected Framework، وهو عبارة عن مجموعة من المبادئ التوجيهية التي يمكن استخدامها لتحسين جودة حمل العمل. لمزيد من المعلومات، يرجى مراجعةMicrosoft Azure Well-Architected Framework.
الموثوقيه
تضمن الموثوقية أن التطبيق الخاص بك يمكن أن يفي بالالتزامات التي تتعهد بها لعملائك. لمزيد من المعلومات، راجع قائمة اختيار مراجعة التصميم للموثوقية.
معرف Microsoft Entra هو نظام أساسي SaaS موزع عالميا ومتاح بشكل كبير.
يمكنك نشر APIM في العديد من التكوينات عالية التوفر، وفقا لمتطلبات العمل والتسامح مع التكلفة. لمزيد من المعلومات، راجع ضمان توفر APIM وموثوقيتها.
يدعم مستوى استهلاك Logic Apps التخزين المتكرر جغرافيا. لمزيد من المعلومات، راجع استمرارية الأعمال والتعافي من الكوارث ل Logic Apps.
يتم نسخ تعريفات موارد Event Grid للمواضيع وموضوعات النظام والمجالات واشتراكات الأحداث وبيانات الحدث تلقائيا عبر مناطق التوفر في منطقة ما. عندما يكون هناك فشل في إحدى مناطق التوفر، تفشل موارد Event Grid تلقائيا في منطقة توفر أخرى دون أي تدخل بشري. لمزيد من المعلومات، راجع التعافي من الكوارث عبر المناطق واستمرارية الأعمال.
يدعم ناقل خدمة Microsoft Azure Premium مناطق التعافي من الكوارث الجغرافية والتوافر. يدعم Service Bus Standard النسخ المتماثل.
للحصول على معلومات حول تفاصيل التوفر المضمونة لكل خدمة، راجع اتفاقيات مستوى الخدمة خدمات الإنترنت.
الأمان
ويوفر عامل الأمان ضمانات للحماية من الهجمات المتعمدة واستغلال البيانات والأنظمة القيمة الخاصة بك. لمزيد من المعلومات، راجع قائمة اختيار مراجعة التصميم للأمان.
للمساعدة في تأمين ناقل خدمة Microsoft، قم بإقران مصادقة Microsoft Entra بالهويات المدارة. يوفر تكامل معرف Microsoft Entra لموارد ناقل خدمة Microsoft Azure التحكم في الوصول استنادا إلى الدور (RBAC) للتحكم الدقيق في وصول العميل إلى الموارد. يمكنك استخدام Azure RBAC لمنح أذونات لمدير أمان، مثل مستخدم أو مجموعة أو كيان خدمة تطبيق. كيان خدمة التطبيق في هذا السيناريو هو هوية مدارة.
إذا لم تتمكن من استخدام معرف Microsoft Entra، فاستخدم مصادقة توقيع الوصول المشترك (SAS) لمنح المستخدمين حق الوصول وحقوق محددة لموارد ناقل خدمة Microsoft Azure.
إذا كنت بحاجة إلى عرض قائمة انتظار أو موضوع ناقل خدمة Microsoft Azure كنقطة نهاية HTTP، على سبيل المثال، لنشر رسائل جديدة، فاستخدم APIM للمساعدة في تأمين قائمة الانتظار عن طريق واجهة نقطة النهاية. يمكنك بعد ذلك استخدام الشهادات أو مصادقة OAuth للمساعدة في تأمين نقطة النهاية. أسهل طريقة للمساعدة في تأمين نقطة نهاية هي استخدام تطبيق منطقي يحتوي على طلب HTTP أو مشغل استجابة كوسيط.
تساعد خدمة Event Grid في تأمين تسليم الحدث من خلال رمز التحقق من الصحة. إذا كنت تستخدم Logic Apps لاستهلاك الحدث، يكون التحقق من الصحة تلقائيا. لمزيد من المعلومات، راجع أمان Event Grid والمصادقة عليها.
أمن الشبكة
ضع في اعتبارك أمان الشبكة طوال تصميمك.
يمكنك ربط ناقل خدمة Microsoft Azure Premium بنقطة نهاية خدمة الشبكة الفرعية للشبكة الظاهرية. يساعد هذا التكوين على تأمين مساحة الاسم لأنه يقبل نسبة استخدام الشبكة فقط من الشبكات الظاهرية المعتمدة. يمكنك أيضا استخدام Azure Private Link للسماح فقط بنسبة استخدام الشبكة الخاصة إلى شبكتك الظاهرية عبر نقاط النهاية الخاصة.
يمكنك تكوين Logic Apps Standard وPremium لقبول نسبة استخدام الشبكة الواردة من خلال نقاط النهاية الخاصة وإرسال نسبة استخدام الشبكة الصادرة من خلال تكامل الشبكة الظاهرية.
يمكنك استخدام شبكة Azure الظاهرية للمساعدة في تأمين الوصول إلى مثيل APIM وواجهات برمجة التطبيقات. يدعم هذا الأسلوب نقاط النهاية الخاصة. لمزيد من المعلومات، راجع استخدام شبكة ظاهرية مع APIM.
تحسين التكلفة
يتعلق تحسين التكلفة بالبحث عن طرق لتقليل النفقات غير الضرورية وتحسين الكفاءة التشغيلية. لمزيد من المعلومات، راجع قائمة اختيار مراجعة التصميم لتحسين التكلفة.
استخدم حاسبة تسعير Azure لتقدير التكاليف. فيما يلي بعض الاعتبارات الأخرى.
API Management
تتم محاسبتك على جميع مثيلات APIM عند تشغيلها. إذا قمت بالتحجيم لأعلى، ثم لم تعد بحاجة إلى هذا المستوى من الأداء، فغير الحجم يدويا أو قم بتكوين التحجيم التلقائي.
بالنسبة لأحمال العمل ذات الاستخدام الخفيف، ضع في اعتبارك طبقة الاستهلاك، وهو خيار منخفض التكلفة بلا خادم. تتم فوترة مستوى الاستهلاك لكل استدعاء API. تتم فوترة المستويات الأخرى في الساعة.
Logic Apps
تستخدم Logic Apps نموذجاً بلا خادم. يتم حساب الفوترة استنادا إلى عدد الإجراءات ومكالمات الموصل. لمزيد من المعلومات، راجع أسعار تطبيقات المنطق.
قوائم انتظار وموضوعات واشتراكات ناقل خدمة Microsoft Azure
تدعم قوائم انتظار واشتراكات ناقل خدمة Microsoft Azure كلا من نماذج الدفع والسحب المدعومة لتسليم الرسائل. في نموذج السحب، يتم قياس كل طلب اقتراع كإجراء. حتى إذا قمت بتعيين الاستقصاء الطويل إلى الافتراضي 30 ثانية، يمكن أن تكون التكلفة عالية. ما لم تكن بحاجة إلى تسليم الرسائل في الوقت الحقيقي، ففكر في استخدام نموذج الدفع المقتصد.
يتم تضمين قوائم انتظار ناقل خدمة Microsoft Azure في جميع المستويات: Basic وStandard وPremium. تتوفر مواضيع واشتراكات ناقل خدمة Microsoft Azure في المستويات القياسية والمتميزة. لمزيد من المعلومات، راجع أسعار ناقل خدمة Microsoft Azure.
Event Grid
تستخدم Event Grid نموذجاً بلا خادم. يتم حساب الفوترة استنادا إلى عدد العمليات. تتضمن العمليات الأحداث التي تنتقل إلى المجالات أو الموضوعات والمطابقات المتقدمة ومحاولات التسليم ومكالمات الإدارة. استخدام ما يصل إلى 100000 عملية مجاني.
لمزيد من المعلومات، راجع تسعير شبكة الأحداث وتحسين تكلفة إطار العمل المصمم جيدا.
التميز التشغيلي
يغطي التميز التشغيلي العمليات التي تنشر تطبيقا وتبقيه قيد التشغيل في الإنتاج. لمزيد من المعلومات، راجع قائمة اختيار مراجعة التصميم للتميز التشغيلي.
توفر البنية المرجعية الأساسية لتكامل المؤسسة إرشادات حول أنماط DevOps، والتي تتوافق مع ركيزة التميز التشغيلي لإطار العمل المصمم جيدا.
أتمتة عمليات الاسترداد قدر الإمكان للمساعدة في تحسين التميز التشغيلي. مع مراعاة الأتمتة، يمكنك الجمع بين مراقبة سجل Azure وأتمتة Azure لأتمتة تجاوز الفشل لموارد ناقل خدمة Microsoft Azure. للحصول على مثال لمنطق التشغيل التلقائي لبدء تجاوز الفشل، راجع تدفق تجاوز الفشل.
كفاءة الأداء
كفاءة الأداء هي قدرة حمل العمل الخاص بك على التوسع لتلبية الطلبات التي يضعها المستخدمون عليه بطريقة فعالة. لمزيد من المعلومات، راجع قائمة اختيار مراجعة التصميم لكفاءة الأداء.
لتحقيق قابلية تطوير أعلى، يمكن لطبقة ناقل خدمة Microsoft Azure Premium زيادة عدد وحدات المراسلة. لمزيد من المعلومات، راجع مستويات المراسلة المتميزة والقياسية لناقل خدمة Microsoft Azure وميزة التحجيم التلقائي.
لمزيد من توصيات ناقل خدمة Microsoft Azure، راجع أفضل الممارسات لتحسين الأداء باستخدام مراسلة ناقل خدمة Microsoft Azure.
الخطوات التالية
- نظرة عامة على تكامل ناقل خدمة Microsoft Azure إلى Event Grid
- البرنامج التعليمي الذي يستخدم المراسلة لدمج الأنظمة غير التابعة ل Microsoft عبر NServiceBus