د Yandex.Market لټون څنګه کار کوي او څه پیښیږي که چیرې یو سرور ناکام شي

سلام، زما نوم Evgeniy دی. زه د Yandex.Market لټون زیربنا کې کار کوم. زه غواړم د بازار د داخلي پخلنځي په اړه د حبر ټولنې ته ووایم - او زه د ویلو لپاره ډیر څه لرم. لومړی، د بازار لټون څنګه کار کوي، پروسې او جوړښت. موږ څنګه د بیړنیو حالتونو سره معامله کوو: څه پیښیږي که چیرې یو سرور ښکته شي؟ که چیرې 100 داسې سرورونه شتون ولري؟

تاسو به دا هم زده کړئ چې څنګه موږ په یو وخت کې د سرورونو په ډله کې نوي فعالیت پلي کوو. او څنګه موږ په مستقیم ډول په تولید کې پیچلي خدمتونه ازموینه کوو، پرته له دې چې کاروونکو ته کوم تکلیف رامنځته کړي. په عموم کې، د بازار لټون څنګه کار کوي ترڅو هرڅوک ښه وخت ولري.

زموږ په اړه لږ څه: موږ کومه ستونزه حل کوو

کله چې تاسو متن داخل کړئ، د پیرامیټونو په واسطه د محصول لټون وکړئ، یا په مختلفو پلورنځیو کې نرخونه پرتله کړئ، ټولې غوښتنې د لټون خدمت ته لیږل کیږي. لټون په بازار کې ترټولو لوی خدمت دی.

موږ د لټون ټولې غوښتنې پروسس کوو: له سایټونو market.yandex.ru, beru.ru، د سوپر چیک خدمت، Yandex.Advisor، ګرځنده غوښتنلیکونه. موږ په yandex.ru کې د لټون پایلو کې د محصول وړاندیزونه هم شاملوو.

د لټون خدمت لخوا زما مطلب نه یوازې پخپله لټون دی ، بلکه په بازار کې د ټولو وړاندیزونو سره ډیټابیس هم دی. پیمانه دا ده: هره ورځ له یو ملیارد څخه ډیر د لټون غوښتنې پروسس کیږي. او هرڅه باید په چټکۍ سره کار وکړي، پرته له خنډونو او تل مطلوب پایله تولیدوي.

څه شی دی: د بازار جوړښت

زه به په لنډه توګه د بازار اوسنی جوړښت تشریح کړم. دا د لاندې ډیاګرام لخوا تقریبا تشریح کیدی شي:

راځئ چې یو ملګری پلورنځی موږ ته راشي. هغه وايي زه غواړم یو لوبی وپلورم: دا ناوړه پیشو د چیکر سره. او بل غوسه شوی پیشو پرته له چیچونکی. او یوازې یو بلی. بیا پلورنځي اړتیا لري وړاندیزونه چمتو کړي د کوم لپاره چې بازار لټون کوي. پلورنځي د وړاندیزونو سره یو ځانګړی xml رامینځته کوي او د وابسته انٹرفیس له لارې دې xml ته لاره رسوي. بیا شاخص په وخت سره دا xml ډاونلوډ کوي، د غلطیو لپاره ګوري او ټول معلومات په لوی ډیټابیس کې خوندي کوي.

ډیری داسې خوندي شوي xmls شتون لري. د دې ډیټابیس څخه د لټون شاخص رامینځته شوی. شاخص په داخلي بڼه کې ساتل کیږي. د شاخص رامینځته کولو وروسته ، د ترتیب خدمت دا د لټون سرورونو ته اپلوډ کوي.

د پایلې په توګه، په ډیټابیس کې د غوسه شوي پیشو سره ښکاري، او د پیشو شاخص په سرور کې ښکاري.

زه به تاسو ته ووایم چې څنګه موږ د لټون معمارۍ په برخه کې د پیشو لټون کوو.

د بازار لټون جوړښت

موږ د مایکرو خدماتو نړۍ کې ژوند کوو: هره راتلونکی غوښتنه market.yandex.ru د ډیری فرعي پوښتنو لامل کیږي، او لسګونه خدمتونه د دوی په پروسس کې ښکیل دي. انځور یوازې یو څو ښیي:

د غوښتنې پروسس کولو ساده سکیم

