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

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

راځئ هڅه وکړو چې معلومات فلټر کړو او اساسي فورمول ولیکئ. موږ به زموږ د نوي عکس شریکولو سایټ Graminsta ګام په ګام له 1 څخه تر 100 کاروونکو اندازه کړو.

راځئ چې ولیکئ چې کوم ځانګړي اقدامات باید ترسره شي کله چې لیدونکي 10، 100، 1000، 10،000 او 100،000 خلکو ته لوړ شي.

1 کاروونکي: 1 ماشین

نږدې هر غوښتنلیک، دا ویب پاڼه یا ګرځنده غوښتنلیک وي، درې کلیدي برخې لري:

• API
• ډیټابیس
• پیرودونکي (د ګرځنده غوښتنلیک پخپله یا ویب پاڼه)

ډیټابیس دوامداره معلومات ذخیره کوي. API د دې معلوماتو او شاوخوا شاوخوا غوښتنې وړاندې کوي. پیرودونکي کارونکي ته معلومات لیږدوي.

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

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

په تیوري کې، موږ کولی شو دا په بادل کې په یو واحد ډیجیټل اوشین ډراپټ یا AWS EC2 مثال کې ځای په ځای کړو، لکه څنګه چې لاندې ښودل شوي:

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

10 کاروونکي: ډیټابیس جلا کچې ته لیږدول

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

دا هغه څه دي چې اوس سیسټم ورته ښکاري:

100 کاروونکي: د پیرودونکي جلا کچې ته لیږدول

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

له همدې امله زه غواړم د پیرودونکي په اړه فکر وکړم چې د API څخه جلا دی. دا د ډیری پلیټ فارمونو لپاره د پراختیا په اړه فکر کول خورا اسانه کوي: ویب ، ګرځنده ویب ، iOS ، Android ، ډیسټاپ غوښتنلیکونه ، د دریمې ډلې خدمات او نور. دا ټول یوازې پیرودونکي دي چې ورته API کاروي.

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

دا هغه څه دي چې دا ډول سیسټم ورته ښکاري:

1000 کاروونکي: د بار توازن اضافه کړئ

شیان ګوري. د Graminsta کاروونکي ډیر او ډیر عکسونه اپلوډ کوي. د نوم لیکنې شمیر هم مخ په ډیریدو دی. زموږ یوازینی API سرور د ټولو ترافیک سره ساتل سخت وخت لري. ډیر اوسپنې ته اړتیا لرئ!

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

موږ د ویب پیرودونکي مخې ته او د API مخې ته جلا جلا بار بیلانسونه ځای په ځای کوو. دا پدې مانا ده چې تاسو کولی شئ د API کوډ او ویب مراجعینو کوډ چلولو ډیری مثالونه پرمخ بوځي. د بار توازن کونکي به سرور ته غوښتنې مستقیم کړي چې لږ بار شوي وي.

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

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

د بار بیلنسر سره، د API کچه تقریبا په غیر مستقیم ډول اندازه کیدی شي، په ساده ډول د غوښتنو شمیر زیاتیدو سره نوي مثالونه اضافه کول.

نوټ. همدا اوس زموږ سیسټم خورا ورته دی چې د PaaS شرکتونه لکه Heroku یا Elastic Beanstalk په AWS کې د بکس څخه بهر وړاندیز کوي (له همدې امله دوی خورا مشهور دي). هیروکو ډیټابیس په جلا کوربه کې اچوي، د اتوماتیک اندازه کولو بار بیلانس اداره کوي، او تاسو ته اجازه درکوي چې د API څخه جلا ویب مراجعین کوربه کړئ. دا د لومړنیو مرحلو پروژو یا پیل کولو لپاره د هیروکو کارولو عالي دلیل دی - تاسو ټول لومړني خدمات له بکس څخه ترلاسه کوئ.

10 کاروونکي: CDN

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

پدې مرحله کې ، تاسو اړتیا لرئ د جامد مینځپانګې ذخیره کولو لپاره د کلاوډ خدمت وکاروئ - عکسونه ، ویډیوګانې او نور ډیر څه (AWS S3 یا ډیجیټل سمندري ځایونه). په عموم کې، زموږ API باید د شیانو د سمبالولو څخه ډډه وکړي لکه د انځورونو خدمت کول او سرور ته د انځورونو پورته کول.

