د خدمت په توګه څارنه: د مایکرو سرویس معمارۍ لپاره ماډلر سیسټم

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

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

تېر: طرحې او پلانونه

موږ څنګه د څارنې اوسني سیسټم ته ورسیدو؟ د دې پوښتنې ځواب لپاره، تاسو اړتیا لرئ چې 2015 ته لاړ شئ. دا هغه څه دي چې بیا ورته ښکاري:

موږ شاوخوا 24 نوډونه درلودل چې د څارنې مسؤلیت یې درلود. دلته د مختلف تاجونو ، سکریپټونو ، ډیمونونو بشپړ کڅوړه شتون لري چې په یو ډول یو څه څارنه کوي ، پیغامونه لیږي او دندې ترسره کوي. موږ فکر کاوه چې هرڅومره چې موږ لاړ شو، دا ډول سیسټم به لږ ګټور وي. د دې پراختیا لپاره هیڅ معنی نشته: دا خورا پیچلی دی.
موږ پریکړه وکړه چې د څارنې هغه عناصر غوره کړو چې موږ به یې وساتو او وده وکړو، او هغه چې موږ یې پریږدو. په دوی کې 19 شتون درلود، یوازې ګرافیټونه، راټولونکي او ګرافانا د ډشبورډ په توګه پاتې دي. خو نوی نظام به څه ډول وي؟ لکه دغه:

موږ د میټریک ذخیره لرو: دا ګرافیټونه دي ، کوم چې د ګړندي SSD ډرایو پراساس وي ، دا د میټریکونو لپاره ځانګړي راټولونکي دي. بل - د ډشبورډونو ښودلو لپاره ګرافانا او د خبرتیا لپاره مورا. موږ هم غوښتل چې د بې نظمیو د لټون لپاره یو سیسټم رامینځته کړو.

معیاري: څارنه 2.0

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

• دوامداره شتون؛
• د میټریک ذخیره کولو وقفه = 10 ثانیې؛
• د میټریکونو او ډشبورډونو جوړښت شوی ذخیره؛
• SLA > 99,99%
• د UDP (!) له لارې د پیښو میټریکونو راټولول.

موږ UDP ته اړتیا درلوده ځکه چې موږ د ترافیک او پیښو لوی جریان لرو چې میټریکونه رامینځته کوي. که تاسو دا ټول په یو وخت کې په ګرافیټ کې ولیکئ، ذخیره به سقوط وکړي. موږ د ټولو میترونو لپاره د لومړۍ درجې مختګونه هم غوره کړل.

هر مختګ یو څه ملکیت لري. د سرورونو، شبکو، کانټینرونو، سرچینو، غوښتنلیکونو او داسې نورو لپاره میټریکونه شتون لري. روښانه، سخت، ټایپ شوي فلټر کول پلي شوي، چیرې چې موږ د لومړۍ درجې میټریکونه منو او پاتې یې په ساده ډول پریږدو. دا څنګه موږ دا سیسټم په 2015 کې پلان کړ. په اوسني وخت کې څه دي؟

اوسنی: د څارنې اجزاو د تعامل ډیاګرام

له هرڅه دمخه ، موږ غوښتنلیکونه څارو: زموږ د پی ایچ پی کوډ ، غوښتنلیکونه او مایکرو خدمات - په لنډه توګه ، هرڅه چې زموږ پراختیا کونکي لیکي. ټول غوښتنلیکونه میټریکونه د UDP له لارې بروبیک راټولونکي ته لیږي (statsd، په C کې بیا لیکل شوی). دا په مصنوعي ازموینو کې ترټولو ګړندی ثابت شو. او دا دمخه راټول شوي میټریکونه د TCP له لارې ګرافیټ ته لیږي.

دا یو ډول میټریک لري چې د ټایمر په نوم یادیږي. دا یو ډیر اسانه شی دی. د مثال په توګه، د خدمت سره د هر کاروونکي پیوستون لپاره، تاسو بربیک ته د ځواب وخت سره میټریک لیږئ. یو ملیون ځوابونه راغلل، مګر راټولونکي یوازې 10 میټریکونه بیرته راستانه کړل. تاسو د هغو خلکو شمیر لرئ چې راغلي، اعظمي، لږترلږه او اوسط غبرګون وخت، منځنۍ او 4 فیصده. بیا ډاټا ګرافیت ته لیږدول کیږي او موږ دا ټول ژوندی ګورو.

