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

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

موږ څنګه مایکرو خدماتو ته راغلو

Avito په نړۍ کې یو له خورا لوی محرم سایټونو څخه دی؛ هره ورځ له 15 ملیون څخه ډیر نوي اعلانونه خپریږي. زموږ پس منظر په هره ثانیه کې له 20 زرو څخه ډیر غوښتنې مني. موږ اوس مهال څو سوه کوچني خدمتونه لرو.

موږ د څو کلونو راهیسې د مایکرو سرویس معمارۍ رامینځته کوو. څنګه دقیقا - زموږ همکاران په تفصیل سره وویل زموږ په RIT++ 2017 برخه کې. په CodeFest 2017 کې (وګورئ. видео)، سرګي اورلوف او میخایل پروکوپچوک په تفصیل سره تشریح کړل چې ولې موږ مایکرو خدماتو ته لیږد ته اړتیا درلوده او دلته کوم رول لوبولی دی. ښه، اوس موږ د اندازه کولو لګښتونو کمولو لپاره هرڅه کوو چې په داسې جوړښت کې موجود دي.

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

اوس د PaaS CLI افادیت کې ، یو نوی خدمت د یوې کمانډ سره رامینځته شوی ، او یو نوی ډیټابیس د دوه نورو سره اضافه شوی او سټیج ته ځای په ځای شوی.

څنګه د "مایکرو سرویس ټوټې کولو" دور باندې بریالي شو

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

برسېره پردې، د دې لپاره چې د مایکرو سرویس جوړښت اغیزمن وي، ډیری پروسې باید تاسیس شي، یعنې:

• ننوتنه;
• د تعقیب غوښتنه (جیجر)؛
• د تېروتنې راټولول (سینټري)؛
• وضعیتونه، پیغامونه، پیښې د کوبرنیټس څخه (د پیښې جریان پروسس کول)؛
• د ریس حد / سرکټ ماتونکی (تاسو کولی شئ Hystrix وکاروئ)؛
• د خدماتو ارتباط کنټرول (موږ نیټرمیش کاروو)؛
• څارنه (Grafana)؛
• مجلس (TeamCity)؛
• اړیکه او خبرتیا (سلیک، بریښنالیک)؛
• د دندې تعقیب؛ (جیره)
• د اسنادو چمتو کول.

د دې لپاره چې ډاډ ترلاسه شي چې سیسټم خپل بشپړتیا له لاسه نه ورکوي او د اندازې په څیر اغیزمن پاتې کیږي، موږ په Avito کې د مایکرو خدماتو تنظیم بیا غور وکړ.

موږ څنګه د مایکرو خدماتو اداره کوو

د ډیری Avito مایکرو خدماتو ترمنځ د متحد "ګوند پالیسي" پلي کولو کې لاندې مرسته کوي:

• زیربناوې په پرتونو ویشل؛
• د خدمت (PaaS) مفهوم په توګه پلیټ فارم؛
• د هر هغه څه څارنه چې د مایکرو خدماتو سره پیښیږي.

د انفراسټرکچر خلاصون پرتونه درې پرتونه لري. راځئ چې له پورته څخه ښکته لاړ شو.

A. پورته - خدمت میش. په لومړي سر کې موږ د اسټیو هڅه وکړه، مګر دا معلومه شوه چې دا ډیری سرچینې کاروي، کوم چې زموږ د حجمونو لپاره خورا ګران دی. له همدې امله، د معمارۍ ټیم لوړ پوړی انجنیر الکساندر لوکیانچینکو خپل حل رامینځته کړ - نیترمیش (په خلاصې سرچینې کې شتون لري)، کوم چې موږ دا مهال په تولید کې کاروو او کوم چې د اسټیو په پرتله څو ځله لږ سرچینې مصرفوي (مګر هر هغه څه نه کوي چې اسټیو یې فخر کولی شي).
ب. منځنی – Kubernetes. موږ په دې کې کوچني خدمتونه ځای په ځای کوو او چلوو.
C. لاندینۍ برخه - نرۍ فلز. موږ بادل یا شیان نه کاروو لکه OpenStack، مګر په بشپړ ډول په فلزاتو تکیه کوو.

