كيفية استعادة حالة النظام في معمارية الميكروسيرفس الحدثية

في سياق معمارية الميكروسيرفس، تصميم مدفوع بالأحداث والرسائل يبدو أنه يكتسب شعبية متزايدة على نحو متزايد (انظر هنا وهنا لبعض الأمثلة، بالإضافة إلى العريضة التفاعلية – خصائص محرك الأحداث) بدلاً من آلية متزامنة (قائمة على REST على سبيل المثال).

بهذا السياق وتخيل نظام طلبات مبسط للغاية، كما هو موضح في الصورة أدناه:

وتدفق الرسائل التالي:

1. يتم تقديم الطلب من مصدر ما (ويب/محمول الخ.).
2. يقبل خدمة الطلبات الطلب وتنشر “CreateOrderEvent”.
3. يستجيب InventoryService لـ “CreateOrderEvent”، ويقوم ببعض العمليات المتعلقة بالمخزون وينشر “InventoryUpdatedEvent” عند انتهائه.
4. يستجيب خدمة الفاتورة لـ “InventoryUpdatedEvent”، وترسل فاتورة وتنشر “EmailInvoiceEvent”.

كل الخدمات متاحة ونقوم بمعالجة الطلبات بسعادة… الجميع سعيد. ثم، تنخفض خدمة المخزون لسبب ما 😬.

بناءً على أن الأحداث على الحافلة الحدثية تتدفق بطريقة “غير مانعة”. أي أن الرسائل تنشر إلى موضوع مركزي ولا تتراكم في طابور انتظار إذا لم يكن هناك خدمة تقرأ منه (ما أحاول توصيله هو حافلة أحداث حيث، إذا تم نشر الحدث على الحافلة، سيتم تدفقه “مباشرة” ولن يتم وضعه في قائمة انتظار – تجاهل ما هو نوع من منصة/تكنولوجيا الرسائل المستخدمة في هذه المرحلة). هذا يعني أنه إذا كانت خدمة المخزون غير متاحة لمدة 5 دقائق، فإن “CreateOrderEvent” التي تمر عبر الحافلة الحدثية خلال ذلك الوقت الآن “ضائعة” أو لا يراها خدمة المخزون لأنه في نظامنا المبسط لا يوجد نظام آخر مهتم بهذه الأحداث.

إذا فإن سؤالي هو: كيف يمكن لخدمة المخزون (والنظام ككل) استعادة الحالة بحيث لا يتم تفويت أو عدم معالجة أي طلبات؟

لضمان عدم تفويت أو عدم معالجة أي طلبات، يمكن لخدمة المخزون والنظام ككل اتباع بعض الإجراءات. إليك بعض الأفكار التي يمكن أن تساعد في هذا الصدد:

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

2. تخزين الحالة المؤقتة: يمكن للخدمة المخزون تخزين الحالة المؤقتة للطلبات التي لم تتم معالجتها بعد. يمكن استخدام قاعدة بيانات أو ذاكرة مؤقتة لهذا الغرض.

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

4. إستعادة الحالة من السجل: في حالة فقدان الرسائل، يمكن للنظام استعادة الحالة من سجل الأحداث (event log) إذا كان متاحًا. يتيح ذلك للنظام إعادة تشغيل معالجة الرسائل التي تم فقدها.

5. استخدام آلية تكرار المحاولة: يمكن تكوين الخدمات لمحاولة إعادة معالجة الرسائل التي لم تصل إلى الخدمة المخزون بعد عندما تصبح متاحة مرة أخرى.

بتطبيق هذه الإجراءات، يمكن للنظام الاستمرار في تعامل الطلبات بكفاءة حتى في حالة فشل مؤقت لإحدى الخدمات.