موږ د هارډویر، سافټویر، سیسټم میټریکونو او زموږ د زاړه مونین څارنې سیسټم (دا زموږ لپاره تر 2015 پورې کار کاوه). موږ دا ټول د C's CollectD ډیمون له لارې راټولوو (دا د مختلف پلگ انونو ټوله ډله لري چې په کې جوړ شوي، دا کولی شي د کوربه سیسټم ټولې سرچینې رایه ورکړي چې دا نصب شوی وي، یوازې په ترتیب کې مشخص کړئ چیرې چې ډاټا لیکل کیږي) او د هغې له لارې ګرافیت ته ډاټا ولیکئ. دا د python پلگ انونو او شیل سکریپټونو ملاتړ هم کوي ، نو تاسو کولی شئ خپل دودیز حلونه ولیکئ: CollectD به دا ډاټا د ځایی یا لرې کوربه کوربه (فرض کولو Curl) څخه راټول کړي او ګرافیټ ته یې واستوي.

بیا موږ ټول میټریکونه لیږو چې موږ کاربن-c-ریلي ته راټول کړل. دا د ګرافیت څخه د کاربن ریل حل دی، په C کې تعدیل شوی. دا یو روټر دی چې ټول هغه میټریکونه راټولوي چې موږ یې د خپلو راټولونکو څخه لیږو او نوډونو ته یې لیږدوو. همدارنګه د روټینګ په مرحله کې، دا د میټریک اعتبار چک کوي. لومړی، دوی باید د مخکینۍ سکیم سره مطابقت ولري چې ما مخکې ښودلی او دوهم، دوی د ګرافیت لپاره اعتبار لري. که نه نو دوی به پریږدي.

کاربن-c-ریلي بیا میټریکونه د ګرافیت کلستر ته لیږي. موږ کاربن کیچ کاروو، په Go کې بیا لیکل شوی، د میټریک اصلي ذخیره په توګه. Go-carbon، د خپل څو اړخیزه کولو له امله، د کاربن کیچ څخه ډیر ښه کار کوي. دا ډاټا ترلاسه کوي او د ویسپر پیکج په کارولو سره ډیسکونو ته لیکي (معیاري، په پیتون کې لیکل شوي). زموږ د ذخیره کولو څخه د معلوماتو لوستلو لپاره، موږ د Graphite API کاروو. دا د معیاري ګرافیت ویب په پرتله خورا ګړندی دی. بیا د معلوماتو سره څه کیږي؟

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

راځئ نور لاړ شو: خبرتیا. دا د قوي سیسټم په کارولو سره تنظیم شوی - موریرا. دا خپلواک دی ځکه چې دا د هود لاندې خپل ګرافیت لري. د SKB "کونټور" څخه د هلکانو لخوا رامینځته شوی ، په python او Go کې لیکل شوی ، په بشپړ ډول خلاص سرچینه. Moira ورته جریان ترلاسه کوي چې ګرافیت ته ځي. که د کوم دلیل لپاره ستاسو ذخیره مړه شي، ستاسو خبرتیا به لاهم کار وکړي.

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

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

موږ د خبرتیا لپاره خپل پرمختګ هم کاروو - Imagotag. موږ پینل تطابق کړی، کوم چې معمولا په پلورنځیو کې د بریښنایی نرخ ټاګونو لپاره کارول کیږي ، زموږ اړتیاو سره سم. موږ دې ته له مویرا څخه محرکونه راوړل. دا په ګوته کوي چې دوی په کوم حالت کې دي او کله پیښ شوي. ځینې ​​پرمختیایی هلکان د دې پینل په ګټه په سلیک او بریښنالیک کې خبرتیاوې پریږدي.

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

د څارنې برخې

دلته د هغو برخو لپاره د لینکونو لیست دی چې موږ یې د دې کار لپاره کاروو. دا ټول خلاصې سرچینې دي.

ګرافیت:

• کاربن github.com/lomik/go-carbon
• چیغې وهل: github.com/graphite-project/whisper
• graphite-api: github.com/brutasse/graphite-api