ټول پرتونه د PaaS لخوا یوځای شوي. او دا پلیټ فارم، په پایله کې، درې برخې لري.

I. جنراتورونه، د CLI کارونې له لارې کنټرول کیږي. دا هغه ده چې د پراختیا کونکي سره په سمه لاره او لږترلږه هڅې سره د مایکرو خدمت رامینځته کولو کې مرسته کوي.

II. جمع راټولونکی د یو عام ډشبورډ له لارې د ټولو وسیلو کنټرول سره.

III. ذخیره کول. د مهالویش کونکو سره وصل کیږي چې په اوتومات ډول د پام وړ کړنو لپاره محرکات تنظیموي. د داسې یو سیسټم څخه مننه، هیڅ یو کار له لاسه نه ورکول کیږي ځکه چې یو څوک په جیره کې د دندې ترتیب کول هیر کړي. موږ د دې لپاره د اطلس په نوم داخلي وسیله کاروو.

په Avito کې د مایکرو خدماتو پلي کول هم د یو واحد سکیم سره سم ترسره کیږي، کوم چې د پراختیا او خوشې کولو په هر پړاو کې د دوی کنټرول ساده کوي.

د معیاري مایکرو سرویس پرمختیا پایپ لاین څنګه کار کوي؟

په عموم کې، د مایکروسافټ جوړولو سلسله داسې ښکاري:

CLI- push → پرله پسې ادغام → پخول → ځای پرځای کول → مصنوعي ازموینې → کانري ازموینې → د سکوز ازموینه → تولید → ساتنه.

راځئ چې په دې ترتیب کې دقیقا له لارې لاړ شو.

CLI - push

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

په پای کې، موږ یو ساده CLI افادیت رامینځته کړی چې د مایکرو سرویس رامینځته کولو پرمهال لومړني مرحلې اتومات کوي. په حقیقت کې، دا د لومړي ګیټ فشار ځای نیسي. دلته هغه څه دي چې واقعیا یې کوي.

- د ټیمپلیټ مطابق خدمت رامینځته کوي - ګام په ګام ، په "وزرډ" حالت کې. موږ په Avito پس منظر کې د اصلي پروګرام کولو ژبو لپاره ټیمپلیټونه لرو: PHP، ګولنګ او پایتون.

- په یو وخت کې یو کمانډ په یو ځانګړي ماشین کې د ځایی پراختیا لپاره چاپیریال ځای په ځای کوي - مینیکیوب په لاره اچول کیږي، د هیلم چارټونه په اوتومات ډول رامینځته کیږي او په محلي کبرنیټ کې پیل کیږي.

- اړین ډیټابیس سره نښلوي. پرمخ وړونکی اړتیا نلري چې هغه ډیټابیس ته لاسرسی ومومي چې هغه ورته اړتیا لري IP ، ننوتل او پاسورډ وپیژني - دا په محلي توګه ، په مرحله کې یا په تولید کې وي. برسېره پردې، ډیټابیس سمدلاسه د غلطۍ زغمونکي ترتیب او توازن سره ځای په ځای شوی.

- دا پخپله ژوندۍ مجلس ترسره کوي. راځئ چې ووایو یو پرمخ وړونکي د خپل IDE له لارې په مایکرو سرویس کې یو څه سم کړي. افادیت د فایل سیسټم کې بدلونونه ګوري او د دوی پراساس ، غوښتنلیک (د ګولنګ لپاره) بیا رغوي او بیا پیل کوي. د PHP لپاره، موږ په ساده ډول د مکعب دننه ډایرکټر وړاندې کوو او هلته ژوندی بیالوډ "په اتوماتيک ډول" ترلاسه کیږي.

- اتومات ازموینې تولیدوي. د خالي په بڼه، مګر د کارولو لپاره خورا مناسب.

• د کوچنیو خدماتو ځای پرځای کول.

د مایکرو خدماتو ځای په ځای کول زموږ لپاره یو څه کار و. لاندې اړتیاوې وې:

I. Dockerfile.

II. ترتیب.
III. د هیلم چارټ، کوم چې پخپله پیچلی دی او پدې کې شامل دي:

- چارټونه پخپله؛
- کينډۍ؛
- ځانګړي ارزښتونه چې مختلف چاپیریالونه په پام کې نیسي.

موږ د کبرنیټس څرګندونو له بیا کار کولو څخه درد لرې کړی دی نو دا اوس په اوتومات ډول تولید شوي. مګر تر ټولو مهم، دوی محدودیت ته ګمارل ساده کړل. له اوس څخه موږ یو Dockerfile لرو، او پراختیا کونکی ټول تشکیل په یو واحد لنډ app.toml فایل کې لیکي.

هو، او پخپله په app.toml کې د یوې دقیقې لپاره هیڅ شی نشته. موږ مشخص کوو چې چیرې او څومره د خدماتو کاپي پورته کول (په dev سرور کې، په سټینګ کې، په تولید کې)، او د هغې انحصار په ګوته کوو. د [انجن] بلاک کې د کرښې اندازه = "کوچني" ته پام وکړئ. دا هغه حد دی چې د Kubernetes له لارې به خدمت ته تخصیص شي.

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

• بنسټیز تایید. دا ډول چکونه هم اتومات دي.
تعقیب ته اړتیا لري:
- ایا د ډاکر فایل شتون لري؛
- ایا app.toml شته؛
- آیا اسناد شته؟
- ایا انحصار په ترتیب سره دی؟
- ایا د خبرتیا مقررات ټاکل شوي دي.
وروستي ټکي ته: د خدماتو مالک پخپله ټاکي چې د کوم محصول میټریک څارنه وکړي.

• د اسنادو چمتو کول.
لاهم د ستونزې ساحه. دا خورا څرګند بریښي ، مګر په ورته وخت کې دا یو ریکارډ هم دی "اکثره هیر شوی" ، او له همدې امله په زنځیر کې یو زیان منونکی لینک.
دا اړینه ده چې د هر مایکرو خدمت لپاره اسناد شتون ولري. پدې کې لاندې بلاکونه شامل دي.

I. د خدمت لنډه توضیحات. په لفظي ډول یو څو جملې پدې اړه چې دا څه کوي او ولې ورته اړتیا ده.

II. د معمارۍ ډیاګرام لینک. دا مهمه ده چې دې ته په ګړندي نظر سره پوهیدل اسانه دي ، د مثال په توګه ، ایا تاسو د کیچ کولو لپاره ریډیس کاروئ یا په دوامداره حالت کې د اصلي ډیټا ذخیره په توګه. په Avito کې د اوس لپاره دا د کنفلوینس سره اړیکه ده.

III. د چلولو کتاب. د خدمت پیل کولو او د هغې د اداره کولو پیچلتیاو په اړه لنډ لارښود.

IV. پرله پسې پوښتنې، چیرې چې دا به ښه وي چې د هغه ستونزو وړاندوینه وکړئ چې ستاسو همکاران د خدمت سره کار کولو پرمهال ورسره مخ کیږي.

V. د API لپاره د پای ټکی تشریح. که ناڅاپه تاسو منزلونه مشخص نه کړي، هغه همکاران چې مایکرو خدمتونه ستاسو سره تړاو لري تقریبا یقینا د هغې لپاره پیسې ورکوي. اوس موږ سویګر کاروو او زموږ حل د دې لپاره لنډ نومیږي.

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

VII. د خدماتو مالک یا مالکین. په ډیری قضیو کې ، دا - یا دوی - د PaaS په کارولو سره په اوتومات ډول ټاکل کیدی شي ، مګر د خوندي اړخ لپاره ، موږ پراختیا کونکي ته اړتیا لرو چې دوی په لاسي ډول مشخص کړي.

په نهایت کې ، دا د اسنادو بیاکتنې لپاره ښه عمل دی ، د کوډ بیاکتنې ته ورته.

دوامداره یوځای کول