هر خدمت یو په زړه پوری شی لري - خپل بیلانس د ځانګړي نوم سره:

بیلانسر موږ ته د خدماتو اداره کولو کې لوی انعطاف درکوي: تاسو کولی شئ د مثال په توګه سرورونه بند کړئ ، کوم چې ډیری وختونه د تازه معلوماتو لپاره اړین وي. بیلانسر ګوري چې سرور شتون نلري او په اتوماتيک ډول نورو سرورونو یا ډیټا مرکزونو ته غوښتنې لیږدوي. کله چې سرور اضافه کول یا لرې کول ، بار په اوتومات ډول د سرورونو ترمینځ توزیع کیږي.

د بیلانس ځانګړی نوم د معلوماتو مرکز پورې اړه نلري. کله چې خدمت A B ته غوښتنه کوي، نو بیا د ډیفالټ بیلانس B لخوا غوښتنه اوسني ډیټا مرکز ته لیږل کیږي. که چیرې خدمت شتون ونلري یا په اوسني ډیټا مرکز کې شتون ونلري ، نو بیا غوښتنه نورو ډیټا مرکزونو ته لیږل کیږي.

د ټولو معلوماتو مرکزونو لپاره یو واحد FQDN خدمت A ته اجازه ورکوي چې په بشپړ ډول له ځایونو څخه خلاص کړي. د خدمت B لپاره د هغه غوښتنه به تل پروسس کیږي. استثنا هغه قضیه ده کله چې خدمت په ټولو ډیټا مرکزونو کې موقعیت لري.

مګر هرڅه د دې بیلانسر سره دومره ګلابي ندي: موږ اضافي منځنۍ برخه لرو. بیلانسر ممکن بې ثباته وي، او دا ستونزه د بې ځایه سرورونو لخوا حل کیږي. د A او B خدماتو ترمنځ اضافي ځنډ هم شتون لري. مګر په عمل کې دا د 1 ms څخه کم دی او د ډیری خدماتو لپاره دا مهم ندي.

د غیر متوقع سره معامله کول: د لټون خدمت توازن او لیوالتیا

تصور وکړئ چې سقوط شتون لري: تاسو اړتیا لرئ یو پیشو د چیکر سره ومومئ ، مګر سرور خرابیږي. یا 100 سرورونه. څنګه بهر شو؟ ایا موږ واقعیا پرته له پیشو څخه کاروونکي پریږدو؟

وضعیت ډارونکی دی، مګر موږ ورته چمتو یو. زه به تاسو ته په ترتیب سره ووایم.

د لټون زیربنا په ډیری ډیټا مرکزونو کې موقعیت لري:

کله چې ډیزاین کول، موږ د یو ډیټا مرکز تړلو امکانات شاملوو. ژوند د حیرانتیا څخه ډک دی - د بیلګې په توګه، یو کیندونکی کولی شي د ځمکې لاندې کیبل پرې کړي (هو، دا پیښ شوي). په پاتې ډیټا مرکزونو کې ظرفیت باید د لوړ بار سره مقاومت کولو لپاره کافي وي.

راځئ چې یو واحد ډیټا مرکز په پام کې ونیسو. هر ډیټا مرکز ورته بیلانس عملیاتي سکیم لري:

یو بیلانسر لږترلږه درې فزیکي سرورونه دي. دا بې ځایه کیدنه د اعتبار لپاره رامینځته شوې. بیلانسران په HAProx کې چلیږي.

موږ HAProx د دې د لوړ فعالیت، ټیټو سرچینو اړتیاو او پراخ فعالیت له امله غوره کړ. زموږ د لټون سافټویر د هر سرور دننه چلیږي.

د یو سرور د ناکامۍ احتمال کم دی. مګر که تاسو ډیری سرورونه لرئ، احتمال یې لږ تر لږه یو به ښکته شي.

دا هغه څه دي چې په واقعیت کې پیښیږي: د سرورونو حادثه. له همدې امله ، دا اړینه ده چې په دوامداره توګه د ټولو سرورونو حالت وڅارئ. که سرور ځواب ورکول ودروي، دا په اتوماتيک ډول د ټرافیک څخه منحل کیږي. د دې هدف لپاره، HAProxy یو جوړ شوی روغتیایی معاینه لري. دا د HTTP غوښتنې "/ping" سره په ثانیه کې یو ځل ټولو سرورونو ته ځي.

