استمرار المراسلة/خدمة الحافلة لفة بلدي أو مخاطر منحنى التعلم?

Question

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

أنا لا ترغب في استخدام MSMQ لأن ليس لدينا السيطرة على جميع أجهزة كمبيوتر العميل من أجل تثبيت/تكوين تأمين MSMQ بشكل صحيح ، لأن الدعم هو أكثر صعوبة بسبب نوعية الأدوات التحقيق في محتويات قوائم انتظار MSMQ.SQL Server 2005 Express على جميع الآلات و يستخدم في تخزين البيانات على التطبيق لدينا.

لدي حاليا إلى خيارين:

1. كتابة الأساسية إلى حد ما المستمرة رسالة الانتظار الذي يخزن الرسائل في الجدول بعد serialising لهم ، ثم يستخدم ThreadPool.QueueUserWorkItem أن يكون لهم معالجتها بواسطة معالجات تكوين ضد كل نوع الرسالة.كل ما في System.Transactions.TransactionScope حتى تتم إزالتها فقط من استمرار طابور إذا كانت معالجتها بنجاح.
2. استخدام NServiceBus (هذا هو خدمة الحافلات لقد ذهب مع الفريق حتى MassTransit الخ ليست خيارات) على العميل ، مع خدمة وسيط النقل التي تستخدم قاعدة البيانات المحلية.

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

هل من أحد لديه أي أفكار ؟

Answer 1

في النهاية كتبت الأساسية messagebus تكوين بلدي SqlTransport بحيث الرسائل تسلسل و حفظها في قاعدة بيانات SQL Server الجدول قبل الأحداث تطرح موضوع مستقل هو أشارت إلى معالجة الرسائل.

Answer 2

حسنا, أنا لا أعرف أن أقترح MSMQ ، ولكن سوف تشير إلى أن هناك الكثير من الحالات حافة للتفكير 'لفة الخاص بك'.

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

سوف تحتاج أيضا إلى التفكير في استمرار الرسائل ، والمدة التي يجب أن تكون موجودة, كيفية الكشف عن "قاتلة" عدم التسليم له ماذا تفعل في هذه الحالة.

هناك أيضا عدد من حافة المحتملة الحالات في سيناريوهات حيث التطبيق الخاص بك يذهب إلى أسفل في نفس الوقت كما انها الطوابير رسالة - على سبيل المثال, قد لا تحصل على الاعتراف بأن الرسالة في قائمة الانتظار ، على الرغم من أنه كان.نعم ، يمكنك ack انتظار إقرار ولكن يمكنك ما لا نهاية ندخل ack الدوائر...

لماذا ليس لديك التطبيق الكشف عن عندما يحصل اتصال وإرسال جميع البيانات في تلك المرحلة ؟

Answer 3

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

إذا كنت لفة الخاص بك يعتمد أيضا على المهارات التي لديك في المنزل و سوف يكون في المستقبل للحفاظ على الحل.

وهناك اعتبار آخر هو في نهاية المطاف على نطاق المنظومة وانها متطلبات الموثوقية.هل في حل نطاق واسع بما فيه الكفاية?

لدينا الند للند رسالة الحافلة ، Zebus ، على أساس ZeroMq (النقل) ، كاساندرا (نظير اكتشاف والمثابرة) و Protobuf (التسلسل).

1. أي عميل نشر على العميل انها مجرد مكتبة
2. رسالة الثبات باستخدام كاساندرا وكذلك مقابض مختلفة كثيرة حافة الحالات (هذا هو اختبار بانتظام في بيئة الإنتاج)
3. انه يؤدي جيدا و كما انها brokerless الحل لا يوجد أداء واحد عنق الزجاجة
4. لا توجد نقطة واحدة من الفشل الدليل يمكن استخدامه مع البيانات المتاحة تخزين مثل كاسندرا

فهو مفتوح المصدر و الإنتاج اختبار https://github.com/Abc-Arbitrage/Zebus