• د ذخیره کولو چمتو کول.
• په TeamCity کې د پایپ لاین جوړول.
• د حقونو تنظیم کول.
• د خدماتو مالکینو لټون. دلته یو هایبرډ سکیم شتون لري - د PaaS څخه لارښود نښه کول او لږترلږه اتومات کول. یو بشپړ اتوماتیک سکیم هغه وخت ناکامیږي کله چې خدمتونه بل پرمختیایی ټیم ته د ملاتړ لپاره لیږدول کیږي یا د مثال په توګه، که د خدماتو پراختیا کونکی پریږدي.
• په اطلس کې د خدمت راجستر کول (پورته وګورئ). د دې ټولو مالکینو او انحصارونو سره.
• مهاجرتونه چک کول. موږ ګورو چې ایا کوم یو یې احتمالي خطرناک دي. د مثال په توګه، په دوی کې یو د بدلون میز یا بل څه پاپ اپ کیږي چې کولی شي د خدماتو مختلف نسخو ترمنځ د ډیټا سکیما مطابقت مات کړي. بیا مهاجرت نه ترسره کیږي ، مګر په ګډون کې ځای په ځای شوی - PaaS باید د خدماتو مالک ته سیګنال ورکړي کله چې دا د کارولو لپاره خوندي وي.

پخول

بل مرحله د ځای پرځای کولو دمخه د بسته بندۍ خدمات دي.

• د غوښتنلیک جوړول. د کلاسیک په وینا - د ډاکر عکس کې.
• پخپله د خدمت او اړوندو سرچینو لپاره د هیلم چارټونو رامینځته کول. د ډیټابیس او کیچ لپاره په شمول. دوی په اتوماتيک ډول د app.toml ترتیب سره سم رامینځته شوي چې د CLI-push مرحله کې رامینځته شوي.
• د بندرونو خلاصولو لپاره د مدیرانو لپاره د ټکټونو رامینځته کول (کله چې اړتیا وي).
• د واحد ازموینې چلول او د کوډ پوښښ محاسبه کول. که چیرې د کوډ پوښښ د ټاکل شوي حد څخه ښکته وي، نو ډیری احتمال به خدمت نوره نه ځي - د ځای پرځای کولو لپاره. که چیرې دا د منلو وړ وي، نو بیا به خدمت ته د "بې حسه کولو" کوفیسینټ وټاکل شي: بیا، که چیرې د وخت په تیریدو سره په شاخص کې کوم پرمختګ ونشي، پراختیا کوونکی به یو خبرتیا ترلاسه کړي چې د ازموینو په شرایطو کې هیڅ پرمختګ شتون نلري ( او په دې اړه باید یو څه وشي).
• د حافظې او CPU محدودیتونو لپاره محاسبه. موږ په عمده توګه په ګولنګ کې مایکرو خدمتونه لیکو او په کوبرنیټس کې یې چلوو. له همدې امله د ګولنګ ژبې ځانګړتیا سره یو فرعي تړاو لري: د ډیفالټ له مخې ، کله چې پیل کیږي ، په ماشین کې ټول کورونه کارول کیږي ، که تاسو په واضح ډول د GOMAXPROCS متغیر تنظیم نه کړئ ، او کله چې په ورته ماشین کې ډیری ورته خدمتونه پیل شي ، دوی پیل کیږي. د سرچینو لپاره سیالي کول، د یو بل سره مداخله کول. لاندې ګرافونه ښیې چې څنګه د اجرا کولو وخت بدلیږي که تاسو غوښتنلیک پرته له کوم جنجال او د سرچینو حالت لپاره په سیالۍ کې پرمخ وړئ. (د ګرافونو سرچینې دي دلته).

د اجرا کولو وخت، لږ ښه دی. اعظمي: 643ms، لږ تر لږه: 42ms. عکس د کلیک کولو وړ دی.

د جراحي لپاره وخت، لږ ښه دی. اعظمي: 14091 ns، لږ تر لږه: 151 ns. عکس د کلیک کولو وړ دی.

د غونډې د چمتو کولو په مرحله کې، تاسو کولی شئ دا متغیر په واضح ډول تنظیم کړئ یا تاسو کولی شئ د کتابتون څخه کار واخلئ automaxprocs د اوبر د هلکانو څخه.

ګمارل

