سؤال

ما هي الدوافع لاستخدام النظام القائم على الرسائل؟

أرى الكثير عن حافلات الخدمة مثل nservicebus و النقل الجماعي وأنا أتساءل عن فوائد المنهجية الأساسية.

هل كانت مفيدة؟

المحلول

هناك مزايا متعددة لاستخدام الأنظمة القائمة على الرسائل.

  1. تشكل الرسائل واجهة محايدة تقنية محددة جيدًا بين التطبيقات.
  2. يتيح اقتران السائبة للتطبيقات.
  3. الكثير من الخيارات للأداء والضبط والتوسيع:
    • نشر الطالب وعملية الخدمة على أجهزة مختلفة
    • العديد من المطلبين يشاركون خادم واحد
    • العديد من المطلبين يشاركون خوادم متعددة
  4. تنفذ العديد من الأوساط المتوسطة الرسائل أنماط المراسلة الشائعة بشكل مستقل عن تطبيقك.
    • طلب الرد
    • النار وننسى التحديثات غير المتصلة بالإنترنت
    • نشر الاشتراك
  5. العديد من منتجات الوسيطة تتعامل مع تحويل الرسائل (على سبيل المثال Swift إلى SwiftXML).
  6. يمكن للعديد من منتجات الوسيطة أن تتحلل طلب واحد كبير في العديد من الطلبات الأصغر.
  7. انهم تقريبا جميع يدعمون منصات متعددة.

بالمناسبة ، فإن اثنين من قادة السوق في هذا المجال هما IBM مع WebSphere MQ والمنتجات ذات الصلة ، و Tibco مع حافلة خدمة المؤسسات.

نصائح أخرى

تقوم الهندسة المعمارية القائمة على الرسائل بإلغاء المنتجين والمستهلكين للرسائل ، في الوقت والمكان. هذا له الكثير من الفوائد:

  • يمكن للمنتجين والمستهلكين الركض على أجهزة مختلفة
  • يمكن للمنتجين والمستهلكين الركض في أوقات مختلفة.
  • يمكن للمنتجين والمستهلكين التشغيل على منصات أجهزة/برامج مختلفة (يحتاجون فقط إلى فهم بروتوكول الرسائل نفسه)
  • من السهل تنسيق العديد من المنتجين / المستهلكين (على سبيل المثال للوظائف المكثفة التي تحتاج إلى آلات متعددة ، كما وصف Dave Markle)
  • استقرار أعلى عندما تكون الخدمات غير مساورة مؤقتًا (على سبيل المثال عند إجراء معالجة الطلبات ، يمكن أن يساعد استخدام نظام المراسلة في تجنب "إسقاط" الطلبات)

تفقد معظم هذه الفوائد عندما تقوم بالاتصال على غرار RPC (أي عند حظره أثناء انتظار ردود الخدمة)

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

كان لديّ مشروعًا حيث اضطررت إلى القيام بالتكامل المركزية مع عدد من 3270 شاشة (كلها بطيئة). كان بإمكاني فتح 10 من هذه العمليات على مربع في وقت واحد. كان لدي آلاف الحسابات إلى نهر الشاشة والتحديث ، لذلك وضعت العمل في قائمة انتظار ، وآلات بلدي (كان لدي حوالي 3 من EM) التقطت عناصر العمل من قائمة انتظار الرسائل (MSMQ) وقمت بتسخين شاشاتها ، وأنه كان عليه. يمكنني بسهولة تدوير آلة جديدة ، أو إلغاء تنشيط الجهاز القديم دون مقاطعة تدفق العمل ، بحيث كان لطيفًا.

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

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

عادةً ما تحتوي بنيات تمرير الرسائل على نفس ميزات خدمات الويب ، لديك خدمات منفصلة يمكنك الاتصال بها ، يمكنك إضافة ميزات جديدة بسهولة.

لا أعتقد أن بنيات تمرير الرسائل تتطلب منتجات الوسيطة الرائعة (ومكلفة!) ، على الرغم من ذلك ، تعمل Windows على بنية مرسلة - كل رسالة WM_* التي تم تمريرها إلى نافذة هي .. حسناً ، رسالة ، وأعتقد أن هذا يعرض الأفضل مثال على الهندسة المعمارية - لا يحتاج أي جزء من النظام إلى معرفة أي جزء آخر ، يمكنك تمديده بلا حدود حيث يمكنك التعامل مع أكبر عدد ممكن من عناصر التحكم التي تريدها في أي مربع حوار ، إلخ ، إلخ.

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

النظام الموجهة للرسالة مفيد بشكل عام لبعض فئات مشاكل التكامل. هناك بدائل أخرى لديها متجر بيانات مشترك (ملف أو استند إلى ديسيبل ربما) للتطبيقات للتواصل مع التطبيقات التي تدمج عبر RPC.

تتمثل مزايا المراسلة على أنماط التكامل هذه في أنك لا تقترن كلا التطبيقين بمخطط مخزن البيانات نفسه ولا تربط تطبيقات سيناريو تكامل RPC للنقطة (التي تزداد تعقيدًا كلما زاد عدد التطبيقات).

هناك أيضًا فوائد الاتصال غير المتزامن (مثل البريد الإلكتروني مقابل الدردشة عبر الإنترنت) وإمكانيات توجيه الرسائل وتحويلها.

لقد ساعدت في تطوير نظام لنظام يستخدم C# و Remoting ، يمكن للعميل (خدمة أو واجهة المستخدم الرسومية) إرسال رسالة كاملة مع بعض البيانات المخصصة وسيحصل المستلم (المستلمون) ، إما عند الاتصال التالي أو على الفور). يمكنهم بعد ذلك معالجة الرسالة (عن طريق أخذ مالكيها في حالة خدمات التوازن). تم استخدامه أيضًا لتحديث واجهة المستخدم الرسومية عند انتهاء العمليات الطويلة.

يحتوي نظام المراسلة نفسه على خطوط أنابيب قابلة للتكوين معالجة كل رسالة ، وهنا بعض الأمثلة على عدد قليل من خطوط الأنابيب التي طورناها:

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

لذا ، رداً على سؤالك ، تعد أنظمة المراسلة وسيلة رائعة لإرسال معلومات حول عندما لا تعرف أو تهتم عميل من هو.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top