مان گهڻي وقت کان مائڪرو سروس آرڪيٽيڪچر جي موضوع تي هڪ مضمون لکڻ چاهيان پيو، پر ٻه شيون مون کي روڪينديون رهيون- جيترو اڳتي وڌان ان موضوع تي، اوترو ئي مون کي اهو محسوس ٿيو ته مان جيڪو ڄاڻان ٿو سو واضح آهي، ۽ مان ڇا نٿو ڪريان. نه ڄاڻڻ جي ضرورت آهي مطالعي ۽ مطالعي جي. ٻئي طرف، مان سمجهان ٿو ته اڳ ۾ ئي وڏين سامعين جي وچ ۾ بحث ڪرڻ لاء ڪجهه آهي. تنهن ڪري متبادل رايا ڀليڪار آهن.
ڪنوي جو قانون ۽ ڪاروبار، تنظيم ۽ معلوماتي نظام جي وچ ۾ تعلق
هڪ دفعو ٻيهر مان پاڻ کي اقتباس ڏيڻ جي اجازت ڏيندس:
"ڪنهن به تنظيم جيڪا هڪ سسٽم ٺاهي ٿي (وسيع معنى ۾) هڪ ڊزائن حاصل ڪندي جنهن جي جوڙجڪ انهي تنظيم ۾ ٽيمن جي جوڙجڪ کي نقل ڪري ٿي."
- ميلوين ڪنوي، 1967
منهنجي خيال ۾، هي قانون وڌيڪ ممڪن آهي ته ڪاروبار کي منظم ڪرڻ جي فزيبلٽي سان لاڳاپيل هجي، بلڪه سڌو سنئون معلومات جي سسٽم سان. اچو ته هڪ مثال سان وضاحت ڪريان. اچو ته چئو ته اسان وٽ ڪافي مستحڪم ڪاروباري موقعو آهي جنهن جي زندگي جي چڪر سان اهڙي ڊگهي آهي ته اهو هڪ ڪمپني کي منظم ڪرڻ جو احساس ڪري ٿو (هي هڪ ٽائپو ناهي، پر مون کي اهو اصطلاح پسند آهي جيڪو مون چوري ڪيو) قدرتي طور تي، هن ڪاروبار جو سپورٽ سسٽم تنظيمي ۽ عمل سان هن ڪاروبار سان ملندو.
انفارميشن سسٽم جي ڪاروباري واقفيت
اچو ته هڪ مثال سان وضاحت ڪريان. اچو ته چوندا آهن ته ڪاروبار جو موقعو آهي ڪاروبار وڪرو پيزا منظم ڪرڻ لاءِ. V1 ورزن ۾ (اچو ته ان کي اڳ-انفارميشن سڏين)، ڪمپني هڪ پيززيريا، هڪ نقد رجسٽر، ۽ ترسيل سروس هئي. هي نسخو گهٽ ماحولياتي variability جي حالتن ۾ ڊگهي رهندو هو. ان کان پوء ورزن 2 ان کي تبديل ڪرڻ لاء آيو - وڌيڪ ترقي يافته ۽ انفارميشن سسٽم کي استعمال ڪرڻ جي قابل ٿي ان جي بنيادي طور تي ڪاروبار لاء هڪ واحد فن تعمير سان. ۽ هتي، منهنجي خيال ۾، اتي رڳو monoliths جي سلسلي ۾ هڪ خوفناڪ ناانصافي آهي. مبينا طور تي monolithic فن تعمير ڊومين جي ڪاروباري ماڊل سان مطابقت نٿو رکي. ها، جيڪڏهن ائين هجي ها، ته سسٽم بلڪل ڪم ڪرڻ جي قابل نه هوندو - ساڳئي ڪنوي جي قانون ۽ عام احساس جي تضاد ۾. نه، monolithic فن تعمير ڪاروباري ترقي جي هن مرحلي تي ڪاروباري ماڊل سان مڪمل طور تي مطابقت رکي ٿو - منهنجو، يقينا، اهو مرحلو آهي جڏهن سسٽم اڳ ۾ ئي ٺاهي وئي آهي ۽ آپريشن ۾ رکيل آهي. اها هڪ بلڪل شاندار حقيقت آهي ته فن تعمير جي نقطه نظر کان سواءِ، ٻئي خدمت تي مبني آرڪيٽيڪچر ورجن 3 ۽ مائڪرو سروسز آرڪيٽيڪچر ورجن N برابر ڪم ڪندا. پڪڙي ڇا آهي؟
هر شيءِ وهندي آهي، هر شيءِ تبديل ٿيندي آهي، يا ڇا مائڪرو سروسز پيچيدگيءَ کي منهن ڏيڻ جو هڪ وسيلو آهي؟
ان کان اڳ جو اسان جاري رکون، اچو ته مائڪروسروس فن تعمير بابت ڪجھ غلط فڪر تي نظر رکون.
مائيڪرو سروسز جي اپروچ استعمال ڪرڻ جا حامي اڪثر بحث ڪندا آهن ته مائيڪرو سروسسز ۾ هڪ سنگت کي ٽوڙڻ انفرادي خدمتن جي ڪوڊ بيس کي گهٽائڻ سان ترقي جي طريقي کي آسان بڻائي ٿو. منهنجي خيال ۾، هي بيان مڪمل بيوقوف آهي. درحقيقت، هڪ واحد ۽ هم جنس ڪوڊ جي اندر واضح ڳالهه ٻولهه پيچيده لڳي ٿي؟ جيڪڏهن واقعي ائين هجي ها ته، سڀ منصوبا شروعاتي طور تي مائڪرو سروسز جي طور تي ٺاهيا ويندا، جڏهن ته مشق ڏيکاري ٿو ته لڏپلاڻ هڪ واحد کان مائڪرو سروسز ڏانهن تمام گهڻو عام آهي. پيچيدگي غائب نه ٿي؛ اهو صرف انفرادي ماڊلز کان انٽرفيس ڏانهن منتقل ٿئي ٿو (اهو ڊيٽا بس، RPC، APIs، ۽ ٻيا پروٽوڪول) ۽ آرڪيسٽريٽنگ سسٽم. ۽ اهو ڏکيو آهي!
هڪ heterogeneous اسٽيڪ استعمال ڪرڻ جو فائدو پڻ قابل اعتراض آهي. مان بحث نه ڪندس ته اهو پڻ ممڪن آهي، پر حقيقت ۾ اهو تمام گهٽ ٿئي ٿو (اڳتي ڏسندي - اهو ٿيڻ گهرجي - بلڪه هڪ فائدي جي نتيجي ۾).
پيداوار جي زندگي چڪر ۽ خدمت زندگي چڪر
مٿي ڏنل ڊراگرام تي هڪ ٻيو نظر وٺو. اهو ڪو اتفاق نه آهي ته مون هڪ ڪاروبار جي هڪ الڳ ورزن جي گهٽجڻ واري زندگي جي چڪر کي نوٽ ڪيو - جديد حالتن ۾، اهو نسخن جي وچ ۾ ڪاروبار جي منتقلي جي تيز رفتار آهي جيڪو ان جي ڪاميابي لاء فيصلو ڪندڙ آهي. پراڊڪٽ جي ڪاميابيءَ جو اندازو لڳايو وڃي ٿو ان ۾ ڪاروباري مفروضن کي جانچڻ جي رفتار سان. ۽ هتي، منهنجي خيال ۾، مائيڪرو سروس فن تعمير جو بنيادي فائدو آهي. پر اچو ته ترتيب سان هلون.
اچو ته انفارميشن سسٽم جي ارتقا ۾ ايندڙ اسٽيج تي وڃو - SOA جي خدمت تي مبني فن تعمير ڏانهن. تنهن ڪري، ڪجهه خاص نقطي تي اسان اسان جي پيداوار ۾ نمايان ڪئي ڊگهي زندگي خدمتون - ڊگهي زندگي ان معنيٰ ۾ ته جڏهن هڪ پراڊڪٽ جي ورزن جي وچ ۾ منتقل ٿئي ٿي، اتي هڪ موقعو آهي ته خدمت جي زندگيءَ جو چڪر پراڊڪٽ جي ايندڙ ورزن جي زندگيءَ جي چڪر کان وڌيڪ ڊگهو هوندو. اهو منطقي هوندو ته انهن کي تبديل نه ڪيو وڃي - اسان ڇا معاملو آهي ايندڙ ورزن ڏانهن منتقلي جي رفتار. پر افسوس، اسان خدمتن ۾ مسلسل تبديليون ڪرڻ تي مجبور آهيون - ۽ هتي سڀ ڪجهه اسان لاءِ ڪم ڪري ٿو، DevOps طريقا، ڪنٽينرائيزيشن، وغيره - هر شي جيڪا ذهن ۾ اچي ٿي. پر اهي اڃا تائين مائڪرو سروسز نه آهن!
پيچيدگي کي منهن ڏيڻ لاءِ هڪ وسيلو طور Microservices... ترتيب جو انتظام
۽ هتي اسان آخرڪار microservices جي وضاحتي ڪردار ڏانهن منتقل ڪري سگهون ٿا - اهو هڪ طريقو آهي جيڪو پروڊڪٽ جي ترتيب جي انتظام کي آسان بڻائي ٿو. وڌيڪ تفصيل سان، هر مائڪرو سروس جو ڪم بيان ڪري ٿو بلڪل ڪاروباري فنڪشن کي پراڊڪٽ جي اندر ڊومين ماڊل جي مطابق - ۽ اهي شيون آهن جيڪي هڪ مختصر مدت واري ورزن ۾ نه، پر هڪ ڊگهي عرصي واري ڪاروباري موقعي ۾ رهن ٿيون. ۽ پراڊڪٽ جي ايندڙ ورزن ڏانهن منتقلي لفظي طور تي اڻڄاتل طور تي ٿيندي آهي - توهان تبديل ڪريو / هڪ مائڪرو سروس شامل ڪريو، ۽ شايد صرف انهن جي رابطي جي اسڪيم، ۽ اوچتو توهان مستقبل ۾ پنهنجو پاڻ کي ڳوليندا، روئيندڙ مقابلي کي ڇڏي، جيڪي نسخن جي وچ ۾ ٽپو جاري رکندا آهن. سندن monoliths. ھاڻي تصور ڪريو ته اڳواٽ بيان ڪيل انٽرفيس ۽ ڪاروباري صلاحيتن سان گڏ مائڪرو سروسز جو ھڪڙو وڏو مقدار آھي. ۽ توهان اچو ۽ تيار ڪيل مائڪرو سروسز مان پنهنجي پروڊڪٽ جو ڍانچو ٺاهيو - مثال طور هڪ خاڪو ٺاهي. مبارڪون - توهان وٽ هڪ پليٽ فارم آهي - ۽ هاڻي توهان پنهنجي لاء ڪاروبار کي راغب ڪري سگهو ٿا. خواب خواب.
پهچڻ
- سسٽم جي فن تعمير کي ان جي اجزاء جي زندگيء جي چڪر طرفان طئي ڪيو وڃي. جيڪڏهن هڪ جزو هڪ پراڊڪٽ ورزن ۾ رهي ٿو، مائڪرو سروس جي طريقي کي استعمال ڪندي سسٽم جي پيچيدگي کي وڌائڻ ۾ ڪو به مقصد ناهي.
- Microservice فن تعمير کي ڊومين ماڊل تي ٻڌل هجڻ گهرجي - ڇاڪاڻ ته ڪاروبار جو موقعو سڀ کان ڊگهو-رهندڙ ڊومين آهي
- پهچائڻ جا طريقا (DevOps طريقا) ۽ آرڪيسٽريشن مائڪرو سروس آرڪيٽيڪچر لاءِ سڀ کان اهم آهن - اهو ئي سبب آهي ته اجزاء جي تبديلي جي شرح ۾ اضافو هنڌن تي پهچائڻ جي رفتار ۽ معيار تي مطالبن کي وڌائي ٿو.
جو ذريعو: www.habr.com