• د کنوانسیونونو چک کول. مخکې لدې چې تاسو خپل ټاکل شوي چاپیریال ته د خدماتو مجلسونو وړاندې کول پیل کړئ ، تاسو اړتیا لرئ لاندې وګورئ:
- د API پای ټکي.
- د سکیما سره د API پای ټکی ځوابونو اطاعت.
- د ننوتلو بڼه.
- خدمت ته د غوښتنو لپاره د سرلیکونو ترتیب کول (اوس مهال دا د نیټرمیش لخوا ترسره کیږي)
- د پیښې بس ته د پیغامونو لیږلو پرمهال د مالک نښه تنظیم کول. دا د بس په اوږدو کې د خدماتو ارتباط تعقیبولو لپاره اړین دی. تاسو کولی شئ دواړه د پام وړ ډیټا بس ته واستوئ، کوم چې د خدماتو ارتباط نه زیاتوي (کوم چې ښه دی)، او د سوداګرۍ ډیټا چې د خدماتو ارتباط پیاوړی کوي (کوم چې خورا خراب دی!). او په هغه وخت کې کله چې دا ارتباط یوه مسله شي ، پدې پوهیدل چې څوک لیکي او لوستل کوي بس د خدماتو په سمه توګه جلا کولو کې مرسته کوي.

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

مصنوعي ازموینې

• تړل شوی لوپ ازموینه. د دې لپاره موږ اوس خلاصې سرچینې کاروو Hoverfly.io. لومړی، دا په خدمت کې اصلي بار ثبتوي، بیا - یوازې په تړل شوي لوپ کې - دا یې تقلید کوي.

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

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

a) موږ ټول بار ته ګورو.
- ډیر کوچنی - ډیری احتمال یو څه کار نه کوي که چیرې بار ناڅاپه څو ځله راټیټ شي.
- ډیر لوی - اصلاح کول اړین دي.

b) موږ د RPS مطابق کټ آف ګورو.
دلته موږ د اوسنۍ نسخې او پخوانۍ نسخې او ټول مقدار ترمینځ توپیر ګورو. د مثال په توګه، که چیرې یو خدمت 100 rps تولید کړي، نو دا یا په خرابه توګه لیکل شوی، یا دا د هغې ځانګړتیا ده، مګر په هر حالت کې، دا یو دلیل دی چې خدمت ته ډیر نږدې وګورئ.
که ، برعکس ، ډیری RPS شتون لري ، نو بیا شاید یو ډول بګ شتون ولري او ځینې پای ټکي د تادیې اجرا کول بند کړي ، او ځینې نور په ساده ډول پیل شوي. return true;

کانري ازموینې

وروسته له دې چې موږ مصنوعي ازموینې تیرې کړو، موږ په لږ شمیر کاروونکو باندې د مایکرو سرویس ازموینه کوو. موږ په احتیاط سره پیل کوو، د خدماتو د ټاکل شوي لیدونکو د یوې کوچنۍ برخې سره - له 0,1٪ څخه کم. پدې مرحله کې ، دا خورا مهم دي چې سم تخنیکي او محصول میټریکونه په نظارت کې شامل شي ترڅو دوی ژر تر ژره په خدمت کې ستونزه وښیې. د کانري ازموینې لپاره لږترلږه وخت 5 دقیقې دی، اصلي 2 ساعته دی. د پیچلو خدماتو لپاره، موږ وخت په لاسي ډول تنظیم کوو.
راځئ چې تحلیل وکړو:
- د ژبې ځانګړي میټریکونه، په ځانګړې توګه، د php-fpm کارکونکي؛
- په سینټري کې تېروتنې؛
د غبرګون حالتونه؛
- د غبرګون وخت، دقیق او اوسط؛
- ځنډ
- استثناوې، پروسس شوي او نه سمبال شوي؛
- د محصول اندازه.

د سکوت ازموینه

