اي حبر!
ڪرونا وائرس جي ڪري موجوده واقعن جي روشني ۾، ڪيتريون ئي انٽرنيٽ سروسز تي لوڊ لوڊ ٿيڻ شروع ٿي ويا آهن. مثال طور، ، ڇاڪاڻ ته اتي ڪافي گنجائش نه هئي. ۽ اهو هميشه ممڪن ناهي ته سرور کي تيز ڪرڻ سان صرف وڌيڪ طاقتور سامان شامل ڪندي، پر ڪلائنٽ جي درخواستن تي عمل ڪيو وڃي (يا اهي مقابلن ڏانهن ويندا).
هن آرٽيڪل ۾ آئون مختصر طور تي مشهور طريقن جي باري ۾ ڳالهائيندس جيڪي توهان کي هڪ تيز ۽ غلطي برداشت ڪندڙ خدمت ٺاهڻ جي اجازت ڏين ٿيون. بهرحال، ممڪن ترقياتي اسڪيمن مان، مون صرف انهن کي چونڊيو جيڪي هن وقت آهن استعمال ڪرڻ آسان. هر شيءِ لاءِ، توهان وٽ يا ته تيار ڪيل لائبريريون آهن، يا توهان وٽ موقعو آهي ته ڪلائوڊ پليٽ فارم استعمال ڪندي مسئلو حل ڪرڻ جو.
افقي اسڪيلنگ
سادو ۽ سڀ کان وڌيڪ مشهور نقطو. روايتي طور تي، سڀ کان وڌيڪ عام ٻه لوڊ ورهائڻ وارا منصوبا افقي ۽ عمودي اسڪيلنگ آهن. توهان خدمتن کي متوازي طور تي هلائڻ جي اجازت ڏيو ٿا، انهي ڪري انهن جي وچ ۾ لوڊ ورهايو وڃي. توهان وڌيڪ طاقتور سرور جو آرڊر ڏيو يا ڪوڊ کي بهتر بڻايو.
مثال طور، مان وٺندس خلاصي ڪلائوڊ فائل اسٽوريج، اهو آهي، ڪجهه اينالاگ OwnCloud، OneDrive، وغيره.
اهڙي سرڪٽ جي معياري تصوير هيٺ ڏنل آهي، پر اهو صرف سسٽم جي پيچيدگي کي ظاهر ڪري ٿو. آخرڪار، اسان کي ڪنهن به طرح خدمتن کي هم وقت سازي ڪرڻ جي ضرورت آهي. ڇا ٿيندو جيڪڏهن صارف ٽيبليٽ تان فائل محفوظ ڪري ۽ پوءِ ان کي فون تان ڏسڻ چاهي؟
طريقن جي وچ ۾ فرق: عمودي اسڪيلنگ ۾، اسان نوڊس جي طاقت کي وڌائڻ لاء تيار آهيون، ۽ افقي اسڪيلنگ ۾، اسان لوڊ کي ورهائڻ لاء نوان نوڊس شامل ڪرڻ لاء تيار آهيون.
سي ق آر ايس
هڪ بلڪه اهم نمونو، ڇاڪاڻ ته اها مختلف گراهڪن کي نه رڳو مختلف خدمتن سان ڳنڍڻ جي اجازت ڏئي ٿي، پر ساڳئي ايونٽ اسٽريمز حاصل ڪرڻ لاء پڻ. ان جا فائدا هڪ سادي ايپليڪيشن لاءِ ايترو واضح نه آهن، پر مصروف خدمت لاءِ اهو انتهائي اهم (۽ سادو) آهي. ان جو جوهر: ايندڙ ۽ ٻاهر نڪرڻ واري ڊيٽا جي وهڪري کي ٽڪرائڻ نه گهرجي. اهو آهي، توهان هڪ درخواست نه موڪلي سگهو ٿا ۽ هڪ جواب جي توقع؛ ان جي بدران، توهان خدمت A ڏانهن هڪ درخواست موڪليندا آهيو، پر سروس B کان جواب وصول ڪندا.
هن طريقي جو پهريون بونس هڪ ڊگهي درخواست تي عمل ڪرڻ دوران ڪنيڪشن کي ٽوڙڻ جي صلاحيت آهي (لفظ جي وسيع معني ۾). مثال طور، اچو ته هڪ وڌيڪ يا گهٽ معياري ترتيب وٺون:
- ڪلائنٽ سرور ڏانهن هڪ درخواست موڪلي.
- سرور هڪ ڊگهو پروسيسنگ وقت شروع ڪيو.
- سرور ڪلائنٽ کي نتيجو سان جواب ڏنو.
اچو ته تصور ڪريو ته پوائنٽ 2 ۾ ڪنيڪشن ٽوڙيو ويو (يا نيٽ ورڪ ٻيهر ڳنڍيو ويو، يا صارف ٻئي صفحي تي ويو، ڪنيڪشن ٽوڙيو). انهي صورت ۾، سرور لاء اهو ڏکيو ٿيندو ته صارف کي معلومات سان جواب موڪلڻ لاء ڇا واقعي عمل ڪيو ويو آهي. CQRS استعمال ڪندي، ترتيب ٿورو مختلف ٿيندو:
- ڪلائنٽ اپڊيٽ جي رڪنيت حاصل ڪئي آهي.
- ڪلائنٽ سرور ڏانهن هڪ درخواست موڪلي.
- سرور جواب ڏنو "درخواست قبول ڪئي وئي."
- سرور پوائنٽ "1" کان چينل ذريعي نتيجو سان جواب ڏنو.
جئين توهان ڏسي سگهو ٿا، اسڪيم ٿورو وڌيڪ پيچيده آهي. ان کان علاوه، غير معمولي درخواست-جواب جو طريقو هتي غائب آهي. بهرحال، جيئن توهان ڏسي سگهو ٿا، هڪ درخواست جي پروسيسنگ دوران ڪنيڪشن جي ڀڃڪڙي غلطي جي اڳواڻي نه ٿيندي. ان کان علاوه، جيڪڏهن حقيقت ۾ صارف ڪيترن ئي ڊوائيسز کان خدمت سان ڳنڍيل آهي (مثال طور، هڪ موبائل فون ۽ هڪ ٽيبليٽ کان)، توهان پڪ ڪري سگهو ٿا ته جواب ٻنهي ڊوائيسز تي اچي ٿو.
دلچسپ ڳالهه اها آهي ته، ايندڙ پيغامن جي پروسيسنگ لاءِ ڪوڊ ساڳيو هوندو آهي (نه 100٪) ٻنهي واقعن لاءِ جيڪي خود ڪلائنٽ کان متاثر ٿيا هئا، ۽ ٻين واقعن لاءِ، بشمول ٻين ڪلائنٽ کان.
جڏهن ته، حقيقت ۾ اسان هڪ اضافي بونس حاصل ڪريون ٿا حقيقت اها آهي ته اڻ سڌي وهڪري کي هڪ فنڪشنل انداز ۾ هٿ ڪري سگهجي ٿو (RX ۽ ساڳي استعمال ڪندي). ۽ اهو اڳ ۾ ئي هڪ سنگين پلس آهي، ڇو ته اصل ۾ ايپليڪيشن کي مڪمل طور تي رد عمل ڪري سگهجي ٿو، ۽ پڻ هڪ فنڪشنل طريقي سان استعمال ڪندي. ٿلهي پروگرامن لاءِ، هي خاص طور تي ترقي ۽ سپورٽ وسيلن کي بچائي سگهي ٿو.
جيڪڏهن اسان هن طريقي کي افقي اسڪيلنگ سان گڏ ڪريون ٿا، پوء هڪ بونس جي طور تي اسان هڪ سرور ڏانهن درخواستون موڪلڻ جي صلاحيت حاصل ڪندا آهيون ۽ ٻئي کان جواب حاصل ڪندا آهيون. اهڙيء طرح، ڪلائنٽ چونڊ ڪري سگهي ٿو خدمت جيڪا هن لاء آسان آهي، ۽ اندر اندر سسٽم اڃا تائين واقعن کي صحيح طريقي سان عمل ڪرڻ جي قابل هوندو.
ايونٽ سورسنگ
جئين توهان کي خبر آهي، هڪ ورهايل نظام جي مکيه خاصيتن مان هڪ عام وقت جي غير موجودگي آهي، هڪ عام نازڪ سيڪشن. هڪ عمل لاءِ، توهان ڪري سگهو ٿا هڪ هم وقت سازي (ساڳئي ميوٽڪس تي)، جنهن ۾ توهان کي پڪ آهي ته ٻيو ڪو به هن ڪوڊ تي عمل نه ڪري رهيو آهي. بهرحال، اهو هڪ ورهايل نظام لاءِ خطرناڪ آهي، ڇاڪاڻ ته ان کي مٿي جي ضرورت پوندي، ۽ پڻ اسڪيلنگ جي تمام خوبصورتي کي ختم ڪري ڇڏيندو - سڀئي اجزاء اڃا تائين هڪ انتظار ڪندا.
هتان کان اسان هڪ اهم حقيقت حاصل ڪريون ٿا - هڪ تيز ورهايل نظام هم وقت سازي نه ٿو ڪري سگهجي، ڇاڪاڻ ته پوء اسان ڪارڪردگي کي گهٽ ڪنداسين. ٻئي طرف، اسان کي اڪثر اجزاء جي وچ ۾ هڪ خاص استحڪام جي ضرورت آهي. ۽ ھن لاء توھان استعمال ڪري سگھوٿا طريقه ڪار سان ، جتي اها ضمانت ڏني وئي آهي ته جيڪڏهن آخري اپڊيٽ ("آخرڪار") کان پوءِ ڪجهه عرصي لاءِ ڊيٽا ۾ ڪابه تبديلي نه آهي، سڀ سوال آخري تازه ڪاري قيمت واپس ڪندا.
اهو سمجهڻ ضروري آهي ته کلاسک ڊيٽابيس لاء اهو اڪثر استعمال ڪيو ويندو آهي , جتي هر نوڊ ۾ ساڳي ڄاڻ هوندي آهي (اهو اڪثر صورت ۾ حاصل ڪيو ويندو آهي جتي ٽرانزيڪشن کي صرف سيڪنڊ سرور جي جواب کان پوء قائم ڪيو ويندو آهي). اڪيلائي جي سطح جي ڪري هتي ڪجهه آرام آهن، پر عام خيال ساڳيو رهي ٿو - توهان مڪمل طور تي هموار ٿيل دنيا ۾ رهي سگهو ٿا.
بهرحال، اچو ته اصل ڪم ڏانهن واپس وڃو. جيڪڏهن سسٽم جو حصو ٺاهي سگهجي ٿو ، پوءِ اسان ھيٺ ڏنل ڊراگرام ٺاھي سگھون ٿا.
هن طريقي جي اهم خاصيتون:
- هر ايندڙ درخواست هڪ قطار ۾ رکيل آهي.
- درخواست تي عمل ڪرڻ دوران، خدمت شايد ٻين قطارن ۾ ڪم رکي سگھي ٿي.
- هر اچڻ واري واقعي جو هڪ سڃاڻپ ڪندڙ هوندو آهي (جيڪو نقل ڪرڻ لاءِ ضروري آهي).
- قطار نظرياتي طور تي "صرف شامل ڪريو" اسڪيم جي مطابق ڪم ڪري ٿو. توھان ان مان عناصر کي ختم نه ڪري سگھو ٿا يا انھن کي ترتيب ڏيو.
- قطار FIFO اسڪيم جي مطابق ڪم ڪري ٿو (تفصيلات لاء معذرت). جيڪڏهن توهان کي متوازي عمل ڪرڻ جي ضرورت آهي، ته پوء هڪ اسٽيج تي توهان شين کي مختلف قطارن ڏانهن منتقل ڪرڻ گهرجي.
مون کي توهان کي ياد ڏيارڻ ڏيو ته اسان آن لائن فائل اسٽوريج جي صورت تي غور ڪري رهيا آهيون. انهي حالت ۾، سسٽم هن طرح ڪجهه نظر ايندو:
اهو ضروري آهي ته ڊراگرام ۾ خدمتون لازمي طور تي هڪ الڳ سرور جو مطلب نه آهي. جيتوڻيڪ اهو عمل ساڳيو ٿي سگهي ٿو. ٻي شيء اهم آهي: نظرياتي طور تي، اهي شيون اهڙي طرح جدا ڪيا ويا آهن ته افقي اسڪيلنگ آساني سان لاڳو ٿي سگهن ٿيون.
۽ ٻن استعمال ڪندڙن لاءِ ڊاگرام ھن طرح نظر ايندو (مختلف استعمال ڪندڙن لاءِ تيار ڪيل خدمتون مختلف رنگن ۾ ڏيکاريل آھن):
اهڙي ميلاپ مان بونس:
- معلومات جي پروسيسنگ سروسز کي الڳ ڪيو ويو آهي. قطارون به جدا جدا آهن. جيڪڏهن اسان کي سسٽم جي ذريعي وڌائڻ جي ضرورت آهي، پوء اسان کي صرف وڌيڪ سرورز تي وڌيڪ خدمتون شروع ڪرڻ جي ضرورت آهي.
- جڏهن اسان صارف کان معلومات حاصل ڪندا آهيون، اسان کي انتظار ڪرڻ جي ضرورت ناهي جيستائين ڊيٽا مڪمل طور تي محفوظ ٿي وڃي. ان جي برعڪس، اسان کي صرف ”ٺيڪ“ جو جواب ڏيڻو پوندو ۽ پوءِ آهستي آهستي ڪم ڪرڻ شروع ڪيو. ساڳي ئي وقت، قطار کي چوٽي کي هموار ڪري ٿو، ڇاڪاڻ ته نئين شئي شامل ڪرڻ جلدي ٿئي ٿي، ۽ صارف کي پوري چڪر ذريعي مڪمل پاس ٿيڻ جو انتظار ڪرڻ جي ضرورت ناهي.
- مثال طور، مون هڪ ڊيڊپليڪيشن سروس شامل ڪئي جيڪا هڪجهڙائي واري فائلن کي ضم ڪرڻ جي ڪوشش ڪري ٿي. جيڪڏهن اهو 1٪ ڪيسن ۾ ڊگهي وقت تائين ڪم ڪري ٿو، ڪلائنٽ ان کي مشڪل سان نوٽيس ڪندو (مٿي ڏسو)، جيڪو هڪ وڏو پلس آهي، ڇو ته اسان کي هاڻي XNUMX٪ رفتار ۽ قابل اعتماد هجڻ جي ضرورت ناهي.
تنهن هوندي به، نقصان فوري طور تي نظر اچن ٿا:
- اسان جو نظام ان جي سخت استحڪام وڃائي چڪو آهي. هن جو مطلب اهو آهي ته جيڪڏهن، مثال طور، توهان مختلف خدمتن جي رڪنيت حاصل ڪندا آهيو، پوء نظرياتي طور تي توهان هڪ مختلف رياست حاصل ڪري سگهو ٿا (جيئن ته خدمتن مان هڪ کي اندروني قطار مان نوٽيفڪيشن حاصل ڪرڻ جو وقت نه هوندو). ٻئي نتيجي طور، سسٽم هاڻي ڪو عام وقت نه آهي. اهو آهي، اهو ناممڪن آهي، مثال طور، سڀني واقعن کي ترتيب ڏيڻ صرف آمد جي وقت سان، ڇاڪاڻ ته سرور جي وچ ۾ ڪلاڪ هم وقت ساز نه هوندا (وڌيڪ، ساڳئي وقت ٻن سرورن تي هڪ يوٽوپيا آهي).
- ڪو به واقعو ھاڻي واپس نه ٿو ڪري سگھجي (جيئن ته ڊيٽابيس سان ٿي سگھي ٿو). ان جي بدران، توهان کي هڪ نئون واقعو شامل ڪرڻ جي ضرورت آهي - ، جيڪو آخري حالت کي گهربل حالت ۾ تبديل ڪندو. مثال طور ساڳي علائقي مان: تاريخ کي ٻيهر لکڻ کان سواءِ (جيڪو ڪجهه ڪيسن ۾ خراب آهي)، توهان گٽ ۾ ڪمٽ واپس نه ٿا ڪري سگهو، پر توهان ڪري سگهو ٿا هڪ خاص ، جيڪو بنيادي طور تي صرف پراڻي رياست کي واپس ڏئي ٿو. بهرحال، ٻئي غلط ڪم ۽ رول بيڪ تاريخ ۾ رهندا.
- ڊيٽا اسڪيما رليز کان رليز تائين تبديل ٿي سگھي ٿي، پر پراڻا واقعا ھاڻي نئين معيار ۾ اپڊيٽ نه ٿي سگھندا (ڇاڪاڻ ته واقعن کي اصول ۾ تبديل نٿو ڪري سگھجي).
جئين توهان ڏسي سگهو ٿا، ايونٽ سورسنگ CQRS سان سٺو ڪم ڪري ٿو. ان کان علاوه، موثر ۽ آسان قطارن سان سسٽم کي لاڳو ڪرڻ، پر ڊيٽا جي وهڪري کي الڳ ڪرڻ کان سواء، پاڻ ۾ اڳ ۾ ئي ڏکيو آهي، ڇو ته توهان کي هم وقت سازي پوائنٽ شامل ڪرڻو پوندو جيڪو قطار جي مڪمل مثبت اثر کي غير جانبدار ڪندو. هڪ ئي وقت تي ٻنهي طريقن کي لاڳو ڪرڻ، ان کي ٿورو ترتيب ڏيڻ ضروري آهي پروگرام ڪوڊ. اسان جي حالت ۾، سرور ڏانهن فائل موڪلڻ وقت، جواب صرف "ٺيڪ" اچي ٿو، جنهن جو مطلب صرف اهو آهي ته "فائل شامل ڪرڻ جو آپريشن محفوظ ڪيو ويو." رسمي طور تي، هن جو مطلب اهو ناهي ته ڊيٽا اڳ ۾ ئي ٻين ڊوائيسز تي موجود آهي (مثال طور، ڊيپليڪشن سروس انڊيڪس کي ٻيهر ٺاهي سگھي ٿو). بهرحال، ڪجهه وقت کان پوء، ڪلائنٽ کي "فائل ايڪس محفوظ ڪيو ويو آهي" جي انداز ۾ هڪ نوٽيفڪيشن ملندي.
نتيجي طور:
- فائل موڪلڻ واري صورتحال جو تعداد وڌي رهيو آهي: کلاسک "فائل موڪلي وئي" جي بدران، اسان ٻه حاصل ڪريون ٿا: "فائل سرور تي قطار ۾ شامل ڪئي وئي آهي" ۽ "فائل کي اسٽوريج ۾ محفوظ ڪيو ويو آهي." جنهنڪري جو مطلب آهي ته ٻيون ڊوائيس اڳ ۾ ئي فائل حاصل ڪرڻ شروع ڪري سگھن ٿيون (ان حقيقت لاءِ ترتيب ڏنل آهي ته قطار مختلف رفتار تي هلن ٿيون).
- انهي حقيقت جي ڪري ته جمع ڪرائڻ واري معلومات هاڻي مختلف چينلن ذريعي اچي ٿي، اسان کي فائل جي پروسيسنگ اسٽيٽس حاصل ڪرڻ لاء حل ڪرڻ جي ضرورت آهي. انهي جي نتيجي ۾: کلاسک درخواست-جواب جي برعڪس، ڪلائنٽ فائل کي پروسيسنگ دوران ٻيهر شروع ڪري سگهجي ٿو، پر هن پروسيسنگ جي صورتحال پاڻ صحيح ٿي ويندي. ان کان علاوه، هي شيون ڪم ڪري ٿو، بنيادي طور تي، دٻي کان ٻاهر. نتيجي طور: اسان هاڻي ناڪامين کي وڌيڪ برداشت ڪري رهيا آهيون.
سخت ڪرڻ
جيئن مٿي بيان ڪيو ويو آهي، ايونٽ سورسنگ سسٽم سخت استحڪام جي کوٽ ناهي. هن جو مطلب آهي ته اسان انهن جي وچ ۾ بغير ڪنهن هم وقت سازي جي ڪيترن ئي اسٽوريج استعمال ڪري سگهون ٿا. اسان جي مسئلي جي حوالي سان، اسان ڪري سگھون ٿا:
- قسم جي لحاظ کان فائلن کي الڳ ڪريو. مثال طور، تصويرون / وڊيوز ڊيڪوڊ ڪري سگھجن ٿيون ۽ وڌيڪ موثر فارميٽ چونڊيو وڃي ٿو.
- ملڪ طرفان الڳ اڪائونٽ. ڪيترن ئي قانونن جي ڪري، اهو شايد گهربل هجي، پر هي آرڪيٽيڪچر اسڪيم خود بخود اهڙو موقعو فراهم ڪري ٿو
جيڪڏھن توھان چاھيو ٿا ڊيٽا ھڪڙي اسٽوريج کان ٻئي ڏانھن منتقل ڪريو، پوء معياري مطلب ھاڻي ڪافي نه آھن. بدقسمتي سان، هن معاملي ۾، توهان کي قطار کي روڪڻ جي ضرورت آهي، لڏپلاڻ ڪريو، ۽ پوء ان کي شروع ڪريو. عام صورت ۾، ڊيٽا منتقل نه ٿي ڪري سگھجي "فلائي تي"، جڏهن ته، جيڪڏهن واقعي جي قطار مڪمل طور تي ذخيرو ٿيل آهي، ۽ توهان وٽ اڳوڻي اسٽوريج رياستن جا سنيپ شاٽ آهن، ته پوء اسان واقعن کي هن ريت هلائي سگهون ٿا:
- واقعي جي ماخذ ۾، هر واقعي جو پنهنجو سڃاڻپ ڪندڙ آهي (مثالي طور تي، غير گهٽجڻ وارو). هن جو مطلب آهي ته اسان اسٽوريج ۾ هڪ فيلڊ شامل ڪري سگهون ٿا - آخري پروسيس ٿيل عنصر جي سڃاڻپ.
- اسان قطار کي نقل ڪريون ٿا ته سڀني واقعن کي ڪيترن ئي آزاد اسٽوريج لاء پروسيس ڪري سگهجي ٿو (پهريون اهو آهي جنهن ۾ ڊيٽا اڳ ۾ ئي ذخيرو ٿيل آهي، ۽ ٻيو نئون آهي، پر اڃا به خالي آهي). ٻي قطار، يقينا، اڃا تائين عمل نه ڪيو پيو وڃي.
- اسان ٻئي قطار شروع ڪندا آهيون (اهو آهي، اسان واقعن کي ٻيهر شروع ڪرڻ شروع ڪندا آهيون).
- جڏهن نئين قطار نسبتا خالي آهي (يعني هڪ عنصر شامل ڪرڻ ۽ ان کي ٻيهر حاصل ڪرڻ جي وچ ۾ اوسط وقت جو فرق قابل قبول آهي)، توهان پڙهندڙن کي نئين اسٽوريج ڏانهن تبديل ڪرڻ شروع ڪري سگهو ٿا.
جئين توهان ڏسي سگهو ٿا، اسان وٽ نه آهي، ۽ اڃا به نه آهي، اسان جي سسٽم ۾ سخت تسلسل. هتي صرف واقعي مستقل مزاجي آهي، اهو آهي، هڪ ضمانت آهي ته واقعن تي عمل ڪيو وڃي ٿو ساڳئي ترتيب سان (پر ممڪن آهي مختلف دير سان). ۽، هن کي استعمال ڪندي، اسان نسبتا آساني سان ڊيٽا کي منتقلي ڪري سگهون ٿا بغير سسٽم کي دنيا جي ٻئي پاسي کان روڪيو.
اهڙيء طرح، فائلن لاء آن لائن اسٽوريج بابت اسان جي مثال کي جاري رکندي، اهڙي فن تعمير اڳ ۾ ئي اسان کي ڪيترائي بونس ڏئي ٿو:
- اسان شين کي متحرڪ طريقي سان صارفين جي ويجهو منتقل ڪري سگهون ٿا. انهي طريقي سان توهان خدمت جي معيار کي بهتر بڻائي سگهو ٿا.
- اسان ڪمپنين ۾ ڪجهه ڊيٽا محفوظ ڪري سگهون ٿا. مثال طور، انٽرنيشنل استعمال ڪندڙ اڪثر ڪري انهن جي ڊيٽا کي ڪنٽرول ٿيل ڊيٽا سينٽرن ۾ ذخيرو ڪرڻ جي ضرورت آهي (ڊيٽا ليڪ کان بچڻ لاء). شارڊنگ ذريعي اسان آساني سان هن جي حمايت ڪري سگهون ٿا. ۽ اهو ڪم اڃا به آسان آهي جيڪڏهن گراهڪ وٽ مطابقت رکندڙ بادل آهي (مثال طور، ).
- ۽ سڀ کان اهم شيء اها آهي ته اسان کي اهو ڪرڻ جي ضرورت ناهي. سڀ کان پوء، شروع ڪرڻ سان، اسان سڀني اڪائونٽن لاء هڪ اسٽوريج سان تمام خوش ٿينداسين (جلدي ڪم شروع ڪرڻ لاء). ۽ هن سسٽم جي اهم خصوصيت اها آهي ته جيتوڻيڪ اهو وسعت وارو آهي، شروعاتي اسٽيج تي اهو بلڪل سادو آهي. توهان کي فوري طور تي ڪوڊ لکڻ جي ضرورت ناهي جيڪا هڪ ملين الڳ الڳ قطارن وغيره سان ڪم ڪري ٿي. جيڪڏهن ضروري آهي، اهو مستقبل ۾ ٿي سگهي ٿو.
جامد مواد هوسٽنگ
اهو نقطو بلڪل واضح ٿي سگهي ٿو، پر اهو اڃا تائين ضروري آهي ته هڪ وڌيڪ يا گهٽ معياري لوڊ ٿيل ايپليڪيشن لاء. ان جو جوهر سادو آهي: سڀئي جامد مواد ورهايل نه آهي ساڳئي سرور مان جتي ايپليڪيشن واقع آهي، پر خاص ماڻهن کان جيڪي خاص طور تي هن ڪم لاء وقف ڪيا ويا آهن. نتيجي طور، اهي آپريشن تيزيء سان ڪيا ويا آهن (مشروط نينڪس فائلن کي وڌيڪ جلدي ۽ گهٽ قيمتي طور تي جاوا سرور کان ڪم ڪري ٿو). پلس سي ڊي اين آرڪيٽيڪچر () اسان کي اسان جي فائلن کي آخري استعمال ڪندڙن جي ويجهو ڳولڻ جي اجازت ڏئي ٿي، جيڪا خدمت سان ڪم ڪرڻ جي سهولت تي مثبت اثر آهي.
جامد مواد جو آسان ۽ معياري مثال ويب سائيٽ لاءِ اسڪرپٽس ۽ تصويرن جو هڪ سيٽ آهي. انھن سان گڏ سڀ ڪجھ سادو آھي - اھي اڳ ۾ سڃاتل آھن، پوءِ آرڪائيو سي ڊي اين سرورز تي اپلوڊ ڪيو ويندو آھي، جتان اھي آخري استعمال ڪندڙن ۾ ورهايا ويندا آھن.
جڏهن ته، حقيقت ۾، جامد مواد لاء، توهان هڪ طريقي سان استعمال ڪري سگهو ٿا ڪجهه حد تائين لامبڊا فن تعمير سان. اچو ته اسان جي ڪم ڏانهن موٽون (آن لائن فائل اسٽوريج)، جنهن ۾ اسان کي فائلن کي صارفين کي ورهائڻ جي ضرورت آهي. آسان حل اهو آهي ته هڪ خدمت ٺاهي جيڪا، هر صارف جي درخواست لاءِ، سڀني ضروري چيڪن (اجازت ڏيڻ، وغيره) ڪري، ۽ پوءِ فائل سڌو سنئون اسان جي اسٽوريج مان ڊائون لوڊ ڪري. هن طريقي جو بنيادي نقصان اهو آهي ته جامد مواد (۽ هڪ فائل هڪ خاص نظر ثاني سان آهي، حقيقت ۾، جامد مواد) ساڳئي سرور طرفان ورهايل آهي جنهن ۾ ڪاروباري منطق شامل آهي. ان جي بدران، توهان هيٺ ڏنل ڊراگرام ٺاهي سگهو ٿا:
- سرور مهيا ڪري ٿو ڊائون لوڊ URL. اهو ٿي سگهي ٿو فارم فائل_id + ڪيئي، جتي ڪيئي هڪ مني ڊجيٽل دستخط آهي جيڪو ايندڙ XNUMX ڪلاڪن تائين وسيلن تائين رسائي جو حق ڏئي ٿو.
- فائل ھيٺ ڏنل اختيارن سان سادي nginx پاران ورهايل آھي:
- مواد ڪيشنگ. جيئن ته هي خدمت هڪ الڳ سرور تي واقع ٿي سگهي ٿي، اسان پاڻ کي مستقبل لاءِ محفوظ رکي ڇڏيو آهي سڀني جديد ڊائون لوڊ ڪيل فائلن کي ڊسڪ تي ذخيرو ڪرڻ جي صلاحيت سان.
- ڪنيڪشن ٺاھڻ وقت چيڪ چيڪ ڪرڻ
- اختياري: اسٽريمنگ مواد پروسيسنگ. مثال طور، جيڪڏهن اسان خدمت ۾ سڀني فائلن کي دٻايو، ته پوء اسين هن ماڊل ۾ سڌو سنئون انزپ ڪري سگهون ٿا. نتيجي طور: IO آپريشن ڪيا ويا آھن جتي اھي تعلق رکن ٿا. جاوا ۾ هڪ آرڪائيور آساني سان تمام گهڻو اضافي ياداشت مختص ڪندو، پر ڪاروباري منطق سان خدمت کي ٻيهر لکڻ سان Rust/C++ شرطن ۾ پڻ غير موثر ٿي سگهي ٿي. اسان جي صورت ۾، مختلف عمل (يا اڃا به خدمتون) استعمال ڪيا ويا آهن، ۽ تنهن ڪري اسان ڪافي مؤثر طريقي سان ڪاروبار منطق ۽ IO عملن کي الڳ ڪري سگهون ٿا.
هي اسڪيم جامد مواد کي ورهائڻ سان تمام گهڻو ملندڙ جلندڙ ناهي (جيئن ته اسان مڪمل جامد پيڪيج کي ڪٿي اپ لوڊ نه ڪندا آهيون)، پر حقيقت ۾، اهو طريقو خاص طور تي ناقابل اعتبار ڊيٽا کي ورهائڻ سان تعلق رکي ٿو. ان کان علاوه، هن اسڪيم کي عام ڪري سگهجي ٿو ٻين ڪيسن ۾ جتي مواد صرف جامد نه آهي، پر ان کي نمائندگي ڪري سگهجي ٿو هڪ سيٽ جي طور تي ناقابل ۽ غير حذف ٿيل بلاڪ (جيتوڻيڪ انهن کي شامل ڪري سگهجي ٿو).
ٻئي مثال طور (تقويق لاءِ): جيڪڏهن توهان ڪم ڪيو آهي جينڪنز/ٽيم سٽي سان، پوءِ توهان کي خبر آهي ته ٻئي حل جاوا ۾ لکيل آهن. اهي ٻئي جاوا عمل آهن جيڪي ٺاهيل آرڪسٽريشن ۽ مواد مينيجمينٽ ٻنهي کي سنڀاليندا آهن. خاص طور تي، انهن ٻنهي جا ڪم آهن جهڙوڪ "سرور کان فائل / فولڊر کي منتقلي." مثال طور: آرٽيڪل جاري ڪرڻ، سورس ڪوڊ جي منتقلي (جڏهن ايجنٽ ڪوڊ سڌو سنئون مخزن مان ڊائون لوڊ نٿو ڪري، پر سرور ان لاءِ ڪندو آهي)، لاگ تائين رسائي. اهي سڀئي ڪم انهن جي IO لوڊ ۾ مختلف آهن. اهو آهي، اهو ظاهر ٿئي ٿو ته سرور کي پيچيده ڪاروباري منطق لاء ذميوار هجڻ گهرجي، هڪ ئي وقت ۾ پنهنجي ذريعي ڊيٽا جي وڏي وهڪري کي مؤثر طور تي زور ڏيڻ جي قابل هوندو. ۽ جيڪو سڀ کان وڌيڪ دلچسپ آهي اهو آهي ته اهڙي آپريشن کي ساڳئي منصوبي جي مطابق ساڳئي نينڪس ڏانهن نمائندو ڪري سگهجي ٿو (سواء ان جي ڊيٽا جي چيڪ کي درخواست ۾ شامل ڪيو وڃي).
تنهن هوندي، جيڪڏهن اسان اسان جي سسٽم ڏانهن واپس وڃون ٿا، اسان کي هڪ جهڙو ڊراگرام ملي ٿو:
جئين توهان ڏسي سگهو ٿا، سسٽم بنيادي طور تي وڌيڪ پيچيده ٿي چڪو آهي. هاڻي اهو صرف هڪ مني پروسيس ناهي جيڪو مقامي طور تي فائلن کي محفوظ ڪري ٿو. ھاڻي ڇا گھربل آھي سادو سپورٽ، API ورزن ڪنٽرول وغيره. تنهن ڪري، سڀني نقشن جي ٺهڻ کان پوء، اهو بهتر آهي ته تفصيل سان اندازو لڳايو وڃي ته ڇا وڌائڻ جي قيمت جي قيمت آهي. بهرحال، جيڪڏهن توهان چاهيو ٿا ته سسٽم کي وڌائڻ جي قابل ٿي (بشمول استعمال ڪندڙن جي وڏي تعداد سان ڪم ڪرڻ)، پوء توهان کي ساڳيو حل لاء وڃڻو پوندو. پر، نتيجي طور، سسٽم تعميراتي طور تي وڌندڙ لوڊ لاء تيار آهي (تقريبا هر جزو کي افقي اسڪيلنگ لاء ڪلون ڪري سگهجي ٿو). سسٽم ان کي روڪڻ کان سواء اپڊيٽ ٿي سگهي ٿو (بس ڪجهه عملن کي ٿورڙي سست ڪيو ويندو).
جيئن ته مون شروع ۾ چيو هو، هاڻي انٽرنيٽ سروسز جو تعداد وڌڻ شروع ڪيو آهي. ۽ انهن مان ڪجهه صرف صحيح ڪم ڪرڻ بند ڪرڻ شروع ڪيو. حقيقت ۾، سسٽم هن وقت بلڪل ناڪام ٿي ويا جڏهن ڪاروبار پئسا ٺاهڻ گهرجي. اهو آهي، ملتوي ترسيل جي بدران، گراهڪن کي مشورو ڏيڻ جي بدران "ايندڙ مهينن لاء توهان جي پهچائڻ جو منصوبو ٺاهيو،" سسٽم صرف چيو "پنهنجي مقابلي ۾ وڃو." حقيقت ۾، هي آهي گهٽ پيداوار جي قيمت: نقصان صحيح طور تي ٿيندو جڏهن منافعو سڀ کان وڌيڪ هوندو.
ٿڪل
اهي سڀ طريقا اڳيئي ڄاڻندا هئا. ساڳئي VK ڊگهي استعمال ڪري رهيو آهي جامد مواد هوسٽنگ جو خيال تصويرون ڏيکارڻ لاءِ. ڪيتريون ئي آن لائين رانديون شارڊنگ اسڪيم استعمال ڪن ٿيون رانديگرن کي علائقن ۾ ورهائڻ يا راندين جي جڳهن کي الڳ ڪرڻ لاءِ (جيڪڏهن دنيا پاڻ هڪ آهي). ايونٽ سورسنگ جو طريقو فعال طور تي اي ميل ۾ استعمال ڪيو ويندو آهي. گهڻيون تجارتي ايپليڪيشنون جتي ڊيٽا مسلسل وصول ٿي رهي آهي اصل ۾ CQRS جي طريقي تي ٺهيل آهن انهي لاءِ ته حاصل ڪيل ڊيٽا کي فلٽر ڪرڻ جي قابل ٿي. خير، افقي اسڪيلنگ ڪيترن ئي خدمتن ۾ ڪافي عرصي تائين استعمال ڪيو ويو آهي.
بهرحال، سڀ کان اهم، اهي سڀئي نمونا جديد ايپليڪيشنن ۾ لاڳو ڪرڻ بلڪل آسان ٿي چڪا آهن (جيڪڏهن اهي مناسب آهن، يقينا). Clouds پيش ڪن ٿا شارڊنگ ۽ افقي اسڪيلنگ فوري طور تي، جيڪو پاڻ کي مختلف ڊيٽا سينٽرن ۾ مختلف وقف سرورن کي ترتيب ڏيڻ کان وڌيڪ آسان آهي. CQRS تمام آسان ٿي چڪو آهي، جيڪڏهن صرف لائبريرين جي ترقي جي ڪري جيئن RX. اٽڪل 10 سال اڳ، هڪ نادر ويب سائيٽ هن جي حمايت ڪري سگهي ٿي. Apache Kafka سان گڏ تيار ٿيل ڪنٽينرز جي مهرباني ايونٽ سورسنگ پڻ ناقابل يقين حد تائين آسان آهي. 10 سال اڳ اها جدت هوندي هئي، هاڻي اها عام ڳالهه آهي. اهو ساڳيو آهي جامد مواد جي ميزباني سان: وڌيڪ آسان ٽيڪنالاجيز جي ڪري (جنهن ۾ حقيقت اها آهي ته تفصيلي دستاويز ۽ جوابن جو هڪ وڏو ڊيٽابيس آهي)، اهو طريقو اڃا به آسان ٿي چڪو آهي.
نتيجي طور، ڪيترن ئي پيچيده تعميراتي نمونن تي عمل درآمد هاڻي تمام آسان ٿي چڪو آهي، جنهن جو مطلب آهي ته اهو بهتر آهي ته اڳ ۾ ان کي ويجهي نظر وٺو. جيڪڏهن ڏهن سالن جي ايپليڪيشن ۾ مٿي ڏنل حلن مان هڪ کي ختم ڪيو ويو آهي ان تي عملدرآمد ۽ آپريشن جي اعلي قيمت جي ڪري، هاڻي، نئين ايپليڪيشن ۾، يا ريفيڪٽرنگ کان پوء، توهان هڪ خدمت ٺاهي سگهو ٿا جيڪو اڳ ۾ ئي تعميراتي طور تي ٻنهي کي وڌايو ويندو ( ڪارڪردگي جي لحاظ کان) ۽ گراهڪن کان نئين درخواستن لاء تيار ڪيل (مثال طور، ذاتي ڊيٽا کي مقامي ڪرڻ لاء).
۽ سڀ کان اهم: مهرباني ڪري اهي طريقا استعمال نه ڪريو جيڪڏهن توهان وٽ هڪ سادي ايپليڪيشن آهي. ها، اهي خوبصورت ۽ دلچسپ آهن، پر هڪ سائيٽ لاءِ 100 ماڻهن جي چوٽي جو دورو، توهان اڪثر ڪري سگهو ٿا هڪ کلاسک مونولٿ سان (گهٽ ۾ گهٽ ٻاهران، اندر جي هر شيءِ کي ماڊلز ۾ ورهائي سگهجي ٿو، وغيره).
جو ذريعو: www.habr.com