مشاركة عبر

الرسائل والحمولات والتسلسل

  • مقالة

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

يعكس نموذج الكائن لعملاء ناقل خدمة Azure الرسمي لـ .NET و Java بنية رسالة ناقل خدمة Azure المجردة، والتي تم تعيينها من بروتوكولات التوصيل وإليها، التي تدعمها ناقل خدمة Azure.

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

يتم سرد خصائص الوسيط المحددة مسبقاً في الجدول التالي. يتم استخدام الأسماء مع جميع واجهات برمجة تطبيقات العميل الرسمية وأيضا في BrokerProperties كائن JSON لتعيين بروتوكول HTTP.

يتم سرد الأسماء المكافئة المستخدمة على مستوى البروتوكول Advanced Message Queuing Protocol (AMQP) بين أقواس. بينما تستخدم الأسماء التالية غلاف الباسكال، فإن عملاء JavaScript وPython سيستخدمون غلاف الجمل والأفعى على التوالي.

اسم الخاصية ‏‏الوصف
ContentType (content-type) يصف اختيارياً حمولة الرسالة، مع واصف يتبع تنسيق RFC2045، القسم 5؛ على سبيل المثال،application/json.
CorrelationId (correlation-id) يُمكّن التطبيق من تحديد سياق الرسالة لأغراض الارتباط؛ على سبيل المثال، يعكس معرّف الرسالة للرسالة التي يتم الرد عليها.
DeadLetterSource يتم تعيينها فقط في الرسائل التي تم تحديدها بشكل نهائي، وتم إعادة توجيهها تلقائياً لاحقاً من قائمة انتظار الرسائل المهملة إلى كيان آخر. يشير إلى الكيان الذي كانت الرسالة مكتوبة بخط مهمل فيه. هذه الخاصية للقراءة فقط.
DeliveryCount

عدد عمليات التسليم التي تمت محاولتها لهذه الرسالة. يتزايد العدد عند انتهاء صلاحية قفل الرسالة أو تخلي المتلقي صراحةً عن الرسالة. هذه الخاصية للقراءة فقط.