کاربن-سي-ریلی:

github.com/grobian/carbon-c-relay

بربیک:

github.com/github/brubeck

راټول شوي:

collected.org

مور:

github.com/moira-alert

ګرافانا:

grafana.com

هیپسټر:

github.com/kubernetes/heapster

Статистика

او دلته ځینې شمیرې دي چې سیسټم زموږ لپاره څنګه کار کوي.

راټولونکی (بربیک)

د میټریکونو شمیر: ~ 300/sec
ګرافیت ته د میټریک لیږلو لپاره وقفه: 30 ثانیې
د سرور سرچینې کارول: ~ 6٪ CPU (موږ د بشپړ سرورونو په اړه خبرې کوو)؛ ~ 1 جي بي RAM؛ ~3 Mbps LAN

ګرافیت (ګو-کاربن)

د میټریکونو شمیر: ~ 1 / min
د میټریک تازه کولو وقفه: 30 ثانیې
د میټریک ذخیره کولو سکیم: 30sec 35d، 5min 90d، 10min 365d (تاسو ته پوهه درکوي چې د اوږدې مودې لپاره خدمت ته څه پیښیږي)
د سرور سرچینې کارول: ~ 10٪ CPU؛ ~ 20GB رام؛ ~30 Mbps LAN

انعطاف

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

دلته د اصلي ستونزې یوه بیلګه ده. په ګرافیټ کې میټریک یوه فایل دی. دا یو نوم لري. د فایل نوم = میټریک نوم. او هلته د رسیدو لپاره لاره شتون لري. په لینکس کې د فایل نومونه تر 255 حروف پورې محدود دي. او موږ د ډیټابیس ډیپارټمنټ څخه (د "داخلي پیرودونکو" په توګه) هلکان لرو. دوی موږ ته وايي: "موږ غواړو زموږ د SQL پوښتنو څارنه وکړو. او دوی 255 حروف نه دي، مګر هر یو 8 MB. موږ غواړو دا په ګرافانا کې ښکاره کړو، د دې غوښتنې لپاره پیرامیټونه وګورو، او حتی غوره، موږ غواړو د داسې غوښتنو سر وګورو. دا به ښه وي که چیرې دا په ریښتیني وخت کې ښکاره شي. دا به واقعیا ښه وي چې دوی په خبرتیا کې واچول شي."

د مثال په توګه د SQL پوښتنې څخه د مثال په توګه اخیستل کیږي سایټ postgrespro.ru

موږ د ریډیس سرور رامینځته کوو او زموږ راټول شوي پلگ انونه کاروو ، کوم چې پوسټګریس ته ځي او له هغه ځایه ټول معلومات اخلي ، ګرافیټ ته میټریکونه لیږي. مګر موږ د میټریک نوم د هشونو سره بدلوو. موږ په ورته وخت کې ورته هش Redis ته د کیلي په توګه لیږو، او د SQL ټول پوښتنه د ارزښت په توګه. ټول هغه څه چې موږ یې باید ترسره کړو ډاډ ترلاسه کړو چې ګرافانا کولی شي ریډیس ته لاړ شي او دا معلومات واخلي. موږ د ګرافیټ API خلاص کوو ځکه چې ... دا د ګرافائٹ سره د څارنې د ټولو اجزاوو د تعامل لپاره اصلي انٹرفیس دی، او موږ هلته یو نوی فنکشن داخلوو چې د aliasByHash() په نوم یادیږي - د ګرافانا څخه موږ د میټریک نوم ترلاسه کوو، او دا د کلیدي په توګه د Redis په غوښتنه کې کاروو. ځواب موږ د کیلي ارزښت ترلاسه کوو، کوم چې زموږ د "SQL پوښتنه" ده په دې توګه، موږ په ګرافانا کې د SQL پوښتنې یوه نمونه ښودلې، کوم چې په تیورۍ کې د احصایې سره سره هلته ښودل ناممکن وو (زنګونه، قطار، ټول_ وخت، ...).

پایلې

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

باور ټولې برخې د خطا زغمونکي دي او زموږ بارونه ښه اداره کوي.

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

