هيلو، مهرباني. OTUS تي هن وقت هڪ نئين ڪورس اسٽريم لاءِ داخلا کليل آهي . ڪورس جي شروعات جي موقعي تي، مان توهان سان حصيداري ڪرڻ چاهيان ٿو منهنجو اصل مضمون.
تعارف
آرڪيٽيڪچرل انداز جو انتخاب هڪ بنيادي فني فيصلن مان هڪ آهي جڏهن معلوماتي نظام جي تعمير. مضمونن جي هن سلسلي ۾، مان تجويز ڪريان ٿو ته سڀ کان وڌيڪ مشهور تعميراتي طرزن جو تجزيو ڪرڻ لاء ايپليڪيشنن جي تعمير لاء ۽ ان سوال جو جواب ڏيو جڏهن ڪهڙو آرڪيٽيڪچرل انداز سڀ کان وڌيڪ ترجيح آهي. پريزنٽيشن جي عمل ۾، مان هڪ منطقي زنجير ٺاهڻ جي ڪوشش ڪندس، جيڪا وضاحت ڪري ٿي آرڪيٽيڪچرل اسلوب جي ترقي کي مونولٿس کان مائڪرو سروسز تائين.
تاريخ جو هڪ سا
جيڪڏهن توهان ڊولپرز کان پڇڻ جي ڪوشش ڪندا: "اسان کي مائڪرو سروسز جي ضرورت ڇو آهي؟"، توهان کي مختلف قسم جا جواب ملندا. توهان ٻڌو ٿا ته مائڪرو سروسز اسڪيبلٽي کي بهتر بڻائي، ڪوڊ کي سمجهڻ آسان بڻائي، غلطي رواداري کي بهتر بڻائي، ۽ ڪڏهن ڪڏهن توهان ٻڌندا ته اهي توهان کي "پنهنجي ڪوڊ کي صاف ڪرڻ" جي اجازت ڏين ٿا. اچو ته تاريخ تي نظر وجهون ته microservices جي وجود ۾ اچڻ جي مقصد کي سمجهڻ لاءِ.
مختصر ۾، اسان جي موجوده سمجهه ۾ مائڪرو سروسز هن ريت پيدا ٿي: 2011 ۾، جيمس ليوس، مختلف ڪمپنين جي ڪم جو تجزيو ڪندي، هڪ نئين "مائڪرو ايپ" جي نموني جي ظاهر ٿيڻ تي ڌيان ڏنو، جيڪو SOA کي تيز ڪرڻ جي لحاظ کان بهتر ڪيو. خدمتون. ٿوري دير کان پوء، 2012 ۾، هڪ فن تعمير جي اجلاس ۾، نموني جو نالو مٽايو ويو microservice. اهڙيء طرح، مائڪرو سروسز متعارف ڪرائڻ جو شروعاتي مقصد بدنام کي بهتر ڪرڻ هو مارڪيٽ لاء وقت.
Microservices 2015 ۾ hype wave تي هيون. ڪجهه مطالعي جي مطابق، هڪ ڪانفرنس مڪمل نه هئي بغير مائڪرو سروسز جي موضوع تي رپورٽ کان سواء. ان کان علاوه، ڪجهه ڪانفرنسون خاص طور تي مائڪرو سروسز لاء وقف ڪيا ويا. اڄڪلهه، ڪيترائي منصوبا هن آرڪيٽيڪچرل انداز کي استعمال ڪرڻ شروع ڪن ٿا، ۽ جيڪڏهن پروجيڪٽ ۾ ڪيترائي ورثي ڪوڊ شامل آهن، ته پوء مائڪرو سروسز ڏانهن لڏپلاڻ شايد فعال طور تي ڪيو پيو وڃي.
مٿين سڀني جي باوجود، ڊولپرز جو ھڪڙو ننڍڙو تعداد اڃا تائين "مائڪرو سروس" جي تصور کي بيان ڪري سگھي ٿو. پر اسان ان بابت ٿوري دير بعد ڳالهائينداسين ...
مونولٿ
آرڪيٽيڪچرل اسلوب جيڪو مائيڪرو سروسز جي ابتڙ آهي اهو مونولٿ (يا سڀ ۾ هڪ) آهي. اهو شايد سمجهه ۾ نٿو اچي ته اهو ٻڌائڻ لاءِ ته هڪ monolith ڇا آهي، تنهن ڪري مان فوري طور تي هن آرڪيٽيڪچرل انداز جي نقصانن کي لسٽ ڪندس، جنهن آرڪيٽيڪچرل اسلوب جي وڌيڪ ترقي جي شروعات ڪئي: سائيز، ڪنيڪشن، ڊيپلائيمينٽ، اسڪيبلٽي، اعتبار ۽ سختي. هيٺ آئون هر هڪ نقص تي الڳ الڳ نظر وجهڻ جي تجويز ڏيان ٿو.
ڪرائون سائيز واري
monolith تمام وڏو آهي. ۽ اهو عام طور تي هڪ تمام وڏي ڊيٽابيس سان رابطو ڪري ٿو. ايپليڪيشن تمام وڏي ٿي وڃي ٿي ھڪڙي ڊولپر لاءِ سمجھڻ لاءِ. صرف اھي جن ھن ڪوڊ تي ڪم ڪرڻ ۾ گھڻو وقت گذاريو آھي اُھي مونولٿ سان چڱيءَ طرح ڪم ڪري سگھن ٿا، جڏھن ته شروعات ڪندڙ گھڻو وقت مونولٿ کي معلوم ڪرڻ جي ڪوشش ۾ گذاريندا آھن ۽ ان جي ڪا به گارنٽي نه آھي ته اھي ان جو پتو لڳائيندا. عام طور تي، جڏهن هڪ monolith سان ڪم ڪري رهيو آهي، اتي هميشه ڪجهه "مشروط" سينيئر هوندو آهي جيڪو مونولٿ کي گهٽ يا گهٽ چڱي طرح ڄاڻي ٿو ۽ هڪ اڌ سال اندر ٻين نئين ڊولپرز جي هٿن کي ماريندو آهي. قدرتي طور، اهڙي مشروط سينيئر ناڪامي جو هڪ واحد نقطو آهي، ۽ سندس روانگي monolith جي موت کي رسي سگهي ٿو.
ڳنڍجڻ
monolith هڪ "مٽي جو وڏو بال" آهي، جنهن ۾ تبديليون غير متوقع نتيجا آڻي سگهن ٿيون. هڪ جاءِ تي تبديليون ڪرڻ سان، توهان ٻئي جاءِ تي مونولٿ کي نقصان پهچائي سگهو ٿا (ساڳي ”توهان پنهنجي ڪن کي ڇڪيو، *@ گريو“). اهو حقيقت جي ڪري آهي ته مونولٿ ۾ اجزاء تمام پيچيده ۽، سڀ کان اهم، غير واضح تعلقات آهن.
ٽپي وڃڻ
monolith کي ترتيب ڏيڻ، ان جي اجزاء جي وچ ۾ پيچيده لاڳاپن جي ڪري، ان جي پنهنجي رسم سان گڏ هڪ ڊگهو عمل آهي. اهڙي رسم عام طور تي مڪمل طور تي معياري نه آهي ۽ "زباني طور تي" تي گذري ٿو.
اسڪاليبلٽي
مونولٿ ماڊلز ۾ متضاد وسيلن جي ضرورتن جي ضرورت آهي، هارڊويئر جي لحاظ کان هڪ سمجھوتو ڪرڻ جي ضرورت آهي. تصور ڪريو ته توھان وٽ ھڪڙو monolith آھي جنھن ۾ خدمتون A ۽ B شامل آھن. خدمت A جي گھربل آھي هارڊ ڊرائيو جي سائيز تي، ۽ خدمت B RAM تي گھري ٿي. انهي صورت ۾، يا ته مشين جنهن تي monolith نصب ٿيل آهي ٻنهي خدمتن جي گهرجن جي حمايت ڪرڻ گهرجي، يا توهان کي دستي طور تي، مصنوعي طور تي هڪ خدمتن کي غير فعال ڪرڻو پوندو.
ٻيو مثال (وڌيڪ ڪلاسڪ): سروس A، سروس B جي ڀيٽ ۾ تمام گهڻي مشهور آهي، تنهنڪري توهان چاهيو ٿا ته اتي 100 خدمتون A هجن، ۽ 10 خدمتون B هجن. ٻيهر، ٻه آپشن: يا ته اسين 100 مڪمل ٺهيل مانوليٿس کي ترتيب ڏيون ٿا، يا ڪجهه پوءِ خدمتون B کي دستي طور تي بند ڪرڻو پوندو.
اعتبار
جيئن ته سڀئي خدمتون گڏ ٿين ٿيون، جيڪڏهن مونولٿ پوي ٿو، ته سڀئي خدمتون هڪ ئي وقت ۾ گر ٿي وڃن. حقيقت ۾، اهو شايد ايترو خراب نه آهي، گهٽ ۾ گهٽ هڪ ورهايل سسٽم ۾ جزوي ناڪامي نه هوندي، پر ٻئي طرف، ڪارڪردگي ۾ هڪ بگ جي ڪري جيڪا 0.001٪ استعمال ڪندڙن طرفان استعمال ڪئي وئي آهي، توهان سڀني صارفين کي وڃائي سگهو ٿا. توهان جي سسٽم جو.
Inertia
monolith جي سائيز جي ڪري، ان کي نئين ٽيڪنالاجي کي تبديل ڪرڻ ڏکيو آهي. نتيجي طور، ساڳئي سينيئر کي برقرار رکڻ هڪ الڳ ڪم آهي. هڪ منصوبي جي شروعات تي چونڊيو ٽيڪنالاجي اسٽيڪ هڪ بلاڪ بڻجي سگهي ٿو جيڪو پيداوار جي ترقي کي روڪي ٿو.
ٿڪل
ايندڙ وقت اسين ڳالهائينداسين ته ڪيئن ماڻهن انهن مسئلن کي حل ڪرڻ جي ڪوشش ڪئي آهي اجزاء ۽ SOA ڏانهن منتقل ڪندي.
وڌيڪ پڙهو:
جو ذريعو: www.habr.com