د کلاوډ کوربه توب بله ګټه د CDN ده (AWS دا اضافه Cloudfront بولي، مګر د کلاوډ ذخیره کولو ډیری چمتو کونکي دا د بکس څخه بهر وړاندیز کوي). CDN په اوتومات ډول زموږ عکسونه د نړۍ په مختلفو ډیټا مرکزونو کې ذخیره کوي.

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

100 کاروونکي: د معلوماتو پرت اندازه کول

CDN ډیره مرسته کړې: ترافیک په بشپړ سرعت وده کوي. مشهور ویډیو بلاګر ماویډ موبریک یوازې زموږ سره راجستر شوی او خپله "کیسه" یې پوسټ کړې ، لکه څنګه چې دوی وايي. د بار بیلنس څخه مننه، د API سرورونو کې د CPU او حافظې کارول ټیټ ساتل شوي (د API لس مثالونه روان دي)، مګر موږ د غوښتنو ډیری وخت پای ته رسیدو پیل کوو ... دا ځنډ له کوم ځای څخه راځي؟

په میټریکونو کې یو څه کیندل ، موږ ګورو چې په ډیټابیس سرور کې CPU 80-90٪ بار شوی. موږ په حد کې یو.

د معلوماتو پرت اندازه کول شاید د مساواتو ترټولو ستونزمن برخه وي. د API سرورونه بې ریاست غوښتنې وړاندې کوي، نو موږ په ساده ډول د API نور مثالونه اضافه کوو. پوزه ډیری ډیټابیس دا نشي کولی. موږ به د مشهور اړوند ډیټابیس مدیریت سیسټمونو (PostgreSQL، MySQL، او نور) په اړه وغږیږو.

کیشینګ

زموږ د ډیټابیس فعالیت زیاتولو لپاره یوه له اسانه لارو څخه د نوي برخې معرفي کول دي: د کیچ پرت. د کیچ کولو ترټولو عام میتود د حافظې د کلیدي ارزښت ریکارډ پلورنځی دی ، لکه ریډیس یا میم کیچ. ډیری کلاوډونه د دې خدماتو اداره شوي نسخه لري: په AWS کې Elasticache او په ګوګل کلاوډ کې Memorystore.

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

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

موږ به پایلې د کیلي په واسطه په Redis کې د ډیټابیس څخه ذخیره کړو user:id د 30 ثانیو د اعتبار موده سره. اوس، کله چې یو څوک د موبریک پروفایل ته ځي، موږ لومړی د ریډیس چک کوو، او که چیرې ډاټا شتون ولري، موږ په ساده ډول د ریډیس څخه لیږدوو. اوس په سایټ کې خورا مشهور پروفایل ته غوښتنې په عملي ډول زموږ ډیټابیس نه پورته کوي.

د ډیری کیشینګ خدماتو بله ګټه دا ده چې دوی د ډیټابیس سرورونو په پرتله اندازه کول اسانه دي. ریډیس یو جوړ شوی ریډیس کلستر حالت لري. د بار بیلانسر ته ورته1، دا تاسو ته اجازه درکوي خپل ریډیس کیچ په ډیری ماشینونو کې توزیع کړئ (که اړتیا وي په زرګونو سرورونو کې).

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

نقلونه ولولئ

کله چې ډیټابیس ته د پوښتنو شمیر خورا ډیر شوی ، یو بل شی چې موږ یې کولی شو د ډیټابیس مدیریت سیسټم کې د لوستلو نقلونه اضافه کول دي. د پورته ذکر شوي مدیریت خدماتو سره، دا په یو کلیک کې ترسره کیدی شي. لوستل شوي نقل به په اصلي ډیټابیس کې اوسني پاتې شي او د SELECT بیاناتو لپاره شتون لري.

دلته زموږ سیسټم اوس دی:

نورې کړنې

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

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

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

سرچینې

دا پوسټ د یو څخه الهام دی د لوړې کچې وړتیا په اړه زما غوره پوسټونه. ما غوښتل چې مقاله د پروژو د لومړیو مرحلو لپاره یو څه نور مشخص کړم او د یو پلورونکي څخه یې خلاص کړم. ډاډه اوسئ چې ولولئ که تاسو د دې موضوع سره علاقه لرئ.

فوټ نوټونه

1. که څه هم په ډیری مواردو کې د بار توزیع شرایطو کې ورته دی، د ریډیس کلستر بنسټیز تطبیق د بار بیلنسر څخه خورا توپیر لري. [راګرځیدل]

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