رخصتۍ پای ته رسیدلي او موږ د اسټیو خدماتو میش لړۍ کې زموږ د دوهم پوسټ سره بیرته یو.
د نن ورځې موضوع سرکټ بریکر دی، کوم چې د روسیې بریښنایی انجینرۍ ته ژباړل شوی د "سرکټ ماتونکی" معنی لري، په عام ډول - "سرکټ بریکر". یوازې په اسټیو کې دا ماشین شارټ یا ډیر بار شوي سرکټ نه جلا کوي ، مګر غلط کانټینرونه.
دا څنګه باید په مثالي توګه کار وکړي
کله چې مایکرو خدمتونه د Kubernetes لخوا اداره کیږي، د بیلګې په توګه د OpenShift پلیټ فارم کې، دوی په اتوماتيک ډول د بار پر بنسټ پورته او ښکته کوي. ځکه چې مایکرو خدمتونه په پوډونو کې پرمخ ځي، کیدای شي په یوه پای کې د کانټینر شوي مایکرو سرویس ډیری مثالونه شتون ولري، او کوبرنیټس به د دوی ترمنځ غوښتنې او بار توازن راوباسي. او - په مثالي توګه - دا ټول باید په سمه توګه کار وکړي.
موږ په یاد لرو چې کوچني خدمتونه کوچني او لنډمهاله دي. Ephemerality، چې دلته د څرګندیدو او ورکیدو اسانتیا معنی لري، ډیری وختونه کم اټکل کیږي. په پوډ کې د مایکرو سرویس بل مثال زیږیدلی او مړینه خورا تمه شوي شیان دي ، OpenShift او Kubernetes دا ښه اداره کوي ، او هرڅه عالي کار کوي - مګر بیا په تیوري کې.
دا څنګه واقعیا کار کوي
اوس تصور وکړئ چې د مایکرو سرویس یوه ځانګړې بیلګه، دا یو کانټینر، د کارولو وړ نه دی: یا دا ځواب نه ورکوي (غلطۍ 503)، یا، هغه څه چې ډیر ناخوښه وي، ځواب ورکوي، مګر ډیر ورو. په بل عبارت، دا ګړندی کیږي یا غوښتنو ته ځواب نه ورکوي، مګر دا په اتوماتيک ډول د حوض څخه نه ایستل کیږي. په دې صورت کې باید څه وشي؟ بیا هڅه کول؟ ایا زه باید دا د روټینګ سکیم څخه لیرې کړم؟ او "ډیر ورو" څه معنی لري - دا په شمیر کې څومره دي، او څوک یې ټاکي؟ شاید یو وقفه ورکړئ او وروسته بیا هڅه وکړئ؟ که داسې وي، څومره وروسته؟
په اسټیو کې د پول انجیکشن څه شی دی؟
او دلته اسټیو د خپل سرکټ بریکر محافظت ماشینونو سره ژغورنې ته راځي ، کوم چې په لنډمهاله توګه د روټینګ او بار توازن سرچینو حوض څخه غلط کانټینرونه لرې کوي ، د حوض Ejection طرزالعمل پلي کوي.
د بهر کشف کولو ستراتیژۍ په کارولو سره ، اسټیو د وکر پوډونه کشف کوي چې له کرښې بهر دي او د ټاکل شوي وخت لپاره یې د سرچینې حوض څخه لرې کوي ، چې د خوب کړکۍ په نوم یادیږي.
د دې لپاره چې وښیې چې دا په اوپن شیفټ پلیټ فارم کې کوبرنیټس کې څنګه کار کوي ، راځئ چې په ذخیره کې د مثال څخه د معمول کار کولو مایکرو خدماتو سکرین شاټ سره پیل وکړو. . دلته موږ دوه پوډونه لرو، v1 او v2، هر یو یو کانټینر چلوي. کله چې د اسټیو روټینګ قواعد نه کارول کیږي ، کوبرنیټس په مساوي ډول متوازن راؤنډ رابین روټینګ ته ډیفالټ کوي:
د حادثې لپاره چمتو کول
مخکې له دې چې د پول ایجیکشن ترسره کړئ، تاسو اړتیا لرئ د اسټیو روټینګ قواعد رامینځته کړئ. راځئ چې ووایو موږ غواړو د پوډونو ترمینځ غوښتنې د 50/50 تناسب کې توزیع کړو. سربیره پردې، موږ به د v2 کانټینرونو شمیر له یو څخه دوه ته لوړ کړو، لکه:
oc scale deployment recommendation-v2 --replicas=2 -n tutorial
اوس موږ د روټینګ قاعده ټاکو ترڅو ترافیک د پوډونو ترمینځ د 50/50 تناسب کې توزیع شي.
دلته د دې قاعدې پایله څه ښکاري:
تاسو کولی شئ د دې حقیقت سره غلطي ومومئ چې دا سکرین 50/50 نه دی ، مګر 14:9 دی ، مګر د وخت په تیریدو سره به وضعیت ښه شي.
خرابي کول
اوس راځئ چې د دوه v2 کانټینرونو څخه یو غیر فعال کړو ترڅو موږ یو صحي v1 کانټینر، یو صحي v2 کانټینر او یو غلط v2 کانټینر ولرو:
د خرابۍ حل کول
نو، موږ یو غلط کانټینر لرو، او دا د حوض ایجیکشن وخت دی. د خورا ساده ترتیب په کارولو سره ، موږ به دا ناکام کانټینر د 15 ثانیو لپاره د هر ډول روټینګ سکیمونو څخه لرې کړو په دې هیله چې دا به صحي حالت ته راستون شي (یا به بیا پیل یا فعالیت بحال کړي). دا هغه څه دي چې دا ترتیب ورته ښکاري او د دې کار پایلې:
لکه څنګه چې تاسو لیدلی شئ، ناکام شوی v2 کانټینر نور د روټینګ غوښتنو لپاره نه کارول کیږي ځکه چې دا د حوض څخه لیرې شوی. مګر د 15 ثانیو وروسته به دا په اوتومات ډول حوض ته راستون شي. په حقیقت کې، موږ یوازې وښودله چې د حوض ایجیکشن څنګه کار کوي.
راځئ چې د معمارۍ جوړول پیل کړو
د حوض Ejection، د اسټیو د څارنې وړتیاوو سره یوځای، تاسو ته اجازه درکوي چې په اتوماتيک ډول د نیمګړتیاو کانټینرونو ځای په ځای کولو لپاره د چوکاټ جوړول پیل کړئ ترڅو کم شي، که له منځه نه وي، د وخت کمولو او ناکامۍ.
ناسا یو لوړ شعار لري - ناکامي یو اختیار نه دی، چې لیکوال یې د الوتنې رییس ګڼل کیږي . دا په روسیه کې ژباړل کیدی شي "ناکامي یو اختیار نه دی" او دلته معنی دا ده چې هرڅه د کار کولو لپاره رامینځته کیدی شي که تاسو پوره اراده ولرئ. په هرصورت، په ریښتینې ژوند کې، ناکامۍ یوازې نه پیښیږي، دوی ناگزیر دي، په هر ځای او هرڅه کې. او د مایکرو خدماتو په قضیه کې د دوی سره څنګه معامله وکړئ؟ زموږ په اند، دا غوره ده چې په ارادې تکیه ونه کړئ، مګر د کانټینرونو په وړتیاوو، , او .
اسټیو، لکه څنګه چې موږ پورته لیکلي، د سرکټ ماتونکي مفهوم پلي کوي، کوم چې ځان په فزیکي نړۍ کې ښه ثابت کړی. او لکه څنګه چې د بریښنایی سرکیټ بریکر د سرکټ یوه ستونزه برخه بندوي ، د اسټیو سافټویر سرکټ بریکر د غوښتنې جریان او د ستونزې کانټینر ترمینځ اړیکه خلاصوي کله چې یو څه د پای ټکي کې غلط وي ، د مثال په توګه ، کله چې سرور خراب شو یا پیل شو. ورو کېدل.
سربیره پردې ، په دویمه قضیه کې یوازې ډیرې ستونزې شتون لري ، ځکه چې د یو کانټینر بریک نه یوازې دا چې دې ته لاسرسي خدماتو کې ځنډ رامینځته کوي او په پایله کې ، په ټولیز ډول د سیسټم فعالیت کموي ، بلکه تکرار هم رامینځته کوي. د دمخه ورو روان خدمت غوښتنه کوي ، کوم چې یوازې وضعیت لا پسې خرابوي.
په تیوري کې سرکټ بریکر
سرکټ بریکر یو پراکسي دی چې پای ټکي ته د غوښتنو جریان کنټرولوي. کله چې دا ټکی کار ودروي یا د ټاکل شوي تنظیماتو پورې اړه لري، ورو پیل کوي، پراکسي د کانټینر سره اړیکه ماتوي. ټرافیک بیا نورو کانټینرونو ته لیږدول کیږي، په ساده ډول د بار د توازن له امله. اړیکه د ورکړل شوي خوب کړکۍ لپاره خلاص پاتې کیږي ، دوه دقیقې ووایاست ، او بیا نیم خلاص ګڼل کیږي. د بلې غوښتنې لیږلو هڅه د پیوستون نور حالت ټاکي. که هرڅه د خدمت سره سم وي ، پیوستون بیرته کاري حالت ته راستون کیږي او بیا تړل کیږي. که چیرې لاهم په خدمت کې یو څه غلط وي ، اړیکه قطع شوې او د خوب کړکۍ بیا فعاله شوې. دلته هغه څه دي چې د ساده سرکټ بریکر حالت ډیاګرام داسې ښکاري:
دلته دا مهمه ده چې یادونه وکړو چې دا ټول د سیسټم جوړښت په کچه واقع کیږي. نو په یو وخت کې تاسو باید خپل غوښتنلیکونه د سرکټ بریکر سره کار کولو لپاره درس ورکړئ ، لکه په ځواب کې د ډیفالټ ارزښت چمتو کول یا که امکان ولري ، د خدماتو شتون له پامه غورځول. د دې لپاره د بلک سر نمونه کارول کیږي، مګر دا د دې مقالې له دائرې څخه بهر ده.
په عمل کې د سرکټ بریکر
د مثال په توګه، موږ به په OpenShift کې زموږ د سپارښتنې مایکرو سرویس دوه نسخې چلوو. نسخه 1 به ښه کار وکړي ، مګر په v2 کې به موږ په سرور کې د سستۍ سمولو لپاره په ځنډ کې جوړ کړو. د پایلو لیدلو لپاره، وسیله وکاروئ :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
داسې ښکاري چې هرڅه کار کوي، مګر په کوم قیمت؟ په لومړي نظر کې، موږ 100٪ شتون لرو، مګر یو نږدې نظر وګورئ - د لیږد اعظمي موده د 12 ثانیو په څیر ده. دا په ښکاره ډول یو خنډ دی او باید پراخ شي.
د دې کولو لپاره، موږ به اسټیو وکاروو ترڅو سست کانټینرونو ته زنګونه له مینځه یوسو. دا هغه څه دي چې ورته ترتیب د سرکټ بریکر کارولو په څیر ښکاري:
د httpMaxRequestsPerConnection پیرامیټر سره وروستنۍ کرښه دا نښه کوي چې اړیکه باید منحل شي کله چې د موجوده یو سربیره بل - دوهم - پیوستون رامینځته کولو هڅه کوي. له هغه ځایه چې زموږ کانټینر یو ورو خدمت سمبالوي ، نو دا ډول شرایط به په دوره توګه رامینځته شي ، او بیا به اسټیو 503 خطا بیرته راولي ، مګر دا هغه څه دي چې محاصره به وښیې:
سمه ده، موږ سرکټ بریکر لرو، بیا څه شی دی؟
نو، موږ پخپله د خدماتو سرچینې کوډ ته لمس کولو پرته اتوماتیک بندول پلي کړل. د سرکټ بریکر او د حوض ایجیکشن طرزالعمل په کارولو سره چې پورته تشریح شوي، موږ کولی شو د بریک کانټینرونه د سرچینې حوض څخه لرې کړو تر هغه چې دوی بیرته عادي حالت ته راشي، او په ټاکل شوي فریکونسۍ کې د دوی حالت وګورئ - زموږ په مثال کې، دا دوه دقیقې دي (د خوب وینډو پیرامیټر).
په یاد ولرئ چې د 503 غلطۍ ته د ځواب ورکولو لپاره د غوښتنلیک وړتیا لاهم د سرچینې کوډ په کچه ټاکل شوې. د وضعیت په پام کې نیولو سره د سرکټ بریکر کارولو لپاره ډیری ستراتیژۍ شتون لري.
په راتلونکي پوسټ کې: موږ به د هغه تعقیب او څارنې په اړه وغږیږو چې دمخه جوړ شوي یا په اسانۍ سره په اسټیو کې اضافه شوي ، او همدارنګه څنګه په سیسټم کې په قصدي ډول غلطۍ معرفي کول.
سرچینه: www.habr.com