ڪيتريون ئي شروعاتون ان مان گذري ويون آهن: نوان استعمال ڪندڙن جو ميڙ هر روز رجسٽر ٿيو، ۽ ترقياتي ٽيم جدوجهد جاري رکڻ جي خدمت کي جاري رکڻ لاء.

اهو هڪ سٺو مسئلو آهي، پر ويب تي ٿوري واضح معلومات آهي ته ڪيئن احتياط سان هڪ ويب ايپليڪيشن کي ماپ ڪري سگهجي ٿو ڪنهن به شيء کان سئو هزارين استعمال ڪندڙن تائين. عام طور تي اتي آهن يا ته فائر حل يا رڪاوٽ حل (۽ اڪثر ڪري ٻئي). تنهن ڪري، ماڻهو پنهنجي شوقين پروجيڪٽ کي حقيقي طور تي سنجيده ڪرڻ لاء استعمال ڪرڻ بدران ڪلچ ٿيل ٽيڪنالاجي استعمال ڪندا آهن.

اچو ته معلومات کي فلٽر ڪرڻ جي ڪوشش ڪريون ۽ بنيادي فارمولا لکون. اسان 1 کان 100 استعمال ڪندڙن تائين قدم بہ قدم پنھنجي نئين فوٽو شيئرنگ سائيٽ Graminsta کي ماپڻ وارا آھيون.

اچو ته لکون ته ڪهڙن مخصوص ڪمن کي کڻڻ جي ضرورت آهي جڏهن سامعين 10، 100، 1000، 10 ۽ 000 ماڻهن تائين پهچي وڃن.

1 استعمال ڪندڙ: 1 مشين

تقريبن هر ايپليڪيشن، اها ويب سائيٽ هجي يا موبائل ايپليڪيشن، ٽي اهم حصا آهن:

• API
• ڊيٽابيس
• ڪلائنٽ (موبائيل ايپليڪيشن پاڻ يا ويب سائيٽ)

ڊيٽابيس مسلسل ڊيٽا کي محفوظ ڪري ٿو. API هن ڊيٽا جي چوڌاري درخواستن جي خدمت ڪري ٿو. ڪلائنٽ صارف کي ڊيٽا منتقل ڪري ٿو.

مان ان نتيجي تي پهتو آهيان ته ايپليڪيشن کي اسڪيل ڪرڻ جي باري ۾ ڳالهائڻ تمام آسان آهي جيڪڏهن، هڪ تعميراتي نقطي نظر کان، ڪلائنٽ ۽ API ادارن کي مڪمل طور تي الڳ ڪيو وڃي.

جڏهن اسان پهريون ڀيرو ايپليڪيشن ٺاهڻ شروع ڪندا آهيون، سڀ ٽي حصا ساڳيا سرور تي هلائي سگھجن ٿا. ڪجھ طريقن ۾، اھو اسان جي ترقي واري ماحول سان ملندڙ جلندڙ آھي: ھڪڙو انجنيئر ھڪڙي مشين تي ڊيٽابيس، API، ۽ ڪلائنٽ ھلائي ٿو.

نظريي ۾، اسان ان کي بادل ۾ هڪ واحد DigitalOcean Droplet يا AWS EC2 مثال تي ترتيب ڏئي سگهون ٿا، جيئن هيٺ ڏيکاريل آهي:

انهي سان گڏ چيو ويندو، جيڪڏهن اتي هڪ سائيٽ تي هڪ کان وڌيڪ صارف هوندا، اهو تقريبا هميشه هڪ ڊيٽابيس جي پرت کي وقف ڪرڻ جو احساس آهي.

10 استعمال ڪندڙ: ڊيٽابيس کي الڳ سطح تي منتقل ڪرڻ

ڊيٽابيس کي منظم ڪيل خدمتن ۾ ورهائڻ جهڙوڪ Amazon RDS يا Digital Ocean Managed Database اسان کي ڊگهي وقت تائين سٺي خدمت ڪندو. اهو هڪ واحد مشين يا EC2 مثال تي خود ميزباني ڪرڻ کان ٿورو وڌيڪ مهانگو آهي، پر انهن خدمتن سان توهان کي باڪس مان تمام گهڻيون ڪارائتيون واڌايون ملن ٿيون جيڪي مستقبل ۾ ڪم اينديون: ملٽي ريجن بيڪ اپ، ريپليڪس پڙهو، خودڪار بيڪ اپ، ۽ وڌيڪ.

