نمط توريد الحدث

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

السياق والمشكلة

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

نهج CRUD له بعض القيود:

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

• في المجال التعاوني مع العديد من المستخدمين المتزامنين، من المرجح أن تعارض تحديث البيانات لأن عمليات التحديث تحدث على عنصر واحد من البيانات.

• ما لم تكن هناك آلية تدقيق أخرى تسجل تفاصيل كل عملية في سجل منفصل، يتم فقدان المحفوظات.

حل

يحدد نمط Event Sourcing نهجاً للتعامل مع العمليات على البيانات التي تحركها سلسلة من الأحداث، يتم تسجيل كل منها في مخزن من نوع "إلحاق فقط". التعليمة البرمجية للتطبيق ترسل سلسلة من الأحداث التي تصف بشكل إلزامي كل إجراء حدث على البيانات إلى مخزن الأحداث، حيثما استمرت ودامت. يمثل كل حدث مجموعة من التغييرات على البيانات (مثل AddedItemToOrder).

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

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

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

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

يوفر نمط تحديد مصادر الأحداث المزايا التالية:

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

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

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

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

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

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

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

المسائل والاعتبارات

راع النقاط التالية عند تحديد كيفية تنفيذ هذا النمط:

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

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

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

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

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

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

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

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

موعد استخدام النمط

استخدم هذا النمط في السيناريوهات التالية:

• عندما تريد تسجيل الهدف أو الغرض أو السبب في البيانات. على سبيل المثال، يمكن تسجيل التغييرات التي تم إجراؤها على كيان العميل كسلسلة من أنواع الأحداث المحددة، مثل تم نقله إلى المنزلأو حساب مغلقأو متوفى.

• عندما يكون من الضروري تقليل حدوث تحديثات متضاربة للبيانات أو تجنبها تماماً.

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

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

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

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

• عند استخدامه مع CQRS، يكون التناسق النهائي مقبولا أثناء تحديث نموذج القراءة، أو يكون تأثير أداء إعادة ترطيب الكيانات والبيانات من دفق الحدث مقبولا.

قد لا يكون هذا النمط مفيدا في الحالات التالية:

• المجالات الصغيرة أو البسيطة، الأنظمة التي لديها القليل من منطق الأعمال أو ليس لديها أي منطق عمل، أو أنظمة غير محددة تعمل بشكل طبيعي وبشكل جيد مع آليات إدارة بيانات CRUD التقليدية.

• الأنظمة التي تتطلب الاتساق والتحديثات في الوقت الحقيقي لطرق عرض البيانات.

• الأنظمة التي تكون فيها مسارات التدقيق والمحفوظات والقدرات اللازمة للعودة إلى الحالة السابقة وإعادة تشغيل الإجراءات غير مطلوبة.

• الأنظمة التي لا يوجد فيها سوى تكرار منخفض للتحديثات المتعارضة للبيانات الأساسية. على سبيل المثال، الأنظمة التي تضيف البيانات في الغالب بدلاً من تحديثها.

تصميم حمل العمل

يجب على المهندس المعماري تقييم كيفية استخدام نمط مصادر الأحداث في تصميم حمل العمل الخاص بهم لمعالجة الأهداف والمبادئ التي تغطيها ركائز Azure Well-Architected Framework. على سبيل المثال:

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

مثال

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

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

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

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

تسلسل إجراءات حجز ترخيص جهاز كالتالي:

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

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

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

3. يستدعي معالج الأوامر طريقة كشفها نموذج المجال لإجراء الحجوزات.

4. يسجل المجمع SeatAvailability حدثاً يحتوي على عدد تراخيص الجهاز التي تم حجزها. في المرة التالية التي يطبق فيها التجميع الأحداث، سيتم استخدام جميع الحجوزات لحساب عدد تراخيص الجهاز المتبقية.

5. يقوم النظام بإلحاق الحدث الجديد بقائمة الأحداث في مخزن الأحداث.

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

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

يمكنك العثور على مزيد من المعلومات حول هذا المثال في مقدمة إلى مصادر الأحداث.

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

• عدم تطابق الممانعة العلائقية للعنصر

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

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

• مدونة مارتن فاولر:

  • مصادر الأحداث
  • لقطة لموقع ويب مطور البرمجيات مارتن فاولر حول تصميم بنية تطبيقات المؤسسات

الموارد ذات الصلة

قد تكون الأنماط والتوجيهات التالية ذات صلة أيضًا عند تنفيذ هذا النمط:

• نمط الفصل بين مسؤولية الأوامر والاستعلامات (CQRS). غالباً ما يعتمد مخزن الكتابة الذي يوفر المصدر الدائم للمعلومات لتطبيق CQRS على تنفيذ نمط مصادر الأحداث. يصف كيفية فصل العمليات التي تقرأ البيانات في تطبيق ما عن العمليات التي تقوم بتحديث البيانات باستخدام واجهات منفصلة.

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

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