"راه رفتن با کفش هایم" - صبر کنید، آیا آنها علامت گذاری شده اند؟

از سال 2019، روسیه قانونی در مورد برچسب زدن اجباری دارد. این قانون شامل همه گروه‌های کالا نمی‌شود و تاریخ لازم‌الاجرا شدن برچسب‌گذاری اجباری برای گروه‌های کالایی متفاوت است. دخانیات، کفش ها و داروها اولین محصولاتی هستند که مشمول برچسب اجباری می شوند؛ محصولات دیگری مانند عطر، منسوجات و شیر بعداً به آن اضافه خواهند شد. این نوآوری قانونی باعث توسعه راه حل های جدید فناوری اطلاعات شد که امکان ردیابی کل زنجیره حیات یک محصول از تولید تا خرید توسط مصرف کننده نهایی را برای همه شرکت کنندگان در فرآیند فراهم می کند: هم خود دولت و هم همه سازمان های فروش کالا برچسب زدن اجباری

در X5، سیستمی که کالاهای دارای برچسب را ردیابی می کند و داده ها را با دولت و تامین کنندگان مبادله می کند "مارکوس" نامیده می شود. بیایید به ترتیب به شما بگوییم که چگونه و چه کسی آن را توسعه داده است، پشته فناوری آن چیست و چرا چیزی برای افتخار کردن داریم.

HighLoad واقعی

"مارکوس" بسیاری از مشکلات را حل می کند، یکی از اصلی ترین آنها تعامل یکپارچه بین سیستم های اطلاعاتی X5 و سیستم اطلاعات دولتی برای محصولات برچسب دار (GIS MP) برای ردیابی حرکت محصولات دارای برچسب است. این پلتفرم همچنین تمام کدهای برچسب‌گذاری دریافتی توسط ما و کل تاریخچه حرکت این کدها را در بین اشیا ذخیره می‌کند و به حذف درجه‌بندی مجدد محصولات برچسب‌گذاری شده کمک می‌کند. با استفاده از نمونه محصولات دخانی که در گروه اول کالاهای دارای برچسب قرار داشتند، تنها یک کامیون سیگار حاوی حدود 600 بسته است که هر کدام کد منحصر به فرد خود را دارند. و وظیفه سیستم ما ردیابی و تأیید قانونی بودن جابجایی هر بسته از این قبیل بین انبارها و فروشگاه ها و در نهایت تأیید صحت فروش آنها به خریدار نهایی است. و ما حدود 000 تراکنش نقدی در ساعت ثبت می کنیم و همچنین باید نحوه ورود هر بسته به فروشگاه را ثبت کنیم. بنابراین، با در نظر گرفتن تمام حرکات بین اجسام، انتظار داریم ده ها میلیارد رکورد در سال به ثبت برسد.

تیم M

علیرغم اینکه مارکوس پروژه ای در X5 محسوب می شود، با رویکرد محصول در حال اجراست. تیم بر اساس اسکرام کار می کند. این پروژه تابستان گذشته شروع شد، اما اولین نتایج فقط در ماه اکتبر به دست آمد - تیم ما به طور کامل مونتاژ شد، معماری سیستم توسعه یافت و تجهیزات خریداری شد. اکنون این تیم 16 نفر دارد که شش نفر از آنها در توسعه باطن و فرانت اند، سه نفر از آنها در تجزیه و تحلیل سیستم شرکت دارند. شش نفر دیگر درگیر تست دستی، بارگیری، خودکار و نگهداری محصول هستند. علاوه بر این، ما یک متخصص SRE داریم.

نه تنها توسعه‌دهندگان در تیم ما کد می‌نویسند، تقریباً همه بچه‌ها می‌دانند چگونه تست‌های خودکار را برنامه‌نویسی و بنویسند، اسکریپت‌ها را بارگذاری کنند و اسکریپت‌های خودکارسازی را بنویسند. ما به این امر توجه ویژه ای می کنیم، زیرا حتی پشتیبانی از محصول به سطح بالایی از اتوماسیون نیاز دارد. ما همیشه سعی می کنیم به همکارانی که قبلاً برنامه نویسی نکرده اند مشاوره و کمک کنیم و کارهای کوچکی را به آنها واگذار کنیم.

با توجه به همه‌گیری ویروس کرونا، ما کل تیم را به کار از راه دور منتقل کردیم؛ در دسترس بودن همه ابزارها برای مدیریت توسعه، گردش کار ساخته شده در Jira و GitLab باعث شد به راحتی از این مرحله عبور کنیم. ماه‌هایی که از راه دور سپری می‌شد نشان داد که در نتیجه بهره‌وری تیم لطمه نمی‌خورد؛ برای بسیاری، راحتی در کار افزایش یافت، تنها چیزی که از دست می‌رفت ارتباط زنده بود.