لا يتم زيادة عدد التسليم عند إغلاق اتصال AMQP الأساسي.
EnqueuedSequenceNumber بالنسبة للرسائل التي تم إعادة توجيهها تلقائياً، تعكس هذه الخاصية الرقم التسلسلي الذي تم تعيينه أولاً للرسالة في نقطة الإرسال الأصلية. هذه الخاصية للقراءة فقط.
EnqueuedTimeUtc لحظة UTC التي تم عندها قبول الرسالة وتخزينها في الكيان. يمكن استخدام هذه القيمة كمؤشر وقت وصول موثوق ومحايد عندما لا يرغب المستلم في الوثوق بساعة المرسل. هذه الخاصية للقراءة فقط.
Expires​AtUtc (absolute-expiry-time) لحظة UTC التي يتم فيها وضع علامة على الرسالة لإزالتها، ولم تعد متاحة للاسترداد من الكيان بسبب انتهاء صلاحيتها. يتم التحكم في انتهاء الصلاحية بواسطة خاصية TimeToLive ويتم حساب هذه الخاصية من EnqueuedTimeUtc + TimeToLive. هذه الخاصية للقراءة فقط.
Label أو Subject (subject) تُمكِّن هذه الخاصية التطبيق من الإشارة إلى الغرض من الرسالة إلى المستلم بطريقة موحدة، على غرار سطر موضوع البريد الإلكتروني.
Locked​Until​Utc بالنسبة للرسائل التي تم استردادها ضمن تأمين (وضع تلقي قفل النظرة الخاطفة، غير مهيأ مسبقا) تعكس هذه الخاصية لحظة UTC حتى يتم الاحتفاظ بالرسالة مؤمنة في قائمة الانتظار/الاشتراك. عند انتهاء صلاحية القفل، تتم زيادة DeliveryCount وتتاح الرسالة مرة أخرى للاسترداد. هذه الخاصية للقراءة فقط.
Lock​Token رمز القفل هو إشارة إلى القفل الذي يحتفظ به الوسيط في وضع الاستلام peek-lock. يمكن استخدام الرمز المميز لتثبيت القفل بشكل دائم من خلال واجهة برمجة تطبيقات التأجيل، وبذلك يتم إخراج الرسالة من التدفق العادي لحالة التسليم. هذه الخاصية للقراءة فقط.
Message​Id (message-id) معرف الرسالة هو قيمة مُعرَّفة من قِبل التطبيق، تُعرِّف الرسالة وحمولتها بشكل فريد. المُعرّف عبارة عن سلسلة ذات شكل حر، ويمكن أن تعكس GUID أو معرفاً مشتقاً من سياق التطبيق. في حالة التمكين، تحدد ميزة duplicate detection وتزيل عمليات الإرسال الثانية والرسائل اللاحقة التي لها نفس معرّف الرسالة.
Partition​Key بالنسبة إلى partitioned entities، يتيح تعيين هذه القيمة تعيين الرسائل ذات الصلة إلى نفس القسم الداخلي، بحيث يتم تسجيل ترتيب تسلسل الإرسال بشكل صحيح. يتم اختيار القسم بواسطة دالة تجزئة فوق هذه القيمة، ولا يمكن اختياره مباشرة. بالنسبة للكيانات المدركة للجلسة، تتجاوز الخاصية SessionId هذه القيمة.
Reply​To (reply-to) هذه القيمة الاختيارية والمعرفة من قِبل التطبيق هي طريقة قياسية للتعبير عن مسار الرد لمتلقي الرسالة. عندما يتوقع المرسل رداً، فإنه يعين القيمة على المسار المطلق أو النسبي لقائمة الانتظار أو الموضوع الذي يتوقع أن يتم إرسال الرد إليه.
Reply​To​Session​Id (reply-to-group-id) تزيد هذه القيمة من معلومات ReplyTo، وتحدد أي SessionId يجب تعيينه للرد عند إرسالها إلى كيان الرد.
Scheduled​Enqueue​Time​Utc بالنسبة للرسائل التي يتم إتاحتها فقط للاسترجاع بعد تأخير، تحدد هذه الخاصية لحظة التوقيت العالمي المتفق عليه (UTC) التي سيتم فيها إدراج الرسالة في قائمة الانتظار منطقياً، وتسلسلها، وبالتالي إتاحتها للاسترداد.
Sequence​Number الرقم التسلسلي هو عدد صحيح فريد من نوعه 64 بت يتم تعيينه للرسالة؛ حيث يتم قبولها وتخزينها بواسطة الوسيط ويعمل كمعرف حقيقي لها. بالنسبة للكيانات المقسمة، تعكس أعلى 16 بت معرف القسم. تتزايد أرقام التسلسل بشكل رتيب وتكون بلا فجوات. تتدحرج إلى 0 عندما يتم استنفاد نطاق 48-64 بت. هذه الخاصية للقراءة فقط.
Session​Id (group-id) بالنسبة للكيانات المدركة للجلسة، تحدد هذه القيمة المعرفة من قِبل التطبيق ارتباط الجلسة للرسالة. تخضع الرسائل التي لها نفس معرف الجلسة لقفل ملخص وتمكين المعالجة الدقيقة بالترتيب وإزالة تعدد الإرسال. بالنسبة للكيانات غير المدركة للجلسة، يتم تجاهل هذه القيمة.
Time​To​Live هذه القيمة هي المدة النسبية التي تنتهي بعدها الرسالة، بدءاً من لحظة قبول الوسيط لها وتخزينها، كما تم التقاطها في EnqueueTimeUtc. عند عدم تعيينها بشكل صريح، تكون القيمة المفترضة هي DefaultTimeToLive لقائمة الانتظار أو الموضوع المعنيّ. لا يمكن أن تكون قيمة TimeToLive على مستوى الرسالة أطول من إعداد DefaultTimeToLive للكيان. إذا كان أطول، يتم ضبطه بصمت.
To (to) هذه الخاصية محجوزة للاستخدام المستقبلي في سيناريوهات التوجيه ويتم تجاهلها حالياً بواسطة الوسيط نفسه. يمكن للتطبيقات استخدام هذه القيمة في سيناريوهات التسلسل التلقائي المستندة إلى القواعد للإشارة إلى الوجهة المنطقية المقصودة للرسالة.
Via​Partition​Key إذا تم إرسال رسالة عبر قائمة انتظار النقل في نطاق المعاملة، فإن هذه القيمة تحدد قسم قائمة انتظار النقل.

يتيح نموذج الرسالة المجرد إرسال رسالة إلى قائمة انتظار عبر HTTPS ويمكن استردادها عبر AMQP. في كلتا الحالتين، تبدو الرسالة طبيعية في سياق البروتوكول المعني. يتم ترجمة خصائص الوسيط حسب الحاجة، ويتم تعيين خصائص المستخدم إلى الموقع الأكثر ملاءمة على نموذج رسالة البروتوكول المعنيّ. في HTTP، يتم تعيين خصائص المستخدم مباشرة من وإلى رؤوس HTTP؛ في AMQP يقومون بتعيين من application-properties وإلى الخريطة.

توجيه الرسائل والارتباط

