حبر نړۍ بدلوي. موږ له یو کال راهیسې بلاګ کوو. شاوخوا شپږ میاشتې مخکې موږ د خابروسک اوسیدونکو څخه خورا منطقي نظر ترلاسه کړ: "دودو، تاسو هرچیرې وایاست چې تاسو خپل سیسټم لرئ. دا څه ډول نظام دی؟ او ولې د پیزایریا سلسله دې ته اړتیا لري؟"
موږ ناست او فکر وکړو او پوه شو چې تاسو سم یاست. موږ هڅه کوو چې هرڅه په خپلو ګوتو تشریح کړو، مګر دا په ټوټه ټوټه کې راځي او د سیسټم بشپړ توضیحات په هیڅ ځای کې نشته. په دې توګه د معلوماتو راټولولو، د لیکوالانو لټون او د Dodo IS په اړه د یو لړ مقالو لیکلو اوږد سفر پیل کړ. مخکې شه!
اعترافونه: له موږ سره د خپل نظر شریکولو لپاره مننه. د هغه څخه مننه، موږ په پای کې سیسټم تشریح کړ، یو ټیکنالوژیډر یې جوړ کړ، او ډیر ژر به زموږ د پروسو لوی توضیحات وړاندې کړي. له تا پرته به نور پنځه کاله همداسې ناست وای.
د مقالو لړۍ "دودو IS څه شی دی؟" په اړه وايي:
- په Dodo IS (2011-2015). (د پرمختګ په حال کې...)
- د دفتر شاته لاره: جلا اډې او بس. (تاسو دلته یاست)
- د پیرودونکي اړخ لاره: د بیس څخه مخ مخ (2016-2017). (د پرمختګ په حال کې...)
- د اصلي مایکرو خدماتو تاریخ. (2018-2019). (د پرمختګ په حال کې...)
- د معمارۍ د مونولیت او ثبات پای ته رسیدل. (د پرمختګ په حال کې...)
که تاسو د بل څه زده کولو لیوالتیا لرئ، په نظرونو کې ولیکئ.
د تاریخي توضیحاتو په اړه د لیکوال نظر
زه په منظمه توګه د نوي کارمندانو لپاره د "سیسټم معمارۍ" موضوع باندې غونډه لرم. موږ دې ته "د دوډو IS آرکیټیکچر تعارف" وایو او دا د نوي پراختیا کونکو لپاره د بورډ کولو پروسې برخه ده. زموږ د معمارۍ په اړه په یوه بڼه یا بل ډول خبرې کول، د هغې ځانګړتیاوو په اړه، ما د توضیحاتو لپاره یو ځانګړی تاریخي طریقه رامینځته کړه.
په دودیز ډول، موږ سیسټم ته د اجزاوو د یوې سیټ (تخنیکي یا لوړې کچې) په توګه ګورو، د سوداګرۍ ماډلونه چې یو بل سره اړیکه لري ترڅو یو هدف ترلاسه کړي. او پداسې حال کې چې دا ډول نظر د ډیزاین لپاره توجیه کیږي، دا په بشپړه توګه د تشریح او پوهیدو لپاره مناسب نه دی. څو لاملونه شتون لري:
- حقیقت د هغه څه څخه توپیر لري چې په کاغذ کې دي. هرڅه لکه څنګه چې پلان شوي کار نه کوي. او موږ علاقه لرو چې څنګه هرڅه واقعیا وګرځیدل او کار کوي.
- د معلوماتو دوامداره پریزنټشن. په حقیقت کې، تاسو کولی شئ په تاریخي ډول له پیل څخه اوسني حالت ته لاړ شئ.
- له ساده څخه پیچلې ته. نړیوال نه، مګر زموږ په قضیه کې دا دی. معمارۍ له ساده لارو څخه نورو پیچلو لارو ته لیږدول شوې. ډیری وختونه ، د پیچلتیا له لارې ، د پلي کولو سرعت او ثبات ستونزې ، او همدارنګه د غیر فعال اړتیاو لیست څخه لسګونه نور ملکیتونه ( د نورو اړتیاو سره د متضاد پیچلتیا په اړه ښه خبرې شوي).
په 2011 کې، د Dodo IS جوړښت داسې ښکاري:
په 2020 کې، دا یو څه نور پیچلي شو او د دې په څیر شو:
دا تکامل څنګه شو؟ ولې د سیسټم بیلابیلو برخو ته اړتیا ده؟ کومې معمارۍ پریکړې وشوې او ولې؟ راځئ چې د مقالو په دې لړۍ کې ومومئ.
د 2016 لومړۍ ستونزې: ولې خدمتونه باید د monolith پریږدي؟
د لړۍ لومړۍ مقالې به د هغو خدماتو په اړه وي چې لومړی یې د مونولیت څخه جلا وو. د دې لپاره چې تاسو په شرایطو کې واچوئ، زه به تاسو ته ووایم چې موږ د 2016 په پیل کې په سیسټم کې کومې ستونزې درلودې، چې موږ باید د خدماتو جلا کولو سره معامله وکړو.
یو واحد MySql ډیټابیس چې په هغه کې ټول غوښتنلیکونه چې په هغه وخت کې په Dodo IS کې موجود وو خپل ریکارډونه لیکلي. پایلې یې وې:
- دروند بار (د 85٪ غوښتنو لوستلو سره).
- اډه وده کوله. د دې له امله، لګښت او ملاتړ یوه مسله شوه.
- د ناکامۍ یو واحد ټکی. که چیرې ډیټابیس ته یو غوښتنلیک لیکل ناڅاپه په ډیر فعال ډول ترسره کول پیل کړي ، نو نورو غوښتنلیکونو اغیزه احساس کړه.
- په ذخیره کولو او پوښتنو کې بې کفایتي. ډیری وختونه ډاټا په یو جوړښت کې زیرمه شوي چې د ځینو سناریوګانو لپاره مناسب و مګر د نورو لپاره نه. شاخصونه ځینې عملیات چټکوي، مګر کولی شي نور ورو کړي.
- ځینې ستونزې د ډیټابیسونو لپاره په ګړندۍ توګه رامینځته شوي کیچونو او لوستلو نقلونو سره حل شوي (دا به په جلا مقاله کې بحث وشي) ، مګر دوی موږ ته یوازې وخت ترلاسه کولو اجازه راکړه او ستونزه یې په اساسي ډول حل نه کړه.
ستونزه پخپله د monolith شتون وه. پایلې یې وې:
- بې ساري او نادر ریلیزونه.
- ستونزه د لوی شمیر خلکو په همکارۍ پراختیا کې ده.
- د نوي ټیکنالوژۍ، نوي چوکاټونو او کتابتونونو په معرفي کولو کې پاتې راتلل.
د بیس او مونولیت ستونزې ډیری وختونه بیان شوي، د بیلګې په توګه، د 2018 په پیل کې د حادثو په شرایطو کې (, и )، نو زه به ډیر نه اوسیږم. اجازه راکړئ یوازې ووایم چې موږ غواړو د خدماتو پراختیا په وخت کې ډیر انعطاف ورکړو. تر ټولو لومړی، دا د هغو کسانو په اړه اندیښمن دي چې په ټول سیسټم کې تر ټولو ډیر بار شوي او ریښه وو - Auth او Tracker.
د شاته دفتر لاره: جلا اډې او بس
څپرکی نیویگیشن
د مونولیت 2016 سکیم
دلته د 2016 Dodo IS monolith اصلي بلاکونه دي، او یوازې لاندې د دوی اصلي دندو ماتول دي.
د تحویلي نغدو میز. د کوریرانو لپاره حساب ورکول، کوریرانو ته امر صادرول.
د تماس مرکز. د آپریټر له لارې امرونه منل.
وېبپاڼه. زموږ ویب پاڼې (dodopizza.ru، dodopizza.co.uk، dodopizza.by، او نور).
است. د بیک دفتر لپاره د اعتبار او تصدیق خدمت.
ټرکر. د پخلنځي امر تعقیبونکی. د امر چمتو کولو پرمهال د چمتووالي حالتونو نښه کولو لپاره خدمت.
د رستورانت د نغدو میز. په رستورانت کې امر اخیستل، کیشیر انٹرفیس.
د صادراتو د. د حساب ورکولو لپاره په 1C کې راپورونه پورته کول.
خبرتیاوې او رسیدونه. په پخلنځي کې غږیز حکمونه (د بیلګې په توګه، "نوی پیزا راغلی") + د کوریرانو لپاره د رسیدونو چاپ کول.
د شفټ مدیر. د شفټ مدیر د کار لپاره انٹرفیسونه: د امرونو لیست، د تولید چارټونه، کارمندان بدلونونو ته راوړي.
د دفتر مدیر. د فرنچائزونو او مدیرانو د کار لپاره انٹرفیس: د کارمندانو استقبال، د پیزایریا د کار په اړه راپورونه.
د رستورانت بورډ. په پیزیریا کې په تلویزیونونو کې مینو ښودل.
اډمین. د ځانګړي پیزیریا لپاره تنظیمات: مینو ، نرخونه ، حساب ورکول ، پروموشنل کوډونه ، ترویجونه ، د سایټ لپاره بینرونه ، او داسې نور.
د کارمند شخصي حساب. د کارمندانو کاري مهال ویش، د کارمندانو په اړه معلومات.
د پخلنځي هڅونې بورډ. یو جلا سکرین چې په پخلنځي کې ځړول کیږي او د پیزا جوړونکو سرعت څرګندوي.
د مخابراتو. ایس ایم ایس او بریښنالیک لیږل.
د فایل ذخیره. د جامد فایلونو ترلاسه کولو او صادرولو لپاره خپل خدمت.
د ستونزو د حل لپاره لومړنۍ هڅې زموږ سره مرسته وکړه، مګر دوی یوازې یو لنډمهاله مهلت وو. دوی د سیسټم حل نه و، نو دا روښانه وه چې د اډو سره باید یو څه ترسره شي. د مثال په توګه، عمومي ډیټابیس په څو نورو متخصصینو ویشئ.
موږ د مونولیت پورته کول پیل کوو: د سند او ټریکر جلا کول
اصلي خدمتونه چې بیا د نورو په پرتله ډیر د ډیټابیس څخه لیکلي او لوستل کیږي:
- سند د بیک دفتر لپاره د اعتبار او تصدیق خدمت.
- تعقیبونکی. د پخلنځي امر تعقیبونکی. د امر چمتو کولو پرمهال د چمتووالي حالتونو نښه کولو لپاره خدمت.
Auth څه کوي؟
Auth یو خدمت دی چې له لارې کاروونکي شاته دفتر ته ننوځي (د پیرودونکي اړخ کې جلا خپلواک ننوت شتون لري). دا په غوښتنه کې هم راجع کیږي ترڅو ډاډ ترلاسه شي چې د لاسرسي سم حقونه شتون لري او دا حقونه د وروستي ننوتلو راهیسې ندي بدل شوي. وسایل د هغې له لارې پیززیریا ته ننوځي.
د مثال په توګه ، موږ غواړو په تالار کې ځړول شوي تلویزیون کې د بشپړ شوي امرونو حالت سره یو نندارتون خلاص کړو. بیا موږ auth.dodopizza.ru پرانیزو، "د وسیلې په توګه ننوتل" غوره کړئ، یو کوډ ښکاري چې د شفټ مدیر کمپیوټر کې په ځانګړې پاڼه کې دننه کیدی شي، د وسیلې ډول (وسیلې) په ګوته کوي. تلویزیون به پخپله د خپل پیزیریا مطلوب انٹرفیس ته لاړ شي او هلته به د پیرودونکو نومونو ښودل پیل کړي چې فرمایشونه چمتو دي.
بارونه له کوم ځای څخه راځي؟
د بیک آفس هر ننوتل شوی کارونکی د هرې غوښتنې لپاره ډیټابیس ته ځي ، د کارونکي میز ته ، د sql پوښتنې له لارې کارونکي له هغه ځای څخه راوباسي او ګوري چې ایا هغه دې پاڼې ته اړین لاسرسی او حق لري.
هر وسیلې یوازې د وسیلې میز سره ورته کوي ، د دې رول او لاسرسي چیک کوي. ماسټر ډیټابیس ته ډیری غوښتنې پدې عملیاتو کې د عمومي ډیټابیس سرچینو بارولو او ضایع کیدو لامل کیږي.
د پورته کولو سند
Auth یو جلا ډومین لري، دا دی، د کاروونکو، ننوتلو یا وسیلو په اړه ډاټا خدمت ته ننوځي (اوس مهال راتلونکی) او هلته پاتې کیږي. که څوک ورته اړتیا ولري، هغه به د معلوماتو لپاره دې خدمت ته لاړ شي.
WAS. د کار جریان په پیل کې داسې و:
زه غواړم یو څه تشریح کړم چې دا څنګه کار کوي:
- یوه بهرنۍ غوښتنه شاته (Asp.Net MVC هلته) ته راځي ، د دې سره د سیشن کوکی راوړي ، کوم چې د ریډیس (1) څخه د سیشن ډیټا ترلاسه کولو لپاره کارول کیږي. دا یا د لاسرسي په اړه معلومات لري ، او بیا کنټرولر ته لاسرسی خلاص دی (3,4) ، یا نه.
- که چیرې لاسرسی شتون ونلري، تاسو اړتیا لرئ چې د جواز ورکولو پروسې ته لاړ شئ. دلته، د سادگي لپاره، دا په ورته ځانګړتیا کې د لارې د یوې برخې په توګه ښودل شوي، که څه هم دا د ننوتلو پاڼې ته لیږد دی. د مثبت سناریو په حالت کې ، موږ به په سمه توګه ډکه ناسته ترلاسه کړو او د بیک آفس کنټرولر ته لاړ شو.
- که چیرې معلومات شتون ولري ، نو تاسو اړتیا لرئ دا د کارونکي ډیټابیس کې د مطابقت لپاره چیک کړئ. ایا د هغه رول بدل شوی، ایا هغه ته اوس په پاڼه کې اجازه نه ورکول کیږي؟ پدې حالت کې ، د ناستې ترلاسه کولو وروسته (1) ، تاسو اړتیا لرئ مستقیم ډیټابیس ته لاړشئ او د تصدیق منطق پرت (2) په کارولو سره د کارونکي لاسرسی چیک کړئ. بیا، یا د ننوتلو پاڼې ته لاړ شئ یا کنټرولر ته لاړ شئ. دا یو ساده سیسټم دی، مګر په بشپړ ډول معیاري نه دی.
- که ټولې کړنلارې بشپړې شي، نو بیا موږ په کنټرولرونو او میتودونو کې منطق کې نور پریږدو.
د کارونکي ډیټا د نورو ټولو ډیټا څخه جلا شوې ، دا په جلا غړیتوب جدول کې زیرمه شوې ، د AuthService منطق پرت څخه افعال ممکن د API میتودونه شي. د ډومین حدود په روښانه ډول تعریف شوي: کاروونکي، د دوی رول، ډاټا ته لاسرسی، صادرول او د لاسرسي لغوه کول. هرڅه داسې ښکاري چې دا یو جلا خدمت ته لیږدول کیدی شي.
جوړ شو. دا هغه څه دي چې دوی یې وکړل:
دا طریقه یو شمیر ستونزې لري. د مثال په توګه، د پروسې دننه د میتود زنګ وهل د HTTP له لارې د بهرني خدمت زنګ وهلو سره ورته ندي. ځنډ، اعتبار، مالتړ، او د عملیاتو روڼتیا په بشپړه توګه توپیر لري. اندری موریفسکي په خپل راپور کې د دې ستونزو په اړه په تفصیل سره خبرې وکړې .
د تصدیق خدمت او د دې سره د وسیلې خدمت د بیک دفتر لپاره کارول کیږي ، دا د خدماتو او انٹرفیسونو لپاره چې په تولید کې کارول کیږي. د مراجعینو خدماتو لپاره تصدیق (لکه ویب پاڼه یا ګرځنده اپلیکیشن) د Auth کارولو پرته په جلا توګه پیښیږي. جلا کول شاوخوا یو کال وخت نیسي ، او اوس موږ بیا پدې موضوع کار کوو ، سیسټم نوي تصدیق خدماتو ته لیږدوو (د معیاري پروتوکولونو سره).
ولې جلا کیدل دومره وخت ونیو؟
په لاره کې ډیری ستونزې وې چې موږ یې ورو کړل:
- موږ غوښتل چې د هیواد ډیټابیسونو څخه د کاروونکو ، وسیلو او تصدیق په اړه ډیټا یو ته انتقال کړو. د دې کولو لپاره، موږ باید ټول میزونه او کارونې د int پیژندونکي څخه نړیوال UUId پیژندونکي ته انتقال کړو (موږ پدې وروستیو کې دا کوډ بیا کار کړی او د خلاصې سرچینې پروژه ). د کارونکي ډیټا ذخیره کول (ځکه چې دا شخصي معلومات دي) خپل محدودیتونه لري او د ځینو هیوادونو لپاره دا اړینه ده چې دا په جلا توګه ذخیره کړئ. مګر دلته باید د نړیوال کارونکي ID وي.
- په ډیټابیس کې ډیری میزونه د هغه کارونکي په اړه د پلټنې معلومات لري چې عملیات یې ترسره کړي. دا یو اضافي میکانیزم ته اړتیا لري ترڅو د دوام ډاډ ترلاسه کړي.
- د API خدماتو له رامینځته کیدو وروسته ، بل سیسټم ته د لیږد اوږده او تدریجي دوره وه. سویچونه باید د کاروونکو لپاره په بې ساري ډول پیښ شي او لاسي کار ته اړتیا لري.
په پیززیریا کې د وسیلې ثبتولو سکیم:
د سند او وسیلو خدمت جلا کولو وروسته عمومي جوړښت:
تبصره. د 2020 لپاره، موږ د Auth په نوې نسخه کار کوو، کوم چې د OAuth 2.0 واک ورکولو معیار پراساس دی. دا معیار خورا پیچلی دی ، مګر د پای څخه تر پای پورې تصدیق کولو خدمت رامینځته کولو لپاره ګټور دی. په مقاله کې "» موږ الیکسي چرنیایف هڅه وکړه چې د معیار په اړه د امکان تر حده په ساده او روښانه توګه خبرې وکړو ترڅو تاسو د مطالعې وخت خوندي کړئ.
ټریکر څه کوي؟
اوس د بار شوي خدماتو دوهم په اړه. تعقیبونکی دوه ګونی رول ترسره کوي:
- له یوې خوا ، د دې دنده دا ده چې په پخلنځي کې کارمندانو ته وښیې چې اوس مهال کوم امرونه په پرمختګ کې دي ، کوم محصولات اوس چمتو کولو ته اړتیا لري.
- له بلې خوا، په پخلنځي کې ټولې پروسې ډیجیټل کړئ.
کله چې یو نوی محصول (د مثال په توګه، پیزا) په ترتیب کې ښکاره شي، دا د "رولینګ" تعقیب سټیشن ته ځي. په دې سټیشن کې د پیزا جوړونکي شتون لري چې د اړتیا وړ اندازې یو بن اخلي او بیا یې راوباسي، وروسته یې د ټریکر ټابلیټ په نښه کوي چې هغه خپله دنده سرته رسولې او د ډوډ اډه بل سټیشن ته لیږدوي - "ډک کول" .
هلته، راتلونکی پیزا جوړونکی پیزا پورته کوي، بیا په ټابلیټ کې نښه کوي چې هغه خپله دنده بشپړه کړې او پیزا په تنور کې اچوي (دا هم یو جلا سټیشن دی چې په ټابلیټ کې نښه کولو ته اړتیا لري). دا ډول سیسټم له پیل څخه په دودو کې او د دودو داعش له پیل څخه شتون درلود. دا تاسو ته اجازه درکوي چې ټول عملیات په بشپړ ډول تعقیب او ډیجیټل کړئ. سربیره پردې ، ټریکر وړاندیز کوي چې څنګه یو ځانګړي محصول چمتو کړي ، هر ډول محصول د خپل تولیدي سکیمونو سره سم ترسره کوي ، د محصول لپاره د پخلی کولو غوره وخت ذخیره کوي ، او په محصول کې ټول عملیات تعقیبوي.
دا هغه څه دي چې د ټابلیټ سکرین د راسکاتکا ټریکر سټیشن کې ښکاري.
بارونه له کوم ځای څخه راځي؟
هر پیزیریا د تعقیب کونکي سره شاوخوا پنځه ټابلیټونه لري. په 2016 کې موږ له 100 څخه ډیر پیزاریا درلودل (او اوس له 600 څخه ډیر دي). هر ټابلیټونه په هرو 10 ثانیو کې بیک انډ ته غوښتنه کوي او د امر میز څخه ډاټا راټولوي (د پیرودونکي او پتې سره اړیکه) ، د ترتیب ترکیب (د محصول سره اړیکه او د مقدار شاخص) ، او د هڅونې میز (دا تعقیبوي. د فشار وخت). کله چې د پیزا جوړونکی په ټریکر کې محصول باندې کلیک کوي ، نو پدې ټولو جدولونو کې ریکارډونه تازه کیږي. د امر جدول عمومي دی؛ دا په ورته وخت کې داخلونه لري کله چې امر منل کیږي ، د سیسټم نورو برخو څخه تازه معلومات ، او ډیری لوستل ، د مثال په توګه ، په تلویزیون کې چې په پیزاریا کې ځړول کیږي او پیرودونکو ته چمتو شوي امرونه ښیې.
د بارونو سره د مبارزې په جریان کې ، کله چې هرڅه او هرڅوک زیرمه شوي او د ډیټابیس غیر متناسب نقل ته لیږدول شوي ، د ټریکر سره دا عملیات ماسټر ډیټابیس ته دوام ورکوي. دلته باید هیڅ ځنډ شتون ونلري، ډاټا باید تازه وي، د همغږۍ څخه بهر د منلو وړ ندي.
همچنان ، زموږ د خپلو میزونو او شاخصونو نشتوالي موږ ته اجازه نه راکوله چې زموږ د کارونې لپاره ځانګړي شوي پوښتنې ولیکو. د مثال په توګه، دا ممکن د ټریکر لپاره اغیزمن وي چې د دې د سپارښتنې میز کې د پیزاریا لپاره شاخص ولري. موږ تل د ټریکر ډیټابیس څخه د پیزیریا امرونه سکریپ کوو. په ورته وخت کې، د امر منلو لپاره، دا مهمه نده چې په کوم پیزاریا کې راځي، هغه څه چې خورا مهم دي دا دي چې کوم پیرودونکي دا امر کړی. دا پدې مانا ده چې د پیرودونکي په اړه یو شاخص ته اړتیا ده. دا د ټریکر لپاره هم اړین ندي چې د چاپ شوي رسید ID یا د آرډر په جدول کې د امر سره تړلي بونس پروموشنونه ذخیره کړي. زموږ د ټریکر خدمت د دې معلوماتو سره علاقه نلري. په یو عام واحد ډیټابیس کې، میزونه یوازې د ټولو کاروونکو ترمنځ جوړجاړی کیدی شي. دا یو له اصلي ستونزو څخه و.
WAS. په پیل کې جوړښت داسې و:
حتی په جلا جلا پروسو کې د جلا کیدو وروسته، د کوډ بیس ډیری برخه د مختلفو خدماتو لپاره عام پاتې شوه. د کنټرولرانو لاندې هرڅه متحد وو او په یوه ذخیره کې ژوند کاوه. د خدماتو عام میتودونه، ذخیره، او یو عام ډیټابیس چې عام میزونه لري کارول شوي.
د ټریکر پورته کول
د ټریکر سره اصلي ستونزه دا ده چې ډاټا باید د مختلف ډیټابیسونو ترمینځ همغږي شي. دا د اثار خدماتو ویش څخه اصلي توپیر هم دی؛ ترتیب او د هغې حالت بدلیدلی شي او باید په مختلفو خدماتو کې ښکاره شي.
موږ د رستورانت چیک آوټ کې سپارښتنې منو (دا یو خدمت دی)، دا په ډیټابیس کې د "منل شوي" حالت کې ساتل کیږي. له هغې وروسته، دا باید ټریکر ته لاړ شي، چیرې چې دا به خپل حالت څو ځله بدل کړي: د "پخلنځي" څخه "بیک شوي" ته. پدې حالت کې ، د کیشیر یا شفټ مدیر انٹرفیس څخه ځینې بهرني تاثیرات ممکن د امر سره پیښ شي. زه به په جدول کې د دوی توضیحاتو سره د ترتیب حالتونه ورکړم:
د امر حالت بدلولو سکیم داسې ښکاري:
حالتونه د مختلفو سیسټمونو ترمنځ بدلیږي. او دلته ټریکر وروستی سیسټم ندی په کوم کې چې ډیټا بند شوی وي. موږ په داسې حالت کې د جلا کولو لپاره ډیری ممکنه لارې لیدلي دي:
- موږ د امر ټولې کړنې په یوه خدمت کې متمرکز کوو. زموږ په قضیه کې، دا اختیار د امر پروسس کولو لپاره خورا ډیر خدمت ته اړتیا لري. که موږ هلته ودرېږو، نو موږ به د دویم مونولیت سره پای ته ورسوو. ستونزې به مو نه وي حل کړې.
- یو سیسټم بل ته زنګ وهي. دوهم انتخاب ډیر په زړه پوری دی. مګر د دې سره، د زنځیرونو زنځیرونه ممکن دي ()، د اجزاوو ارتباط لوړ دی، او اداره کول خورا ستونزمن دي.
- موږ پیښې تنظیم کوو، او هر خدمت د دې پیښو له لارې د بل سره تبادله کوي. د پایلې په توګه، دریم انتخاب غوره شو، چې له مخې یې ټول خدمتونه د یو بل سره د پیښو تبادله پیل کوي.
دا حقیقت چې موږ دریم اختیار غوره کړی دا پدې معنی وه چې ټریکر به خپل ډیټابیس ولري ، او په ترتیب کې د هر بدلون لپاره به پدې اړه یوه پیښه واستوي ، کوم چې نور خدمات به ګډون وکړي او کوم چې به په ماسټر ډیټابیس کې هم شامل شي. د دې کولو لپاره، موږ یو څه خدمت ته اړتیا لرو چې د خدماتو ترمنځ د پیغام رسولو ډاډ ترلاسه کړي.
تر هغه وخته، موږ لا دمخه په سټیک کې RabbitMQ درلود، له همدې امله د پیغام بروکر په توګه د کارولو وروستۍ پریکړه. ډیاګرام د رستورانت کیشیر څخه د ټریکر له لارې د امر لیږد ښیې ، چیرې چې دا د مدیر امرونو انٹرفیس کې خپل حالت او د هغې ښودنه بدلوي. جوړ شو:
ګام په ګام لاره ترتیب کړئ
د امر لاره د امر سرچینې خدماتو څخه یو کې پیل کیږي. دلته د رستورانت کیشیر دی:
- امر په چیک آوټ کې په بشپړ ډول چمتو دی ، او دا وخت دی چې دا ټریکر ته واستوي. هغه پیښه چې د ټریکر ګډون کوي غورځول کیږي.
- ټریکر، یو امر مني، دا په خپل ډیټابیس کې خوندي کوي، د "ټریکر لخوا منل شوی امر" پیښه جوړوي او RMQ ته یې لیږي.
- ډیری سمبالونکي دمخه د دودیز پیښې بس کې ګډون کوي. هغه څه چې زموږ لپاره مهم دي هغه هغه دي چې د واحد ډیټابیس سره همغږي کیږي.
- هینډلر پیښه ترلاسه کوي ، له هغې څخه هغه معلومات غوره کوي چې د دې لپاره مهم دي: زموږ په قضیه کې ، دا د امر حالت دی "د ټریکر لخوا منل شوی" او په اصلي ډیټابیس کې د دې امر اداره تازه کوي.
که څوک په ځانګړي ډول د واحد حکمونو جدول څخه امر ته اړتیا ولري ، نو دوی کولی شي له هغه ځایه هم ولولي. د مثال په توګه، دا هغه څه دي چې د شفټ مدیر کې د امر انٹرفیس ته اړتیا لري:
نور ټول خدمات هم کولی شي د ټریکر څخه د پیښو امر کولو لپاره ګډون وکړي ترڅو دوی د ځان لپاره وکاروي.
که د یو څه وخت وروسته یو امر تولید ته واستول شي، د هغې حالت لومړی په ډیټابیس (ټریکر ډیټابیس) کې بدلیږي، او بیا د "OrderInWork" پیښه سمدلاسه رامینځته کیږي. دا RMQ ته هم رسیږي، له هغه ځایه دا په یو واحد ډیټابیس کې همغږي کیږي او نورو خدماتو ته سپارل کیږي. ښايي په دې لاره کې بېلابېلې ستونزې موجودې وي؛ د هغوی په اړه نور جزیات د ژینیا پیشکوف په راپور کې موندلی شئ .
په سند او ټریکر کې د بدلونونو وروسته وروستی جوړښت
د لنډیز لپاره: په پیل کې، ما دا نظر درلود چې د Dodo IS سیسټم نهه کلن تاریخ په یوه مقاله کې بسته کړم. ما غوښتل چې په چټکۍ او ساده ډول د تکامل پړاوونو په اړه خبرې وکړم. په هرصورت، د موادو مطالعې ته ناست، ما پوهیده چې هر څه خورا پیچلي او په زړه پوري دي تر هغه چې ښکاري.
د داسې موادو د ګټو (یا د هغې نشتوالي) ته په پام سره، زه دې پایلې ته رسیدلی یم چې د پیښو بشپړ تاریخ، د پخوانیو پریکړو د توضیحاتو او تحلیلونو پرته دوامداره پرمختګ ناشونی دی.
زه امید لرم چې تاسو زموږ د سفر په اړه زده کړه ګټور او په زړه پوري ومومئ. اوس زه د دې انتخاب سره مخ یم چې د ډوډو IS سیسټم کومه برخه په راتلونکې مقاله کې تشریح کړم: په نظرونو کې ولیکئ یا رایه ورکړئ.
یوازې راجستر شوي کاروونکي کولی شي په سروې کې برخه واخلي. مهرباني وکړئ
تاسو به په راتلونکې مقاله کې د Dodo IS د کومې برخې په اړه زده کړه غواړئ؟
-
۸۵٪په Dodo IS (2011-2015) 14 کې ابتدايي monolith
-
۸۵٪لومړۍ ستونزې او د هغوی د حل لارې (2015-2016) 14
-
۸۵٪د پیرودونکي برخې لاره: د بیس څخه پورته مخ (2016-2017)12
-
۸۵٪د اصلي مایکرو خدماتو تاریخ (2018-2019) 21
-
۸۵٪د مونولیت د قطع کولو او د معمارۍ ثبات بشپړول 26
-
۸۵٪د سیسټم د پراختیا لپاره د نورو پلانونو په اړه 17
-
۸۵٪زه نه غواړم د Dodo IS11 په اړه څه پوه شم
58 کاروونکو رایه ورکړه. 6 کاروونکي منع شوي.
سرچینه: www.habr.com