جلسه تیم از راه دور

جلسات در حین کار از راه دور

پشته فناوری راه حل

مخزن استاندارد و ابزار CI/CD برای X5 GitLab است. ما از آن برای ذخیره کد، آزمایش مداوم و استقرار برای آزمایش و تولید سرورها استفاده می کنیم. ما همچنین از تمرین بازبینی کد استفاده می کنیم، زمانی که حداقل 2 همکار نیاز به تایید تغییرات ایجاد شده توسط توسعه دهنده در کد دارند. تحلیلگرهای کد استاتیک SonarQube و JaCoCo به ما کمک می کنند تا کد خود را تمیز نگه داریم و از سطح مورد نیاز پوشش تست واحد اطمینان حاصل کنیم. تمام تغییرات در کد باید از طریق این بررسی ها انجام شود. تمام اسکریپت های آزمایشی که به صورت دستی اجرا می شوند، متعاقباً خودکار می شوند.

برای اجرای موفقیت آمیز فرآیندهای تجاری توسط "مارکوس"، ما مجبور شدیم تعدادی از مشکلات تکنولوژیکی را به ترتیب حل کنیم.

وظیفه 1. نیاز به مقیاس پذیری افقی سیستم

برای حل این مشکل، ما یک رویکرد میکروسرویس را برای معماری انتخاب کردیم. در عین حال، درک حوزه های مسئولیت خدمات بسیار مهم بود. ما سعی کردیم آنها را با در نظر گرفتن ویژگی های فرآیندها به عملیات تجاری تقسیم کنیم. به عنوان مثال، پذیرش در یک انبار یک عملیات بسیار مکرر نیست، بلکه در مقیاس بسیار بزرگ است، که طی آن لازم است اطلاعات مربوط به واحدهای کالای مورد پذیرش را که تعداد آنها در یک تحویل به 600000 می رسد، از رگولاتور دولتی به سرعت دریافت کنید. ، قابل قبول بودن پذیرش این کالا در انبار را بررسی کرده و کلیه اطلاعات لازم برای سیستم اتوماسیون انبار را برگردانید. اما حمل و نقل از انبارها دارای شدت بسیار بیشتری است، اما در عین حال با حجم کمی از داده ها عمل می کند.

ما همه خدمات را بر اساس بدون وضعیت اجرا می کنیم و حتی سعی می کنیم عملیات های داخلی را با استفاده از آنچه که خود موضوعات کافکا می نامیم به مراحل تقسیم کنیم. این زمانی است که یک میکروسرویس پیامی را به خود می‌فرستد، که به شما امکان می‌دهد تا بار را در عملیات‌های با منابع فشرده‌تر متعادل کنید و تعمیر و نگهداری محصول را ساده‌تر کنید، اما بعداً بیشتر در مورد آن صحبت خواهیم کرد.

ما تصمیم گرفتیم که ماژول ها را برای تعامل با سیستم های خارجی به سرویس های جداگانه جدا کنیم. این امکان حل مشکل تغییر مکرر APIهای سیستم های خارجی را بدون هیچ تاثیری بر خدمات با عملکرد تجاری فراهم کرد.

همه میکروسرویس‌ها در یک خوشه OpenShift مستقر شده‌اند، که هم مشکل مقیاس‌گذاری هر میکروسرویس را حل می‌کند و هم به ما امکان می‌دهد از ابزارهای سرویس کشف شخص ثالث استفاده نکنیم.

وظیفه 2. نیاز به حفظ بار بالا و تبادل داده بسیار فشرده بین خدمات پلت فرم: تنها در مرحله راه اندازی پروژه، حدود 600 عملیات در ثانیه انجام می شود. انتظار داریم این مقدار به 5000 عملیات در ثانیه افزایش یابد، زیرا خرده فروشی ها به پلتفرم ما متصل می شوند.

