سلام، حبر! زه Artem Karamyshev، د سیسټم د ادارې ټیم مشر یم . موږ په تیر کال کې ډیری نوي محصولات پیل کړي دي. موږ غوښتل ډاډ ترلاسه کړو چې د API خدمتونه په اسانۍ سره د توزیع وړ، د غلطۍ زغمونکي، او د کاروونکي بار کې د چټک ودې لپاره چمتو دي. زموږ پلیټ فارم په OpenStack کې پلي شوی، او زه غواړم تاسو ته ووایم چې د نیمګړتیا زغمونکي سیسټم ترلاسه کولو لپاره موږ د کومې برخې غلطی زغم ستونزې حل کړې وې. زه فکر کوم دا به د هغو کسانو لپاره په زړه پوري وي څوک چې په OpenStack کې محصولات هم رامینځته کوي.
د پلیټ فارم عمومي غلطی زغم د دې اجزاو انعطاف څخه جوړ دی. نو موږ به په تدریجي ډول د ټولو کچو څخه تیر شو چیرې چې موږ خطرونه پیژندلي او وتړل.
د دې کیسې ویډیو نسخه ، چې لومړنۍ سرچینه یې د اپټایم ورځې 4 کنفرانس کې راپور و ، لخوا تنظیم شوی ، تاسو لیدلی شئ .
د فزیکي جوړښت مقاومت
د MCS کلاوډ عامه برخه اوس په دوه ټایر III ډیټا مرکزونو کې میشته ده ، د دوی په مینځ کې خپل تیاره فایبر شتون لري ، په فزیکي کچه د مختلف لارو لخوا ساتل شوی ، د 200 Gbit/s له لارې پټې سره. دریمه درجه د فزیکي زیربنا لپاره د غلطۍ زغم اړین کچه چمتو کوي.
تیاره فایبر په دواړو فزیکي او منطقي کچو کې ساتل کیږي. د چینل ریزرویشن پروسه تکراري وه، ستونزې رامنځ ته شوې، او موږ په دوامداره توګه د معلوماتو مرکزونو ترمنځ ارتباط ښه کوو.
د مثال په توګه، ډیر وخت دمخه، کله چې د معلوماتو مرکز ته نږدې په یوه څاه کې کار کاوه، یو کیندونکي یو پایپ مات کړ، او د دې پایپ دننه دواړه اصلي او بیک اپ آپټیکل کیبل وو. د ډیټا مرکز سره زموږ د خطا زغمونکي مخابراتي چینل په یو ځای کې ، په څاه کې زیانمن شو. په دې اساس، موږ د زیربنا یوه برخه له لاسه ورکړې ده. موږ نتیجې ته ورسیدو او یو شمیر عملونه مو ترسره کړل، په شمول په نږدې څاه کې د اضافي نظرونو نصب کول.
د معلوماتو په مرکزونو کې د مخابراتو چمتو کونکو شتون شتون لري چې موږ ورته د BGP له لارې خپل مختګونه خپروو. د هرې شبکې لارښوونې لپاره، غوره میټریک غوره شوی، کوم چې مختلف پیرودونکو ته اجازه ورکوي چې د غوره ارتباط کیفیت سره چمتو شي. که چیرې د یو چمتو کونکي له لارې اړیکه کمه شي، موږ د شته چمتو کونکو له لارې زموږ لاره بیا رغوو.
که یو برابرونکی ناکام شي، موږ په اتوماتيک ډول بل ته بدلوو. د معلوماتو د یو مرکز د ناکامۍ په صورت کې، موږ په دویم ډیټا مرکز کې زموږ د خدماتو عکس کاپي لرو، کوم چې ټول بار په غاړه اخلي.
د فزیکي زیربنا مقاومت
هغه څه چې موږ یې د غوښتنلیک کچې غلطۍ زغم لپاره کاروو
زموږ خدمت د خلاصې سرچینې په یو شمیر برخو کې جوړ شوی دی.
ExaBGP یو خدمت دی چې د BGP پر بنسټ متحرک روټینګ پروتوکول په کارولو سره یو شمیر دندې پلي کوي. موږ په فعاله توګه دا زموږ د سپین لیست شوي IP پتې اعلانولو لپاره کاروو چې له لارې کاروونکي API ته لاسرسی لري.
HAProxy د لوړ بار بیلانسر دی چې تاسو ته اجازه درکوي د OSI ماډل مختلف کچو کې خورا انعطاف وړ ترافیک توازن مقررات تنظیم کړئ. موږ دا د ټولو خدماتو په وړاندې د توازن لپاره کاروو: ډیټابیس، پیغام بروکرز، API خدمتونه، ویب خدمتونه، زموږ داخلي پروژې - هرڅه د HAProxy تر شا دي.
د API غوښتنلیک - یو ویب اپلیکیشن چې په python لیکل شوی، د کوم سره چې کاروونکي خپل زیربنا او د هغه خدمت اداره کوي.
د کارګر غوښتنلیک (له دې وروسته په ساده ډول کارګر) - په OpenStack خدماتو کې، دا یو زیربنا ډیمون دی چې تاسو ته اجازه درکوي زیربنا ته د API کمانډونه نشر کړئ. د مثال په توګه، د ډیسک جوړول په کارګر کې واقع کیږي، او د جوړولو غوښتنه د غوښتنلیک API کې واقع کیږي.
د معیاري OpenStack غوښتنلیک آرکیټیکچر
ډیری خدمتونه چې د OpenStack لپاره رامینځته شوي هڅه کوي یو واحد تمثیل تعقیب کړي. یو خدمت معمولا له 2 برخو څخه جوړ دی: API او کارګران (د شاتړ اجرا کونکي). د یوې قاعدې په توګه، API په python کې د WSGI غوښتنلیک دی، کوم چې یا د یوې خپلواکې پروسې (ډیمون) په توګه پیل شوی، یا د چمتو شوي نګینکس یا اپاچي ویب سرور په کارولو سره. API د کارونکي غوښتنه پروسس کوي او د اجرا کولو لپاره د کارګر غوښتنلیک ته نور لارښوونې لیږدوي. لیږد د پیغام بروکر په کارولو سره پیښیږي، معمولا RabbitMQ، نور یې په کمزوري توګه ملاتړ کیږي. کله چې پیغامونه بروکر ته ورسیږي، دوی د کارګرانو لخوا پروسس کیږي او که اړتیا وي، ځواب بیرته راولي.
پدې تمثیل کې د ناکامۍ جلا جلا ټکي شامل دي: RabbitMQ او ډیټابیس. مګر RabbitMQ په یو خدمت کې جلا دی او په تیوري کې، د هر خدمت لپاره انفرادي کیدی شي. نو په MCS کې موږ دا خدمات د امکان تر حده جلا کوو؛ د هرې انفرادي پروژې لپاره موږ یو جلا ډیټابیس جوړوو، یو جلا RabbitMQ. دا طریقه ښه ده ځکه چې په ځینو زیان منونکو نقطو کې د حادثې په صورت کې، ټول خدمت نه ماتیږي، مګر یوازې د هغې یوه برخه.
د کارګر غوښتنلیکونو شمیر لامحدود دی، نو API کولی شي په اسانۍ سره په افقی ډول د بیلانسونو شاته اندازه کړي ترڅو د فعالیت او غلطۍ زغم زیات کړي.
ځینې خدمتونه په خدمت کې همغږي ته اړتیا لري کله چې د APIs او کارمندانو ترمنځ پیچلي ترتیبي عملیات ترسره کیږي. په دې حالت کې، د همغږۍ یو واحد مرکز کارول کیږي، د کلستر سیسټم لکه Redis، Memcache، etcd، کوم چې یو کارګر ته اجازه ورکوي چې بل ته ووایي چې دا دنده ورته سپارل شوې ده ("مهرباني وکړئ دا مه اخلئ"). موږ etcd کاروو. د یوې قاعدې په توګه، کارګران په فعاله توګه د ډیټابیس سره اړیکه نیسي، له هغه ځایه معلومات لیکي او لوستل. موږ mariadb د ډیټابیس په توګه کاروو، کوم چې په ملټي ماسټر کلستر کې موقعیت لري.
دا کلاسیک واحد خدمت په داسې طریقه تنظیم شوی چې عموما د OpenStack لپاره منل شوی. دا د تړل شوي سیسټم په توګه ګڼل کیدی شي، د کوم لپاره چې د پیمانه کولو او د غلطۍ زغم میتودونه خورا څرګند دي. د مثال په توګه، د API غلطی زغم لپاره، دا کافي ده چې د دوی په وړاندې یو بیلانس کیښودل شي. د اندازه کولو کارګران د دوی د شمیر په زیاتولو سره ترلاسه کیږي.
په ټوله سکیم کې ضعیف ټکی RabbitMQ او MariaDB دی. د دوی جوړښت د جلا مقالې مستحق دی. پدې مقاله کې زه غواړم د API غلطی زغم باندې تمرکز وکړم.
د اوپنسټیک غوښتنلیک آرکیټیکچر. د بادل پلیټ فارم توازن او غلطۍ زغم
د ExaBGP په کارولو سره د HAProxy بیلانسر غلطی برداشت کول
د دې لپاره چې زموږ APIs د توزیع وړ ، ګړندي او د خطا زغمونکي شي ، موږ د دوی په مخ کې د بار بیلنسر کېښودو. موږ HAProxy غوره کړه. زما په نظر، دا زموږ د دندې لپاره ټول اړین ځانګړتیاوې لري: د OSI په څو کچو کې توازن، د مدیریت انٹرفیس، انعطاف او اندازه کولو وړتیا، د توازن ډیری میتودونه، د سیشن میزونو لپاره ملاتړ.
لومړۍ ستونزه چې حل کولو ته اړتیا وه پخپله د بیلانسر غلط زغم و. په ساده ډول د بیلانس نصب کول هم د ناکامۍ نقطه رامینځته کوي: بیلانس ماتیږي او خدمت خرابیږي. د دې څخه د مخنیوي لپاره، موږ د ExaBGP سره په ګډه د HAProxy کارول.
ExaBGP تاسو ته اجازه درکوي د خدماتو حالت چیک کولو لپاره میکانیزم پلي کړئ. موږ دا میکانیزم د HAProxy فعالیت چک کولو لپاره کارولی او د ستونزو په صورت کې د BGP څخه د HAProxy خدمت غیر فعال کړئ.
ExaBGP+HAProxy سکیم
- موږ اړین سافټویر، ExaBGP او HAProxy په دریو سرورونو کې نصب کوو.
- موږ په هر سرور کې د لوپ بیک انٹرفیس رامینځته کوو.
- په ټولو دریو سرورونو کې موږ دې انٹرفیس ته ورته سپین IP پته ورکوو.
- یو سپین IP پته د ExaBGP له لارې انټرنیټ ته اعلان شوی.
د غلطی زغم د ټولو دریو سرورونو څخه د ورته IP پتې اعلانولو سره ترلاسه کیږي. د شبکې له نظره، ورته پته د دریو مختلف راتلونکو هپس څخه د لاسرسي وړ ده. روټر درې ورته لارې ګوري، د خپل میټریک پراساس د دوی ترټولو لوړ لومړیتوب غوره کوي (دا معمولا ورته اختیار دی)، او ټرافيک یوازې یو سرور ته ځي.
د HAProxy عملیاتو یا د سرور ناکامۍ سره د ستونزو په صورت کې ، ExaBGP د لارې اعلان کول ودروي ، او ترافیک په اسانۍ سره بل سرور ته تیریږي.
په دې توګه، موږ د توازن د غلطۍ زغم ترلاسه کړ.
د HAProxy بیلانسونو غلط برداشت
سکیم نیمګړی وګرځیده: موږ زده کړل چې څنګه د HAProxy ذخیره کړو، مګر په خدماتو کې د بار ویشلو څرنګوالي زده کړل. له همدې امله، موږ دا سکیم یو څه پراخ کړ: موږ د څو سپینو IP پتو ترمنځ توازن ته لاړ.
د DNS پلس BGP پراساس توازن
زموږ د HAProxy لپاره د بار توازن مسله حل شوې نه ده. په هرصورت، دا په ساده ډول حل کیدی شي، لکه څنګه چې موږ دلته وکړل.
د دریو سرورونو توازن لپاره تاسو به 3 سپینې IP پتې او ښه زاړه DNS ته اړتیا ولرئ. د دې پتې هر یو د هر HAProxy لوپ بیک انٹرفیس کې ټاکل کیږي او انټرنیټ ته اعلان شوي.
په OpenStack کې، د سرچینو اداره کولو لپاره، د خدماتو لارښود کارول کیږي، کوم چې د یو ځانګړي خدمت پای ټکی API مشخص کوي. پدې لارښود کې موږ د ډومین نوم راجستر کوو - public.infra.mail.ru، کوم چې د DNS له لارې د دریو مختلف IP پتې لخوا حل کیږي. د پایلې په توګه، موږ د DNS له لارې د دریو پتو ترمنځ د بار ویش ترلاسه کوو.
مګر له هغه وخته چې د سپینې IP پتې اعلان کول موږ د سرور انتخاب لومړیتوبونه نه کنټرولوو، دا لاهم توازن نه دی. عموما، یوازې یو سرور به د IP پتې لوړتیا پراساس غوره شي، او نور دوه به بې کاره وي ځکه چې په BGP کې هیڅ معیارونه ندي مشخص شوي.
موږ د ExaBGP له لارې د مختلف میټریکونو سره د لارو لیږل پیل کړل. هر بیلنسر ټول درې سپینې IP پتې اعلانوي، مګر یو له دوی څخه، د دې بیلانس لپاره اصلي یو، د لږترلږه میټریک سره اعلان شوی. نو پداسې حال کې چې ټول درې بیلانسران په کار کې دي، د لومړي IP پتې ته زنګونه لومړی بیلانسر ته ځي، دویم څخه دویم ته زنګ وهي، او دریم څخه دریم ته زنګ وهي.
څه پیښیږي کله چې یو بیلانس راټیټ شي؟ که کوم بیلانس ناکام شي، د هغې اصلي پته لاهم د نورو دوو څخه اعلان کیږي، او ټرافیک د دوی ترمنځ بیا ویشل کیږي. په دې توګه، موږ کارونکي ته د DNS له لارې یوځل څو IP پتې ورکوو. د DNS او مختلف میټریکونو لخوا توازن کولو سره ، موږ په ټولو دریو بیلانسونو کې د بار مساوي توزیع ترلاسه کوو. او په ورته وخت کې موږ د غلطۍ زغم له لاسه نه ورکوو.
د DNS + BGP پر بنسټ د HAProxy توازن کول
د ExaBGP او HAProxy ترمنځ تعامل
نو، موږ د غلطۍ زغم پلي کوو که چیرې سرور پریږدي، د لارو د اعلان بندولو پراساس. مګر HAProxy کولی شي د سرور ناکامۍ په پرتله د نورو دلیلونو لپاره وتړل شي: د ادارې تېروتنې، په خدمت کې ناکامۍ. موږ غواړو په دې قضیو کې هم د بار لاندې مات شوی بیلانس لرې کړو، او موږ یو بل میکانیزم ته اړتیا لرو.
له همدې امله، د پخوانۍ سکیم پراخول، موږ د ExaBGP او HAProxy ترمنځ د زړه ضربان پلي کړل. دا د ExaBGP او HAProxy ترمنځ د متقابل عمل سافټویر پلي کول دي، کله چې ExaBGP د غوښتنلیکونو حالت چک کولو لپاره دودیز سکریپټونه کاروي.
د دې کولو لپاره ، تاسو اړتیا لرئ د ExaBGP ترتیب کې د روغتیا چیک کونکی تنظیم کړئ ، کوم چې کولی شي د HAProxy حالت وګوري. زموږ په قضیه کې، موږ په HAProxy کې د روغتیا پس منظر ترتیب کړی، او د ExaBGP اړخ څخه موږ د ساده GET غوښتنې سره ګورو. که اعلان پیښ شي ، نو بیا HAProxy ډیری احتمال کار نه کوي او د دې اعلان کولو ته اړتیا نشته.
د HAProxy روغتیا معاینه
HAProxy Peers: د ناستې همغږي کول
د ترسره کولو راتلونکی شی د غونډو ترکیب کول وو. کله چې د توزیع شوي بیلانسونو له لارې کار کول، د پیرودونکو غونډو په اړه د معلوماتو ذخیره کولو تنظیم کول ستونزمن دي. مګر HAProxy یو له څو بیلانسرز څخه دی چې کولی شي دا د Peers فعالیت له امله ترسره کړي - د مختلف HAProxy پروسو ترمنځ د سیشن میزونو لیږدولو وړتیا.
د انډول کولو بیلابیل میتودونه شتون لري: ساده یې لکه ، او غزول شوی ، کله چې د پیرودونکي ناسته په یاد وي ، او هر ځل چې هغه د پخوا په څیر ورته سرور پای ته رسوي. موږ غوښتل دوهم انتخاب پلي کړو.
HAProxy د دې میکانیزم د پیرودونکي ناستې خوندي کولو لپاره سټیک میزونه کاروي. دوی د پیرودونکي اصلي IP پته، د ټاکل شوي هدف پته (بیک اینډ) او د خدماتو ځینې معلومات خوندي کوي. عموما، د سټیک میزونه د سرچینې-IP + منزل-IP جوړه ذخیره کولو لپاره کارول کیږي، کوم چې په ځانګړې توګه د هغو غوښتنلیکونو لپاره ګټور دی چې نشي کولی د کاروونکي سیشن شرایط انتقال کړي کله چې بل بیلنس ته تیریږي، د بیلګې په توګه، د RoundRobin توازن حالت کې.
که چیرې د سټیک میز ته د مختلف HAProxy پروسو تر مینځ حرکت کول زده کړل شي (په منځ کې چې توازن رامینځته کیږي) ، زموږ بیلانسران به وکولی شي د سټیک میزونو له یو حوض سره کار وکړي. دا به د دې امکان رامینځته کړي چې په بې ساري ډول د پیرودونکي شبکه بدله کړي که چیرې یو بیلانس ناکام شي؛ د پیرودونکي غونډو سره کار به په ورته پس منظرونو کې دوام ومومي کوم چې دمخه غوره شوي.
د سم عملیاتو لپاره ، د بیلانس د سرچینې IP پتې ستونزه له کوم ځای څخه چې ناسته رامینځته شوې باید حل شي. زموږ په قضیه کې، دا د لوپ بیک انٹرفیس کې یو متحرک پته ده.
د همکارانو سم کار یوازې د ځانګړو شرایطو لاندې ترلاسه کیږي. دا دی، د TCP مهال ویش باید په کافي اندازه لوی وي یا سویچ کول باید دومره ګړندي وي ترڅو د TCP سیشن پای ته رسیدو لپاره وخت ونه لري. په هرصورت، دا د بې سیمه سویچ کولو لپاره اجازه ورکوي.
په IaaS کې موږ د ورته ټیکنالوژۍ په کارولو سره جوړ شوی خدمت لرو. دا ، کوم چې د اکټاویا په نوم یادیږي. دا د دوه HAProxy پروسو پراساس دی او په پیل کې د ملګرو لپاره ملاتړ شامل دی. دوی په دې خدمت کې ځان ښه ثابت کړی دی.
انځور په سکیماتیکه توګه د درې HAProxy مثالونو تر مینځ د پییر میزونو حرکت ښیې، یو ترتیب وړاندیز شوی چې دا څنګه تنظیم کیدی شي:
HAProxy Peers (د ناستې همغږي کول)
که تاسو ورته سکیم پلي کړئ، د هغې عملیات باید په دقت سره معاینه شي. دا حقیقت ندی چې دا به د وخت 100٪ په ورته ډول کار وکړي. مګر لږترلږه تاسو به د سټیک میزونه له لاسه ورنکړئ کله چې تاسو اړتیا لرئ د پیرودونکي سرچینې IP په یاد ولرئ.
د ورته پیرودونکي څخه د ورته غوښتنو شمیر محدودول
هر هغه خدمتونه چې په عامه توګه شتون لري، زموږ د APIs په ګډون، د غوښتنو د تودوخې تابع کیدی شي. د دوی لاملونه په بشپړ ډول توپیر کیدی شي، د کاروونکو غلطیتونو څخه هدفي بریدونو ته. موږ په دوره توګه د IP پتې لخوا DDoSed یو. پیرودونکي اکثرا په خپلو سکریپټونو کې غلطي کوي او موږ ته کوچني DDoSs راکوي.
یو یا بل ډول، اضافي محافظت باید چمتو شي. ښکاره حل دا دی چې د API غوښتنو شمیر محدود کړي او د ناوړه غوښتنو پروسس کولو CPU وخت ضایع نکړي.
د دې ډول محدودیتونو پلي کولو لپاره ، موږ د ورته سټیک میزونو په کارولو سره د HAProxy پراساس تنظیم شوي د نرخ محدودیتونه کاروو. د محدودیتونو تنظیم کول خورا ساده دي او تاسو ته اجازه درکوي چې کاروونکي API ته د غوښتنو شمیر پورې محدود کړي. الګوریتم د سرچینې IP یادونه کوي چې له کوم ځای څخه غوښتنې کیږي او د یو کارونکي څخه د ورته غوښتنو شمیر محدودوي. البته، موږ د هر خدمت لپاره د اوسط API بار پروفایل محاسبه کړی او د دې ارزښت 10 ځله حد ټاکلی. موږ وضعیت له نږدې څارو او په نبض کې مو ګوتې ساتو.
دا په عمل کې څه ښکاري؟ موږ پیرودونکي لرو چې هر وخت زموږ د اتوماتیک کولو APIs کاروي. دوی په سهار کې شاوخوا دوه تر درې سوه مجازی ماشینونه رامینځته کوي او ماښام یې حذف کوي. د OpenStack لپاره، د مجازی ماشین رامینځته کول، د PaaS خدماتو سره هم، لږترلږه 1000 API غوښتنو ته اړتیا لري، ځکه چې د خدماتو ترمنځ تعامل هم د API له لارې واقع کیږي.
د دندو دا ډول لیږد د کافي لوی بار لامل کیږي. موږ د دې بار ارزونه وکړه، هره ورځ مو راټول کړل، لس چنده مو زیات کړل، او دا زموږ د نرخ حد شو. موږ خپله ګوته په نبض کې ساتو. موږ ډیری وختونه بوټونه او سکینرونه ګورو چې هڅه کوي موږ ته وګورو ترڅو وګورو چې ایا موږ کوم CGA سکریپټونه لرو چې چلولی شي، موږ په فعاله توګه پرې کوو.
څنګه خپل کوډبیس تازه کړئ پرته لدې چې کاروونکو ته پام وکړئ
موږ د کوډ پلي کولو پروسو په کچه د غلطۍ زغم هم پلي کوو. د رول آوټ په جریان کې ممکن خنډونه شتون ولري، مګر د خدماتو په شتون باندې د دوی اغیز کم کیدی شي.
موږ په دوامداره توګه خپل خدمات تازه کوو او باید ډاډ ترلاسه کړو چې کوډبیس د کاروونکو اغیزه کولو پرته تازه کیږي. موږ دا ستونزه د HAProxy مدیریت وړتیاو او زموږ په خدماتو کې د زړه راښکونکي بند پلي کولو په کارولو سره حل کړه.
د دې ستونزې د حل لپاره، دا اړینه وه چې د توازن کنټرول او د خدماتو "سمه" بندولو ډاډ ترلاسه کړئ:
- د HAProxy په قضیه کې، کنټرول د احصایې فایل له لارې ترسره کیږي، کوم چې په اصل کې ساکټ دی او د HAProxy ترتیب کې تعریف شوی. تاسو کولی شئ دې ته د سټیډیو له لارې امرونه واستوئ. مګر زموږ د تنظیم کولو اصلي کنټرول وسیله د منلو وړ ده، نو دا د HAProxy اداره کولو لپاره جوړ شوی ماډل لري. کوم چې موږ په فعاله توګه کاروو.
- زموږ ډیری API او انجن خدمتونه د زړه راښکونکي بند ټیکنالوژیو ملاتړ کوي: کله چې وتړل شي، دوی د اوسني کار بشپړیدو ته انتظار باسي، دا د HTTP غوښتنه یا ځینې خدمت دنده وي. ورته شی د کارګر سره پیښیږي. دا ټول هغه دندې پیژني چې دا یې کوي او پای ته رسیږي کله چې دا په بریالیتوب سره هرڅه بشپړ کړي.
د دې دوو ټکو څخه مننه، زموږ د ګمارنې لپاره خوندي الګوریتم داسې ښکاري.
- پراختیا کونکی د کوډ نوې کڅوړه راټولوي (زموږ لپاره دا RPM دی) ، دا په dev چاپیریال کې ازموي ، په مرحله کې یې ازموي ، او د مرحلې ذخیره کې یې پریږدي.
- پراختیا کونکی د ګمارنې لپاره دنده د "آثارو" خورا تفصيلي توضیحاتو سره تنظیموي: د نوي کڅوړې نسخه ، د نوي فعالیت توضیحات او د اړتیا په صورت کې د پلي کولو په اړه نور توضیحات.
- د سیسټم مدیر تازه کول پیلوي. د ځواب وړ لوبو کتاب پیلوي، کوم چې په پایله کې لاندې کار کوي:
- د مرحلې ذخیره څخه کڅوړه اخلي او د محصول ذخیره کې د کڅوړې نسخه تازه کولو لپاره کاروي.
- د تازه شوي خدمت د شالیدونو لیست ترتیبوي.
- په HAProxy کې د نوي کیدو لپاره لومړی خدمت بندوي او د هغې پروسې پای ته رسیدو ته انتظار باسي. د زړه راښکونکي بند څخه مننه، موږ ډاډه یو چې د پیرودونکي ټولې اوسني غوښتنې به په بریالیتوب سره بشپړې شي.
- وروسته له دې چې API او کارګران په بشپړ ډول ودرول شي، او HAProxy بند شي، کوډ تازه کیږي.
- د ځواب وړ چلولو خدمتونه.
- د هر خدمت لپاره، ځینې "سندونه" ایستل کیږي، کوم چې په یو شمیر مخکې ټاکل شوي کلیدي ازموینو کې د واحد ازموینه ترسره کوي. د نوي کوډ بنسټیز چک ترسره کیږي.
- که په تیرو ګامونو کې کومه تېروتنه ونه موندل شوه، پس منظر فعال شوی.
- راځئ چې راتلونکي پس منظر ته لاړ شو.
- وروسته له دې چې ټول بیکینډونه تازه شي، فعالې ازموینې پیل کیږي. که دوی ورک وي، نو بیا پراختیا کونکي هر هغه نوي فعالیت ته ګوري چې هغه رامینځته کړی.
دا ځای پرځای کول بشپړوي.
د خدماتو تازه کولو دوره
دا سکیم به کار ونکړي که چیرې موږ یو قانون نه لرو. موږ په جګړه کې د زړو او نویو نسخو ملاتړ کوو. مخکې له دې، د سافټویر پراختیا په مرحله کې، دا ایښودل شوي چې حتی که د خدماتو ډیټابیس کې بدلونونه شتون ولري، دوی به پخوانی کوډ مات نه کړي. د پایلې په توګه، د کوډ اساس په تدریجي ډول تازه کیږي.
پایلې
د غلطۍ زغمونکي ویب جوړښت په اړه زما خپل نظرونه شریکول، زه غواړم یو ځل بیا د دې کلیدي ټکو یادونه وکړم:
- د فزیکي عیب زغم؛
- د شبکې غلطی زغم (توازن، BGP)؛
- د کارول شوي او رامینځته شوي سافټویر غلط زغم.
د هرچا باثباته وخت!
سرچینه: www.habr.com
