تاريخ هندسة Dodo IS: مسار المكتب الخلفي

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

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

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

سلسلة مقالات "ما هو طائر الدودو؟" تحدث عن:

1. متراصة مبكرة في Dodo IS (2011-2015). (في تَقَدم...)
2. مسار المكتب الخلفي: قواعد وحافلات منفصلة. (أنت هنا)
3. المسار الجانبي للعميل: الواجهة فوق القاعدة (2016-2017). (في تَقَدم...)
4. تاريخ الخدمات المصغرة الحقيقية. (2018-2019). (في تَقَدم...)
5. الانتهاء من نشر متراصة واستقرار العمارة. (في تَقَدم...)

إذا كنت مهتمًا بمعرفة شيء آخر - اكتب التعليقات.

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

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

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

في عام 2011 ، بدت هندسة Dodo IS كما يلي:

بحلول عام 2020 ، أصبح الأمر أكثر تعقيدًا قليلاً وأصبح مثل هذا:

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

المشاكل الأولى لعام 2016: لماذا يجب أن تترك الخدمات المتراصة

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

قاعدة بيانات MySql واحدة ، حيث كتبت جميع التطبيقات التي كانت موجودة في ذلك الوقت في Dodo IS سجلاتها. كانت العواقب:

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

كانت المشكلة هي وجود الكتلة نفسها. كانت العواقب:

• اصدارات مفردة ونادرة.
• صعوبة في التنمية المشتركة لعدد كبير من الناس.
• عدم القدرة على إدخال تقنيات جديدة وأطر عمل ومكتبات جديدة.

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

مسار المكتب الخلفي: قواعد وحافلات منفصلة

التنقل في الفصل

1. مخطط Monolith 2016
2. البدء في تفريغ Monolith: Auth and Tracker Separation
   
3. ماذا تفعل Auth؟
4. من أين تأتي الأحمال؟
5. تفريغ المصادقة
6. ماذا تفعل Tracker؟
7. من أين تأتي الأحمال؟
8. تفريغ المقتفي

مخطط Monolith 2016

فيما يلي الكتل الرئيسية لـ Dodo IS 2016 monolith ، وفيما يلي نسخة من مهامهم الرئيسية.

تسليم أمين الصندوق. المحاسبة عن السعاة ، وإصدار الأوامر إلى السعاة.
مركز التواصل. قبول الطلبات من خلال المشغل.
موقع. مواقعنا الإلكترونية (dodopizza.ru ، dodopizza.co.uk ، dodopizza.by ، إلخ).
المصادقة. خدمة التفويض والمصادقة للمكتب الخلفي.
تعقب. طلب تعقب في المطبخ. خدمة لتمييز حالات الجاهزية عند إعداد الطلب.
مكتب النقدية للمطعم. تلقي الطلبات في مطعم واجهات أمين الصندوق.
تصدير. تحميل التقارير في 1C للمحاسبة.
الإخطارات والفواتير. أوامر صوتية في المطبخ (على سبيل المثال ، "وصلت بيتزا جديدة") + طباعة الفاتورة للسعاة.
مدير التحول. واجهات عمل مدير الوردية: قائمة الطلبات ، الرسوم البيانية للأداء ، نقل الموظفين إلى الوردية.
مدير مكتب. واجهات عمل صاحب الامتياز والمدير: استقبال الموظفين ، تقارير عن عمل مطعم البيتزا.
لوحة نتائج المطعم. عرض القائمة على أجهزة التلفزيون في مطاعم البيتزا.
مسؤل. الإعدادات في مطعم بيتزا معين: القائمة ، والأسعار ، والمحاسبة ، والرموز الترويجية ، والعروض الترويجية ، ولافتات مواقع الويب ، إلخ.
الحساب الشخصي للموظف. جداول عمل الموظفين ، معلومات عن الموظفين.
مجلس تحفيز المطبخ. شاشة منفصلة معلقة بالمطبخ وتعرض سرعة ماكينات صنع البيتزا.
Communication. إرسال الرسائل القصيرة والبريد الإلكتروني.
ملف التخزين. خدمة خاصة لاستلام وإصدار الملفات الثابتة.

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

البدء في تفريغ Monolith: Auth and Tracker Separation

الخدمات الرئيسية التي سجلت بعد ذلك وقراءتها من قاعدة البيانات أكثر من غيرها:

1. المصادقة. خدمة التفويض والمصادقة للمكتب الخلفي.
2. تعقب. طلب تعقب في المطبخ. خدمة لتمييز حالات الجاهزية عند إعداد الطلب.

ماذا تفعل Auth؟

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

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

من أين تأتي الأحمال؟

ينتقل كل مستخدم مسجل الدخول من المكتب الخلفي إلى قاعدة البيانات ، إلى جدول المستخدم لكل طلب ، ويسحب المستخدم من خلال استعلام SQL ويتحقق مما إذا كان لديه الوصول والحقوق اللازمة لهذه الصفحة.

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

تفريغ المصادقة

يحتوي Auth على مجال معزول ، أي بيانات حول المستخدمين أو عمليات تسجيل الدخول أو الأجهزة التي تدخل الخدمة (في الوقت الحالي) وتبقى هناك. إذا احتاجهم شخص ما ، فسيذهب إلى هذه الخدمة للحصول على البيانات.

