له 2019 راهیسې ، روسیه د لازمي لیبل کولو قانون لري. قانون د توکو په ټولو ګروپونو کې نه پلي کیږي، او د محصول ګروپونو لپاره د اجباري لیبل کولو ځواک ته د ننوتلو نیټې توپیر لري. تمباکو، بوټان او درمل به لومړی د لازمي لیبل کولو تابع وي؛ نور محصولات به وروسته اضافه شي، د بیلګې په توګه، عطر، ټوکر، او شیدې. دې قانون جوړونې نوښت د نوي معلوماتي ټیکنالوژۍ حلونو پراختیا ته وهڅول چې دا به د دې امکان رامینځته کړي چې د محصول ټول ژوند سلسله د تولید څخه تر پیرود پورې د وروستي مصرف کونکي لخوا په پروسه کې ټولو برخه اخیستونکو ته تعقیب کړي: دواړه پخپله دولت او ټول هغه سازمانونه چې توکي پلوري. لازمي لیبل کول.
په X5 کې، هغه سیسټم چې لیبل شوي توکي تعقیبوي او د دولت او عرضه کونکو سره ډیټا تبادله کوي "مارکوس" نومیږي. راځئ چې تاسو ته په ترتیب سره ووایو چې دا څنګه او چا رامینځته کړی، د دې ټیکنالوژۍ سټیک څه دی، او ولې موږ یو څه لرو چې ویاړو.
ریښتیني لوړ بار
"مارکوس" ډیری ستونزې حل کوي، اصلي یې د X5 معلوماتو سیسټمونو او د لیبل شوي محصولاتو (GIS MP) لپاره د دولتي معلوماتو سیسټم ترمنځ د ادغام تعامل دی ترڅو د لیبل شوي محصولاتو حرکت تعقیب کړي. پلیټ فارم زموږ لخوا ترلاسه شوي ټول لیبلینګ کوډونه او د شیانو په اوږدو کې د دې کوډونو حرکت ټول تاریخ هم ذخیره کوي ، او د لیبل شوي محصولاتو بیا درجه بندي له مینځه وړلو کې مرسته کوي. د تمباکو محصولاتو مثال په کارولو سره، کوم چې د لیبل شوي توکو په لومړیو ګروپونو کې شامل شوي، یوازې د سګرټو یوه لارۍ شاوخوا 600 کڅوړې لري، چې هر یو یې خپل ځانګړی کوډ لري. او زموږ د سیسټم دنده دا ده چې د ګودامونو او پلورنځیو ترمینځ د هر ډول کڅوړو حرکتونو قانونيیت تعقیب او تصدیق کړي ، او په نهایت کې د پای پیرودونکي ته د دوی د پلور منل تایید کړي. او موږ په هر ساعت کې شاوخوا 000 نغدي راکړې ورکړې ثبت کوو، او موږ باید دا هم ثبت کړو چې دا ډول هر کڅوړه څنګه پلورنځي ته ورسیده. په دې توګه، د شیانو ترمنځ ټول حرکتونه په پام کې نیولو سره، موږ په کال کې د لسګونو ملیارد ریکارډونو تمه کوو.
ټیم ایم
د دې حقیقت سره سره چې مارکس په X5 کې یوه پروژه ګڼل کیږي، دا د محصول طریقې په کارولو سره پلي کیږي. ټیم د سکرم مطابق کار کوي. پروژه تیر دوبي پیل شوه ، مګر لومړۍ پایلې یوازې په اکتوبر کې راغلې - زموږ خپل ټیم په بشپړ ډول راټول شوی و ، د سیسټم جوړښت رامینځته شوی او تجهیزات پیرودل شوي. اوس ټیم 16 کسان لري، چې شپږ یې د شاته او مخکني پراختیا کې ښکیل دي، چې درې یې د سیسټم تحلیل کې ښکیل دي. شپږ نور خلک په لارښود، بار، اتوماتیک ازموینې، او د محصول ساتنه کې ښکیل دي. سربیره پردې، موږ د SRE متخصص لرو.
نه یوازې پراختیا کونکي زموږ په ټیم کې کوډ لیکي؛ نږدې ټول هلکان پوهیږي چې څنګه د اتوماتیک ازموینې ، بار سکریپټونو او اتومات سکریپټونو برنامې او لیکلو څرنګوالی. موږ دې ته ځانګړې پاملرنه کوو، ځکه چې حتی د محصول ملاتړ د لوړې کچې اتومات ته اړتیا لري. موږ تل هڅه کوو چې هغه همکارانو ته مشوره او مرسته وکړو چې مخکې یې پروګرام نه دی کړی، او دوی ته د کار کولو لپاره ځینې کوچني کارونه ورکړئ.
د کورونویرس ناروغۍ له امله ، موږ ټول ټیم لیرې کار ته لیږدول؛ د پراختیا مدیریت لپاره د ټولو وسیلو شتون ، په جیرا او ګیټ لیب کې رامینځته شوي کاري فلو دا امکان رامینځته کړی چې دا مرحله په اسانۍ سره تیر کړو. هغه میاشتې چې په لیرې توګه مصرف شوي وښودله چې د ټیم محصول د پایلې په توګه زیانمن شوی نه دی؛ د ډیری لپاره، په کار کې راحته زیاتوالی راغلی، یوازینی شی چې ورک شوی ژوندی اړیکه وه.
د لیرې ټیم غونډه
د لیرې کار په جریان کې ناستې
د حل ټیکنالوژۍ سټک
د X5 لپاره معیاري ذخیره او CI/CD وسیله GitLab دی. موږ دا د کوډ ذخیره کولو ، دوامداره ازموینې ، او ازموینې او تولید سرورونو لپاره ګمارلو لپاره کاروو. موږ د کوډ بیاکتنې تمرین هم کاروو، کله چې لږترلږه 2 همکاران اړتیا لري چې د پراختیا کونکي لخوا په کوډ کې شوي بدلونونه تصویب کړي. د جامد کوډ تحلیل کونکي سونار کیوب او JaCoCo موږ سره مرسته کوي چې زموږ کوډ پاک وساتو او د واحد ازموینې پوښښ اړین کچې ډاډ ترلاسه کړو. په کوډ کې ټول بدلونونه باید د دې چکونو له لارې تیر شي. ټول ټیسټ سکریپټونه چې په لاسي ډول پرمخ وړل کیږي وروسته اتومات کیږي.
د "مارکوس" لخوا د سوداګرۍ پروسې بریالي پلي کولو لپاره، موږ باید یو شمیر تخنیکي ستونزې حل کړو، د هر یو په اړه.
دنده 1. د سیسټم افقی پیمانه کولو اړتیا
د دې ستونزې د حل لپاره، موږ د معمارۍ لپاره د مایکرو سرویس طریقه غوره کړه. په ورته وخت کې، دا خورا مهم و چې د خدماتو مسؤلیت ساحې پوه شي. موږ هڅه وکړه چې دوی د پروسو مشخصاتو په پام کې نیولو سره په سوداګریزو عملیاتو کې وویشو. د مثال په توګه ، په ګودام کې منل خورا مکرر ندي ، مګر خورا لوی پیمانه عملیات دي ، چې په جریان کې دا اړینه ده چې ژر تر ژره د دولت تنظیم کونکي څخه د منل شوي توکو واحدونو په اړه معلومات ترلاسه کړي ، چې شمیر یې په یوه تحویل کې 600000 ته رسیږي. ، په ګودام کې د دې محصول منلو وړتیا چیک کړئ او د ګودام اتومات سیسټم لپاره ټول اړین معلومات بیرته ورکړئ. مګر د ګودامونو څخه بار وړل خورا لوی شدت لري ، مګر په ورته وخت کې د ډیټا کوچني مقدار سره کار کوي.
موږ ټول خدمتونه په بې ریاسته توګه پلي کوو او حتی هڅه کوو چې داخلي عملیات په مرحلو ویشو، د هغه څه په کارولو سره چې موږ د کافکا ځان موضوعات بولو. دا هغه وخت دی چې یو مایکروسافټ ځان ته یو پیغام لیږي، کوم چې تاسو ته اجازه درکوي چې د ډیرو سرچینو په اړه عملیاتونو بار توازن کړئ او د محصول ساتنه ساده کړي، مګر وروسته یې نور.
موږ پریکړه وکړه چې د بهرنیو سیسټمونو سره د تعامل لپاره ماډلونه په جلا خدماتو کې جلا کړو. دا د دې امکان رامینځته کړی چې د بهرني سیسټمونو د پرله پسې APIs بدلولو ستونزه حل کړي ، پرته له دې چې د سوداګرۍ فعالیت سره خدماتو باندې واقعیا هیڅ اغیزه ونلري.
ټول مایکرو خدمتونه په OpenShift کلستر کې ځای په ځای شوي، کوم چې د هر مایکرو خدماتو اندازه کولو دواړه ستونزې حل کوي او موږ ته اجازه راکوي چې د دریمې ډلې خدماتو کشف وسیلې ونه کاروو.
دنده 2. د پلیټ فارم خدماتو ترمینځ د لوړ بار او خورا ژور ډیټا تبادلې ساتلو اړتیا: یوازې د پروژې د پیل په مرحله کې، په هره ثانیه کې شاوخوا 600 عملیات ترسره کیږي. موږ تمه لرو چې دا ارزښت به 5000 ops/sec ته لوړ شي ځکه چې پرچون پلورونکي زموږ پلیټ فارم سره وصل دي.
دا ستونزه د کافکا کلستر په ځای پر ځای کولو او د پلیټ فارم د مایکرو خدماتو ترمنځ د همغږي تعامل په بشپړ ډول پریښودلو سره حل شوې. دا د سیسټم اړتیاو خورا محتاط تحلیل ته اړتیا لري، ځکه چې ټول عملیات نشي کولی غیر متناسب وي. په ورته وخت کې، موږ نه یوازې د بروکر له لارې پیښې لیږدوو، بلکې په پیغام کې ټول اړین سوداګریز معلومات هم لیږدوو. په دې توګه، د پیغام اندازه څو سوه کیلوبایټ ته رسیږي. په کافکا کې د پیغام اندازه محدودیت موږ ته اړتیا لري چې د پیغام اندازې په سمه توګه وړاندوینه وکړو، او که اړتیا وي، موږ یې ویشو، مګر ویش منطقي دی، د سوداګرۍ عملیاتو پورې اړه لري.
د مثال په توګه، موږ هغه توکي چې په موټر کې راځي په بکسونو ویشو. د همغږي عملیاتو لپاره، جلا مایکرو خدمتونه تخصیص شوي او د بار بشپړ ازموینه ترسره کیږي. د کافکا کارول موږ ته یو بل ننګونه وړاندې کړه - زموږ د خدماتو عملیات ازموینه د کافکا ادغام په پام کې نیولو سره زموږ ټول واحد ازموینې غیر متناسب کوي. موږ دا ستونزه د ایمبیډډ کافکا بروکر په کارولو سره زموږ د خپلو ګټورو میتودونو په لیکلو سره حل کړه. دا د انفرادي میتودونو لپاره د واحد ازموینې لیکلو اړتیا له مینځه وړي ، مګر موږ غوره کوو چې د کافکا په کارولو سره پیچلې قضیې و ازمو.
د لاګونو تعقیب کولو ته ډیره پاملرنه شوې ترڅو د دوی TraceId له لاسه ورنکړل شي کله چې د خدماتو عملیاتو پرمهال یا د کافکا بیچ سره کار کولو پرمهال استثناوې رامینځته شي. او که چیرې د لومړي سره کومه ځانګړې مسله شتون ونلري ، نو په دوهم حالت کې موږ مجبور یو چې ټول ټریس آیډونه ولګوو چې بست ورسره راغلی او د تعقیب دوام لپاره یو غوره کړئ. بیا، کله چې د اصلي TraceId لخوا لټون کول، کاروونکي به په اسانۍ سره معلومه کړي چې د کومې سره تعقیب دوام لري.
3 دنده. د ډیرو معلوماتو ذخیره کولو اړتیا: یوازې د تنباکو لپاره په کال کې له 1 ملیارد څخه ډیر لیبلونه X5 ته راځي. دوی دوامداره او چټک لاسرسي ته اړتیا لري. په مجموع کې، سیسټم باید د دې لیبل شوي توکو د حرکت تاریخ شاوخوا 10 ملیارد ریکارډونه پروسس کړي.
د دریمې ستونزې د حل لپاره، د NoSQL ډیټابیس MongoDB غوره شوی. موږ د 5 نوډونو شارډ جوړ کړی او هر نوډ د 3 سرورونو ریپلیکا سیټ لري. دا تاسو ته اجازه درکوي سیسټم په افقی ډول اندازه کړئ، په کلستر کې نوي سرورونه اضافه کړئ، او د هغې د غلطۍ زغم ډاډمن کړئ. دلته موږ له بلې ستونزې سره مخ شو - د مونګو کلستر کې د راکړې ورکړې ډاډمن کول، د افقی اندازې وړ مایکرو خدماتو کارولو په پام کې نیولو سره. د مثال په توګه، زموږ د سیسټم یوه دنده د ورته لیبل کولو کوډونو سره د محصولاتو بیا پلورلو هڅې پیژندل دي. دلته، پوښونه د غلط سکینونو یا د کیشیر لخوا غلط عملیات سره ښکاري. موږ وموندله چې دا ډول نقلونه د کافکا په یوه بسته کې چې پروسس کیږي دواړه واقع کیدی شي ، او په دوه برخو کې چې په موازي ډول پروسس کیږي. په دې توګه، د ډیټابیس د پوښتنې په واسطه د نقلونو لپاره چک کول هیڅ شی ندی ورکړی. د هر مایکرو خدمت لپاره، موږ د دې خدمت د سوداګرۍ منطق پراساس په جلا توګه ستونزه حل کړه. د مثال په توګه، د چکونو لپاره، موږ د بستې دننه یو چیک اضافه کړ او د ننوتلو په وخت کې د نقلونو څرګندیدو لپاره جلا پروسس کول.
د دې لپاره چې ډاډ ترلاسه شي چې د عملیاتو تاریخ سره د کاروونکو کار په هیڅ ډول خورا مهم شی باندې تاثیر نه کوي - زموږ د سوداګرۍ پروسو فعالیت ، موږ ټول تاریخي معلومات د جلا ډیټابیس سره په جلا خدمت کې جلا کړي ، کوم چې د کافکا له لارې معلومات هم ترلاسه کوي. . په دې توګه، کاروونکي د یو جلا خدمت سره کار کوي پرته له دې چې خدماتو اغیزه وکړي چې د روانو عملیاتو لپاره ډاټا پروسس کوي.
څلورمه دنده: د قطار بیا پروسس او څارنه:
په ویشل شوي سیسټمونو کې، ستونزې او خطاګانې په ناڅاپي ډول د ډیټابیسونو، کتارونو، او د بهرنیو معلوماتو سرچینو په شتون کې رامنځته کیږي. د مارکس په قضیه کې، د دې ډول غلطیتونو سرچینه د بهرنیو سیسټمونو سره یوځای کول دي. دا اړینه وه چې یو داسې حل ومومئ چې د ځینې ټاکل شوي وخت پای سره د غلط ځوابونو تکرار غوښتنو ته اجازه ورکړي، مګر په ورته وخت کې په اصلي کتار کې د بریالي غوښتنو پروسس کولو مخه ونیسئ. د دې هدف لپاره، د "موضوع پر بنسټ بیا هڅه" مفهوم غوره شو. د هرې اصلي موضوع لپاره، یو یا څو بیا تکرار شوي موضوعات رامینځته کیږي چې غلط پیغامونه لیږل کیږي او په ورته وخت کې د اصلي موضوع څخه د پیغامونو پروسس کولو کې ځنډ له منځه ځي. د تعامل سکیم -
د دې ډول سکیم پلي کولو لپاره، موږ لاندې اړتیاوو ته اړتیا لرو: د پسرلي سره دا حل یوځای کول او د کوډ نقل کولو څخه مخنیوی کول. د ویب سرف کولو پرمهال، موږ د پسرلي بین پوسټ پروسیسر پراساس ورته ورته حل سره مخ شو، مګر دا زموږ لپاره غیر ضروري ستونزمن ښکاري. زموږ ټیم یو ساده حل رامینځته کړی چې موږ ته اجازه راکوي د مصرف کونکي رامینځته کولو لپاره د پسرلي دورې کې مدغم شو او سربیره پردې د بیا هڅه کولو مصرف کونکي اضافه کړو. موږ د پسرلي ټیم ته زموږ د حل پروټوټایپ وړاندیز کړی ، تاسو یې لیدلی شئ . د بیاکتنې مصرف کونکو شمیر او د هر مصرف کونکي لپاره د هڅو شمیر د پیرامیټونو له لارې تنظیم شوي ، د سوداګرۍ پروسې اړتیاو پورې اړه لري ، او د هرڅه کار کولو لپاره ، ټول هغه څه چې پاتې دي د تشریح اضافه کول دي org.springframework.kafka.annotation.KafkaListener ، کوم چې د پسرلي ټولو پراختیا کونکو ته پیژندل کیږي.
که چیرې پیغام د ټولو بیا ځلي هڅو وروسته پروسس نشي، نو دا د پسرلي DeadLetterPublishingRecoverer په کارولو سره DLT (مړ لیک موضوع) ته ځي. د ملاتړ په غوښتنه، موږ دا فعالیت پراخ کړ او یو جلا خدمت مو جوړ کړ چې تاسو ته اجازه درکوي په DLT، StackTrace، TraceId او د دوی په اړه نور ګټور معلومات کې شامل پیغامونه وګورئ. برسېره پردې، د DLT ټولو موضوعاتو کې څارنه او خبرتیاوې اضافه شوي، او اوس، په حقیقت کې، د DLT موضوع کې د پیغام څرګندیدل د نیمګړتیا تحلیل او حل کولو یو دلیل دی. دا خورا اسانه دی - د موضوع په نوم ، موږ سمدلاسه پوهیږو چې د پروسې په کوم مرحله کې ستونزه رامینځته شوې ، کوم چې د دې اصلي لامل لټون د پام وړ ګړندی کوي.
په دې وروستیو کې، موږ یو انٹرفیس پلي کړی چې موږ ته اجازه راکوي چې د دوی د لاملونو له منځه وړلو وروسته زموږ د ملاتړ په کارولو سره پیغامونه بیرته واستوو (د مثال په توګه، د بهرني سیسټم فعالیت بحالول) او البته، د تحلیل لپاره ورته عیب رامینځته کول. دا هغه ځای دی چې زموږ د ځان موضوعات په لاس کې راځي: د دې لپاره چې د اوږدې پروسس کولو سلسله بیا پیل نه کړئ، تاسو کولی شئ دا د مطلوب ګام څخه بیا پیل کړئ.
د پلیټ فارم عملیات
پلیټ فارم لا دمخه په تولیدي عملیاتو کې دی ، هره ورځ موږ تحویلي او بار وړل ترسره کوو ، د توزیع نوي مرکزونه او پلورنځي وصل کوو. د پیلوټ د یوې برخې په توګه، سیسټم د "تنباکو" او "بوټو" محصول ګروپونو سره کار کوي.
زموږ ټوله ډله د پیلوټانو په ترسره کولو کې برخه اخلي، راڅرګندېدونکي ستونزې تحلیلوي او زموږ د محصول ښه کولو لپاره وړاندیزونه وړاندې کوي، د لاګونو ښه کولو څخه د پروسو بدلولو پورې.
د دې لپاره چې زموږ غلطي تکرار نشي، د پیلوټ په جریان کې موندل شوي ټولې قضیې په اتوماتیک ازموینو کې منعکس شوي. د لوی شمیر آټوټیسټونو او یونټ ازموینو شتون تاسو ته اجازه درکوي د ریګریشن ازموینې ترسره کړئ او په څو ساعتونو کې په لفظي ډول د هاټ فکس نصب کړئ.
اوس موږ خپل پلیټ فارم ته وده او وده ورکولو ته دوام ورکوو، او په دوامداره توګه د نویو ننګونو سره مخ یو. که تاسو علاقه لرئ ، موږ به په لاندې مقالو کې زموږ د حلونو په اړه وغږیږو.
سرچینه: www.habr.com