Microservices ھڪڙي وڏي ايپليڪيشن کي ٽوڙڻ جو ھڪڙو طريقو آھي جنھن کي آسانيءَ سان جوڙيل ماڊلز ۾ شامل ڪيو ويو آھي جيڪي ھڪ ٻئي سان ڳالھيون ڪندا آھن ھڪڙي سادي API ذريعي.
تازو، صرف گونگا ماڻهو مائڪرو سروسز بابت نه ڳالهايو آهي. اهو وڌيڪ ۽ وڌيڪ مشهور ٿي رهيو آهي. ماڊلر آرڪيٽيڪچرل انداز خاص طور تي کلاؤڊ تي ٻڌل ماحول لاءِ مناسب لڳي ٿو ۽ مقبوليت ۾ وڌي رهيو آهي. ان کان اڳ جو اسان تفصيل ۾ وڃون، اچو ته هر شيء جي پکيء جي نظر کي ڏسو . تنهن ڪري: Microservices هڪ وڏي منصوبي کي ننڍڙن، آزاد ۽ آسانيءَ سان جوڙيل ماڊلز ۾ ٽوڙڻ جو هڪ طريقو آهي. آزاد ماڊلز واضح طور تي بيان ڪيل ۽ ڌار ڌار ڪمن جا ذميوار آهن ۽ هڪ سادي ۽ رسائي واري API ذريعي هڪ ٻئي سان رابطو ڪن ٿا. ٻين لفظن ۾، microservices صرف هڪ مختلف آرڪيٽيڪچرل انداز آهن پيچيده ڊزائين ڪرڻ لاءِ، اڪثر ويب ايپليڪيشنون. پر موجوده آرڪيٽيڪچرل حلن جهڙوڪ SOA (خدمت تي مبني فن تعمير) بابت ڇا خراب آهي؟ SOA استعمال ڪندي لکندڙ اڪثر جديد ڪاروباري حل تمام سٺو ڪم ڪرڻ لڳي. اهو شايد هڪ بهترين وقت آهي ڪجهه مسئلن بابت ڳالهائڻ لاءِ جيڪي صنعت هن ڏينهن کي منهن ڏئي رهي آهي... اچو ته هڪ سادي مثال سان شروع ڪريون. اچو ته مون کي جاوا ۾ لکيل هڪ کلاسک ايپليڪيشن هلائڻ جي ضرورت آهي. پهرين آئون يوزر انٽرفيس ٺاهيندس، پوءِ ڪاروباري منطق پرت، ڪيترن ئي حصن سان جيڪي UI سان لهه وچڙ ۾ اينديون، ۽ آخر ۾ ڊيٽابيس جي پرت، جيڪا مسلسل ڊيٽابيس تائين پهچندي. هاڻي حقيقت جي مطابق ته مان ايپليڪيشن کي هلائڻ چاهيان ٿو، مان هڪ WAR/EAR/JAR ٺاهيندس ۽ ان کي سرور تي نصب ڪندس (جهڙوڪ JBoss، Tomcat يا WebLogic). جيئن ته هي سڀ هڪ ۾ ڪيو ويو آهي، مون کي هڪ واحد ايپليڪيشن ملي ٿي، جنهن جو مطلب آهي ته سڀئي اجزاء هڪ جاء تي آهن... مثال تصوير ۾:
گهڻو ڪري، توهان اڳ ۾ ئي هن طريقي سان واقف آهيو ۽ ان کي استعمال ڪيو آهي، پر خيال اهو آهي ته هن مثال کي استعمال ڪرڻ لاء ڏيکاريو ته ڊولپرز کي هن تعميراتي حل کي استعمال ڪندي ڪهڙي چئلينج کي منهن ڏيڻو پوندو. Monolithic ايپليڪيشن: چئلينج چئلينج
خدا جي بچاءُ لاءِ مائڪرو سروسز ڪنهن به اڏاوتي حل ۾ سڀ کان اهم خاصيتن مان هڪ اسڪيلبلٽي آهي. جڏهن مان پهريون ڀيرو مائڪرو سروسز سکي رهيو هوس، مون ڏٺو ته هر شيءِ ڪتاب ”دي آرٽ آف اسڪاليبليٽي“ جي حوالن سان ملي ٿي. هي هڪ بهترين شروعات ۽ بحث لاءِ جڳهه آهي. هي ڪتاب وضاحت ڪري ٿو نام نهاد "Scalability Cube" ماڊل، جيڪو بيان ڪري ٿو هڪ ٽي-dimensional اسپيبلٽي سسٽم:
جئين توهان ڏسي سگهو ٿا، ايڪس محور "افقي اسڪيلنگ" کي بيان ڪري ٿو (جيڪو اسان ڏٺو آهي ته monolithic آرڪيٽيڪچرز لاء پڻ موجود آهي)، Y محور مختلف خدمت حصن کي الڳ ڪرڻ جي معني ۾ اسڪيلنگ جي نمائندگي ڪري ٿو . Z محور جو خيال سمجھيو ويندو آھي جڏھن ڊيٽا کي ورهايو ويندو آھي ۽ ايپليڪيشن درخواستون موڪليندو آھي بلڪل صحيح جتي ڊيٽا واقع آھي. اهو آهي، اهي سڀ هڪ جاء تي نه آهن. Y محور جو خيال اهو آهي جيڪو اسان وڌيڪ تفصيل سان ڌيان ڏينداسين. هي محور هڪ فنڪشنل خراب ٿيڻ جي نمائندگي ڪري ٿو . هن حڪمت عملي ۾، مختلف ڪمن کي آزاد خدمتون سمجهي سگهجي ٿو. تنهن ڪري، سڄي ايپليڪيشن کي نصب ڪندي صرف جڏهن سڀ ڪجهه ٿي چڪو آهي، ڊولپرز انفرادي خدمتن کي هڪ ٻئي کان آزاد طور تي نصب ڪري سگهن ٿا ۽ ٻين جي ماڊلز تي ڪم ختم ڪرڻ جو انتظار نه ڪندا. اهو نه صرف ترقي جي وقت کي بهتر بڻائيندو، پر ايپليڪيشن جي باقي حصن جي باري ۾ پريشان ٿيڻ جي بغير تبديل ڪرڻ ۽ ٻيهر بحال ڪرڻ جي لچڪ پڻ پيش ڪندو. اچو ته هن ڊرائگرام کي پوئين monolithic سان ڀيٽيون:
Microservices: فائدا مائڪرو سروسز جا فائدا ڪافي نظر اچن ٿا انٽرپرائز ڊولپرز کي قائل ڪرڻ لاءِ جيئن Amazon, Netflix, Ebay هن طريقي کي استعمال ڪرڻ لاءِ. monolithic آرڪيٽيڪچرل ايپليڪيشنن جي برعڪس، microservices:
- جيئن ته ايپليڪيشن وڌندي آهي، تيئن ئي ڪوڊ جو مقدار لکندو آهي، جيڪو شايد ترقي واري ماحول کي اوورلوڊ ڪري سگھي ٿو هر وقت توهان کي ان کي کولڻ جي ضرورت آهي. اهو يقيني طور تي ڊولپر جي ڪارڪردگي کي گھٽائي ٿو.
- جيئن ته هر شي کي هڪ جڳهه تي نصب ڪيو وڃي ٿو، اهو حقيقت ڏانهن وٺي ٿو ته ڪنهن ٻئي پروگرامنگ ٻولي کي تبديل ڪرڻ يا ٻين ٽيڪنالاجي ڏانهن سوئچ ڪرڻ هڪ وڏو مسئلو آهي. مثال طور، توهان جاوا ۾ هڪ ايپليڪيشن لکي، ۽ ٿوري دير کان پوءِ Kotlin ٻاهر آيو ۽ توهان ان کي ٻيهر لکڻ جا خواهشمند هئا، ڇاڪاڻ ته ان کي کولر، بهتر، تيزيءَ
سان ترقي ڏني وئي هئي.هڪ واحد ايپليڪيشن سان، ريفڪٽرنگ جي باري ۾ سوچڻ به حقيقي درد جو سبب بڻجندو، نه ته پروسيس پاڻ جو ذڪر ڪرڻ. هن وقت ڪيتريون ئي ايپليڪيشنون آهن جيڪي هن طريقي سان ڪيون ويون آهن ۽ ڪوڊ جي لائينن جو تعداد صرف ناقابل اعتبار آهي. - جيڪڏهن جزن مان ڪو به ڪنهن سبب جي ڪري ڪم ڪرڻ
بند ڪري ٿو، ته سڄي ايپليڪيشن به خراب ٿي ويندي. بس تصور ڪريو ته ھڪڙو ويب ايپليڪيشن آھي جنھن ۾ ماڊل آھن جھڙوڪ اختيار، ادائيگي، تاريخ، وغيره. ۽ ڪجهه سببن لاء انهن مان هڪ ڀڃي. اهو صرف ڪاروبار لاء هڪ جھٽڪو آهي ۽ نتيجي طور، ڊولپرز لاء. - هڪ واحد ايپليڪيشن کي ماپڻ صرف ساڳئي قسم جي ٻي ايپليڪيشن کي وڌائڻ سان حاصل ڪري سگهجي ٿو. پر ڇا جيڪڏھن توھان کي صرف ھڪڙي جزو کي ماپڻ جي ضرورت آھي، ۽ پوري ايپليڪيشن کي نه. ڪيترا وسيلا ضايع ٿيندا؟...
- اهو ترقي جي عمل ۽ ايپليڪيشن جي تنصيب جي عمل تي وڏو اثر پئجي سگهي ٿو. وڏي ايپليڪيشن، وڌيڪ اهم اهو آهي ته ڊولپرز ايپليڪيشن کي ننڍن ڪم ڪندڙ حصن ۾ ورهائي سگهن ٿا. ڇاڪاڻ ته هڪ واحد ايپليڪيشن ۾ سڀئي ماڊل هڪ ٻئي سان ڳنڍيل آهن، ڊولپر انهن ماڊلز کي هڪ ٻئي کان آزاد طور تي ڪم/ماؤنٽ نٿا ڪري سگهن. جيئن ته ڊولپرز هڪ ٻئي تي ڀاڙين ٿا، ترقي جو وقت وڌائي ٿو.
- جزو جي ناڪامي جي اڪيلائي کي بهتر بڻائي ٿو: وڏيون ايپليڪيشنون موثر طريقي سان هلائڻ جاري رکي سگھن ٿيون جيتوڻيڪ هڪ واحد ماڊل ناڪام ٿئي.
- ايپليڪيشن جي وابستگي کي ختم ڪري ٿو هڪ ٽيڪنالاجي اسٽيڪ لاءِ: جيڪڏهن توهان ڪوشش ڪرڻ چاهيو ٿا هڪ نئين ٽيڪنالاجي اسٽيڪ تي ڪجهه خدمت تي، اڳتي وڌو. انحصار هڪ واحد جي ڀيٽ ۾ تمام گهڻو هلڪو هوندو، ۽ اهو پڻ تمام آسان ٿيندو ته هر شيء کي واپس آڻڻ لاء. هڪ ايپليڪيشن ۾ گهٽ ڪوڊ، اهو ڪم ڪرڻ آسان آهي.
- نون ملازمن لاءِ خدمت جي ڪارڪردگي کي سمجهڻ لاءِ اهو تمام آسان بڻائي ٿو.
- ورهايل نظام کي ترقي ڪرڻ ڏکيو ٿي سگهي ٿو. هن مان منهنجو مطلب اهو آهي ته سڀئي حصا هاڻي آزاد خدمتون آهن - توهان کي ماڊلز جي وچ ۾ گذرڻ واري درخواستن کي تمام احتياط سان سنڀالڻ جي ضرورت آهي. اتي ھڪڙو منظر ٿي سگھي ٿو جتي ھڪڙو ماڊل جواب نه ڏئي رھيو آھي، توھان کي مجبور ڪري ٿو اضافي ڪوڊ لکڻ لاءِ سسٽم کي خراب ٿيڻ کان بچڻ لاءِ. اهو وڌيڪ ڏکيو ٿي سگهي ٿو جيڪڏهن ريموٽ ڪالون دير سان حساس آهن .
- گهڻن ڊيٽابيس ۽ ٽرانزيڪشن جو انتظام هڪ حقيقي درد ٿي سگهي ٿو.
- microservice ايپليڪيشنن کي جاچڻ مشڪل ٿي سگھي ٿو. هڪ واحد ايپليڪيشن استعمال ڪندي، اسان کي صرف سرور تي WAR/EAR/JAR آرڪائيو هلائڻو پوندو ۽ پڪ ڪريو ته اهو ڊيٽابيس سان ڳنڍيل آهي. ۽ microservices ۾، هر فرد جي خدمت شروع ٿيڻ گهرجي ان کان اڳ جو ٽيسٽ شروع ٿي سگهي.
- ايپليڪيشنن کي نصب ڪرڻ مشڪل ٿي سگھي ٿو. انهن کي شايد ڪيترن ئي خدمتن جي چوڌاري همراه جي ضرورت هجي جيڪا شايد WAR ڪنٽينر وانگر چڙهڻ آسان نه هجي.
GO TO FULL VERSION