ھاڻي اھو آھي جيڪو سسٽم وانگر ڏسڻ ۾ اچي ٿو:

100 استعمال ڪندڙ: ڪلائنٽ کي الڳ سطح تي منتقل ڪرڻ

خوشقسمتيءَ سان، اسان جي پهرين صارفين واقعي اسان جي ايپليڪيشن کي پسند ڪيو. ٽريفڪ وڌيڪ مستحڪم ٿي رهي آهي، تنهنڪري اهو وقت آهي ڪلائنٽ کي الڳ سطح تي منتقل ڪرڻ جو. اها ڳالهه نوٽ ڪرڻ گهرجي ته جدائي ادارن هڪ اسپيبلبل ايپليڪيشن جي تعمير جو هڪ اهم پاسو آهي. جيئن ته سسٽم جو هڪ حصو وڌيڪ ٽريفڪ حاصل ڪري ٿو، اسان ان کي ورهائي سگھون ٿا ڪنٽرول ڪرڻ لاءِ ته خدمت جي پيماني تي مخصوص ٽرئفڪ جي نمونن جي بنياد تي.

اهو ئي سبب آهي ته آئون ڪلائنٽ کي API کان الڳ سوچڻ چاهيان ٿو. اهو ڪيترن ئي پليٽ فارمن لاءِ ترقي ڪرڻ جي باري ۾ سوچڻ تمام آسان بڻائي ٿو: ويب، موبائل ويب، iOS، Android، ڊيسڪ ٽاپ ايپليڪيشنون، ٽئين پارٽي خدمتون، وغيره. اهي سڀ صرف هڪ ئي API استعمال ڪندڙ ڪلائنٽ آهن.

مثال طور، ھاڻي اسان جا صارف اڪثر پڇندا آھن موبائل ايپليڪيشن ڇڏڻ لاءِ. جيڪڏهن توهان ڪلائنٽ ۽ API ادارن کي الڳ ڪريو ٿا، اهو آسان ٿي ويندو.

اهو آهي جيڪو اهڙي نظام وانگر ڏسڻ ۾ اچي ٿو:

1000 استعمال ڪندڙ: لوڊ بيلنس شامل ڪريو

شيون ڏسي رهيا آهن. Graminsta صارفين وڌيڪ ۽ وڌيڪ تصويرون اپ لوڊ ڪري رهيا آهن. رجسٽريشن جو تعداد پڻ وڌي رهيو آهي. اسان جو اڪيلو API سرور تمام ٽريفڪ سان گڏ رکڻ ۾ مشڪل وقت گذري رهيو آهي. وڌيڪ لوهه جي ضرورت آهي!

لوڊ بيلنس هڪ تمام طاقتور تصور آهي. اهم خيال اهو آهي ته اسان API جي سامهون هڪ لوڊ بيلنس رکون ٿا، ۽ اهو ٽرئفڪ کي انفرادي خدمت جي مثالن ۾ ورهائي ٿو. اهو ڪيئن آهي اسان افقي طور تي ماپ ڪريون ٿا، مطلب ته اسان ساڳئي ڪوڊ سان وڌيڪ سرور شامل ڪريون ٿا، درخواستن جو تعداد وڌايو جيڪو اسان پروسيس ڪري سگهون ٿا.

اسان ويب ڪلائنٽ جي سامهون ۽ API جي سامهون الڳ لوڊ بيلنس رکڻ وارا آهيون. ان جو مطلب آهي ته توهان هلائي سگهو ٿا ڪيترائي مثال هلائيندڙ API ڪوڊ ۽ ويب ڪلائنٽ ڪوڊ. لوڊ بيلنس ڪندڙ سرور ڏانهن درخواستون سڌو ڪندو جيڪو گهٽ لوڊ ٿيل آهي.

هتي اسان کي هڪ ٻيو اهم فائدو حاصل - redundancy. جڏهن هڪ مثال ناڪام ٿئي ٿو (شايد اوورلوڊ ٿيل يا تباهه ٿيل)، اسان ٻين سان گڏ رهون ٿا جيڪي ايندڙ درخواستن جو جواب ڏيڻ جاري رکون ٿا. جيڪڏهن صرف هڪ مثال ڪم ڪري رهيو هو، ته پوء ناڪامي جي صورت ۾ سڄو سسٽم تباهه ٿي ويندو.

