توضح هذه المقالة الأنواع المختلفة من الرسائل والكيانات التي تشارك في بنية أساسية للمراسلة. استنادًا إلى متطلبات كل نوع رسالة، توصي المقالة بخدمات مراسلة Azure. تتضمن الخيارات ناقل خدمة Azure المراسلة وAzure Event Grid وAzure Event Hubs. لمقارنة المنتجات، راجع مقارنة خدمات المراسلة.
على المستوى المعماري، الرسالة هي مخطط بيانات تم إنشاؤه بواسطة كيان (منتج)، لتوزيع المعلومات بحيث يمكن للكيانات الأخرى (المستهلكين) أن تكون على دراية وتعمل وفقًا لذلك. يمكن للمنتج والمستهلك التواصل مباشرة أو اختياريًا من خلال كيان وسيط (وسيط الرسائل). تركز هذه المقالة على المراسلة غير المتزامنة باستخدام وسيط الرسائل.
يمكننا تصنيف الرسائل إلى فئتين رئيسيتين. إذا كان المنتج يتوقع إجراء من المستهلك، فإن هذه الرسالة هي أمر. إذا كانت الرسالة تعلم المستهلك بأن إجراء قد تم اتخاذه، فإن الرسالة عبارة عن حدث.
الأوامر
يرسل المنتج أمرًا بهدف أن يقوم المستهلك (المستهلكون) بتنفيذ عملية ضمن نطاق معاملة تجارية.
الأمر عبارة عن رسالة عالية القيمة ويجب تسليمها مرة واحدة على الأقل. إذا تم فقدان أمر، فقد تفشل معاملة العمل بأكملها. أيضًا، لا يجب معالجة الأمر أكثر من مرة. قد يؤدي القيام بذلك إلى معاملة خاطئة. قد يحصل العميل على طلبات مكررة أو تتم فوترته مرتين.
غالبًا ما تستخدم الأوامر لإدارة سير عمل معاملة عمل متعددة الخطوات. اعتمادا على منطق العمل، قد يتوقع المنتج من المستهلك الاعتراف بالرسالة والإبلاغ عن نتائج العملية. واستنادا إلى هذه النتيجة، قد يختار المنتج مسارا مناسبا للعمل.
الأحداث
الحدث هو نوع من الرسائل التي يرفعها المنتج للإعلان عن الحقائق.
لا يتوقع المنتج (المعروف باسم الناشر في هذا السياق) أن تؤدي الأحداث إلى أي إجراء.
يمكن للمستهلك (المستهلكين) المهتمين الاشتراك والاستماع إلى الأحداث واتخاذ إجراءات اعتمادا على سيناريو الاستهلاك الخاص بهم. يمكن أن تحتوي الأحداث على عدة مشتركين أو لا يوجد مشتركون على الإطلاق. يمكن لاثنين من المشتركين المختلفين التفاعل مع حدث بإجراءات مختلفة ولا يكونوا على دراية ببعضهم البعض.
المنتج والمستهلك مقترنان بشكل غير محكم ويداران بشكل مستقل. لا يتوقع المنتج أن يقر المستهلك بالحدث مرة أخرى إلى المنتج. يمكن للمستهلك الذي لم يعد مهتما بالأحداث إلغاء الاشتراك، ما يزيل المستهلك من البنية الأساسية لبرنامج ربط العمليات التجارية دون التأثير على المنتج أو الوظيفة العامة للنظام.
هناك فئتان من الأحداث:
المنتج يثير الأحداث للإعلان عن حقائق منفصلة. حالة الاستخدام الشائعة هي إعلام الحدث. على سبيل المثال، يقوم Azure Resource Manager برفع الأحداث عند إنشاء الموارد أو تعديلها أو حذفها. يمكن أن يكون المشترك في هذه الأحداث هو Logic App الذي يرسل رسائل بريد إلكتروني للتنبيه.
يقوم المنتج برفع الأحداث ذات الصلة في تسلسل، أو دفق من الأحداث، على مدى فترة زمنية. عادة ما يتم استهلاك دفق للتقييم الإحصائي. يمكن أن يحدث التقييم داخل نافذة زمنية أو مع وصول الأحداث. بيانات تتبع الاستخدام هي حالة استخدام شائعة (على سبيل المثال، مراقبة السلامة والتحميل للنظام). حالة أخرى هي تدفق الأحداث من أجهزة IoT.
النمط الشائع لتنفيذ مراسلة الأحداث هو نمط الناشر-المشترك.
دور وفوائد وسيط الرسائل
يوفر وسيط الرسائل الوسيط وظيفة نقل الرسائل من المنتج إلى المستهلك ويمكن أن يقدم المزيد من الفوائد.
فك الارتباط
يقوم وسيط الرسائل بفصل المنتج عن المستهلك في المنطق الذي ينشئ الرسائل ويستخدمها، على التوالي. في سير عمل معقد، يمكن للوسيط تشجيع العمليات التجارية على الفصل والمساعدة في تنسيق سير العمل.
على سبيل المثال، تتطلب معاملة عمل واحدة عمليات مميزة يتم تنفيذها في تسلسل منطق العمل. يصدر المنتج أمرًا يشير إلى المستهلك لبدء عملية. يقر المستهلك بالرسالة في قائمة انتظار منفصلة محجوزة لصف الاستجابات للمنتج. فقط بعد تلقي الاستجابة يرسل المنتج رسالة جديدة لبدء العملية التالية في التسلسل. يعالج مستهلك مختلف هذه الرسالة ويرسل رسالة إكمال إلى قائمة انتظار الاستجابة. باستخدام المراسلة، تنسق الخدمات سير عمل المعاملة فيما بينها.
يوفر وسيط الرسائل فصلًا زمنيًا. لا يتعين على المنتج والمستهلك التشغيل بشكل متزامن. يمكن للمنتج إرسال رسالة إلى وسيط الرسالة بغض النظر عن توفر المستهلك. وعلى العكس من ذلك، لا يقتصر توفر المنتج على المستهلك.
على سبيل المثال، تنشئ واجهة المستخدم لتطبيق ويب رسائل وتستخدم قائمة انتظار كوسيط رسائل. عندما يكون المستهلك جاهزا، يمكنه استرداد الرسائل من قائمة الانتظار وتنفيذ العمل. يساعد الفصل الزمني واجهة المستخدم على البقاء مستجيبة. لا يتم حظره في أثناء معالجة الرسائل بشكل غير متزامن.
قد تستغرق بعض العمليات وقتًا طويلًا لإكمالها. بعد أن يصدر الأمر، لا يجب على المنتج الانتظار حتى يكمله المستهلك. يساعد وسيط الرسائل في المعالجة غير المتزامنة للرسائل.
موازنة الأحمال
يمكن للمنتجين نشر عدد كبير من الرسائل التي يقوم العديد من المستهلكين بصيانتها. استخدم وسيط الرسائل لتوزيع المعالجة عبر الخوادم وتحسين معدل النقل. يمكن تشغيل المستهلكين على خوادم مختلفة لنشر الحمل. يمكن إضافة المستهلكين ديناميكيًا لتوسيع نطاق النظام عند الحاجة أو إزالتهم بخلاف ذلك.
يوضح نمط المستهلكين المتنافسين كيفية معالجة رسائل متعددة بشكل متزامن لتحسين معدل النقل وتحسين قابلية التوسع والتوافر وموازنة حمل العمل.
مقياس الحمل
يمكن أن يكون حجم الرسائل التي ينشئها المنتج أو مجموعة من المنتجين متغيرًا. في بعض الأحيان قد يكون هناك حجم كبير يسبب ارتفاعات في الرسائل. بدلًا من إضافة المستهلكين للتعامل مع هذا العمل، يمكن أن يعمل وسيط الرسائل كمخزن مؤقت، والمستهلكين يستنزفون الرسائل تدريجيًا بوتيرتهم الخاصة دون التأكيد على النظام.
يوفر نمط تسوية التحميل المستند إلى قائمة الانتظار مزيدا من المعلومات.
المراسلة الموثوق بها
يساعد وسيط الرسائل على ضمان عدم فقدان الرسائل حتى إذا فشل الاتصال بين المنتج والمستهلك. يمكن للمنتج نشر الرسائل إلى وسيط الرسائل ويمكن للمستهلك استردادها عند إعادة تأسيس الاتصال. لا يتم حظر المنتج ما لم يفقد الاتصال مع وسيط الرسائل.
المراسلة المرنة
يمكن لوسيط الرسائل إضافة مرونة إلى المستهلكين في النظام الخاص بك. إذا فشل المستهلك في أثناء معالجة رسالة، يمكن لمثيل آخر للمستهلك معالجة تلك الرسالة. إعادة المعالجة ممكنة لأن الرسالة تستمر في الوسيط.
خيارات التكنولوجيا لوسيط الرسائل
يوفر Azure العديد من خدمات وسيط الرسائل، لكل منها مجموعة من الميزات. قبل اختيار خدمة، حدد الهدف ومتطلبات الرسائل.
Azure Service Bus Messaging
ناقل خدمة Azure قوائم انتظار المراسلة مناسبة تماما لنقل الأوامر من المنتجين إلى المستهلكين. فيما يلي بعض الاعتبارات.
نموذج السحب
يستطلع مستهلك قائمة انتظار ناقل خدمة Microsoft Azure ناقل خدمة Microsoft Azure باستمرار للتحقق مما إذا كانت الرسائل الجديدة متوفرة. مشغل SDKs العميل وAzure Functions لناقل خدمة Microsoft Azure مجرد هذا النموذج. عند توفر رسالة جديدة، يتم استدعاء رد اتصال المستهلك ويتم إرسال الرسالة إلى المستهلك.
تسليم مضمون
يسمح ناقل خدمة Microsoft Azure للمستهلك بلق نظرة خاطفة على قائمة الانتظار وتأمين رسالة من مستهلكين آخرين.
تقع على عاتق المستهلك مسؤولية الإبلاغ عن حالة معالجة الرسالة. فقط عندما يضع المستهلك علامة على الرسالة على أنها مستهلكة، يقوم ناقل خدمة Microsoft Azure بإزالة الرسالة من قائمة الانتظار. في حالة حدوث فشل أو مهلة أو تعطل، يقوم ناقل خدمة Microsoft Azure بإلغاء تأمين الرسالة حتى يتمكن المستهلكون الآخرون من استردادها. بهذه الطريقة، لا يتم فقدان الرسائل في النقل.
قد يرسل المنتج نفس الرسالة مرتين عن طريق الخطأ. على سبيل المثال، يفشل مثيل المنتج بعد إرسال رسالة. يحل منتج آخر محل المثيل الأصلي ويرسل الرسالة مرة أخرى. توفر قوائم الانتظار ناقل خدمة Azure إمكانية مضمنة لإزالة التكرار التي تكشف عن الرسائل المكررة وتزيلها. لا تزال هناك فرصة لتسليم رسالة مرتين. على سبيل المثال، إذا فشل المستهلك أثناء المعالجة، يتم إرجاع الرسالة إلى قائمة الانتظار ويتم استردادها من قبل نفس المستهلك أو مستهلك آخر. يجب أن يكون منطق معالجة الرسائل في المستهلك غير فعال بحيث حتى إذا تم تكرار العمل، فلن تتغير حالة النظام.
ترتيب الرسائل
إذا كنت تريد أن يحصل المستهلكون على الرسائل بالترتيب الذي يتم إرسالها به، تضمن قوائم انتظار ناقل خدمة Microsoft Azure التسليم المطلوب أولا من البداية (FIFO) باستخدام جلسات العمل. يمكن أن تحتوي جلسة العمل على رسالة واحدة أو أكثر. ترتبط الرسائل بخاصية SessionId. لا تنتهي صلاحية الرسائل التي تعد جزءًا من جلسة عمل. يمكن تأمين جلسة عمل لمستهلك لمنع معالجة رسائله من قبل مستهلك مختلف.
لمزيد من المعلومات، راجع جلسات عمل الرسائل.
استمرارية الرسالة
تدعم قوائم انتظار ناقل الخدمة الفصل الزمني. حتى عندما لا يكون المستهلك متوفرًا أو غير قادر على معالجة الرسالة، فإنه يبقى في قائمة الانتظار.
نقطة تفتيش المعاملات طويلة الأمد
يمكن تشغيل المعاملات التجارية لفترة طويلة. يمكن أن تحتوي كل عملية في المعاملة على رسائل متعددة. استخدم نقاط التحقق لتنسيق سير العمل وتوفير المرونة في حالة فشل المعاملة.
تسمح قوائم انتظار ناقل خدمة Microsoft Azure بنقاط التحقق من خلال إمكانية حالة جلسة العمل. يتم تسجيل معلومات الحالة بشكل متزايد في قائمة الانتظار (SetState) للرسائل التي تنتمي إلى جلسة عمل. على سبيل المثال، يمكن للمستهلك تعقب التقدم عن طريق التحقق من الحالة (GetState) بين الحين والآخر. إذا فشل المستهلك، يمكن لمستهلك آخر استخدام معلومات الحالة لتحديد آخر نقطة تحقق معروفة لاستئناف جلسة العمل.
قائمة انتظار غير مستخدمة (DLQ)
تحتوي قائمة انتظار ناقل خدمة Microsoft Azure على قائمة انتظار فرعية افتراضية، تسمى قائمة انتظار الرسائل المهملة (DLQ) للاحتفاظ بالرسائل التي تعذر تسليمها أو معالجتها. يمكن لناقل الخدمة أو منطق معالجة الرسائل في المستهلك إضافة رسائل إلى DLQ. يحتفظ DLQ بالرسائل حتى يتم استردادها من قائمة الانتظار.
فيما يلي أمثلة على الوقت الذي يمكن أن ينتهي به الأمر برسالة في DLQ:
الرسالة غير الصحيحة هي رسالة لا يمكن معالجتها لأنها مشوهة أو تحتوي على معلومات غير متوقعة. في قوائم انتظار ناقل خدمة Microsoft Azure، يمكنك الكشف عن الرسائل السامة عن طريق تعيين الخاصية MaxDeliveryCount لقائمة الانتظار. إذا تجاوز عدد المرات التي تم فيها تلقي نفس الرسالة قيمة الخاصية هذه، ينقل ناقل خدمة Microsoft Azure الرسالة إلى DLQ.
قد لا تكون الرسالة ذات صلة بعد الآن إذا لم تتم معالجتها خلال فترة. تسمح قوائم انتظار ناقل خدمة Microsoft Azure للمنتج بنشر الرسائل بسمة مدة البقاء. إذا انتهت صلاحية هذه الفترة قبل تلقي الرسالة، يتم وضع الرسالة في DLQ.
افحص الرسائل في DLQ لتحديد سبب الفشل.
حل مختلط
جسر ناقل خدمة Microsoft Azure للأنظمة المحلية والحلول السحابية. غالبًا ما يصعب الوصول إلى الأنظمة المحلية بسبب قيود جدار الحماية. يمكن لكل من المنتج والمستهلك (إما أن يكون محليًا أو السحابة) استخدام نقطة نهاية قائمة انتظار ناقل خدمة Microsoft Azure كموقع استلام وإفلات للرسائل.
نمط جسر المراسلة هو طريقة أخرى للتعامل مع هذه السيناريوهات.
الموضوعات والاشتراكات
يدعم ناقل خدمة Microsoft Azure نمط Publisher-Subscriber من خلال مواضيع واشتراكات ناقل خدمة Microsoft Azure.
توفر هذه الميزة طريقة للمنتج لبث الرسائل إلى مستهلكين متعددين. عندما يتلقى موضوع رسالة، تتم إعادة توجيهه إلى جميع المستهلكين المشتركين. اختياريًا، يمكن أن يحتوي الاشتراك على معايير تصفية تسمح للمستهلك بالحصول على مجموعة فرعية من الرسائل. يسترد كل مستهلك الرسائل من اشتراك بطريقة مشابهة لقائمة انتظار.
لمزيد من المعلومات، راجع مواضيع Azure Service Bus.
Azure Event Grid
نوصي ب Azure Event Grid للأحداث المنفصلة. تتبع Event Grid نمط Publisher-Subscriber. عندما تؤدي مصادر الأحداث إلى تشغيل الأحداث، يتم نشرها في مواضيع Event Grid. ينشئ مستهلكو هذه الأحداث اشتراكات Event Grid عن طريق تحديد أنواع الأحداث ومعالج الأحداث الذي سيعالج الأحداث. إذا لم يكن هناك مشتركون، يتم تجاهل الأحداث. يمكن أن يكون لكل حدث اشتراكات متعددة.
نموذج الدفع
تنشر Event Grid الرسائل إلى المشتركين في نموذج دفع. لنفترض أن لديك اشتراك Event Grid مع إخطار على الويب. عند وصول حدث جديد، تنشر Event Grid الحدث إلى نقطة نهاية خطاف الويب.
متكامل مع Azure
اختر Event Grid إذا كنت تريد الحصول على إعلامات حول موارد Azure. تعمل العديد من خدمات Azure كمصادر أحداث تحتوي على مواضيع شبكة الأحداث المضمنة. تدعم Event Grid أيضًا خدمات Azure المختلفة التي يمكن تكوينها كمعالجات أحداث. من السهل الاشتراك في هذه الموضوعات لتوجيه الأحداث إلى معالجات الأحداث التي تختارها. على سبيل المثال، يمكنك استخدام Event Grid لاستدعاء وظيفة Azure عند إنشاء تخزين كائن ثنائي كبير الحجم أو حذفه.
الموضوعات المخصصة
إنشاء مواضيع شبكة الأحداث المخصصة إذا كنت تريد إرسال أحداث من التطبيق الخاص بك أو خدمة Azure غير متكاملة مع Event Grid.
على سبيل المثال، لمعرفة تقدم معاملة تجارية بأكملها، تريد أن تقوم الخدمات المشاركة برفع الأحداث أثناء معالجة عملياتها التجارية الفردية. يعرض تطبيق الويب هذه الأحداث. إحدى الطرق لإنجاز هذه المهمة هي إنشاء موضوع مخصص وإضافة اشتراك مع تطبيق الويب الخاص بك المسجل من خلال HTTP WebHook. نظرًا لأن خدمات الأعمال ترسل الأحداث إلى الموضوع المخصص، فإن Event Grid تدفعها إلى تطبيق الويب الخاص بك.
الأحداث التي تمت تصفيتها
يمكنك تحديد عوامل التصفية في اشتراك لتوجيه Event Grid لتوجيه مجموعة فرعية فقط من الأحداث إلى معالج أحداث معين. يمكنك تحديد عوامل التصفية في مخطط الاشتراك. تتم إعادة توجيه أي حدث يتم إرساله إلى الموضوع بقيم تطابق عامل التصفية تلقائيا إلى هذا الاشتراك.
على سبيل المثال، يتم تحميل المحتوى بتنسيقات مختلفة إلى Blob Storage. في كل مرة تتم فيها إضافة ملف، يتم رفع حدث ونشره في Event Grid. قد يحتوي اشتراك الحدث على عامل تصفية يرسل الأحداث للصور فقط بحيث يمكن لمعالج الأحداث إنشاء صور مصغرة.
لمزيد من المعلومات حول التصفية، راجع تصفية الأحداث لشبكة الأحداث.
معدل نقل عالٍ
شبكة الأحداث يمكنها توجيه 10,000,000 حدثًا في الثانية لكل منطقة. أول 100.000 عملية شهريا مجانية. لاعتبارات التكلفة، راجع كم تكلفة شبكة الأحداث؟
التسليم المرن
على الرغم من أن التسليم الناجح للأحداث ليس مهما مثل الأوامر، فقد لا تزال ترغب في بعض الضمانات اعتمادًا على نوع الحدث. تقدم Event Grid ميزات يمكنك تمكينها وتخصيصها، مثل نهج إعادة المحاولة ووقت انتهاء الصلاحية والرسائل غير المستخدمة. لمزيد من المعلومات، راجع تسليم رسالة Event Grid، وإعادة المحاولة.
يمكن أن تساعد عملية إعادة محاولة شبكة الأحداث في المرونة ولكنها ليست آمنة من الفشل. في عملية إعادة المحاولة، قد تقوم Event Grid بتسليم الرسالة أكثر من مرة واحدة، أو تخطي بعض عمليات إعادة المحاولة أو تأخيرها إذا كانت نقطة النهاية غير مستجيبة لفترة طويلة. لمزيد من المعلومات، راجع جدول إعادة المحاولة.
يمكنك الاستمرار في الأحداث غير المحذوفة إلى حساب تخزين كائن ثنائي كبير الحجم عن طريق تمكين الكتابة غير المستخدمة. هناك تأخير في تسليم الرسالة إلى نقطة نهاية تخزين الكائن الثنائي كبير الحجم وإذا كانت نقطة النهاية هذه غير مستجيبة، فإن Event Grid تتجاهل الحدث. لمزيد من المعلومات، راجع تعيين موقع غير مستخدم ونهج إعادة المحاولة.
مراكز أحداث Azure
عندما تعمل مع دفق حدث، فإن Azure Event Hubs هو وسيط الرسائل الموصى به. بشكل أساسي، إنه مخزن مؤقت كبير قادر على تلقي كميات كبيرة من البيانات مع زمن انتقال منخفض. يمكن قراءة البيانات المستلمة بسرعة من خلال العمليات المتزامنة. يمكنك تحويل البيانات المستلمة باستخدام أي موفر تحليلات في الوقت الحقيقي. توفر مراكز الأحداث أيضًا القدرة على تخزين الأحداث في حساب تخزين.
الاستيعاب السريع
مراكز الأحداث قادرة على استيعاب ملايين الأحداث في الثانية. يتم إلحاق الأحداث بالتدفق فقط ويتم ترتيبها حسب الوقت.
نموذج السحب
مثل Event Grid، توفر مراكز الأحداث أيضًا قدرات Publisher-Subscriber. يوجد فرق رئيسي بين شبكة الأحداث ومراكز الأحداث في الطريقة التي يتم بها توفير بيانات الحدث للمشتركين. تدفع Event Grid البيانات التي تم استيعابها إلى المشتركين بينما توفر Event Hubs البيانات في نموذج سحب. في أثناء تلقي الأحداث، تقوم مراكز الأحداث بإلحاقها بالتدفق. يدير المشترك المؤشر الخاص به ويمكنه الانتقال إلى الأمام والخلف في الدفق، وتحديد إزاحة زمنية، وإعادة تشغيل تسلسل في وتيرته.
معالجات الدفق هي مشتركون يسحبون البيانات من مراكز الأحداث لأغراض التحويل والتحليل الإحصائي. استخدم Azure Stream Analytics وApache Spark للمعالجة المعقدة مثل التجميع بمرور الوقت أو الكشف عن الحالات الخارجة عن المألوف.
إذا كنت ترغب في العمل على كل حدث لكل قسم، يمكنك سحب البيانات باستخدام مضيف معالج الأحداث، أو باستخدام موصل مضمن مثل Azure Logic Apps لتوفير منطق التحويل. خيار آخر هو استخدام Azure Functions.
التقسيم
القسم هو جزء من دفق الحدث. يتم تقسيم الأحداث باستخدام مفتاح قسم. على سبيل المثال، ترسل العديد من أجهزة IoT بيانات الجهاز إلى مركز أحداث. مفتاح القسم هو معرف الجهاز. في أثناء استيعاب الأحداث، تنقلها مراكز الأحداث إلى أقسام منفصلة. داخل كل قسم، يتم ترتيب جميع الأحداث حسب الوقت.
المستهلك هو مثيل للتعليمات البرمجية التي تعالج بيانات الحدث. تتبع مراكز الأحداث نمط مستهلك مقسم. يقرأ كل مستهلك فقط قسمًا معينًا. يؤدي وجود أقسام متعددة إلى معالجة أسرع لأنه يمكن قراءة الدفق بشكل متزامن من قبل عدة مستهلكين.
تشكل مثيلات نفس المستهلك مجموعة مستهلكين واحدة. يمكن لمجموعات مستهلكين متعددة قراءة نفس الدفق مع نوايا مختلفة. لنفترض أن دفق الأحداث يحتوي على بيانات من مستشعر درجة الحرارة. يمكن لمجموعة مستهلكين واحدة قراءة الدفق للكشف عن الحالات الخارجة عن المألوف مثل ارتفاع في درجة الحرارة. يمكن لدفق آخر قراءة نفس الدفق لحساب متوسط درجة الحرارة المتداول في نافذة زمنية.
تدعم مراكز الأحداث نمط Publisher-Subscriber من خلال السماح لمجموعات مستهلكين متعددة. كل مجموعة مستهلكين هي مشترك.
لمزيد من المعلومات حول تقسيم مراكز الأحداث، راجع الأقسام.
التقاط مراكز الأحداث
تسمح لك ميزة Capture بتخزين دفق الحدث إلى تخزين Azure Blob أو Data Lake Storage. هذه الطريقة لتخزين الأحداث موثوقة لأنه حتى إذا لم يكن حساب التخزين متوفرا، يحتفظ Capture ببياناتك لفترة، ثم يكتب إلى التخزين بعد توفره.
يمكن أن تقدم خدمات التخزين أيضًا ميزات إضافية لتحليل الأحداث. على سبيل المثال، من خلال الاستفادة من مستويات الوصول لحساب تخزين كائن ثنائي كبير الحجم، يمكنك تخزين الأحداث في طبقة ساخنة للبيانات التي تحتاج إلى وصول متكرر. يمكنك استخدام هذه البيانات للتصور. بدلًا من ذلك، يمكنك تخزين البيانات في طبقة الأرشيف واستردادها أحيانًا لأغراض التدقيق.
يخزن الالتقاط جميع الأحداث التي تم تناولها بواسطة مراكز الأحداث وهو مفيد لمعالجة الدفعات. يمكنك إنشاء تقارير حول البيانات باستخدام دالة MapReduce. يمكن أن تكون البيانات التي تم التقاطها أيضًا كمصدر للحقيقة. إذا فقدت بعض الحقائق أثناء تجميع البيانات، يمكنك الرجوع إلى البيانات التي تم التقاطها.
لمزيد من التفاصيل عن هذه الميزة، راجع التقاط الأحداث من خلال مراكز الأحداث Azure في تخزين Azure Blob أو تخزين Azure Data Lake Storage.
دعم عملاء Apache Kafka
توفر مراكز الأحداث نقطة نهاية لعملاء Apache Kafka. يمكن للعملاء الحاليين تحديث التكوين الخاص بهم للإشارة إلى نقطة النهاية والبدء في إرسال الأحداث إلى مراكز الأحداث. لا تحتاج إلى إجراء أي تغييرات في التعليمات البرمجية.
لمزيدٍ من المعلومات، راجع Event Hubs لـ Apache Kafka.
سيناريوهات التجاوز
في بعض الحالات، من المفيد دمج خدمتي مراسلة.
يمكن أن يزيد الجمع بين الخدمات من كفاءة نظام المراسلة الخاص بك. على سبيل المثال، في المعاملة التجارية الخاصة بك، يمكنك استخدام قوائم انتظار ناقل خدمة Azure لمعالجة الرسائل. قوائم الانتظار التي تكون في الغالب الخامة وتتلقى الرسائل غير فعالة في بعض الأحيان، لأن المستهلك يقوم باستمرار باستقصاء قائمة الانتظار للرسائل الجديدة. يمكنك إعداد اشتراك Event Grid باستخدام Azure Function كمعالج الحدث. في كل مرة تتلقى فيها قائمة الانتظار رسالة ولا يوجد مستهلكون يستمعون، ترسل Event Grid إعلاما يستدعي وظيفة Azure التي تستنزف قائمة الانتظار.
للحصول على تفاصيل حول توصيل ناقل خدمة Microsoft Azure بشبكة الأحداث، راجع نظرة عامة على تكامل شبكة الأحداث لناقل خدمة Azure.
يظهر تكامل المؤسسة باستخدام قوائم انتظار الرسائل والبنية المرجعية للأحداث تنفيذ تكامل Service Bus to Event Grid.
فيما يلي مثال آخر: تتلقى Event Grid مجموعة من الأحداث التي تتطلب فيها بعض الأحداث سير عمل بينما تتطلب أحداث أخرى الإعلام. تشير بيانات تعريف الرسالة إلى نوع الحدث. إحدى الطرق للتمييز هي التحقق من بيانات التعريف باستخدام ميزة التصفية في اشتراك الحدث. إذا كان يتطلب سير عمل، ترسله Event Grid إلى قائمة انتظار ناقل خدمة Azure. يمكن لمستلمي قائمة الانتظار هذه اتخاذ الإجراءات اللازمة. يتم إرسال أحداث الإعلام إلى Logic Apps لإرسال رسائل بريد إلكتروني للتنبيه.
أنماط ذات صلة
ضع في اعتبارك هذه الأنماط عند تنفيذ المراسلة غير المتزامنة:
- نمط المستهلكين المنافسين. قد يحتاج العديد من المستهلكين إلى التنافس لقراءة الرسائل من قائمة انتظار. يشرح هذا النمط كيفية معالجة رسائل متعددة بشكل متزامن لتحسين معدل النقل، وتحسين قابلية التوسع والتوافر، وموازنة حمل العمل.
- نمط قائمة انتظار الأولوية. بالنسبة للحالات التي يتطلب فيها منطق العمل معالجة بعض الرسائل قبل غيرها، يصف هذا النمط كيفية تلقي الرسائل التي يتم نشرها بواسطة منتج ذي أولوية أعلى ومعالجتها بسرعة أكبر من الرسائل ذات الأولوية الأقل.
- نمط تسوية التحميل المستند إلى قائمة الانتظار. يستخدم هذا النمط وسيط رسائل للعمل كمخزن مؤقت بين المنتج والمستهلك للمساعدة في تقليل التأثير على توفر الأحمال الثقيلة المتقطعة واستجابتها لكلا الكيانين.
- نمط إعادة المحاولة. قد لا يتمكن المنتج أو المستهلك من الاتصال بقائمة انتظار، ولكن قد تكون أسباب هذا الفشل مؤقتة وسريعة. يصف هذا النمط كيفية التعامل مع هذا الموقف لإضافة مرونة إلى تطبيق.
- نمط مشرف عامل المجدول. غالبًا ما يتم استخدام المراسلة كجزء من تنفيذ سير العمل. يوضح هذا النمط كيف يمكن للمراسلة تنسيق مجموعة من الإجراءات عبر مجموعة موزعة من الخدمات والموارد البعيدة الأخرى، وتمكين النظام من استرداد الإجراءات التي تفشل وإعادة محاولة تنفيذها.
- نمط الكوريغرافيا. يوضح هذا النمط كيف يمكن للخدمات استخدام المراسلة للتحكم في سير عمل معاملة تجارية.
- نمط التحقق من المطالبة. يوضح هذا النمط كيفية تقسيم رسالة كبيرة إلى فحص مطالبة وحمولة.