كانت. كان مخطط العمل الأصلي كما يلي:

أود أن أشرح قليلاً كيف يعمل:

1. يأتي الطلب من الخارج إلى الواجهة الخلفية (يوجد Asp.Net MVC) ، ويحضر معه ملف تعريف ارتباط الجلسة ، والذي يستخدم للحصول على بيانات الجلسة من Redis (1). إما أنه يحتوي على معلومات حول عمليات الوصول ، ومن ثم يكون الوصول إلى وحدة التحكم مفتوحًا (3,4،XNUMX) ، أو لا.
2. إذا لم يكن هناك وصول ، فأنت بحاجة إلى متابعة إجراء التفويض. هنا ، من أجل التبسيط ، يتم عرضه كجزء من المسار في نفس السمة ، على الرغم من أنه انتقال إلى صفحة تسجيل الدخول. في حالة وجود سيناريو إيجابي ، سنحصل على جلسة مكتملة بشكل صحيح وننتقل إلى Backoffice Controller.
3. إذا كانت هناك بيانات ، فأنت بحاجة إلى التحقق من ملاءمتها في قاعدة بيانات المستخدم. هل تغير دوره ، ألا يُسمح له بالاطلاع على الصفحة الآن؟ في هذه الحالة ، بعد تلقي الجلسة (1) ، تحتاج إلى الانتقال مباشرة إلى قاعدة البيانات والتحقق من وصول المستخدم باستخدام طبقة منطق المصادقة (2). بعد ذلك ، إما إلى صفحة تسجيل الدخول ، أو انتقل إلى وحدة التحكم. مثل هذا النظام البسيط ، لكنه ليس قياسيًا تمامًا.
4. إذا تم تمرير جميع الإجراءات ، فإننا نتخطى المزيد في المنطق في وحدات التحكم والطرق.

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

يصبح. لذلك فعلوا:

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

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

لماذا استغرق الانفصال وقتا طويلا؟
كانت هناك العديد من المشاكل على طول الطريق وأبطأتنا:

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

مخطط تسجيل الجهاز في مطعم بيتزا:

العمارة العامة بعد استخراج خدمة المصادقة والأجهزة:

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

ماذا تفعل Tracker؟

الآن حول الثانية من الخدمات المحملة. يقوم المتعقب بدور مزدوج:

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

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

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

هكذا تبدو شاشة الجهاز اللوحي في محطة المتتبع "Raskatka"

من أين تأتي الأحمال؟

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

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

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

كانت. كانت العمارة الأصلية:

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

تفريغ المقتفي

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

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

يبدو مخطط تغيير حالات الطلب كما يلي:

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

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

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

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

ترتيب المسار خطوة بخطوة
يبدأ مسار الطلب في إحدى خدمات مصدر الطلب. هنا أمين الصندوق للمطعم:

1. عند الخروج ، يكون الطلب جاهزًا تمامًا ، وقد حان الوقت لإرساله إلى المتعقب. يتم إلقاء الحدث الذي اشترك فيه المتعقب.
2. يقوم المتعقب ، بقبول طلب لنفسه ، بحفظه في قاعدة البيانات الخاصة به ، مما يجعل الحدث "تم قبول الطلب بواسطة المتتبع" وإرساله إلى RMQ.
3. هناك العديد من المتعاملين المشتركين بالفعل في ناقل الحدث لكل طلب. بالنسبة لنا ، من المهم إجراء التزامن مع قاعدة متجانسة.
4. يتلقى المعالج حدثًا ، ويختار منه البيانات المهمة له: في حالتنا ، هذه هي حالة الطلب "مقبول من قِبل المتتبع" ويقوم بتحديث كيان الطلب في قاعدة البيانات الرئيسية.

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

يمكن لجميع الخدمات الأخرى أيضًا الاشتراك في طلب الأحداث من المتعقب لاستخدامها لأنفسهم.

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

البنية النهائية بعد التغييرات في Auth و Tracker

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

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

آمل أن يكون التعرف على مسارنا مفيدًا وممتعًا. أواجه الآن خيارًا لأي جزء من نظام Dodo IS يجب وصفه في المقالة التالية: اكتب التعليقات أو التصويت.

يمكن للمستخدمين المسجلين فقط المشاركة في الاستطلاع. تسجيل الدخول، من فضلك.

ما هو الجزء من Dodo IS الذي تريد أن تعرف عنه في المقالة التالية؟

• 24,1%متراصة مبكرة في Dodo IS (2011-2015) 14

• 24,1%المشكلات الأولى وحلولها (2015-2016) 14

• 20,7%مسار جانب العميل: الواجهة فوق القاعدة (2016-2017) 12

• 36,2%تاريخ الخدمات المصغرة الحقيقية (2018-2019) 21

• 44,8%نشر متراصة كاملة واستقرار العمارة 26

• 29,3%حول خطط أخرى لتطوير النظام 17

• 19,0%لا أريد أن أعرف أي شيء عن Dodo IS11

صوت 58 مستخدمين. امتنع 6 مستخدما عن التصويت.

المصدر: www.habr.com