لوڊ بيلنس پڻ خودڪار اسڪيلنگ مهيا ڪري ٿو. اسان ان کي ترتيب ڏئي سگھون ٿا مثالن جو تعداد وڌائڻ لاءِ چوٽي لوڊ ٿيڻ کان اڳ، ۽ ان کي گھٽائي سگھون ٿا جڏھن سڀ استعمال ڪندڙ ننڊ ۾ ھجن.

لوڊ بيلنس سان، API سطح تقريبا اڻڄاتل طور تي ماپ ڪري سگهجي ٿو، صرف نوان مثال شامل ڪندي جيئن درخواستن جو تعداد وڌائي ٿو.

نوٽ. هن وقت اسان جو سسٽم تمام گهڻو ساڳيو آهي جيڪو PaaS ڪمپنيون جهڙوڪ Heroku يا Elastic Beanstalk on AWS پيش ڪن ٿيون دٻي مان ٻاهر (جنهن ڪري اهي تمام مشهور آهن). هيروڪو ڊيٽابيس کي هڪ الڳ ميزبان تي رکي ٿو، هڪ خودڪار اسڪيلنگ لوڊ بيلنس کي منظم ڪري ٿو، ۽ توهان کي API کان الڳ ويب ڪلائنٽ کي ميزباني ڪرڻ جي اجازت ڏئي ٿو. ھي ھڪڙو وڏو سبب آھي Heroku استعمال ڪرڻ لاءِ شروعاتي اسٽيج پروجيڪٽس يا شروع ڪرڻ لاءِ - توھان حاصل ڪريو سڀ بنيادي خدمتون دٻي مان.

10 استعمال ڪندڙ: CDN

شايد اسان کي اهو شروع کان ئي ڪرڻ گهرجي ها. درخواستن تي عمل ڪرڻ ۽ نيون تصويرون قبول ڪرڻ اسان جي سرورن تي تمام گهڻو دٻاءُ وجهڻ شروع ڪيو آهي.

ھن مرحلي تي، توھان کي استعمال ڪرڻ جي ضرورت آھي ڪلائوڊ سروس کي محفوظ ڪرڻ لاءِ جامد مواد - تصويرون، وڊيوز ۽ گھڻو ڪجھ (AWS S3 يا Digital Ocean Spaces). عام طور تي، اسان جي API شين کي هٿ ڪرڻ کان پاسو ڪرڻ گهرجي جهڙوڪ تصويرون پيش ڪرڻ ۽ تصويرون سرور تي اپلوڊ ڪرڻ.

ڪلائوڊ هوسٽنگ جو ٻيو فائدو سي ڊي اين آهي (AWS هن ايڊ آن ڪلائوڊ فرنٽ کي سڏي ٿو، پر ڪيترائي ڪلائوڊ اسٽوريج فراهم ڪندڙ ان کي دٻي کان ٻاهر پيش ڪن ٿا). CDN خودڪار طريقي سان اسان جي تصويرن کي دنيا جي مختلف ڊيٽا سينٽرن ۾ محفوظ ڪري ٿو.

جيتوڻيڪ اسان جو مکيه ڊيٽا سينٽر اوهائيو ۾ واقع ٿي سگهي ٿو، جيڪڏهن ڪو ماڻهو جاپان کان هڪ تصوير جي درخواست ڪري ٿو، ڪلائوڊ فراهم ڪندڙ هڪ ڪاپي ٺاهي ۽ ان کي پنهنجي جاپاني ڊيٽا سينٽر ۾ محفوظ ڪندو. ايندڙ شخص جيڪو جاپان ۾ هن تصوير جي درخواست ڪندو ان کي تمام جلدي وصول ڪندو. اھو ضروري آھي جڏھن اسان وڏين فائلن سان ڪم ڪريون، جھڙوڪ فوٽوز يا وڊيوز، جن کي ڊائون لوڊ ڪرڻ ۽ پوري ڌرتيءَ تي منتقل ڪرڻ ۾ گھڻو وقت لڳندو آھي.

100 استعمال ڪندڙ: ڊيٽا پرت کي ماپڻ

