اختيار ما إذا كنت تريد استخدام الرسائل أو الأحداث
لنفترض أنك تخطط لبنية تطبيق موزع لمشاركة الموسيقى. وتريد التأكد من أن التطبيق موثوق به وقابل للتطوير قدر الإمكان، وأنت تعتزم استخدام تكنولوجيات Azure لإنشاء بنية أساسية قوية للاتصالات.
قبل أن تتمكن من اختيار التكنولوجيا الصحيحة من Azure، عليك أن تفهم كل اتصال فردي تتبادله مكونات التطبيق. لكل اتصال، يمكنك اختيار تكنولوجيا Azure مختلفة.
أول شيء يجب فهمه حول الاتصال هو ما إذا كان يرسل رسائل أو أحداثا. تساعدك هذه المعرفة على اختيار خدمة Azure المناسبة لاستخدامها.
استراتيجيات الاتصال في Azure (واجهات برمجة التطبيقات)
ما هي الرسالة؟
في مصطلحات التطبيقات الموزعة، تتمتع الرسائل بالخصائص التالية:
- تحتوي الرسالة على بيانات أولية، ينتجها مكون واحد ويستهلكها مكون آخر.
- وتحتوي الرسالة على البيانات نفسها، وليس مجرد مرجع إلى تلك البيانات.
- يتوقع مكون الإرسال أن يقوم المكون الوجهة بمعالجة محتوى الرسالة بطريقة معينة. قد تعتمد تكامل النظام الكلي على كل من المرسل والمتلقي الذي يقوم بمهمة معينة.
على سبيل المثال، افترض أن مستخدمًا يقوم بتحميل أغنية جديدة باستخدام تطبيق مشاركة الموسيقى على الجهاز المحمول. يجب أن يرسل تطبيق الأجهزة المحمولة هذه الأغنية إلى واجهة برمجة تطبيقات الويب، التي تعمل في Azure. ويجب إرسال ملف وسائط الأغنية نفسه، وليس فقط تنبيه يشير إلى إضافة أغنية جديدة. يتوقع تطبيق الهاتف المحمول أن تقوم واجهة برمجة التطبيقات على الويب بتخزين الأغنية الجديدة في قاعدة البيانات وإتاحتها للمستخدمين الآخرين. هذا مثال على الرسالة.
ما هو الحدث؟
الأحداث أكثر خفة من الرسائل، وغالبا ما تستخدم لاتصالات البث. تعرف المكونات التي ترسل الحدث باسم الناشرين، وتعرف أجهزة الاستقبال بالمشتركين.
مع الأحداث، تحدد مكونات الاستلام الاتصالات التي تهتم بها، و"تشترك" في تلك الأحداث. يدير الوسيط الاشتراك، مثل Azure Event Grid أو Azure Event Hubs. عندما يرسل الناشرون حدثا، يوجه الوسيط هذا الحدث إلى المشتركين المهتمين. يعرف هذا النمط باسم "بنية النشر والاشتراك". إنها ليست الطريقة الوحيدة للتعامل مع الأحداث، ولكنها الأكثر شيوعا.
تتميز الأحداث بالخصائص التالية:
- الحدث هو إشعار خفيف الوزن يشير إلى حدوث شيء ما.
- قد يتم إرسال الحدث إلى مكونات استقبال متعددة، أو لا يرسل للمستقبلات على الإطلاق.
- غالبًا ما يقصد من الأحداث أنها «تنتشر» أو تحتوي على عدد كبير من المشتركين لكل ناشر.
- ولا يكون لناشر الحدث توقعات حيال الإجراء الذي يأخذه المكون المستقبل.
- بعض الأحداث هي وحدات منفصلة ولا علاقة لها بأحداث أخرى.
- بعض الأحداث هي جزء من سلسلة ذات صلة وأمر.
على سبيل المثال، افترض أن تحميل ملف الموسيقى قد اكتمل، وتمت إضافة الأغنية الجديدة إلى قاعدة البيانات. من أجل إشعار المستخدمين بالملف الجديد، يجب على واجهة برمجة التطبيقات على الويب إبلاغ واجهة الويب الأمامية ومستخدمي التطبيق المحمول بالملف الجديد. يمكن للمستخدمين اختيار ما إذا كانوا سيستمعون إلى الأغنية الجديدة، لذلك لا يتضمن الإعلام الأولي ملف الموسيقى ولكنه يعلم المستخدمين فقط بوجود الأغنية. لا يملك المرسل توقعا محددا بأن يقوم مستلمو الحدث بأي شيء على وجه الخصوص استجابة لهذا الحدث.
هذا السيناريو هو مثال على حدث منفصل.
كيفية اختيار الرسائل أو الأحداث
من المحتمل أن يستخدم التطبيق الواحد الأحداث لبعض الأغراض والرسائل للأغراض الأخرى. قبل أن تختار، يجب عليك تحليل بنية التطبيق الخاص بك وجميع حالات الاستخدام الخاصة به لتحديد جميع الأغراض المختلفة حيث يجب أن تتواصل مكوناته مع بعضها البعض.
من المرجح أن يتم استخدام الأحداث في عمليات البث، وغالبا ما تكون سريعة الزوال. وهذا يعني أنه قد لا تتم معالجة الاتصال من قبل أي متلقي إذا لم يكن هناك أي اتصال مشترك حاليا. الرسائل أكثر احتمالاً أن يتم استخدامها حيث يتطلب التطبيق الموزع ضمانة أن الاتصالات ستتم معالجتها.
لكل اتصال، ضع في اعتبارك السؤال التالي: هل يتوقع مكون الإرسال معالجة الاتصال بطريقة معينة بواسطة المكون الوجهة؟
إذا كانت الإجابة بنعم، فاختر استخدام رسالة. إذا كانت الإجابة لا، فقد تتمكن من استخدام الأحداث.
يساعدك فهم كيفية اتصال المكونات على اختيار كيفية اتصال مكوناتك. لنبدأ بالرسائل.