يتم استخدام مجموعة فرعية من خصائص الوسيط الموضحة سابقا، To وReplyTo وReplyToSessionId وMessageId وCorrelationId وSessionId وتحديدا لمساعدة التطبيقات على توجيه الرسائل إلى وجهات معينة. لتوضيح هذه الميزة، ضع في اعتبارك بعض الأنماط:

  • طلب/رد بسيط: يرسل الناشر رسالة إلى قائمة انتظار ويتوقع ردا من مستهلك الرسالة. لتلقي الرد، يمتلك الناشر قائمة انتظار يتوقع أن يتم تسليم الردود إليها. يتم التعبير عن عنوان قائمة الانتظار في الخاصية ReplyTo للرسالة الصادرة. عندما يستجيب المستهلك، فإنه ينسخ MessageId للرسالة التي تمت معالجتها في خاصية CorrelationId لرسالة الرد ويسلم الرسالة إلى الوجهة المشار إليها بواسطة ReplyTo خاصية. يمكن أن تسفر رسالة واحدة عن ردود متعددة، اعتمادا على سياق التطبيق.
  • طلب/رد الإرسال المتعدد: كتنوع للنمط السابق، يرسل الناشر الرسالة إلى موضوع ويصبح العديد من المشتركين مؤهلين لاستهلاك الرسالة. قد يستجيب كل مشترك هكذا بالصورة الموضحة سابقا. يستخدم هذا النمط في سيناريوهات الاكتشاف أو استدعاء الأسماء وعادة ما يعرف المستجيب نفسه مع خاصية مستخدم أو داخل الحمولة. إذا كان ReplyTo يشير إلى موضوع ما، فيمكن توزيع مثل هذه المجموعة من استجابات الاكتشاف على الجمهور.
  • تعدد الإرسال: تتيح ميزة الجلسة هذه مضاعفة تدفق الرسائل ذات الصلة من خلال قائمة انتظار واحدة أو اشتراك واحد بحيث يتم توجيه كل جلسة (أو مجموعة) من الرسائل ذات الصلة، والتي تم تحديدها من خلال مطابقة قيم SessionId إلى جهاز استقبال معين أثناء قيام جهاز الاستقبال بإغلاق الجلسة. اقرأ المزيد حول تفاصيل الجلسات هنا.
  • طلب/رد متعدد الرسائل/الرد: تتيح ميزة جلسة العمل هذه ردودا متعددة، مما يسمح للعديد من الناشرين بمشاركة قائمة انتظار الرد. من خلال تعيين ReplyToSessionId، يمكن للناشر إرشاد المستهلكين لنسخ تلك القيمة إلى خاصية SessionId لرسالة الرد. لا يلزم أن تكون قائمة انتظار النشر أو الموضوع مدركة للجلسة. أثناء إرسال الرسالة، يمكن للناشر أن ينتظر جلسة محددة مع SessionId المحدد حتى تتحقق في قائمة الانتظار عن طريق القبول المشروط لمستقبل الجلسة.

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

تسلسل الحمولة

عند النقل أو التخزين داخل ناقل خدمة Azure، الحمولة تكون دائمًا كتلة ثنائية مبهمة. خاصية ContentType تمكن التطبيقات لوصف الحمولة، مع تنسيق المقترح لقيم الخاصية هو وصف نوع محتوى MIME وفقا ل IETF RFC2045؛ على سبيل المثال، application/json;charset=utf-8.

بخلاف متغيرات Java أو .NET Standard، يدعم إصدار .NET Framework من Service Bus API إنشاء مثيلات BrokeredMessage عن طريق تمرير كائنات .NET عشوائية إلى المُنشئ.

في 30 سبتمبر 2026، سنتقاعد مكتبات SDK ناقل خدمة Azure WindowsAzure.ServiceBus وMicrosoft.Azure.ServiceBus و com.microsoft.azure.servicebus، والتي لا تتوافق مع إرشادات Azure SDK. سننهي أيضا دعم بروتوكول SBMP، لذلك لن تتمكن من استخدام هذا البروتوكول بعد 30 سبتمبر 2026. قم بالترحيل إلى أحدث مكتبات Azure SDK، والتي توفر تحديثات أمان هامة وقدرات محسنة، قبل ذلك التاريخ.

على الرغم من أنه لا يزال من الممكن استخدام المكتبات القديمة بعد 30 سبتمبر 2026، إلا أنها لن تتلقى بعد ذلك الدعم والتحديثات الرسمية من Microsoft. لمزيد من المعلومات، راجع إعلان إيقاف الدعم.

عند استخدام بروتوكول SBMP القديم، يتم بعد ذلك إجراء تسلسل لهذه الكائنات باستخدام جهاز التسلسل الثنائي الافتراضي، أو باستخدام جهاز تسلسلي يتم توفيره خارجياً. يتم إجراء تسلسل للعنصر في عنصر AMQP. يمكن استرداد المتلقي هذه الكائنات باستخدام طريقة GetBody\<T>() توفير النوع المتوقع. مع AMQP، يتم تسلسل الكائنات في رسم بياني AMQP ArrayListIDictionary<string,object> والكائنات، وأي عميل AMQP يمكن فك ترميزها.

في 30 سبتمبر 2026، سنتقاعد دعم بروتوكول SBMP ناقل خدمة Azure، لذلك لن تتمكن من استخدام هذا البروتوكول بعد 30 سبتمبر 2026. قم بالترحيل إلى أحدث مكتبات SDK ناقل خدمة Azure باستخدام بروتوكول AMQP، الذي يوفر تحديثات أمان مهمة وقدرات محسنة، قبل ذلك التاريخ.

لمزيد من المعلومات، راجع إعلان إيقاف الدعم.

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

تقبل متغيرات NET Standard. وJava API فقط مصفوفات البايت، ما يعني أن التطبيق يجب أن يتعامل مع التحكم في تسلسل العناصر.

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

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

لمعرفة المزيد حول رسائل ناقل الخدمة، راجع الموضوعات التالية: