منذ عام 2019، أصدرت روسيا قانونًا بشأن وضع العلامات الإلزامية. لا ينطبق القانون على جميع مجموعات السلع، وتختلف مواعيد دخول العلامات الإلزامية لمجموعات المنتجات حيز التنفيذ. وسيكون التبغ والأحذية والأدوية أول من سيخضع للملصقات الإلزامية، وستتم إضافة منتجات أخرى لاحقًا، على سبيل المثال العطور والمنسوجات والحليب. دفع هذا الابتكار التشريعي إلى تطوير حلول جديدة لتكنولوجيا المعلومات من شأنها أن تجعل من الممكن تتبع سلسلة الحياة الكاملة للمنتج من الإنتاج إلى الشراء من قبل المستهلك النهائي، إلى جميع المشاركين في العملية: كل من الدولة نفسها وجميع المنظمات التي تبيع البضائع مع وضع العلامات الإلزامية.
في X5، يُطلق على النظام الذي سيتتبع البضائع المُصنفة ويتبادل البيانات مع الدولة والموردين اسم "ماركوس". دعنا نخبرك بالترتيب كيف ومن قام بتطويره، وما هي مجموعته التكنولوجية، ولماذا لدينا شيء نفخر به.
الحمولة العالية الحقيقية
يحل "ماركوس" العديد من المشاكل، أهمها هو التفاعل التكاملي بين أنظمة المعلومات X5 ونظام معلومات الدولة للمنتجات ذات العلامات (GIS MP) لتتبع حركة المنتجات ذات العلامات. تقوم المنصة أيضًا بتخزين جميع رموز التصنيف التي نتلقاها والتاريخ الكامل لحركة هذه الرموز عبر الكائنات، وتساعد في القضاء على إعادة تصنيف المنتجات ذات العلامات. وباستخدام مثال منتجات التبغ، التي تم تضمينها في المجموعات الأولى من السلع الموسومة، فإن حمولة شاحنة واحدة فقط من السجائر تحتوي على حوالي 600 ألف علبة، ولكل منها رمز فريد خاص بها. ومهمة نظامنا هي تتبع والتحقق من قانونية تحركات كل عبوة بين المستودعات والمخازن، والتحقق في نهاية المطاف من مقبولية بيعها للمشتري النهائي. ونحن نسجل حوالي 000 معاملة نقدية في الساعة، ونحتاج أيضًا إلى تسجيل كيفية وصول كل حزمة إلى المتجر. وبالتالي، مع الأخذ في الاعتبار جميع الحركات بين الأشياء، فإننا نتوقع عشرات المليارات من السجلات سنويًا.
فريق م
على الرغم من اعتبار ماركوس مشروعًا ضمن X5، إلا أنه يتم تنفيذه باستخدام نهج المنتج. يعمل الفريق وفقًا لـ Scrum. بدأ المشروع في الصيف الماضي، لكن النتائج الأولى لم تظهر إلا في أكتوبر - تم تجميع فريقنا بالكامل، وتم تطوير بنية النظام وشراء المعدات. يضم الفريق الآن 16 شخصًا، ستة منهم يشاركون في تطوير الواجهة الخلفية والواجهة الأمامية، وثلاثة منهم يشاركون في تحليل النظام. ويشارك ستة أشخاص آخرين في الاختبار اليدوي والتحميل والاختبار الآلي وصيانة المنتج. وبالإضافة إلى ذلك، لدينا متخصص SRE.
لا يقوم المطورون فقط بكتابة التعليمات البرمجية في فريقنا، بل يعرف جميع اللاعبين تقريبًا كيفية برمجة وكتابة الاختبارات التلقائية وتحميل البرامج النصية والبرامج النصية للتشغيل الآلي. نحن نولي اهتمامًا خاصًا لهذا الأمر، نظرًا لأن دعم المنتج يتطلب مستوى عالٍ من الأتمتة. نحاول دائمًا تقديم النصح والمساعدة للزملاء الذين لم يبرمجوا من قبل، ونعطيهم بعض المهام الصغيرة للعمل عليها.
بسبب جائحة فيروس كورونا، قمنا بنقل الفريق بأكمله إلى العمل عن بعد؛ إن توفر جميع الأدوات لإدارة التطوير، وسير العمل المدمج في Jira وGitLab جعل من الممكن اجتياز هذه المرحلة بسهولة. وأظهرت الأشهر التي قضاها الفريق عن بعد أن إنتاجية الفريق لم تتأثر نتيجة لذلك؛ فبالنسبة للكثيرين، زادت الراحة في العمل، وكان الشيء الوحيد المفقود هو التواصل وجهاً لوجه.
اجتماع الفريق عن بعد
الاجتماعات أثناء العمل عن بعد
كومة التكنولوجيا من الحل
المستودع القياسي وأداة CI/CD لـ X5 هو GitLab. نستخدمها لتخزين التعليمات البرمجية والاختبار المستمر والنشر لخوادم الاختبار والإنتاج. نستخدم أيضًا ممارسة مراجعة التعليمات البرمجية، عندما يحتاج زملاؤه على الأقل إلى الموافقة على التغييرات التي أجراها المطور على التعليمات البرمجية. يساعدنا محللو التعليمات البرمجية الثابتة SonarQube وJaCoCo في الحفاظ على نظافة التعليمات البرمجية الخاصة بنا وضمان المستوى المطلوب لتغطية اختبار الوحدة. يجب أن تمر جميع التغييرات التي يتم إجراؤها على الكود عبر عمليات التحقق هذه. جميع البرامج النصية للاختبار التي يتم تشغيلها يدويًا يتم تشغيلها تلقائيًا لاحقًا.
من أجل التنفيذ الناجح للعمليات التجارية بواسطة "ماركوس"، كان علينا حل عدد من المشكلات التكنولوجية، حول كل منها بالترتيب.
المهمة 1. الحاجة إلى قابلية التوسع الأفقي للنظام
لحل هذه المشكلة، اخترنا نهج الخدمات الصغيرة في الهندسة المعمارية. وفي الوقت نفسه، كان من المهم جدًا فهم مجالات مسؤولية الخدمات. حاولنا تقسيمها إلى عمليات تجارية، مع مراعاة تفاصيل العمليات. على سبيل المثال، القبول في المستودع ليس عملية متكررة للغاية، ولكنها عملية واسعة النطاق للغاية، حيث من الضروري الحصول بسرعة من الجهة التنظيمية للدولة على معلومات حول وحدات البضائع المقبولة، والتي يصل عددها في تسليم واحد إلى 600000 ، تحقق من مقبولية قبول هذا المنتج في المستودع وإرجاع جميع المعلومات اللازمة لنظام أتمتة المستودع. لكن الشحن من المستودعات له كثافة أكبر بكثير، ولكنه في نفس الوقت يعمل بكميات صغيرة من البيانات.
نقوم بتنفيذ جميع الخدمات على أساس عديم الحالة، بل ونحاول تقسيم العمليات الداخلية إلى خطوات، باستخدام ما نسميه موضوعات كافكا الذاتية. يحدث هذا عندما ترسل خدمة صغيرة رسالة إلى نفسها، مما يسمح لك بموازنة الحمل على العمليات الأكثر استهلاكًا للموارد وتبسيط صيانة المنتج، ولكن المزيد عن ذلك لاحقًا.
قررنا فصل وحدات التفاعل مع الأنظمة الخارجية إلى خدمات منفصلة. وقد جعل هذا من الممكن حل مشكلة واجهات برمجة التطبيقات (APIs) المتغيرة بشكل متكرر للأنظمة الخارجية، دون أي تأثير تقريبًا على الخدمات ذات وظائف الأعمال.
يتم نشر جميع الخدمات الصغيرة في مجموعة OpenShift، مما يحل مشكلة توسيع نطاق كل خدمة صغيرة ويسمح لنا بعدم استخدام أدوات اكتشاف الخدمة التابعة لجهات خارجية.
المهمة 2. الحاجة إلى الحفاظ على تبادل بيانات عالي التحميل ومكثف للغاية بين خدمات النظام الأساسي: وخلال مرحلة إطلاق المشروع وحدها، يتم تنفيذ حوالي 600 عملية في الثانية. نتوقع أن تزيد هذه القيمة إلى 5000 عملية في الثانية مع اتصال منافذ البيع بالتجزئة بمنصتنا.
تم حل هذه المشكلة عن طريق نشر مجموعة كافكا والتخلي بشكل شبه كامل عن التفاعل المتزامن بين الخدمات الصغيرة للمنصة. وهذا يتطلب تحليلًا دقيقًا جدًا لمتطلبات النظام، حيث لا يمكن أن تكون جميع العمليات غير متزامنة. وفي الوقت نفسه، لا ننقل الأحداث عبر الوسيط فحسب، بل ننقل أيضًا جميع معلومات العمل المطلوبة في الرسالة. وبالتالي، يمكن أن يصل حجم الرسالة إلى عدة مئات من الكيلوبايت. يتطلب حد حجم الرسالة في كافكا منا التنبؤ بدقة بحجم الرسالة، وإذا لزم الأمر، نقوم بتقسيمها، ولكن التقسيم منطقي، ويتعلق بالعمليات التجارية.
على سبيل المثال، نقوم بتقسيم البضائع التي تصل في السيارة إلى صناديق. بالنسبة للعمليات المتزامنة، يتم تخصيص خدمات صغيرة منفصلة ويتم إجراء اختبار حمل شامل. لقد قدم لنا استخدام كافكا تحديًا آخر - اختبار تشغيل خدمتنا مع الأخذ في الاعتبار تكامل كافكا مما يجعل جميع اختبارات وحدتنا غير متزامنة. لقد قمنا بحل هذه المشكلة عن طريق كتابة أساليب المساعدة الخاصة بنا باستخدام Embedded Kafka Broker. هذا لا يلغي الحاجة إلى كتابة اختبارات الوحدة للطرق الفردية، لكننا نفضل اختبار الحالات المعقدة باستخدام كافكا.
تم إيلاء الكثير من الاهتمام لتتبع السجلات حتى لا يتم فقدان معرف التتبع الخاص بها عند حدوث استثناءات أثناء تشغيل الخدمات أو عند العمل مع مجموعة كافكا. وإذا لم تكن هناك مشكلات خاصة في الحالة الأولى، ففي الحالة الثانية سنضطر إلى تسجيل جميع معرفات التتبع التي جاءت معها الدفعة واختيار واحدة لمواصلة التتبع. وبعد ذلك، عند البحث باستخدام معرف التتبع الأصلي، سيكتشف المستخدم بسهولة المكان الذي استمر به التتبع.
المهمة 3. الحاجة إلى تخزين كمية كبيرة من البيانات: يأتي أكثر من مليار ملصق سنويًا للتبغ وحده إلى X1. أنها تتطلب الوصول المستمر والسريع. في المجمل، يجب على النظام معالجة حوالي 5 مليار سجل لتاريخ حركة هذه البضائع الموسومة.
ولحل المشكلة الثالثة، تم اختيار قاعدة بيانات NoSQL MongoDB. لقد قمنا ببناء جزء من 5 عقد ولكل عقدة مجموعة متماثلة مكونة من 3 خوادم. يتيح لك ذلك توسيع نطاق النظام أفقيًا، وإضافة خوادم جديدة إلى المجموعة، والتأكد من تحمل الأخطاء. هنا واجهنا مشكلة أخرى - ضمان المعاملات في مجموعة مونغو، مع مراعاة استخدام الخدمات الصغيرة القابلة للتطوير أفقيا. على سبيل المثال، تتمثل إحدى مهام نظامنا في تحديد محاولات إعادة بيع المنتجات التي تحمل نفس رموز الملصقات. تظهر هنا تراكبات مع عمليات فحص خاطئة أو عمليات خاطئة بواسطة الصرافين. لقد وجدنا أن مثل هذه التكرارات يمكن أن تحدث داخل دفعة كافكا التي تتم معالجتها، وضمن دفعتين تتم معالجتها بالتوازي. وبالتالي، فإن التحقق من التكرارات عن طريق الاستعلام عن قاعدة البيانات لم يعط أي شيء. بالنسبة لكل خدمة صغيرة، قمنا بحل المشكلة بشكل منفصل بناءً على منطق الأعمال الخاص بهذه الخدمة. على سبيل المثال، بالنسبة للشيكات، أضفنا شيكًا داخل الدفعة ومعالجة منفصلة لظهور التكرارات عند الإدراج.
للتأكد من أن عمل المستخدمين مع سجل العمليات لا يؤثر بأي شكل من الأشكال على الشيء الأكثر أهمية - وهو أداء عمليات الأعمال لدينا، قمنا بفصل جميع البيانات التاريخية إلى خدمة منفصلة بقاعدة بيانات منفصلة، والتي تتلقى أيضًا المعلومات من خلال كافكا . بهذه الطريقة، يعمل المستخدمون مع خدمة معزولة دون التأثير على الخدمات التي تعالج البيانات للعمليات الجارية.
المهمة 4: إعادة معالجة قائمة الانتظار ومراقبتها:
في الأنظمة الموزعة، تنشأ حتما مشاكل وأخطاء في توفر قواعد البيانات، وقوائم الانتظار، ومصادر البيانات الخارجية. وفي حالة ماركوس، فإن مصدر هذه الأخطاء هو التكامل مع الأنظمة الخارجية. كان من الضروري إيجاد حل يسمح بالطلبات المتكررة للاستجابات الخاطئة مع انتهاء المهلة المحددة، ولكن في نفس الوقت عدم التوقف عن معالجة الطلبات الناجحة في قائمة الانتظار الرئيسية. ولهذا الغرض، تم اختيار ما يسمى بمفهوم "إعادة المحاولة على أساس الموضوع". لكل موضوع رئيسي، يتم إنشاء موضوع إعادة محاولة واحد أو أكثر يتم إرسال الرسائل الخاطئة إليه وفي نفس الوقت يتم التخلص من التأخير في معالجة الرسائل من الموضوع الرئيسي. مخطط التفاعل -
لتنفيذ مثل هذا المخطط، كنا بحاجة إلى ما يلي: دمج هذا الحل مع Spring وتجنب تكرار التعليمات البرمجية. أثناء تصفح الويب، صادفنا حلًا مشابهًا يعتمد على Spring BeanPostProccessor، لكنه بدا مرهقًا بلا داعٍ بالنسبة لنا. لقد ابتكر فريقنا حلاً أبسط يسمح لنا بالاندماج في دورة الربيع لإنشاء مستهلكين وإضافة مستهلكين إضافيين. لقد قدمنا نموذجًا أوليًا لحلنا لفريق الربيع، يمكنك رؤيته . يتم تكوين عدد إعادة المحاولة للمستهلكين وعدد المحاولات لكل مستهلك من خلال المعلمات، اعتمادًا على احتياجات عملية الأعمال، ولكي يعمل كل شيء، كل ما تبقى هو إضافة التعليق التوضيحي org.springframework.kafka.annotation.KafkaListener ، وهو أمر مألوف لدى جميع مطوري Spring.
إذا تعذرت معالجة الرسالة بعد كل محاولات إعادة المحاولة، فستنتقل إلى DLT (موضوع الرسالة الميتة) باستخدام Spring DeadLetterPublishingRecoverer. بناءً على طلب الدعم، قمنا بتوسيع هذه الوظيفة وإنشاء خدمة منفصلة تتيح لك عرض الرسائل المضمنة في DLT وstackTrace وtraceId وغيرها من المعلومات المفيدة عنها. بالإضافة إلى ذلك، تمت إضافة المراقبة والتنبيهات إلى جميع موضوعات DLT، والآن أصبح ظهور رسالة في موضوع DLT سببًا لتحليل الخلل وإصلاحه. إنه مناسب للغاية - من خلال اسم الموضوع، نفهم على الفور في أي خطوة من العملية نشأت المشكلة، مما يسرع بشكل كبير البحث عن السبب الجذري.
في الآونة الأخيرة، قمنا بتنفيذ واجهة تسمح لنا بإعادة إرسال الرسائل باستخدام دعمنا بعد إزالة أسبابها (على سبيل المثال، استعادة وظائف النظام الخارجي)، وبالطبع تحديد الخلل المقابل للتحليل. هذا هو المكان الذي تكون فيه موضوعاتنا الذاتية مفيدة: لكي لا تعيد تشغيل سلسلة معالجة طويلة، يمكنك إعادة تشغيلها من الخطوة المطلوبة.
تشغيل المنصة
المنصة قيد التشغيل الإنتاجي بالفعل، حيث نقوم كل يوم بتنفيذ عمليات التسليم والشحن، وربط مراكز التوزيع والمتاجر الجديدة. وكجزء من البرنامج التجريبي، يعمل النظام مع مجموعتي منتجات "التبغ" و"الأحذية".
يشارك فريقنا بأكمله في إجراء التجارب، ويحلل المشكلات الناشئة ويقدم اقتراحات لتحسين منتجنا، بدءًا من تحسين السجلات وحتى تغيير العمليات.
وحتى لا نكرر أخطائنا، فإن جميع الحالات التي تم اكتشافها أثناء التجربة تنعكس في الاختبارات الآلية. يتيح لك وجود عدد كبير من الاختبارات التلقائية واختبارات الوحدات إجراء اختبار الانحدار وتثبيت الإصلاح العاجل حرفيًا في غضون ساعات قليلة.
ونحن الآن نواصل تطوير وتحسين منصتنا، ونواجه تحديات جديدة باستمرار. إذا كنت مهتمًا، فسنتحدث عن حلولنا في المقالات التالية.
المصدر: www.habr.com