سي ڊي اين تمام گهڻي مدد ڪئي آهي: ٽرئفڪ وڌي رهي آهي پوري رفتار سان. مشهور وڊيو بلاگر Mavid Mobrick صرف اسان سان رجسٽر ٿيو ۽ پوسٽ ڪيو "ڪهاڻي"، جيئن اهي چون ٿا. لوڊ بيلنس جي مهرباني، API سرورز تي سي پي يو ۽ ميموري جو استعمال گهٽ رکيو ويو آهي (ڏهه API مثال هلندڙ)، پر اسان درخواستن تي گهڻو وقت ختم ڪرڻ شروع ڪري رهيا آهيون... اهي دير ڪٿان اچي رهيا آهن؟

ميٽرڪس ۾ ٿورڙي کوٽائي، اسان ڏسون ٿا ته سي پي يو ڊيٽابيس سرور تي 80-90٪ لوڊ ٿيل آهي. اسان حد ۾ آهيون.

ڊيٽا پرت کي اسڪيل ڪرڻ شايد مساوات جو سڀ کان ڏکيو حصو آهي. API سرور بي رياستي درخواستن جي خدمت ڪندا آهن، تنهنڪري اسان صرف وڌيڪ API مثال شامل ڪندا آهيون. نڪ اڪثريت ڊيٽابيس ائين نٿا ڪري سگهن. اسان بابت ڳالهائينداسين مشهور تعلق رکندڙ ڊيٽابيس مينيجمينٽ سسٽم (PostgreSQL، MySQL، وغيره).

ڪيشنگ

اسان جي ڊيٽابيس جي ڪارڪردگي کي وڌائڻ لاء آسان طريقن مان ھڪڙو ھڪڙو نئون حصو متعارف ڪرائڻ آھي: ڪيش پرت. سڀ کان وڌيڪ عام ڪيشنگ طريقو آهي هڪ ان-ميموري ڪي-ويليو رڪارڊ اسٽور، جهڙوڪ ريڊس يا ميمڪچڊ. اڪثر بادلن وٽ انهن خدمتن جو هڪ منظم نسخو آهي: AWS تي Elasticache ۽ Google Cloud تي Memorystore.

هڪ ڪيش مفيد آهي جڏهن هڪ خدمت ساڳئي معلومات کي ٻيهر حاصل ڪرڻ لاء ڊيٽابيس ڏانهن ڪيترائي بار بار ڪالون ڪري ٿي. لازمي طور تي، اسان صرف هڪ ڀيرو ڊيٽابيس تائين رسائي ڪريون ٿا، معلومات کي ڪيش ۾ ذخيرو ڪريو، ۽ ان کي ٻيهر نه ڇڪيو.

مثال طور، اسان جي گرامينسٽا سروس ۾، هر ڀيري ڪو ماڻهو اسٽار موبرڪ جي پروفائل پيج تي وڃي ٿو، API سرور ان جي پروفائيل مان معلومات لاءِ ڊيٽابيس کان سوال ڪري ٿو. اهو بار بار ٿئي ٿو. جيئن ته Mobrik جي پروفائيل جي معلومات هر درخواست سان تبديل نه ٿيندي آهي، اهو ڪيشنگ لاءِ بهترين آهي.

اسان ريڊيس ۾ ڊيٽابيس مان نتيجن کي ڪيش ذريعي ڪيش ڪنداسين user:id 30 سيڪنڊن جي صحيح مدت سان. هاڻي، جڏهن ڪو ماڻهو Mobrik جي پروفائيل تي وڃي ٿو، اسان پهريان Redis کي چيڪ ڪريون ٿا، ۽ جيڪڏهن ڊيٽا موجود آهي، ته اسان ان کي سڌو سنئون Redis مان منتقل ڪريون ٿا. هاڻي سائيٽ تي سڀ کان وڌيڪ مشهور پروفائل ڏانهن درخواستون عملي طور تي اسان جي ڊيٽابيس کي لوڊ نه ڪندا آهن.

سڀ کان وڌيڪ ڪيشنگ سروسز جو ٻيو فائدو اهو آهي ته اهي ڊيٽابيس سرورز جي ڀيٽ ۾ پيماني تي آسان آهن. ريڊس وٽ بلٽ ان ريڊس ڪلستر موڊ آھي. لوڊ بيلنسر وانگر1، اهو توهان کي توهان جي Redis ڪيش کي ڪيترن ئي مشينن ۾ ورهائڻ جي اجازت ڏئي ٿو (جيڪڏهن ضرورت هجي ته هزارين سرورن ۾).

