كيفية سد النظم ذات الفعالية ومصدرها (والتغلب على الغوريلا)

لديك نظام CQRS جديد لامع ، وهو "مكتمل ديف" ، وأنت على وشك البدء في اختبار التكامل. وتستيقظ الغوريلا التي يبلغ وزنها 800 رطل والتي كانت نائمة في الزاوية أثناء مناقشات مجالك.

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

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

مرحبا شباب! لا يمكنني الانتظار لمعرفة كيف يتكامل تطبيق RESTful للخدمة الصغيرة مع نظام ERP المفصل الذي يبلغ من العمر ثلاثين عامًا! آمل أن تكونوا مثل كوبول. (الصورة مجاملة من

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

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

التعامل مع النظم القديمة

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

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

يا رب حسن! بيرغ البيانات! لا تنتظر ، هذا مجرد فاتبرغ. أنا سعيد لأنني اخترت مهنة في الكود بدلاً من الصرف الصحي. (الصورة الائتمان: أسوشيتد برس)

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

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

تقترب التكامل

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

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

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

حل متشكك

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

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

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

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

تقوم بوابة الحالة هذه بتقييم الحالة مقارنة بالحالة الأخيرة المعروفة (كما يعرفها نظام الاشتراك).

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

السيدات والجراثيم ، المشترك المتشكك!

بعض المتطلبات

لاستخدام هذا النهج ، يحتاج نظام الاشتراك الخاص بك إلى:

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

يحتاج نظام تحديد الحدث الخاص بك إلى:

  1. توفير خدمة استعلام تمثل حالة النظام بشكل موثوق وتشمل جميع خصائص الحالة المطلوبة من قبل نظام الاشتراك
  2. قم بتوفير بيانات كافية في دفق الحدث لتحديد السجلات ذات الصلة في خدمة الاستعلام
  3. دعم "قائمة" أو غيرها من الاستعلام الدفعي من خدمة الاستعلام

يجب أن يتضمن المشترك المتشكك الذي تقوم بتطبيقه ما يلي:

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

يجوز للمشترك المتشكك أيضًا تنفيذ عملية الأعمال في نظام الاشتراك.

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

إذا قمت ببدء عمليات الأعمال هذه ، يجب عليك أيضًا تطبيق تأمين البوابة حتى لا تضاعف من بدء العملية في حالة حدوث حدث حدث أثناء عملية ETL.

نتائج إيجابية

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

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

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

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

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

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

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

افكار اخيرة

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

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

جوناثان هو المدير المساعد للعمارة والعمليات بقسم نظم المعلومات البحثية في جامعة كاليفورنيا. بعد حصوله على شهادة فيزياء من جامعة ستانفورد ، قضى أكثر من 10 سنوات في العمل في هندسة نظم المعلومات ، وتحسين العمليات التجارية القائمة على البيانات ، والإدارة التنظيمية. وهو أيضًا مؤسس Peach Pie Apps Workshop ، وهي شركة تركز على بناء حلول البيانات للمنظمات غير الربحية.