د HAProxy بله ځانګړتیا: د اجنټ چیک تاسو ته اجازه درکوي ټول سرورونه په مساوي ډول پورته کړئ. د دې کولو لپاره، HAProxy د ټولو سرورونو سره نښلوي، او دوی خپل وزن له 1 څخه تر 100 پورې د اوسني بار پورې اړه لري. وزن د پروسس کولو لپاره په کتار کې د غوښتنو شمیر او پروسیسر باندې د بار په اساس محاسبه کیږي.

اوس د بلی موندلو په اړه. په غوښتنو کې د لټون پایلې لکه: /لټون؟text=angry+cat. د دې لپاره چې لټون چټک شي، د بلی ټول شاخص باید په رام کې فټ شي. حتی د SSD څخه لوستل کافي ګړندي ندي.

یو وخت، د وړاندیز ډیټابیس کوچنی و، او د یو سرور رام د دې لپاره کافي و. لکه څنګه چې د وړاندیز اساس وده وکړه ، هرڅه نور پدې رام کې مناسب ندي ، او ډاټا په دوه برخو ویشل شوي: شارډ 1 او شارډ 2.

مګر دا تل پیښیږي: هر حل، حتی یو ښه، نورو ستونزو ته وده ورکوي.

بیلانسر لاهم کوم سرور ته لاړ. مګر په ماشین کې چیرې چې غوښتنه راغله، یوازې د شاخص نیمایي وه. پاتې نور په نورو سرورونو کې وو. له همدې امله، سرور باید ځینې ګاونډی ماشین ته لاړ شي. د دواړو سرورونو څخه د معلوماتو ترلاسه کولو وروسته، پایلې یوځای شوي او بیا درجه بندي شوي.

څرنګه چې بیلانسر غوښتنې په مساوي ډول توزیع کوي، ټول سرورونه په بیا درجه بندي کې بوخت وو، او نه یوازې د معلوماتو لیږلو.

ستونزه رامنځ ته شوه که چیرې یو ګاونډی سرور شتون ونلري. د حل لاره دا وه چې د "ګاونډی" سرور په توګه د مختلف لومړیتوبونو سره ډیری سرورونه مشخص کړئ. لومړی، غوښتنه په اوسني ریک کې سرورونو ته لیږل شوې. که ځواب نه وي، غوښتنه د دې ډاټا مرکز ټولو سرورونو ته لیږل شوې وه. او په نهایت کې ، غوښتنه نورو معلوماتو مرکزونو ته لاړه.
لکه څنګه چې د وړاندیزونو شمیر زیات شو، معلومات په څلورو برخو ویشل شوي. مګر دا حد نه و.

اوس مهال، د اتو شارډونو ترتیب کارول کیږي. سربیره پردې ، د حتی ډیر حافظې خوندي کولو لپاره ، شاخص د لټون برخه (کوم چې د لټون لپاره کارول کیږي) او یوه ټوټه برخه (کوم چې په لټون کې دخیل ندي) ویشل شوې وه.

یو سرور یوازې د یوې شارډ لپاره معلومات لري. له همدې امله ، د بشپړ شاخص لټون کولو لپاره ، تاسو اړتیا لرئ په اتو سرورونو کې لټون وکړئ چې مختلف شارډونه لري.

سرورونه په کلسترونو ګروپ شوي دي. هر کلستر اته د لټون انجنونه او یو snippet سرور لري.

د سپیټ سرور د جامد ډیټا سره د کلیدي ارزښت ډیټابیس چلوي. دوی د اسنادو صادرولو ته اړتیا لري، د بیلګې په توګه، د بلی سره د بلی تشریح. ډاټا په ځانګړي ډول جلا سرور ته لیږدول کیږي ترڅو د لټون سرورونو حافظه پورته نشي.

څرنګه چې د سند IDs یوازې په یوه شاخص کې ځانګړي دي، داسې حالت رامینځته کیدی شي چیرې چې په ټوټې کې اسناد شتون نلري. ښه، یا دا چې د یو ID لپاره به مختلف مینځپانګې وي. له همدې امله، د دې لپاره چې د لټون کار وکړي او پایلې بیرته راستانه شي، په ټول کلستر کې د دوام لپاره اړتیا وه. زه به تاسو ته لاندې ووایم چې موږ څنګه د دوام څارنه کوو.