این مشکل با استقرار یک خوشه کافکا و کنار گذاشتن تقریباً کامل تعامل همزمان بین میکروسرویس‌های پلتفرم حل شد. این نیاز به تجزیه و تحلیل بسیار دقیق نیازهای سیستم دارد، زیرا همه عملیات نمی توانند ناهمزمان باشند. در عین حال، ما نه تنها رویدادها را از طریق کارگزار منتقل می کنیم، بلکه تمام اطلاعات تجاری مورد نیاز را در پیام منتقل می کنیم. بنابراین، اندازه پیام می تواند به چند صد کیلوبایت برسد. محدودیت اندازه پیام در کافکا ما را ملزم می کند که اندازه پیام را به طور دقیق پیش بینی کنیم و در صورت لزوم آنها را تقسیم کنیم، اما این تقسیم بندی منطقی است و مربوط به عملیات تجاری است.
به عنوان مثال، ما کالاهایی را که با ماشین می رسند به جعبه تقسیم می کنیم. برای عملیات سنکرون، میکروسرویس های جداگانه اختصاص داده شده و آزمایش بار کامل انجام می شود. استفاده از کافکا ما را با چالش دیگری روبرو کرد - آزمایش عملکرد سرویس ما با در نظر گرفتن ادغام کافکا باعث می‌شود همه تست‌های واحد ما ناهمزمان شوند. ما این مشکل را با نوشتن روش‌های کاربردی خودمان با استفاده از بروکر کافکای جاسازی شده حل کردیم. این کار نیازی به نوشتن تست های واحد برای روش های فردی را برطرف نمی کند، اما ما ترجیح می دهیم موارد پیچیده را با استفاده از کافکا آزمایش کنیم.

توجه زیادی به ردیابی لاگ‌ها صورت گرفت تا در هنگام استفاده از سرویس‌ها یا هنگام کار با دسته کافکا، TraceId آنها از بین نرود. و اگر مشکل خاصی در مورد اول وجود نداشت، در مورد دوم مجبور می شویم تمام TraceIdهایی را که دسته با آنها ارائه شده است ثبت کنیم و یکی را برای ادامه ردیابی انتخاب کنیم. سپس، هنگام جستجو بر اساس TraceId اصلی، کاربر به راحتی متوجه می شود که ردیابی با کدام یک ادامه یافته است.

وظیفه 3. نیاز به ذخیره حجم زیادی از داده ها: بیش از 1 میلیارد برچسب در سال فقط برای تنباکو به X5 می رسد. آنها نیاز به دسترسی مداوم و سریع دارند. در مجموع، این سیستم باید حدود 10 میلیارد رکورد از تاریخچه جابجایی این کالاهای دارای برچسب را پردازش کند.

برای حل مشکل سوم، پایگاه داده NoSQL MongoDB انتخاب شد. ما یک قطعه از 5 گره ساخته‌ایم و هر گره یک Replica Set از 3 سرور دارد. این به شما امکان می دهد سیستم را به صورت افقی مقیاس کنید، سرورهای جدیدی را به خوشه اضافه کنید و از تحمل خطای آن اطمینان حاصل کنید. در اینجا ما با مشکل دیگری مواجه شدیم - اطمینان از قابلیت تراکنش در خوشه مونگو، با در نظر گرفتن استفاده از میکروسرویس های مقیاس پذیر افقی. به عنوان مثال، یکی از وظایف سیستم ما شناسایی تلاش ها برای فروش مجدد محصولات با کدهای برچسب گذاری یکسان است. در اینجا، پوشش‌ها با اسکن‌های اشتباه یا عملیات اشتباه توسط صندوق‌داران ظاهر می‌شوند. ما دریافتیم که چنین تکراری می تواند هم در یک دسته کافکا در حال پردازش و هم در دو دسته که به طور موازی پردازش می شوند رخ دهد. بنابراین، بررسی موارد تکراری با پرس و جو از پایگاه داده چیزی به دست نیاورد. برای هر میکروسرویس به صورت جداگانه بر اساس منطق تجاری این سرویس مشکل را حل کردیم. به عنوان مثال، برای چک‌ها، یک چک درون دسته‌ای و پردازش جداگانه برای ظاهر موارد تکراری هنگام درج اضافه کردیم.

برای اطمینان از اینکه کار کاربران با سابقه عملیات به هیچ وجه بر مهمترین چیز تأثیر نمی گذارد - عملکرد فرآیندهای تجاری ما، ما تمام داده های تاریخی را در یک سرویس جداگانه با یک پایگاه داده جداگانه جدا کرده ایم که همچنین اطلاعات را از طریق کافکا دریافت می کند. . به این ترتیب، کاربران با یک سرویس ایزوله کار می کنند بدون اینکه بر سرویس هایی که داده ها را برای عملیات در حال پردازش پردازش می کنند تأثیر بگذارند.

وظیفه 4: پردازش مجدد صف و نظارت:

