ما المقصود بالهيكلة المدفوعة بالأحداث (EDA)؟

الهيكلة المدفوعة بالأحداث (EDA) هي نمط تصميم حديث يتألف من خدمات صغيرة منفصلة تنشر الأحداث أو تستهلكها أو توجهها.

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

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

لماذا يُعد التصميم المنفصل مهمًا؟

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

تعمل إستراتيجية البيانات المنفصلة على تحسين التعامل مع الأعطال والمرونة، مما يساعد على تسريع الوقت اللازم للطرح بالأسواق (TTM) لميزات تطبيقك الجديد.

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

ما مزايا الهيكلة المدفوعة بالأحداث (EDA)؟

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

توسيع النطاق مع استقلاله في حالة الفشل

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

يمكن للهيكلة المدفوعة بالأحداث أن تسهِّل أيضًا تصميم أنظمة قريبة من الوقت الفعلي، ما يساعد المؤسسات في الابتعاد عن المعالجة القائمة على الدفعات. تُنشئ الأحداث عندما تتغير حالة التطبيق. مع توسُّع نطاق الأحداث، يتوسع نطاق الطبقة التي تعالج الأحداث هو الآخر.

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

المرونة في التطوير

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

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

بناء أنظمة قابلة للتوسيع

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

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

تقليل التعقيد

تمكِّن الخدمات المصغرة المطورين والمهندسين المصممين من تحليل مهام سير العمل المعقدة. على سبيل المثال، يمكنهم تقسيم تطبيق موحَّد للتجارة الإلكترونية إلى عمليات قبول ووعمليات دفع مع خدمات منفصلة للمخزون والتنفيذ والمحاسبة.

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

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

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

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

التدقيق بكل سهولة

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

تخفيض التكاليف

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

كيف تعمل الهيكلة المدفوعة بالأحداث (EDA)؟

فيما يلي مثال على الهيكلة المدفوعة بالأحداث (EDA) لموقع للتجارة الإلكترونية:

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

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

ما أنواع أعباء العمل المناسبة للهيكلة المدفوعة بالأحداث (EDA)؟

يمكن أن توفر عمليات الهيكلة المدفوعة بالأحداث (EDAs) طريقة فعالة لتلبية متطلبات أعباء العمل القابلة للتطوير بدرجة عالية والمتاحة بشكل كبير. تنطبق أيضًا EDA بشكل جيد على أعباء العمل ذات أنماط حركة المرور غير المتوقعة أو "الشائكة".

كيف تعمل الهيكلة المدفوعة بالأحداث (EDA) على تحسين التطبيقات؟

تعزِّز الهيكلة المدفوعة بالأحداث (EDA) الاقتران الحُر بين المكونات، وهو ما يجعلها طريقة جيدة لإنشاء تطبيقات حديثة وموزعة.

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

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

ما بعض حالات الاستخدام الشائع للهيكلة المدفوعة بالأحداث (EDA)؟

اتصالات الخدمات المصغرة للواجهات الخلفية للويب والهاتف المحمول

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

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

أتمتة سير عمل الأعمال

تتطلب العديد من مهام سير العمل، مثل معاملات الخدمات المالية، تكرار الخطوات نفسها. يمكنك بدء هذه الخطوات وأتمتتها باستخدام الهيكلة المدفوعة بالأحداث (EDA).

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

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

تكامل تطبيقات SaaS

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

أتمتة البنية التحتية

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

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

متى يجب استخدام عمليات الهيكلة المدفوعة بالأحداث (EDAs)؟

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

تكامل الأنظمة غير المتجانسة

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

استنساخ البيانات عبر المناطق وعبر الحسابات

يمكنك استخدام EDA لتنسيق الأنظمة بين الفِرق العاملة في مناطق وحسابات AWS المختلفة والمنتشرة عبرها. باستخدام جهاز توجيه الأحداث لنقل البيانات بين الأنظمة، يمكنك تطوير الخدمات وتوسيع نطاقها ونشرها بشكل مستقل عن الفِرق الأخرى.