لټون پخپله په لاندې ډول جوړ شوی دی: د لټون غوښتنه کولی شي د اتو سرورونو څخه هر یو ته راشي. راځئ چې ووایو هغه سرور 1 ته راغلی. دا سرور ټول دلیلونه پروسس کوي او پوهیږي چې څه او څنګه یې په لټه کې دي. د راتلوونکي غوښتنې پورې اړه لري، سرور کولی شي د اړین معلوماتو لپاره بهرني خدماتو ته اضافي غوښتنې وکړي. یوه غوښتنه د بهرنیو خدماتو لپاره تر لسو پورې غوښتنې تعقیب کیدی شي.

د اړینو معلوماتو راټولولو وروسته، د وړاندیز ډیټابیس کې لټون پیل کیږي. د دې کولو لپاره، فرعي پوښتنې په کلستر کې ټولو اتو سرورونو ته جوړ شوي.

کله چې ځوابونه ترلاسه شي، پایلې یوځای کیږي. په پاى کې، د نتايجو د رامنځته کولو لپاره د سنيپټ سرور ته څو نور فرعي پوښتنو ته اړتيا لري.

په کلستر کې د لټون پوښتنې داسې ښکاري: /shard1?text=angry+cat. سربیره پردې، د فورمې فرعي پوښتنې په دوامداره توګه د کلستر دننه د ټولو سرورونو ترمنځ په ثانیه کې یو ځل جوړیږي: /حالت.

غوښتنه /حالت داسې وضعیت کشف کوي چیرې چې سرور شتون نلري.

دا هم کنټرولوي چې د لټون انجن نسخه او د شاخص نسخه په ټولو سرورونو کې یو شان دي، که نه نو په کلستر کې به متضاد معلومات وي.

د دې حقیقت سره سره چې یو سنیپټ سرور د اتو پلټونکو انجنونو څخه غوښتنې پروسس کوي ، د دې پروسیسر خورا لږ بار شوی دی. له همدې امله، موږ اوس د سپیټ ډاټا جلا خدمت ته لیږدوو.

د معلوماتو لیږدولو لپاره، موږ د اسنادو لپاره یونیورسل کیلي معرفي کړل. اوس دا د داسې وضعیت لپاره ناممکن دی چیرې چې د بل سند مینځپانګه د یوې کیلي په کارولو سره بیرته راستانه کیږي.

مګر بل معمارۍ ته لیږد لاهم بشپړ شوی نه دی. اوس موږ غواړو د وقف شوي سنیپټ سرور څخه ځان خلاص کړو. او بیا د کلستر جوړښت څخه په بشپړه توګه لیرې لاړ شئ. دا به موږ ته اجازه درکړو چې په اسانۍ سره اندازه کولو ته دوام ورکړو. یو اضافي بونس د پام وړ اوسپنې سپما ده.

او اوس د خوښې پایونو سره ویرونکي کیسې ته. راځئ چې د سرور نه شتون ډیری قضیې په پام کې ونیسو.

یو څه ناوړه پیښ شوي: یو سرور شتون نلري

راځئ چې ووایو یو سرور شتون نلري. بیا په کلستر کې پاتې سرورونه ځواب ته دوام ورکوي، مګر د لټون پایلې به نیمګړې وي.

د وضعیت چیک له لارې /حالت ګاونډی سرورونه پوهیږي چې یو شتون نلري. له همدې امله، د بشپړتیا ساتلو لپاره، ټول سرورونه په کلستر کې په هره غوښتنه کې /پینګ دوی بیلانس ته ځواب ویل پیل کوي چې دوی هم شتون نلري. دا معلومه شوه چې په کلستر کې ټول سرورونه مړه شوي (کوم چې ریښتیا ندي). دا زموږ د کلستر سکیم اصلي نیمګړتیا ده - له همدې امله موږ غواړو له دې څخه لرې شو.

هغه غوښتنې چې د غلطۍ سره ناکامې شوې د بیلانس لخوا په نورو سرورونو کې لیږل کیږي.
بیلانسر هم مړه سرورونو ته د کارونکي ترافیک لیږل ودروي ، مګر د دوی حالت چیک کولو ته دوام ورکوي.