تقريبن تمام وڏي پيماني تي ايپليڪيشنون ڪيشنگ استعمال ڪن ٿيون؛ اهو هڪ بلڪل لازمي حصو آهي فاسٽ API جو. تيز پڇا ڳاڇا پروسيسنگ ۽ وڌيڪ پيداواري ڪوڊ تمام اهم آهن، پر ڪيش کان سواءِ لکين صارفين جي خدمت کي ماپڻ لڳ ڀڳ ناممڪن آهي.

Replicas پڙهو

جڏهن ڊيٽابيس ۾ سوالن جو تعداد تمام گهڻو وڌي ويو آهي، هڪ وڌيڪ شيء جيڪو اسان ڪري سگهون ٿا اهو آهي ته ڊيٽابيس مينيجمينٽ سسٽم ۾ پڙهيل replicas شامل ڪرڻ. مٿي بيان ڪيل منظم ڪيل خدمتن سان، اهو ٿي سگهي ٿو هڪ ڪلڪ ۾. پڙھيل نقل موجود رھندي مکيه ڊيٽابيس ۾ ۽ موجود آھي SELECT بيانن لاءِ.

ھاڻي آھي اسان جو سسٽم:

اڳيون قدم

جيئن ته ايپليڪيشن پيماني تي جاري آهي، اسان انهن کي آزاد طور تي ماپڻ لاء خدمتن کي الڳ ڪرڻ جاري رکنداسين. مثال طور، جيڪڏهن اسان Websockets استعمال ڪرڻ شروع ڪريون ٿا، ته پوءِ اهو سمجھ ۾ اچي ٿو ته Websockets پروسيسنگ ڪوڊ کي الڳ سروس ۾ ڇڪيو. اسان ان کي نئين مثالن تي رکي سگھون ٿا اسان جي پنهنجي لوڊ بيلنس جي پويان، جيڪو کليل ويب ساکٽس ڪنيڪشن جي بنياد تي ۽ HTTP درخواستن جي تعداد جي لحاظ کان مٿي ۽ گھٽ ڪري سگھي ٿو.

اسان به ڊيٽابيس جي سطح تي پابندين سان وڙهندا رهنداسين. اهو هن اسٽيج تي آهي ته اهو وقت آهي ڊيٽابيس جي ورهاڱي ۽ شارڊنگ جو مطالعو ڪرڻ. ٻنهي طريقن کي اضافي اوور هيڊ جي ضرورت آهي، پر توهان کي ڊيٽابيس کي ماپڻ جي اجازت ڏين ٿا تقريبن اڻڄاتل طور تي.

اسان پڻ انسٽال ڪرڻ چاهيون ٿا مانيٽرنگ ۽ اينالائيٽڪس سروس جهڙوڪ New Relic يا Datadog. اهو توهان کي سست سوالن جي نشاندهي ڪرڻ ۾ مدد ڏيندو ۽ سمجھندو جتي بهتري جي ضرورت آهي. جيئن اسان ماپ ڪريون ٿا، اسان چاهيون ٿا ته رڪاوٽون ڳولڻ ۽ انهن کي ختم ڪرڻ تي- گهڻو ڪري پوئين حصن مان ڪجهه خيالن کي استعمال ڪندي.

ذريعو

هي پوسٽ انهن مان هڪ کان متاثر آهي منهنجي پسنديده پوسٽون اعلي اسڪاليبلٽي بابت. مان چاهيان ٿو ته آرٽيڪل ٿورو وڌيڪ مخصوص منصوبن جي شروعاتي مرحلن لاءِ ۽ ان کي هڪ وينڊر کان ڌار ڪريان. ضرور پڙهو جيڪڏهن توهان هن موضوع ۾ دلچسپي رکو ٿا.

فوٽيون

1. جيتوڻيڪ ڪيترن ئي مثالن ۾ لوڊ ورهائڻ جي لحاظ کان هڪجهڙائي، هڪ Redis ڪلستر جو بنيادي عمل لوڊ بيلنس کان تمام مختلف آهي. [واپسي]

جو ذريعو: www.habr.com