خپلواکي. تاسو کولی شئ دا ټول پخپله د DevOps انجینرانو مرستې پرته ترسره کړئ. او دا یوه ګټه ده، ځکه چې تاسو کولی شئ همدا اوس خپله پروژه وڅارئ، تاسو اړتیا نلرئ له چا څخه وپوښتئ - یا د کار پیل کولو یا بدلونونو لپاره.

موږ د څه لپاره هدف یو؟

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

1. د بې نظمۍ کشف کونکی. موږ غواړو یو داسې خدمت رامینځته کړو چې زموږ د ګرافیټ ذخیره کولو ته لاړ شي او د مختلف الګوریتمونو په کارولو سره هر میټریک چیک کړي. دلته دمخه الګوریتمونه شتون لري چې موږ یې غواړو وګورو، معلومات شتون لري، موږ پوهیږو چې څنګه ورسره کار وکړو.
2. میټاډاټا. موږ ډیری خدمتونه لرو، دوی د وخت په تیریدو سره بدلیږي، لکه د خلکو په څیر چې ورسره کار کوي. په دوامداره توګه په لاسي ډول د اسنادو ساتل یو اختیار ندی. له همدې امله موږ اوس زموږ مایکرو خدماتو کې میټاډاټا ځای په ځای کوو. دا په ګوته کوي چې چا دا وده کړې، کومې ژبې چې ورسره اړیکه لري، د SLA اړتیاوې، چیرته او چا ته باید خبرتیاوې واستول شي. کله چې د خدماتو ځای په ځای کول، د ادارې ټول معلومات په خپلواک ډول جوړ شوي. د پایلې په توګه، تاسو دوه لینکونه ترلاسه کوئ - یو د محرک کولو لپاره، بل په ګرافانا کې ډشبورډونو ته.
3. په هر کور کې څارنه. موږ باور لرو چې ټول پراختیا کونکي باید دا ډول سیسټم وکاروي. په دې حالت کې، تاسو تل پوهیږئ چې ستاسو ټرافيک چیرته دی، څه پیښیږي، چیرته راښکته کیږي، چیرته چې د هغې ضعفونه دي. که د مثال په توګه، یو څه راشي او ستاسو خدمت خراب کړي، نو تاسو به د دې په اړه د مدیر څخه د تلیفون په جریان کې نه، مګر د خبرتیا څخه زده کړئ، او تاسو کولی شئ سمدستي وروستي لاګونه پرانیزئ او وګورئ چې هلته څه پیښ شوي.
4. لوړ فعالیت. زموږ پروژه په دوامداره توګه وده کوي، او نن ورځ دا په یوه دقیقه کې شاوخوا 2 میټریک ارزښتونه پروسس کوي. یو کال دمخه، دا شمیره 000 وه. او وده دوام لري، او دا پدې مانا ده چې یو څه وخت وروسته ګرافیت (ویسپر) به د ډیسک فرعي سیسټم په ډیره اندازه بارول پیل کړي. لکه څنګه چې ما مخکې وویل، دا د څارنې سیسټم د اجزاوو د تبادلې له امله خورا نړیوال دی. یو څوک ساتي او په دوامداره توګه خپل زیربناوې په ځانګړي ډول د ګرافیت لپاره پراخوي ، مګر موږ پریکړه وکړه چې بله لاره لاړ شو: کارول ټک هاوس زموږ د میټریکونو لپاره د ذخیره کولو په توګه. دا لیږد تقریبا بشپړ شوی دی، او ډیر ژر به زه تاسو ته په تفصیل سره ووایم چې دا څنګه ترسره شوي: کوم مشکلات شتون درلود او دوی څنګه بریالي شوي، د مهاجرت پروسه څنګه پرمخ تللې، زه به هغه برخې تشریح کړم چې د پابندۍ په توګه غوره شوي او د دوی تشکیلات.

له پاملرنې څخه مو مننه! د موضوع په اړه خپلې پوښتنې وپوښتئ، زه به هڅه وکړم چې دلته یا په لاندې پوسټونو کې ځواب ورکړم. شاید یو څوک د ورته نظارت سیسټم رامینځته کولو تجربه ولري یا په ورته حالت کې کلیک هاؤس ته لاړ شي - په نظرونو کې یې شریک کړئ.

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