کله چې سرور شتون ولري ، نو ځواب ورکول پیل کوي /پینګ. هرڅومره ژر چې د مړو سرورونو څخه پینګونو ته نورمال ځوابونه راشي ، بیلانسران هلته د کارونکي ترافیک لیږل پیل کوي. د کلستر عملیات بیرته راستانه شوي، ژر.

حتی بدتر: ډیری سرورونه شتون نلري

د معلوماتو په مرکز کې د سرورونو د پام وړ برخه پرې شوې. څه وکړي، چیرته وتښتي؟ بیلانسر بیا ژغورنې ته راځي. هر بیلانسر په دوامداره توګه د ژوندی سرورونو اوسنی شمیر په حافظه کې ساتي. دا په دوامداره توګه د ترافیک اعظمي مقدار محاسبه کوي چې اوسنی ډیټا مرکز پروسس کولی شي.

کله چې د ډیټا مرکز کې ډیری سرورونه ښکته کیږي، بیلانسر پوهیږي چې دا ډیټا مرکز نشي کولی ټول ټرافیک پروسس کړي.

بیا اضافي ترافیک په تصادفي ډول نورو ډیټا مرکزونو ته توزیع کیږي. هرڅه کار کوي، هرڅوک خوشحاله دي.

موږ دا څنګه کوو: د خپرونو خپرول

اوس راځئ چې په دې اړه وغږیږو چې څنګه موږ په خدمت کې شوي بدلونونه خپروو. دلته موږ د پروسو د ساده کولو لاره نیولې ده: د نوي خوشې کول تقریبا په بشپړ ډول اتوماتیک دي.
کله چې په پروژه کې یو مشخص شمیر بدلونونه راټول شي، یو نوی ریلیز په اوتومات ډول رامینځته کیږي او د هغې جوړول پیل کیږي.

بیا خدمت ازموینې ته لیږدول کیږي ، چیرې چې د عملیاتو ثبات معاینه کیږي.

په ورته وخت کې، د اتوماتیک فعالیت ازموینه پیل شوې. دا د یو ځانګړي خدمت لخوا اداره کیږي. زه به اوس د دې په اړه خبرې ونه کړم - د دې توضیح د جلا مقالې وړ دی.

که په ازمایښت کې خپرونه بریالۍ وي، په پرسټیبل کې د خپریدو خپرول په اوتومات ډول پیل کیږي. Prestable یو ځانګړی کلستر دی چیرې چې د کاروونکي نورمال ترافیک لارښوونه کیږي. که دا یوه تېروتنه راوباسي، بیلانسر تولید ته بیا غوښتنه کوي.

په پرسټیبل کې، د غبرګون وختونه اندازه کیږي او په تولید کې د تیرو خپرونو سره پرتله کیږي. که هرڅه سم وي، نو یو شخص وصل کیږي: د بار ازموینې ګرافونه او پایلې چک کوي او بیا تولید ته پیل کوي.

ټول غوره کارونکي ته ځي: A/B ازموینه

دا تل روښانه نده چې ایا په خدمت کې بدلونونه به ریښتینې ګټې راوړي. د بدلونونو ګټورتیا اندازه کولو لپاره، خلک د A/B ازموینې سره راغلل. زه به تاسو ته لږ څه ووایم چې دا څنګه د Yandex.Market لټون کې کار کوي.

دا ټول د نوي CGI پیرامیټر اضافه کولو سره پیل کیږي چې نوي فعالیت وړوي. اجازه راکړئ چې زموږ پیرامیټر وي: بازار_نوی_فعالیت = 1. بیا په کوډ کې موږ دا فعالیت فعال کوو که چیرې بیرغ شتون ولري:

If (cgi.experiments.market_new_functionality) {
// enable new functionality
}

نوي فعالیت تولید ته لیږدول کیږي.

د A/B ازموینې اتومات کولو لپاره، یو وقف شوی خدمت شتون لري چې توضیحات لري دلته تشریح شوی. په خدمت کې یو تجربه رامینځته کیږي. د ټرافیک ونډه ټاکل شوې، د بیلګې په توګه، 15٪. سلنه د پوښتنو لپاره نه، مګر د کاروونکو لپاره ټاکل شوي. د تجربې موده هم اشاره شوې، د بیلګې په توګه، یوه اونۍ.

