توهان مهينا گذاريا آهن توهان جي مونولٿ کي مائڪرو سروسز ۾ ٻيهر ڊزائين ڪرڻ ۾، ۽ آخرڪار هرڪو گڏ ٿيو آهي سوئچ کي فلپ ڪرڻ لاءِ. توهان پهرين ويب پيج تي وڃو ... ۽ ڪجھ به نه ٿيندو. توهان ان کي ٻيهر لوڊ ڪريو - ۽ ٻيهر ڪجھ به سٺو ناهي، سائيٽ تمام سست آهي ته اهو ڪيترن ئي منٽن تائين جواب نٿو ڏئي. ڇا ٿيو؟
هن جي ڳالهين ۾، جمي بوگارڊ هڪ حقيقي زندگي مائڪرو سروس آفت تي "پوسٽ مارٽم" ڪندو. هو ڏيکاريندو ماڊلنگ، ڊولپمينٽ، ۽ پيداوار جا مسئلا جيڪي هن دريافت ڪيا، ۽ ڪيئن هن جي ٽيم آهستي آهستي نئين ورهايل مونولٿ کي سنجيدگي جي آخري تصوير ۾ تبديل ڪيو. جيتوڻيڪ ڊزائن جي غلطين کي مڪمل طور تي روڪڻ ناممڪن آهي، توهان گهٽ ۾ گهٽ ڊزائن جي عمل جي شروعات ۾ مسئلن جي نشاندهي ڪري سگهو ٿا ته يقيني بڻائين ته حتمي پيداوار هڪ قابل اعتماد ورهايل نظام بڻجي وڃي.
هيلو سڀني کي، مان جمي آهيان ۽ اڄ توهان ٻڌائڻ وارا آهيو ته ڪيئن توهان ميگا آفتن کان بچي سگهو ٿا جڏهن مائڪرو سروسز ٺاهي رهيا آهيو. هي هڪ ڪمپني جي ڪهاڻي آهي جنهن لاءِ مون اٽڪل ڏيڍ سال ڪم ڪيو ته جيئن سندن جهاز کي برفاني ٽڪريءَ سان ٽڪرائجڻ کان بچائي سگهجي. هن ڪهاڻي کي صحيح طور تي ٻڌائڻ لاءِ، اسان کي وقت ۾ واپس وڃڻو پوندو ۽ ڳالهائڻو پوندو ته هي ڪمپني ڪٿي شروع ٿي ۽ ڪيئن ان جي آئي ٽي انفراسٽرڪچر وقت سان گڏ وڌيو آهي. هن آفت ۾ انهن معصومن جي نالن کي بچائڻ لاءِ مون هن ڪمپني جو نالو بدلائي بيل ڪمپيوٽرز رکيو آهي. ايندڙ سلائڊ ڏيکاري ٿو ته 90s جي وچ ڌاري اهڙين ڪمپنين جو آئي ٽي انفراسٽرڪچر ڇا نظر آيو. هي ڪمپيوٽر هارڊويئر اسٽور کي هلائڻ لاءِ هڪ وڏي آفاقي غلطي برداشت ڪندڙ HP ٽنڊم مين فريم سرور جو هڪ عام فن تعمير آهي.
انهن سڀني آرڊر، سيلز، واپسي، پراڊڪٽ جي فهرست، ۽ ڪسٽمر بنياد کي منظم ڪرڻ لاء هڪ سسٽم ٺاهڻ جي ضرورت هئي، تنهنڪري انهن وقت تي سڀ کان وڌيڪ عام مين فريم حل چونڊيو. هن وشال سسٽم ۾ ڪمپني بابت هر بٽ معلومات شامل هئي، هر ممڪن، ۽ هر ٽرانزيڪشن هن مين فريم ذريعي ڪيو ويو. هنن پنهنجا سڀ آنا هڪ ٽوڪري ۾ رکيا ۽ سوچيو ته اهو عام آهي. صرف هڪ شيء جيڪا هتي شامل نه آهي ميل آرڊر جي فهرست ۽ فون ذريعي آرڊر ڏيڻ.
وقت گذرڻ سان گڏ، اهو نظام وڏو ۽ وڏو ٿيندو ويو، ۽ ان ۾ ڪچري جو هڪ وڏو مقدار جمع ٿي ويو. انهي سان گڏ، COBOL دنيا ۾ سڀ کان وڌيڪ اظهار ڪندڙ ٻولي نه آهي، تنهنڪري سسٽم ختم ٿي ويو هڪ وڏو، ڪچرو جو ٽڪرو آهي. 2000 تائين، هنن ڏٺو ته ڪيتريون ئي ڪمپنيون ويب سائيٽون هيون جن ذريعي هنن پنهنجو سمورو ڪاروبار ڪيو، ۽ فيصلو ڪيو ته پنهنجي پهرين تجارتي ڊاٽ ڪام ويب سائيٽ ٺاهي.
شروعاتي ڊيزائن تمام سٺي لڳندي هئي ۽ هڪ اعليٰ سطحي سائيٽ bell.com ۽ انفرادي ايپليڪيشنن لاءِ ڪيترن ئي ذيلي ڊومينز تي مشتمل هئي: catalog.bell.com، accounts.bell.com، orders.bell.com، پراڊڪٽ سرچ search.bell. com. هر ذيلي ڊومين استعمال ڪيو ASP.Net 1.0 فريم ورڪ ۽ ان جو پنهنجو ڊيٽابيس، ۽ اهي سڀئي ڳالهائيندا هئا سسٽم پس منظر. بهرحال، سڀني حڪمن تي عمل جاري رهيو ۽ هڪ واحد وڏي مين فريم جي اندر عمل ڪيو ويو، جنهن ۾ سڀ گندگي رهي، پر سامهون آخر ۾ الڳ الڳ ويب سائيٽون انفرادي ايپليڪيشنون ۽ الڳ ڊيٽابيس سان گڏ هئا.
تنهن ڪري سسٽم جو ڊزائين منظم ۽ منطقي نظر آيو، پر اصل سسٽم هو جيئن ايندڙ سلائڊ ۾ ڏيکاريل آهي.
سڀئي عناصر هڪ ٻئي ڏانهن ڪالن کي خطاب ڪن ٿا، APIs تائين رسائي، ٽئين پارٽي ڊي ايل ايلز، ۽ جهڙوڪ. اهو اڪثر ٿئي ٿو ته ورزن ڪنٽرول سسٽم ڪنهن ٻئي جي ڪوڊ کي پڪڙي، ان کي پروجيڪٽ جي اندر ڇڪي، ۽ پوء سڀ ڪجهه ڀڄي ويندو. MS SQL Server 2005 ۾ لنڪ سرور جو تصور استعمال ڪيو ويو، ۽ جيتوڻيڪ مون سلائڊ تي تير نه ڏيکاريا، پر هر هڪ ڊيٽابيس پڻ هڪ ٻئي سان ڳالهايو، ڇاڪاڻ ته ڪيترن ئي ڊيٽابيس مان حاصل ڪيل ڊيٽا جي بنياد تي ٽيبل ٺاهڻ ۾ ڪجھ به غلط ناهي.
جيئن ته اهي هاڻي سسٽم جي مختلف منطقي علائقن جي وچ ۾ ڪجهه الڳ ٿي چڪا هئا، اهو گندگي جي ورهايل بلب بڻجي ويو، ڪچري جو سڀ کان وڏو ٽڪرو اڃا تائين مين فريم جي پس منظر ۾ رهي ٿو.
عجيب ڳالهه اها هئي ته هي مين فريم بيل ڪمپيوٽرن جي مقابلي ۾ ٺاهيو ويو هو ۽ اڃا تائين انهن جي ٽيڪنيڪل صلاحڪارن طرفان برقرار رکيو ويو هو. ان جي ايپليڪيشنن جي غير اطمينان بخش ڪارڪردگي جو قائل، ڪمپني انهن کي ختم ڪرڻ ۽ سسٽم کي ٻيهر ترتيب ڏيڻ جو فيصلو ڪيو.
موجوده ايپليڪيشن 15 سالن تائين پيداوار ۾ هئي، جيڪا ASP.Net تي ٻڌل ايپليڪيشنن لاءِ هڪ رڪارڊ آهي. سروس سڄي دنيا مان آرڊر قبول ڪيا، ۽ هن واحد ايپليڪيشن مان سالياني آمدني هڪ ارب ڊالر تائين پهچي وئي. نفعي جو هڪ اهم حصو ٺاهي وئي bell.com ويب سائيٽ. بليڪ فرائيڊس تي، سائيٽ ذريعي رکيل آرڊر جو تعداد ڪيترن ئي ملين تائين پهچي ويو. بهرحال، موجوده فن تعمير کي ڪنهن به ترقي جي اجازت نه ڏني وئي، ڇاڪاڻ ته سسٽم عناصر جي سخت ڪنيڪشن عملي طور تي خدمت ۾ ڪنهن به تبديلي جي اجازت نه ڏني هئي.
سڀ کان وڌيڪ سنگين مسئلو هڪ ملڪ کان آرڊر ڪرڻ جي ناڪامي هئي، ان جي لاء ٻئي ۾ ادا ڪريو ۽ ان کي ٽئين ڏانهن موڪليو، ان حقيقت جي باوجود ته اهڙي تجارتي منصوبي عالمي ڪمپنين ۾ تمام عام آهي. موجوده ويب سائيٽ اهڙي ڪنهن به شيءِ جي اجازت نه ڏني هئي، تنهنڪري انهن کي فون تي اهي آرڊر قبول ڪرڻ ۽ رکڻ گهرجن. انهي جي نتيجي ۾ ڪمپني جي تعمير کي تبديل ڪرڻ بابت، خاص طور تي مائڪرو سروسز کي تبديل ڪرڻ بابت سوچڻ.
انهن ٻين ڪمپنين کي ڏسڻ سان هوشيار ڪم ڪيو ته ڏسو ته انهن هڪ جهڙو مسئلو ڪيئن حل ڪيو آهي. انهن حلن مان هڪ Netflix سروس آرڪيٽيڪچر هو، جيڪو هڪ API ۽ هڪ خارجي ڊيٽابيس ذريعي ڳنڍيل مائڪرو سروسز تي مشتمل آهي.
بيل ڪمپيوٽرن جي انتظاميا فيصلو ڪيو ته صرف هڪ اهڙي آرڪيٽيڪچر ٺاهڻ جو، ڪجهه بنيادي اصولن تي عمل ڪندي. پهريون، انهن ڊيٽا جي نقل کي ختم ڪيو هڪ گڏيل ڊيٽابيس جي طريقي سان استعمال ڪندي. ڪو به ڊيٽا نه موڪليو ويو؛ ان جي برعڪس، هرڪو جيڪو ان جي ضرورت آهي، هڪ مرڪزي ذريعو ڏانهن وڃڻ گهرجي. ان جي پٺيان اڪيلائي ۽ خودمختياري هئي - هر خدمت ٻين کان آزاد هئي. هنن فيصلو ڪيو ته ويب API استعمال ڪرڻ لاءِ بلڪل هر شيءِ - جيڪڏهن توهان چاهيو ته ڊيٽا حاصل ڪرڻ يا ڪنهن ٻئي سسٽم ۾ تبديليون ڪرڻ چاهيو، اهو سڀ ڪجهه ويب API ذريعي ڪيو ويو. آخري وڏي شيءِ ”بيل آن بيل“ نالي هڪ نئون مين فريم هو جيئن ته مقابلي ڪندڙن جي هارڊويئر تي ٻڌل ”بيل“ مين فريم جي برخلاف.
تنهن ڪري، 18 مهينن جي دوران، انهن بنيادي اصولن جي چوڌاري سسٽم ٺاهيو ۽ ان کي اڳ-پيداوار ڏانهن آندو. هفتي جي آخر کان پوء ڪم تي واپسي، ڊولپرز گڏ ٿيا ۽ سڀني سرورن کي آن ڪيو جن سان نئون سسٽم ڳنڍيل هو. 18 مهينا ڪم، سوين ڊولپرز، جديد ترين بيل هارڊويئر - ۽ ڪو به مثبت نتيجو ناهي! هن ڪيترن ئي ماڻهن کي مايوس ڪيو آهي ڇاڪاڻ ته انهن هن سسٽم کي پنهنجي ليپ ٽاپ تي ڪيترائي ڀيرا هلائي ڇڏيو آهي ۽ سڀ ڪجهه ٺيڪ هو.
اهي هوشيار هئا ته هن مسئلي کي حل ڪرڻ تي پنهنجو سمورو پئسو اڇلائي. انهن سوئچز سان گڏ جديد ترين سرور ريڪ نصب ڪيا، گيگابٽ آپٽيڪل فائبر استعمال ڪيو، تمام طاقتور سرور هارڊويئر جنهن ۾ ريم جي وڏي مقدار سان، سڀني کي ڳنڍيو، ان کي ترتيب ڏنو - ۽ ٻيهر، ڪجھ به نه! پوءِ انهن شڪ ڪرڻ شروع ڪيو ته اهو سبب شايد وقت ختم ٿي سگهي ٿو، تنهن ڪري اهي سڀئي ويب سيٽنگون، سڀ API سيٽنگون ۾ ويا ۽ پوري ٽائم آئوٽ جي ترتيب کي وڌ ۾ وڌ قدرن تائين اپڊيٽ ڪيو، ته جيئن اهي سڀ ڪجهه ڪري سگهن ويٺي رهي ۽ ڪجهه ٿيڻ جو انتظار ڪري. سائيٽ ڏانهن. انهن انتظار ڪيو ۽ انتظار ڪيو ۽ 9 ۽ اڌ منٽن تائين انتظار ڪيو جيستائين ويب سائيٽ آخرڪار لوڊ ٿي.
ان کان پوءِ کين اها ڳالهه سمجهه ۾ آئي ته موجوده صورتحال جو تفصيلي جائزو وٺڻ جي ضرورت آهي، ۽ هنن اسان کي دعوت ڏني. پهرين شيء جيڪا اسان کي معلوم ٿي وئي اها هئي ته ترقي جي سڀني 18 مهينن دوران، هڪ به حقيقي "مائڪرو" پيدا نه ڪيو ويو - هر شيء صرف وڏي ٿي وئي. ان کان پوءِ، اسان هڪ پوسٽ مارٽم لکڻ شروع ڪيو، جنهن کي ”ريٽرو اسپيڪٽو“ يا ”sad retrospective“ به چيو وڃي ٿو، جنهن کي ”بليم طوفان“ به چيو وڃي ٿو، ”دماغي طوفان“ وانگر، آفت جي سبب کي سمجهڻ لاءِ.
اسان وٽ ڪيترائي اشارا هئا، جن مان هڪ API ڪال جي وقت مڪمل ٽرئفڪ جي سنترپشن هئي. جڏهن توهان هڪ واحد خدمت آرڪيٽيڪچر استعمال ڪندا آهيو، توهان فوري طور تي سمجهي سگهو ٿا ته ڇا غلط ٿي ويو آهي ڇو ته توهان وٽ هڪ اسٽيڪ ٽريڪ آهي جيڪو هر شي جي رپورٽ ڪري ٿو جيڪا ناڪامي سبب ٿي سگهي ٿي. ان صورت ۾ جتي خدمتن جو هڪ گروپ هڪ ئي وقت ساڳئي API تائين رسائي ڪري ٿو، اتي ٽريڪ کي ٽريڪ ڪرڻ جو ڪو طريقو ناهي سواء اضافي نيٽ ورڪ مانيٽرنگ اوزار استعمال ڪرڻ کان سواء WireShark، جنهن جي مهرباني توهان هڪ واحد درخواست جي جانچ ڪري سگهو ٿا ۽ اهو معلوم ڪري سگهو ٿا ته ان جي عملدرآمد دوران ڇا ٿيو. تنهن ڪري اسان هڪ ويب پيج ورتو ۽ تقريباً 2 هفتا گذاريا ان پزل جي ٽڪرن کي گڏ ڪرڻ ۾، ان تي مختلف ڪالون ڪيون ۽ تجزيو ڪيو ته انهن مان هر هڪ ڇا ٿيو.
هن تصوير کي ڏسو. اهو ڏيکاري ٿو ته هڪ خارجي درخواست خدمت کي اشارو ڪري ٿو ڪيترن ئي اندروني ڪالون ڪرڻ لاءِ جيڪي واپس موٽندا. اهو ظاهر ٿئي ٿو ته هر اندروني ڪال هن درخواست جي آزاديء سان خدمت ڪرڻ جي قابل ٿيڻ لاء اضافي هپس ٺاهي ٿي، ڇاڪاڻ ته اهو ضروري معلومات حاصل ڪرڻ لاء ڪٿي به نه ٿو ڦري. هي تصوير ڏسڻ ۾ اچي ٿي ڪالن جي بي معنيٰ cascade، جيئن ته خارجي درخواست اضافي خدمتن کي سڏين ٿا، جيڪي ٻين اضافي خدمتن کي سڏين ٿيون، ۽ ائين ئي، تقريباً اشتهار لامحدود.
هن ڊراگرام ۾ سائو رنگ هڪ نيم دائرو ڏيکاري ٿو جنهن ۾ خدمتون هڪ ٻئي کي سڏين ٿيون - سروس A ڪال سروس B، سروس B ڪال سروس C، ۽ اها خدمت A کي ٻيهر سڏين ٿا. نتيجي طور، اسان کي "تقسيم ٿيل بندش" ملي ٿو. ھڪڙي درخواست ھڪڙي ھزار نيٽ ورڪ API ڪالون ٺاھيو، ۽ جيئن ته سسٽم ۾ بلٽ ان فالٽ رواداري ۽ لوپ تحفظ نه ھو، درخواست ناڪام ٿي ويندي جيڪڏھن انھن مان ھڪڙو API ڪال ناڪام ٿي.
اسان ڪجهه رياضي ڪئي. هر API ڪال ۾ 150 ms ۽ 99,9٪ اپ ٽائم کان وڌيڪ نه جو SLA هو. ھڪڙي درخواست سبب 200 مختلف ڪالون ٿيون، ۽ بھترين صورت ۾، صفحو 200 x 150 ms = 30 سيڪنڊن ۾ ڏيکاري سگھجي ٿو. قدرتي طور، اهو سٺو نه هو. 99,9 تائين 200٪ اپ ٽائم کي ضرب ڪندي، اسان کي 0٪ دستيابي ملي ٿي. اهو ظاهر ٿئي ٿو ته هن فن تعمير جي شروعات کان ئي ناڪام ٿي وئي هئي.
اسان ڊولپرز کان پڇيو ته اهي 18 مهينن جي ڪم کان پوء هن مسئلي کي ڪيئن سڃاڻڻ ۾ ناڪام ٿيا؟ اهو ظاهر ٿيو ته انهن صرف SLA کي ڳڻيو آهي ڪوڊ لاءِ جيڪي اهي هلائيندا هئا، پر جيڪڏهن انهن جي سروس ڪنهن ٻي سروس کي سڏيو، انهن اهو وقت پنهنجي SLA ۾ شمار نه ڪيو. هر شي جيڪا هڪ عمل جي اندر شروع ڪئي وئي هئي 150 ايم ايس جي قيمت تي عمل ڪيو ويو، پر ٻين خدمت جي عملن تائين رسائي مجموعي تاخير کي ڪيترائي ڀيرا وڌايو. پهريون سبق سکيو ويو: "ڇا توهان پنهنجي SLA جي ڪنٽرول ۾ آهيو، يا SLA توهان جي ڪنٽرول ۾ آهي؟" اسان جي صورت ۾، ان جي آخري هئي.
ايندڙ شيء جيڪا اسان دريافت ڪئي اها هئي ته اهي ورهايل ڪمپيوٽنگ غلط تصور جي تصور جي باري ۾ ڄاڻن ٿا، پيٽر ڊيچ ۽ جيمس گوسلنگ پاران ٺاهيل، پر انهن ان جي پهرين حصي کي نظرانداز ڪيو. اهو بيان ڪري ٿو ته "نيٽ ورڪ قابل اعتماد آهي،" "صفر ويڪرائي،" ۽ "لامحدود throughput" غلط فڪر آهن. ٻين غلط فهمين ۾ بيان شامل آهن "نيٽ ورڪ محفوظ آهي،" "ٽاپولوجي ڪڏهن به تبديل نه ٿيندي آهي،" "هميشه صرف هڪ منتظم آهي،" "ڊيٽا جي منتقلي جي قيمت صفر آهي،" ۽ "نيٽ ورڪ هڪجهڙائي آهي."
انهن هڪ غلطي ڪئي ڇاڪاڻ ته انهن پنهنجي خدمت کي مقامي مشينن تي آزمايو ۽ ڪڏهن به خارجي خدمتن سان جڙيل ناهي. جڏهن مقامي طور تي ترقي ڪندي ۽ مقامي ڪيش استعمال ڪندي، انهن کي ڪڏهن به نيٽ ورڪ هپس سان منهن نه ڪيو. ترقي جي سڀني 18 مهينن ۾، انهن ڪڏهن به اهو نه سوچيو ته ڇا ٿيندو جيڪڏهن ٻاهرين خدمتون متاثر ٿينديون.
جيڪڏهن توهان پوئين تصوير ۾ خدمت جي حدن تي نظر اچن ٿا، توهان ڏسي سگهو ٿا ته اهي سڀئي غلط آهن. اتي ڪيترائي ذريعا آھن جيڪي صلاح ڏين ٿا ته خدمت جي حدن کي ڪيئن بيان ڪجي، ۽ گھڻا اھو غلط ڪندا آھن، جيئن Microsoft ايندڙ سلائڊ تي.
هي تصوير ايم ايس بلاگ جي موضوع تي آهي “ڪيئن ٺاهيون مائڪرو سروسز”. هي ڏيکاري ٿو هڪ سادي ويب ايپليڪيشن، ڪاروباري منطق جو هڪ بلاڪ، ۽ هڪ ڊيٽابيس. درخواست سڌو اچي ٿي، اتي شايد ويب لاءِ ھڪڙو سرور آھي، ھڪڙو سرور ڪاروبار لاءِ ۽ ھڪڙو ڊيٽابيس لاءِ. جيڪڏهن توهان ٽرئفڪ کي وڌايو، تصوير ٿوري تبديل ٿي ويندي.
هتي ٻن ويب سرورن جي وچ ۾ ٽرئفڪ کي ورهائڻ لاءِ هڪ لوڊ بيلنس اچي ٿو، هڪ ڪيش ويب سروس ۽ ڪاروباري منطق جي وچ ۾ واقع آهي، ۽ ٻيو ڪيش ڪاروباري منطق ۽ ڊيٽابيس جي وچ ۾. اهو بلڪل آرڪيٽيڪچر بيل آهي جيڪو 2000 جي وچ ڌاري پنهنجي لوڊ بيلنسنگ ۽ نيري/گرين ڊيپلائيمينٽ ايپليڪيشن لاءِ استعمال ڪيو ويو. ڪجھ وقت تائين، سڀڪنھن شيء کي چڱي طرح ڪم ڪيو، ڇاڪاڻ ته هن اسڪيم هڪ monolithic جوڙجڪ لاء ارادو ڪيو ويو.
هيٺ ڏنل تصوير ڏيکاري ٿي ته ڪيئن MS سفارش ڪري ٿو هڪ مانوليٿ کان مائڪرو سروسز ڏانهن - بس هر هڪ مکيه خدمتن کي الڳ الڳ مائڪرو سروسز ۾ ورهائڻ. اهو هن منصوبي تي عمل ڪرڻ دوران هو ته بيل هڪ غلطي ڪئي.
انهن پنهنجي سڀني خدمتن کي مختلف درجن ۾ ورهايو، جن مان هر هڪ ڪيترن ئي انفرادي خدمتن تي مشتمل آهي. مثال طور، ويب سروس ۾ شامل ڪيو ويو microservices for content rendering and authentication, business logic service تي مشتمل آهي microservices for processing orders and account information , ڊيٽابيس کي ورهايو ويو هڪ گروپ ۾ microservices with specialized data. ٻئي ويب، ڪاروباري منطق، ۽ ڊيٽابيس بي رياست خدمتون هيون.
بهرحال، اها تصوير مڪمل طور تي غلط هئي ڇو ته هن ڪمپني جي آئي ٽي ڪلستر کان ٻاهر ڪنهن به ڪاروباري يونٽ جو نقشو نه ڪيو. هن اسڪيم کي ٻاهرئين دنيا سان ڪنهن به تعلق ۾ نه ورتو ويو، تنهنڪري اهو واضح ناهي ته ڪيئن، مثال طور، ٽئين پارٽي جي ڪاروباري تجزياتي حاصل ڪرڻ لاء. مون نوٽ ڪيو ته انهن وٽ پڻ ڪيتريون ئي خدمتون ايجاد ڪيون ويون آهن صرف انفرادي ملازمن جي ڪيريئر کي ترقي ڪرڻ لاءِ جيڪي ان لاءِ وڌيڪ پئسا حاصل ڪرڻ لاءِ جيترو ٿي سگهي ماڻهن کي منظم ڪرڻ جي ڪوشش ڪندا هئا.
انهن جو خيال هو ته مائڪرو سروسز ڏانهن منتقل ٿيڻ ايترو ئي آسان هو جيترو انهن جي اندروني N-tier فزيڪل پرت انفراسٽرڪچر کي کڻڻ ۽ ڊاکر کي ان تي چسپڻ. اچو ته هڪ نظر رکون ته ڇا روايتي N-tier فن تعمير وانگر نظر اچي ٿو.
اهو 4 سطحن تي مشتمل آهي: UI يوزر انٽرفيس جي سطح، ڪاروباري منطق جي سطح، ڊيٽا جي رسائي جي سطح ۽ ڊيٽابيس. وڌيڪ ترقي پسند آهي DDD (ڊومين-ڊرائيو ڊيزائين)، يا سافٽ ويئر تي مبني فن تعمير، جتي ٻه وچولي سطحون ڊومين شيون ۽ هڪ مخزن آهن.
مون ڪوشش ڪئي تبديلي جي مختلف علائقن کي ڏسڻ جي، مختلف علائقن ۾ ذميواري جي هن فن تعمير ۾. هڪ عام N-tier ايپليڪيشن ۾، تبديليءَ جي مختلف علائقن کي ورهايو ويو آهي جيڪي ڍانچي کي عمودي طور تي مٿي کان تري تائين پکڙيل آهن. اهي فهرست آهن، انفرادي ڪمپيوٽرن تي ترتيب ڏنل سيٽنگون، ۽ چيڪ آئوٽ چيڪ، جيڪي منهنجي ٽيم پاران هٿ ڪيا ويا.
هن اسڪيم جي خاص ڳالهه اها آهي ته تبديليءَ جي انهن علائقن جون حدون نه رڳو ڪاروباري منطق جي سطح تي اثر انداز ٿين ٿيون، پر ڊيٽابيس تائين به وڌن ٿيون.
اچو ته ڏسو ته خدمت ٿيڻ جو مطلب ڇا آهي. خدمت جي تعريف جا 6 خاصيتون آهن - اهو سافٽ ويئر آهي جيڪو:
- هڪ مخصوص تنظيم پاران ٺاهيل ۽ استعمال ڪيو ويو؛
- سسٽم جي اندر هڪ خاص قسم جي معلومات جي مواد، پروسيسنگ ۽ / يا روزي لاء ذميوار آهي؛
- مخصوص آپريشنل ضرورتن کي پورو ڪرڻ لاءِ آزاديءَ سان تعمير، مقرر ۽ هلائي سگھجي ٿو.
- صارفين ۽ ٻين خدمتن سان ڳالھ ٻولھ، معاهدي يا معاهدي جي ضمانت جي بنياد تي معلومات مهيا ڪرڻ؛
- پاڻ کي غير مجاز رسائي کان بچائي ٿو، ۽ ان جي معلومات کي نقصان کان؛
- ناڪامين کي اهڙي طرح سنڀاليندو آهي ته اهي معلومات کي نقصان نه پهچائيندا آهن.
اهي سڀئي خاصيتون هڪ لفظ "خودمختاري" ۾ بيان ڪري سگهجن ٿيون. خدمتون هڪ ٻئي کان آزاديءَ سان هلن ٿيون، ڪجهه پابندين کي پورو ڪن ٿيون، ۽ معاهدن جي وضاحت ڪن ٿيون جن جي بنياد تي ماڻهو گهربل معلومات حاصل ڪري سگهن ٿا. مون خاص ٽيڪنالاجي جو ذڪر نه ڪيو، جن جو استعمال خود واضح آهي.
هاڻي اچو ته microservices جي تعريف کي ڏسو:
- هڪ microservice سائيز ۾ ننڍو آهي ۽ هڪ مخصوص مسئلو حل ڪرڻ لاء ٺهيل آهي؛
- microservice خودمختيار آهي؛
- جڏهن هڪ microservice فن تعمير ٺاهي، شهر جي منصوبه بندي استعارا استعمال ڪيو ويندو آهي. سام نيومن جي ڪتاب، بلڊنگ مائڪرو سروسز مان اها تعريف آهي.
Bounded Context جي تعريف Eric Evans جي ڪتاب Domain-Driven Design مان ورتي وئي آهي. اهو ڊي ڊي ڊي ۾ هڪ بنيادي نمونو آهي، هڪ آرڪيٽيڪچر ڊزائين سينٽر جيڪو ڪم ڪري ٿو حجماتي آرڪيٽيڪچرل ماڊلز، انهن کي مختلف حدن ۾ ورهائڻ ۽ انهن جي وچ ۾ رابطي کي واضح طور تي بيان ڪري ٿو.
سادي لفظ ۾، هڪ پابند ڪنڪسٽ دائري کي ظاهر ڪري ٿو جنهن ۾ هڪ خاص ماڊل استعمال ڪري سگهجي ٿو. هن حوالي سان هڪ منطقي طور تي متحد نموني آهي جيڪو ڏسي سگهجي ٿو، مثال طور، توهان جي ڪاروباري ڊومين ۾. جيڪڏهن توهان پڇو ته ”ڪير ڪلائنٽ آهي“ آرڊر ۾ شامل اهلڪارن کان، توهان کي هڪ تعريف ملندي، جيڪڏهن توهان انهن کان پڇو جيڪي سيلز ۾ شامل آهن، توهان کي ٻي ملندي، ۽ اداڪار توهان کي ٽيون تعريف ڏيندا.
تنهن ڪري، Bounded Context چوي ٿو ته جيڪڏهن اسان واضع تعريف نٿا ڪري سگهون ته اسان جي خدمتن جو صارف ڇا آهي، اچو ته انهن حدن جي وضاحت ڪريون جن جي اندر اسين هن اصطلاح جي معنيٰ بابت ڳالهائي سگهون ٿا، ۽ پوءِ انهن مختلف معنائن جي وچ ۾ منتقلي نقطن جي وضاحت ڪريون. اهو آهي، جيڪڏهن اسان آرڊر ڏيڻ جي نقطي نظر کان هڪ ڪلائنٽ بابت ڳالهائي رهيا آهيون، ان جو مطلب اهو آهي ۽ اهو، ۽ جيڪڏهن سيلز جي نقطي نظر کان، هن جو مطلب اهو آهي ۽ اهو.
مائيڪرو سروس جي ايندڙ وصف ڪنهن به قسم جي اندروني عملن جي انڪپسوليشن آهي، ماحول ۾ ڪم جي عمل جي اجزاء جي ”ليڪيج“ کي روڪڻ. اڳيون اچي ٿو "ٻاهرين ڳالهين لاءِ واضح معاهدن جي تعريف، يا خارجي ڪميونيڪيشن،" جيڪو SLAs کان موٽڻ واري معاهدي جي خيال جي نمائندگي ڪري ٿو. آخري وصف هڪ سيل يا سيل جو استعارو آهي، جنهن جو مطلب آهي مائڪرو سروس جي اندر آپريشن جي هڪ سيٽ جو مڪمل انڪپسوليشن ۽ ان ۾ موجود ريڪٽرز جي موجودگي ٻاهرين دنيا سان رابطي لاءِ.
تنهن ڪري اسان بيل ڪمپيوٽرز جي ماڻهن کي چيو، ”اسان توهان جي پيدا ڪيل افراتفري مان ڪنهن کي به ٺيڪ نه ٿا ڪري سگهون ڇو ته توهان وٽ صرف اهو ڪرڻ لاءِ پئسا نه آهن، پر اسان صرف هڪ خدمت کي درست ڪنداسين ته جيئن اهو سڀ ڪجهه ڪري سگهي. احساس.” هن نقطي تي، مان توهان کي ٻڌائڻ شروع ڪندس ته اسان ڪيئن اسان جي صرف خدمت کي مقرر ڪيو آهي ته جيئن اهو 9 ۽ اڌ منٽن کان تيزيء سان درخواستن جو جواب ڏئي.
22:30 منٽ
تمام جلد جاري ڪيو ويندو ...
ٿورڙو اشتهار
اسان سان گڏ رهڻ لاء توهان جي مهرباني. ڇا توهان اسان جا مضمون پسند ڪندا آهيو؟ وڌيڪ دلچسپ مواد ڏسڻ چاهيو ٿا؟ آرڊر ڏيڻ يا دوستن کي سفارش ڪندي اسان جي مدد ڪريو، , داخلا-سطح سرورز جو هڪ منفرد اينالاگ، جيڪو اسان توهان لاءِ ايجاد ڪيو هو: (RAID1 ۽ RAID10 سان دستياب آهي، 24 ڪور تائين ۽ 40GB DDR4 تائين).
ڊيل R730xd 2x سستا Equinix Tier IV ڊيٽا سينٽر ۾ Amsterdam ۾؟ صرف هتي هالينڊ ۾! ڊيل R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 کان! جي باري ۾ پڙهو
جو ذريعو: www.habr.com