سؤال

أحتاج إلى إنشاء خادم هوية مثل Microsoft's http://login.live.com.

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

لقد بدأت للتو في تعلم بنية حافلة الخدمة وما هو غير واضح بالنسبة لي هو كيفية التعامل مع سيناريو الفشل لحافلة الخدمة.

سؤال:

  1. إذا لم يكن خادم قاعدة البيانات متوفرًا ، فما الذي سيحدث مع الرسائل المنشورة؟
  2. هل سيتم تخزينها في مكان ما وأين؟
  3. هل أحتاج إلى آلة إضافية أو مجموعة للتعامل مع فشل حافلة الخدمة؟
  4. قرأت أنه يمكن استخدام SQL Server كمتجر للرسائل ولكن هل يمكنني استخدام MSMQ متين؟ أنا في طوابير الرسائل لأتمكن من كتابتها إلى قاعدة البيانات ، فلماذا أقوم بتخزينها إلى DB أولاً فقط لأخذها وكتابتها مرة أخرى؟ أو ، أشعر بهذا الخطأ ويستخدم DB فقط لقائمة الاشتراكات وليس للرسائل؟
هل كانت مفيدة؟

المحلول

  1. سيعتمد هذا على كيفية الإعداد ، ولكن في MassTransit يمكنك ترك الاشتراك نشطًا بحيث لا يزال يتم تسليم الرسالة إلى قائمة الانتظار الخاصة بـ DB. عندما يكون DB نشطًا مرة أخرى ، يمكنك قراءة الرسائل في قائمة الانتظار.

  2. كل خدمة متصلة بحافلة خدمة ، في MassTransit ، لديها قائمة انتظار نشطة لنفسها. سيتم تخزين الرسائل هناك.

  3. أعتقد أن هذا "يعتمد" ... لدى MassTransit دعمًا لـ MQS الأخرى من MSMQ ولكنه مبني حقًا حول MSMQ. ليس لدينا دعم كبير لأشياء مثل الفشل من MSMQ. ومع ذلك ، سيستمر كل شيء في العمل بدون خطأ إذا فشلت خدمة الاشتراك (أي الحافلة) - الخدمات تعرف بالفعل من الذي يجب التحدث إليه. إنه فقط عندما يكون التغيير في المستهلك (الاشتراك أو إلغاء الاشتراك) حيث يصبح هذا مشكلة. بالنسبة لي ، هذا حدث يحدث أبدًا تقريبًا.

  4. مع MassTransit ، نستخدم DB لتخزين حالات الاشتراك ولكن يتم تخزين جميع الرسائل في MSMQ.

إذا كنت ترغب في مزيد من التفاصيل في أحد هذه الردود أو لديك أسئلة إضافية حول MT ، فيمكنك الانضمام إلينا في القائمة البريدية: http://groups.google.com/group/masstransit-discuss.

نصائح أخرى

WHE تنفيذ هذا النوع من الهندسة المعمارية ، يجب أن تنظر في تطبيق مبادئ CQRS - الاستعلامات (هل هذا التحرير والسرد PWD صالح) لا ينبغي القيام به عبر الحافلة ؛ يتم إرسال الأوامر (تغيير PWD ، نسيت PWD) عبر الحافلة ، ولم يتم نشرها كأحداث. بينما من المحتمل أن تستخدم الأحداث داخليًا للحفاظ على جوانب الأمر والاستعلام في متزامنة ، فإن هذا لا يشمل العميل.

يمكن إجراء الاستعلامات باستخدام ADO.NET بسيطة مقابل قفص القراءة المتكررة من DB الخاص بك-ما يعرف بنموذج العرض المستمر في CQRs. إذا أردت ، يمكنك وضع بعض WCF بسيط أمام ذلك أيضًا.

عند استخدام MSMQ ، يتم تسليم جميع الرسائل عبر المتجر والجدوى. هذا يعني أنه تم تخزينه لأول مرة على العميل قبل تسليمه إلى الخادم ، لذلك إذا كان الخادم قد انخفض ، فإن الرسائل تجلس على العميل تنتظر. لتسامح الأخطاء ، سترغب في أن تكون رسائلك قابلة للاسترداد (مكتوبة إلى القرص) - هذا هو الافتراضي في NserviceBus ولكن ليس الافتراضي لـ MSMQ القياسي (لا أعرف عن MassTransit). لا تحتاج إلى قاعدة البيانات لهذا الغرض.

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

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