مشاركة عبر

«مراكز الأحداث» والموثوقية

  • مقالة

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

لمزيد من المعلومات عن استخدام «مراكز الأحداث»، راجع وثائق مراكز أحداث Azure لمعرفة كيفية استخدام «مراكز الأحداث» لاستيعاب ملايين الأحداث في الثانية من الأجهزة والتطبيقات المتصلة.

لمعرفة كيفية استخدام "مراكز الأحداث" لإنشاء عبء عمل أكثر موثوقية، راجع معالجة الكوارث - الجغرافية - في مراكز أحداث Azure .

تتعلق المقاطع التالية بمراكز أحداث Azure والموثوقية:

  • اعتبارات التصميم
  • قائمة مراجعة التكوين
  • خيارات التكوين الموصى بها
  • البيانات الاصطناعية المصدر

اعتبارات التصميم

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

قائمة الاختيار

هل كوّنت Azure Event Grid مع مراعاة الموثوقية؟

  • إنشاء نُهج SendOnly وListenOnly لناشر الحدث والمستهلك، على التوالي.
  • عند استخدام SDK لإرسال الأحداث إلى مراكز الأحداث، تأكد من الاطلاع على الاستثناءات المطروحة من نهج إعادة المحاولة (EventHubsException أو OperationCancelledException) بشكل صحيح.
  • في سيناريوهات معدل النقل العالية، استخدم الأحداث المُنفَذة على دفعات.
  • يمكن أن يقرأ كل مستهلك الأحداث من واحد إلى 32 من الأقسام.
  • عند تصميم تطبيقات جديدة، استخدم EventProcessorClient (.NET وJava) أو EventHubConsumerClient (Python وJavaScript) كأداة SDK العميل.
  • كجزء من إستراتيجية قابلية الوصول والإصلاح بعد كارثة على نطاق الحل، يُرجى مراجعة تمكين خيار الإصلاح بعد كوارث المواقع الجغرافية لمراكز الأحداث.
  • عندما يحتوي الحل على عدد كبير من ناشري الأحداث المستقلين، يُرجى مراعاة استخدام ناشري الأحداث للتحكم في الوصول الدقيق.
  • لا تنشر الأحداث في قسم معين.
  • عند نشر الأحداث بشكل متكرر، استخدم بروتوكول AMQP عند الإمكان.
  • يوضح عدد الأقسام درجة توازي تلقي المعلومات التي يمكنك تحقيقها.
  • تأكد من استخدام كل تطبيق مستهلك لمجموعة مستهلك منفصلة واستخدام مستقبل واحد نشط فقط لكل مجموعة مستهلك.
  • عند استخدام ميزة التسجيل، يُرجى مراعاة تكوين الإطار الزمني وحجم الملف، خاصة مع وحدات تخزين الأحداث منخفضة الحجم.

توصيات التكوين

يُرجى مراعاة التوصيات التالية لتحسين الموثوقية عند تكوين مراكز أحداث Azure:

التوصية الوصف
عند استخدام SDK لإرسال الأحداث إلى مراكز الأحداث، تأكد من الاطلاع على الاستثناءات المطروحة من نهج إعادة المحاولة (EventHubsException أو OperationCancelledException) بشكل صحيح. عند استخدام HTTPS، تأكد من تطبيق نمط إعادة محاولة صحيح.
في سيناريوهات معدل النقل العالية، استخدم الأحداث المُنفَذة على دفعات. ستقدم الخدمة صفيف json يحتوي على أحداث متعددة للمشتركين بدلاً من صفيف بحدث واحد. يجب أن يكون التطبيق المستهلك قادراً على معالجة هذه الصفائف.
يمكن أن يقرأ كل مستهلك الأحداث من واحد إلى 32 من الأقسام. لتحقيق الحد الأقصى لتغيير الحجم من جانب التطبيق المستهلك، يجب أن يقرأ كل مستهلك من قسم واحد.
عند تصميم تطبيقات جديدة، استخدم EventProcessorClient (.NET وJava) أو EventHubConsumerClient (Python وJavaScript) كأداة SDK العميل. EventProcessorHost مهمل.
كجزء من إستراتيجية قابلية الوصول والإصلاح بعد كارثة على نطاق الحل، يُرجى مراجعة تمكين خيار الإصلاح بعد كوارث المواقع الجغرافية لمراكز الأحداث. يسمح هذا الخيار بإنشاء مساحة اسم خدمة ثانوية في منطقة أخرى. تتلقى مساحة اسم الخدمة النشطة رسائل في أي وقت فقط. لا تُنسَخ الرسائل والأحداث إلى المنطقة الثانوية. يصل هدف RTO لعملية الفشل الإقليمية حتى 30 دقيقة. تأكد من توافق هدف RTO هذا مع متطلبات العميل وإستراتيجية قابلية الوصول الأوسع. إذا كان مطلوباً هدف RTO أعلى، فيُرجى مراعاة تطبيق نمط تجاوز الفشل من جانب العميل.
عندما يحتوي الحل على عدد كبير من ناشري الأحداث المستقلين، يُرجى مراعاة استخدام ناشري الأحداث للتحكم في الوصول الدقيق. يعيِّن ناشرو الأحداث مفتاح القسم تلقائياً إلى اسم الناشر، لذا لا يجب استخدام هذه الميزة إلا في حالة إنشاء الأحداث من جميع الناشرين بالتساوي فقط.
لا تنشر الأحداث في قسم معين. إذا كان ترتيب الأحداث ضرورياً، فنفِّذ الأمر في اتجاه تنازلي أو استخدم خدمة مراسلة أخرى بدلاً من ذلك.
عند نشر الأحداث بشكل متكرر، استخدم بروتوكول AMQP عند الإمكان. تتميز AMQP بتكلفة شبكة اتصال أعلى عند بدء جلسة العمل، لكن HTTPS يتطلب نفقات TLS إضافية لكل طلب. تتميز AMQP بأداء أعلى للناشرين المتكررين.
يوضح عدد الأقسام درجة توازي تلقي المعلومات التي يمكنك تحقيقها. للحصول على أقصى معدل نقل، استخدم أقصى عدد من الأقسام (32) عند إنشاء مركز الحدث. يسمح لك أقصى عدد من الأقسام بتوسيع النطاق إلى 32 من كيانات المعالجة المتزامنة وسيقدم أعلى قابلية وصول لإرسال واستقبال البيانات.
عند استخدام ميزة التسجيل، يُرجى مراعاة تكوين الإطار الزمني وحجم الملف، خاصة مع وحدات تخزين الأحداث منخفضة الحجم. سيفرض مستودع البيانات رسوماً على الحد الأدنى لحجم الملف للتخزين (gen1) أو الحد الأدنى لحجم المعاملة (gen2). في حالة تعيين إطار زمني منخفض جداً بحيث لا يصل الملف إلى الحد الأدنى للحجم، ستتحمل تكلفة إضافية.

البيانات الاصطناعية المصدر

للعثور على مساحات أسماء خدمة مراكز الأحداث باستخدام أداة SKU الأساسية، اتبع الاستعلام التالي:

Resources 
| where type == 'microsoft.eventhub/namespaces'
| where sku.name == 'Basic'
| project resourceGroup, name, sku.name

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

«مراكز الأحداث» والتميز التشغيلي