ډیری تجربې په یو وخت کې ترسره کیدی شي. په ترتیباتو کې تاسو کولی شئ مشخص کړئ چې ایا د نورو تجربو سره تقاطع امکان لري.

د پایلې په توګه، خدمت په اوتومات ډول یو دلیل اضافه کوي بازار_نوی_فعالیت = 1 15٪ کاروونکو ته. دا په اتوماتيک ډول ټاکل شوي میټریکونه هم محاسبه کوي. وروسته له دې چې تجربه بشپړه شي، شنونکي پایلې ګوري او پایلې یې راوړي. د موندنو پر بنسټ، د تولید یا تصفیه کولو لپاره پریکړه کیږي.

د بازار وړ لاس: په تولید کې ازموینه

دا ډیری وختونه پیښیږي چې تاسو اړتیا لرئ په تولید کې د نوي فعالیت فعالیت ازموینه وکړئ ، مګر تاسو ډاډه نه یاست چې دا به د "جګړې" شرایطو کې د دروند بار لاندې څنګه چلند وکړي.

یو حل شتون لري: په CGI پیرامیټونو کې بیرغونه نه یوازې د A/B ازموینې لپاره کارول کیدی شي ، بلکه د نوي فعالیت ازموینې لپاره هم کارول کیدی شي.

موږ یوه وسیله جوړه کړې چې تاسو ته اجازه درکوي په سمدستي توګه په زرګونو سرورونو کې تنظیمات بدل کړئ پرته لدې چې خدمت خطرونو ته افشا کړئ. دې ته "Stop Tap" ویل کیږي. اصلي نظر دا و چې پرته له ترتیب پرته ځینې فعالیت په چټکۍ سره غیر فعال کړئ. بیا وسیله پراخه شوه او خورا پیچلې شوه.

د خدمت جریان ډیاګرام لاندې وړاندې کیږي:

د بیرغ ارزښتونه د API له لارې تنظیم شوي. د مدیریت خدمت دا ارزښتونه په ډیټابیس کې ساتي. ټول سرورونه په هرو لسو ثانیو کې یو ځل ډیټابیس ته ځي، د بیرغ ارزښتونه پمپ کړئ او دا ارزښتونه هرې غوښتنې ته پلي کړئ.

د سټاپ نل کې تاسو کولی شئ دوه ډوله ارزښتونه تنظیم کړئ:

1) شرطي څرګندونې. تطبیق کړئ کله چې یو ارزښت ریښتیا وي. د مثال په ډول:

{
	"condition":"IS_DC1",
	"value":"3",
}, 
{
	"condition": "CLUSTER==2 and IS_BERU", 
	"value": "4!" 
}

ارزښت "3" به پلي شي کله چې غوښتنه په DC1 ځای کې پروسس شي. او ارزښت یې "4" دی کله چې غوښتنه د beru.ru سایټ لپاره په دوهم کلستر کې پروسس کیږي.

2) غیر مشروط ارزښتونه. د ډیفالټ لخوا غوښتنه وکړئ که چیرې هیڅ یو شرط نه وي پوره شوی. د مثال په ډول:

ارزښت، ارزښت!

که یو ارزښت د عجب ټکي سره پای ته ورسیږي ، دا لوړ لومړیتوب ورکول کیږي.

د CGI پیرامیټر پارسر URL تجزیه کوي. بیا د Stop Tap څخه ارزښتونه پلي کوي.

ارزښتونه د لاندې لومړیتوبونو سره پلي کیږي:

1. د Stop Tap (د عجب نښه) څخه د لومړیتوب زیاتوالي سره.
2. د غوښتنې څخه ارزښت.
3. د سټاپ نل څخه ډیفالټ ارزښت.
4. په کوډ کې ډیفالټ ارزښت.

ډیری بیرغونه شتون لري چې په مشروط ارزښتونو کې ښودل شوي - دا د ټولو سناریو ګانو لپاره کافي دي چې موږ ته پیژندل شوي:

• د معلوماتو مرکز.
• چاپیریال: تولید، ازموینه، سیوري.
• ځای: بازار، بیرو.
• د کلستر شمیره.