Squeeze Testing ته "squeezing" testing هم ویل کیږي. د تخنیک نوم په Netflix کې معرفي شو. د دې جوهر دا دی چې لومړی موږ د ناکامۍ نقطې ته د ریښتیني ترافیک سره یو مثال ډکوو او پدې توګه یې حد ټاکو. بیا موږ یو بل مثال اضافه کوو او دا جوړه پورته کوو - بیا تر اعظمي حد پورې؛ موږ د دوی چت او ډیلټا د لومړي "چوک" سره ګورو. او نو موږ په یو وخت کې یو مثال سره وصل کوو او د بدلونونو نمونه محاسبه کوو.
د "چچلو" له لارې د ازموینې ډاټا هم یو عام میټریک ډیټابیس ته ځي، چیرې چې موږ یا د دوی سره د مصنوعي بار پایلې بډایه کوو، یا حتی د دوی سره "مصنوعی" ځای په ځای کوو.

تولید

• اندازه کول. کله چې موږ تولید ته خدمت وړاندې کوو، موږ څارنه کوو چې دا څنګه اندازه کیږي. زموږ په تجربه کې، یوازې د CPU شاخصونو څارنه غیر اغیزمنه ده. په خپل خالص شکل کې د RPS بنچمارکینګ سره اتومات اندازه کول کار کوي ، مګر یوازې د ځینې خدماتو لپاره ، لکه آنلاین سټریمینګ. نو موږ لومړی د غوښتنلیک ځانګړي محصول میټریکونو ته ګورو.

د پایلې په توګه، کله چې اندازه کول موږ تحلیل کوو:
- د CPU او رام شاخصونه،
- په کتار کې د غوښتنو شمیر،
- د غبرګون وخت
- وړاندوینه د راټول شوي تاریخي معلوماتو پراساس.

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

خدمت

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

دلته عادي حالتونه دي په کوم کې چې محرکات واقع کیږي.
- احتمالي خطرناک مهاجرتونه کشف شوي.
- امنیتي تازه معلومات خپاره شوي.
- خدمت پخپله د اوږدې مودې لپاره نه دی تازه شوی.
- په خدمت باندې بار د پام وړ کم شوی یا د دې ځینې محصول میټریکونه د نورمال حد څخه بهر دي.
- خدمت نور د نوي پلیټ فارم اړتیاوې نه پوره کوي.

ځینې ​​محرکونه د عملیاتو ثبات لپاره مسؤل دي ، ځینې - د سیسټم ساتنې فعالیت په توګه - د مثال په توګه ، ځینې خدمتونه د اوږدې مودې لپاره ندي ګمارل شوي او د دې اساس عکس د امنیت چکونو تیریدل بند کړي.

ډشبورډ

په لنډه توګه، ډشبورډ زموږ د ټول PaaS کنټرول پینل دی.

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

ټول

د PaaS معرفي کولو دمخه، یو نوی پرمخ وړونکی کولی شي څو اونۍ په تولید کې د مایکرو سرویس پیل کولو لپاره د ټولو اړینو وسیلو په پوهیدو کې تیر کړي: Kubernetes، Helm، زموږ د ټیم سیټي داخلي ځانګړتیاوې، د ډیټابیسونو او کیچونو سره په غلطۍ سره د اړیکو تنظیم کول، او داسې نور. د چټک پیل لوستلو لپاره څو ساعته وخت نیسي او پخپله خدمت رامینځته کوي.

ما د دې موضوع په اړه د HighLoad++ 2018 لپاره راپور ورکړ، تاسو یې لیدلی شئ видео и پریزنټیشن.

د هغو کسانو لپاره د بونس ټریک چې پای ته یې لوستل

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

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

تاسو کولی شئ د ګډون لپاره غوښتنه وکړئ په دې ګوګل فورمه کې. له تاسو څخه - د دې پوښتنې ځواب چې ولې تاسو اړتیا لرئ په روزنې کې برخه واخلئ او معلومات چې تاسو سره اړیکه ونیسئ. په انګلیسي کې ځواب ورکړئ، ځکه چې کریس به هغه ګډون کوونکی وټاکي چې پخپله روزنه کې ګډون وکړي.
موږ به د روزنې برخه اخیستونکي نوم پدې پوسټ کې او په ټولنیزو شبکو کې د پراختیا کونکو لپاره Avito کې اعلان کړو (AvitoTech in فیسبوک, Vkontakte, ټویټر) د جولای له 19 څخه وروسته.

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