مراقبة حالة الموارد والتنبيه بشأنها

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

الإخطارات والمعالجة المتوازية

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

ما الأنماط الشائعة للهيكلة المدفوعة بالأحداث (EDA)؟

وظائف قصيرة عديدة

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

المعالجة عند الطلب بدلاً من الدُفعات

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

في الهيكلة المدفوعة بالأحداث (EDA)، يمكن للمعالجة المخصصة الاستجابة لكل حدث. يسمح هذا للخدمة بتوسيع نطاق التزامن حسب الحاجة لمعالجة المعاملات في الوقت الفعلي تقريبًا.

التعافي من التعطل

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

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

ما بعض التحديات المتعلقة بالهيكلة المدفوعة بالأحداث (EDA)؟

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

زمن الاستجابة المتغير

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

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

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

الاتساق النهائي

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

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

يمكن أن يوفر DynamoDB قراءات متسقة للغاية، في زمن استجابة أعلى أحيانًا، ويمكنه أيضًا دعم المعاملات للمساعدة في الحفاظ على اتساق البيانات.

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

إرجاع القيم إلى المتصلين

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

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

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

إصلاح الأخطاء عبر الخدمات والوظائف

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

التكوين والتنسيق والإدارة المؤتمتة

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

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

ما خدمات AWS التي تستخدم هيكلة مدفوعة بالأحداث (EDA)؟

عادةً ما تنتج خدمات AWS الأحداث أو تستهلكها، وهو ما يُسهِّل إنشاء حلول ذات هيكلة مدفوعة بالأحداث (EDA).

بالإضافة إلى ذلك، تتضمن خدمات مثل Amazon EventBridge وAmazon SNS وAmazon SQS وAWS Step Functions ميزات تساعد العملاء على كتابة تعليمات برمجية نموذجية أقل وإنشاء EDAs بشكل أسرع.

Amazon EventBridge

يمكنك استخدام Amazon EventBridge لإنشاء حافلات الأحداث للتطبيقات المستندة إلى الأحداث على نطاق واسع باستخدام أحداث من تطبيقات SaaS أو خدمات AWS الأخرى أو تطبيقات مخصصة.

تطبق EventBridge قواعد لتوجيه الأحداث من مصادر الأحداث إلى أهداف مختلفة. يمكن أن تشمل الأهداف خدمات AWS مثل AWS Lambda وStep Functions وAmazon Kinesis أو أي نقطة نهاية HTTP عبر وجهات EventBridge API.

إن التكامل الشائع لحالات استخدام EDA هو Step Functions، حيث تُشغِّل الأحداث عمليات سير عمل محددة.

AWS Step Functions

AWS Step Functions تتضمن Workflow Studio، وهو مُصمِّم سير عمل مرئي منخفض التعليمات البرمجية يستخدمه المنشئون لتنظيم خدمات AWS المختلفة. يمكنك استخدام Workflow Studio لإنشاء التطبيقات الموزّعة، وأتمتة عمليات تكنولوجيا المعلومات والأعمال، وإنشاء البيانات ومسارات تعلم الآلة باستخدام خدمات AWS.

Amazon SNS

نوصي باستخدام خدمة الإشعارات البسيطة في Amazon (Amazon SNS) لإنشاء تطبيقات تتفاعل مع معدل النقل العالي وأحداث زمن الاستجابة المنخفض التي تنشرها التطبيقات الأخرى أو الخدمات المصغرة أو خدمات AWS. يمكنك أيضًا استخدام Amazon SNS للتطبيقات التي تحتاج إلى انتشار كبير للغاية للآلاف أو حتى الملايين من نقاط النهاية.

Amazon SQS

تقدم خدمة قوائم الانتظار البسيطة في Amazon (Amazon SQS) خدمة قائمة انتظار مُستضافة آمنة ودائمة ومتوفرة يمكنك استخدامها لدمج أنظمة ومكونات البرمجيات الموزّعة وفصلها. تقدم Amazon SQS تصميمات شائعة مثل طابور الرسائل الخامدة وعلامات تخصيص التكلفة.