د دې وسیلې سره ، تاسو کولی شئ د سرورونو په یو ځانګړي ګروپ کې نوي فعالیت فعال کړئ (د مثال په توګه ، یوازې په یو ډیټا مرکز کې) او د دې فعالیت عملیات پرته له کوم ځانګړي خطر څخه ټول خدمت ته ازموئ. حتی که تاسو په کوم ځای کې جدي غلطي کړې وي ، هرڅه راټیټیدل پیل شوي او د ډیټا ټول مرکز ښکته شوی ، بیلانسران به غوښتنې نورو ډیټا مرکزونو ته واستوي. پای کارونکي به هیڅ شی ونه ګوري.

که تاسو کومه ستونزه وګورئ، تاسو کولی شئ سمدلاسه بیرغ خپل پخواني ارزښت ته بیرته راستانه کړئ او بدلونونه به بیرته وګرځول شي.

دا خدمت هم خپل نیمګړتیاوې لري: پراختیا کونکي دا خورا خوښوي او ډیری وختونه هڅه کوي ټول بدلونونه په سټاپ نل کې فشار راوړي. موږ هڅه کوو چې د ناوړه ګټې اخیستنې سره مبارزه وکړو.

د سټاپ نل طریقه ښه کار کوي کله چې تاسو دمخه ثابت کوډ لرئ چې تولید ته چمتو شي. په ورته وخت کې، تاسو لاهم شک لرئ، او تاسو غواړئ کوډ په "جګړه" شرایطو کې وګورئ.

په هرصورت، Stop Tap د پراختیا په جریان کې د ازموینې لپاره مناسب ندي. د پراختیا کونکو لپاره یو جلا کلستر شتون لري چې د "سیوري کلستر" په نوم یادیږي.

پټه ازموینه: د سیوري کلستر

د یو کلستر څخه غوښتنې د سیوري کلستر ته نقل شوي دي. مګر بیلانسر د دې کلستر څخه ځوابونه په بشپړه توګه له پامه غورځوي. د دې عملیاتو ډیاګرام لاندې وړاندې کیږي.

موږ د ازموینې کلستر ترلاسه کوو چې په ریښتیني "جنګي" شرایطو کې وي. د عادي کاروونکي ترافیک هلته ځي. په دواړو کلسترونو کې هارډویر یو شان دی، نو فعالیت او تېروتنې پرتله کیدی شي.

او له هغه وخته چې بیلانسر په بشپړ ډول ځوابونه له پامه غورځوي، پای کاروونکي به د سیوري کلستر څخه ځوابونه ونه ګوري. له همدې امله، دا ویره نه ده چې غلطي وکړي.

موندنو

نو، موږ څنګه د بازار لټون جوړ کړ؟

د دې لپاره چې هرڅه سم پرمخ ولاړ شي، موږ فعالیت په جلا خدماتو جلا کوو. پدې توګه موږ کولی شو یوازې هغه برخې اندازه کړو چې موږ ورته اړتیا لرو او اجزا ساده کوو. دا اسانه ده چې بل ټیم ​​ته جلا برخه وټاکئ او په هغې باندې د کار کولو مسولیتونه شریک کړئ. او د دې طریقې سره په اوسپنه کې د پام وړ سپما یو څرګند پلس دی.

د سیوري کلستر هم زموږ سره مرسته کوي: موږ کولی شو خدمات رامینځته کړو ، په پروسه کې یې ازموینه وکړو او کارونکي ګډوډ نکړو.

ښه، په تولید کې ازموینه، البته. په زرګونو سرورونو کې ترتیب بدلولو ته اړتیا لرئ؟ اسانه، د Stop Tap وکاروئ. پدې توګه تاسو کولی شئ سمدلاسه چمتو شوي پیچلي حل راوباسئ او که ستونزې رامینځته شي یو مستحکم نسخه ته بیرته راوګرځئ.

زه امید لرم چې زه وتوانید وښیم چې څنګه موږ بازار ګړندی او باثباته کوو د وړاندیزونو تل وده کونکي اساس سره. څنګه چې موږ د سرور ستونزې حل کوو، د ډیری غوښتنو سره معامله کوو، د خدماتو انعطاف ته وده ورکوو او دا کار پرته له دې چې د کاري پروسو مداخله وکړو.

سرچینه: www.habr.com