در سیستم های توزیع شده، مشکلات و خطاها ناگزیر در در دسترس بودن پایگاه های داده، صف ها و منابع داده خارجی به وجود می آیند. در مورد مارکوس، منشأ چنین خطاهایی ادغام با سیستم های خارجی است. لازم بود راه حلی پیدا شود که درخواست های مکرر برای پاسخ های اشتباه با مدت زمان مشخص شده را مجاز کند، اما در عین حال پردازش درخواست های موفق در صف اصلی را متوقف نکند. برای این منظور، مفهوم موسوم به "تحقیق مجدد بر اساس موضوع" انتخاب شد. برای هر موضوع اصلی، یک یا چند موضوع مجدد ایجاد می‌شود که پیام‌های اشتباه به آن ارسال می‌شود و در عین حال تاخیر در پردازش پیام‌ها از موضوع اصلی حذف می‌شود. طرح تعامل -

برای اجرای چنین طرحی به موارد زیر نیاز داشتیم: ادغام این راه حل با Spring و جلوگیری از تکرار کد. در حین گشت و گذار در وب، به راه حل مشابهی بر اساس Spring BeanPostProccessor برخوردیم، اما به نظر ما غیر ضروری به نظر می رسید. تیم ما راه‌حل ساده‌تری ایجاد کرده است که به ما امکان می‌دهد در چرخه بهار برای ایجاد مصرف‌کنندگان ادغام شده و به‌علاوه مجدداً مصرف‌کنندگان را اضافه کنیم. ما یک نمونه اولیه از راه حل خود را به تیم Spring ارائه کردیم، می توانید آن را ببینید اینجا. تعداد مصرف‌کنندگان مجدد و تعداد تلاش‌ها برای هر مصرف‌کننده، بسته به نیاز فرآیند کسب‌وکار، از طریق پارامترها پیکربندی می‌شوند، و برای اینکه همه چیز کار کند، تنها چیزی که باقی می‌ماند اضافه کردن حاشیه‌نویسی org.springframework.kafka.annotation.KafkaListener است. ، که برای همه توسعه دهندگان Spring آشناست.

اگر بعد از همه تلاش‌های مجدد، پیام پردازش نشد، با استفاده از Spring DeadLetterPublishingRecoverer به DLT (موضوع نامه مرده) می‌رود. به درخواست پشتیبانی، ما این قابلیت را گسترش دادیم و یک سرویس جداگانه ایجاد کردیم که به شما امکان می دهد پیام های موجود در DLT، stackTrace، traceId و سایر اطلاعات مفید در مورد آنها را مشاهده کنید. علاوه بر این، مانیتورینگ و هشدار به تمام موضوعات DLT اضافه شد و در واقع، ظاهر شدن یک پیام در یک تاپیک DLT دلیلی برای تجزیه و تحلیل و رفع نقص است. این بسیار راحت است - با نام موضوع، ما بلافاصله متوجه می شویم که مشکل در چه مرحله ای از فرآیند ایجاد شده است، که به طور قابل توجهی جستجو برای علت اصلی آن را سرعت می بخشد.

اخیراً، ما رابطی را پیاده‌سازی کرده‌ایم که به ما امکان می‌دهد پیام‌ها را با استفاده از پشتیبانی خود پس از از بین بردن علل آنها (به عنوان مثال، بازیابی عملکرد سیستم خارجی) و البته ایجاد نقص مربوطه برای تجزیه و تحلیل، دوباره ارسال کنیم. اینجاست که موضوعات خود ما مفید هستند: برای اینکه یک زنجیره پردازش طولانی را راه اندازی مجدد نکنید، می توانید آن را از مرحله دلخواه مجدداً راه اندازی کنید.

عملیات پلت فرم

این پلت فرم در حال حاضر در حال بهره برداری مولد است، ما هر روز تحویل و ارسال را انجام می دهیم، مراکز توزیع و فروشگاه های جدید را به هم متصل می کنیم. به عنوان بخشی از آزمایشی، این سیستم با گروه‌های محصول «تنباکو» و «کفش» کار می‌کند.

کل تیم ما در اجرای آزمایش‌ها شرکت می‌کند، مشکلات در حال ظهور را تجزیه و تحلیل می‌کند و برای بهبود محصولمان، از بهبود گزارش‌ها تا تغییر فرآیندها، پیشنهاداتی ارائه می‌کند.

برای اینکه اشتباهات خود را تکرار نکنیم، تمام مواردی که در خلبان یافت می شوند در تست های خودکار منعکس می شوند. وجود تعداد زیادی تست خودکار و تست واحد به شما این امکان را می دهد که آزمایش رگرسیون را انجام دهید و یک Hotfix را به معنای واقعی کلمه در عرض چند ساعت نصب کنید.

اکنون ما به توسعه و بهبود پلتفرم خود ادامه می دهیم و دائماً با چالش های جدیدی روبرو هستیم. اگر علاقه مند هستید، در مقالات بعدی در مورد راه حل های خود صحبت خواهیم کرد.

منبع: www.habr.com