سلام هر!
اسان Raiffeisenbank ۾ .NET ڊولپرز جي هڪ ڪميونٽي آهيون ۽ اسان .NET ڪور جي بنياد تي بنيادي ڍانچي لائبريرين جي هڪ سيٽ بابت ڳالهائڻ چاهيون ٿا ته هڪ واحد ماحولياتي نظام سان جلدي مائڪرو سروسز ٺاهڻ لاءِ. اهي ان کي اوپن سورس ڏانهن کڻي آيا!
تاريخ جو هڪ سا
هڪ دفعي اسان وٽ هڪ وڏو monolithic منصوبو هو، جيڪو آهستي آهستي مائڪرو سروسز جي هڪ سيٽ ۾ تبديل ٿي ويو (توهان هن پروسيس جي خاصيتن بابت پڙهي سگهو ٿا. ). ان عمل ۾، اسان کي اهو مسئلو درپيش آيو ته جڏهن نيون مائڪرو سروسز ٺاهي رهيا هئاسين، ته اسان کي اڪثر مختلف انفراسٽرڪچر حلن کي نقل ڪرڻو پوندو هو - جهڙوڪ لاگنگ قائم ڪرڻ، ڊيٽابيس سان ڪم ڪرڻ، WCF وغيره. ھڪڙي ٽيم ھن منصوبي تي ڪم ڪيو، ۽ ھرڪو اڳ ۾ ئي انفراسٹرڪچر سان ڪم ڪرڻ لاء ڪجھ قائم ڪيل طريقي سان عادي ھو. تنهن ڪري، اسان عام ڪوڊ کي الڳ مخزن ۾ الڳ ڪيو، گڏ ڪيل لائبريرين کي نگيٽ پيڪيجز ۾ لپي ڇڏيو ۽ انهن کي اسان جي اندروني Nuget مخزن ۾ رکيو.
وقت گذرندو ويو، پروجيڪٽ آهستي آهستي ورهائجي ويو، ۽ جديد JS فريم ورڪ تي نوان ڪلائنٽ-سائيڊ ماڊل ٺاهڻ ۽ انهن کي برائوزر ۾ هلائڻ جي خواهش هئي. اسان WCF/SOAP کان REST/HTTP ڏانهن منتقل ٿيڻ شروع ڪيو، تنهنڪري اسان کي AspNet WebApi جي بنياد تي خدمتون جلدي شروع ڪرڻ لاءِ نئين لائبريرين جي ضرورت آهي. .Net فريم ورڪ 4.5 تي پهريون نسخو اسان جي معمار پنهنجي فارغ وقت ۾ تقريبن گوڏن ڀر تيار ڪيو هو، پر ان دٻي جي ٻاهران پروگرام.cs ۾ ٽن لائينن سان هڪ سروس شروع ڪرڻ ممڪن بڻائي جنهن ۾ اختيار (NTLM) شامل هئا، لاگنگ، Swagger، IoC/DI جي بنياد تي Castle Windsor، ڪسٽمائيز HTTP ڪلائنٽ جيڪي مختلف هيڊرز کي اڳتي وڌائين ٿا ته جيئن پوري پروجيڪٽ ۾ آخر کان آخر تائين لاگنگ مهيا ڪن. ۽ اهو سڀ ڪجهه وڌيڪ ترتيب ڏئي سگهجي ٿو سڌو سنئون خدمت جي ترتيب واري فائل ۾.
تنهن هوندي به، سڀڪنھن شيء کي هموار نه هو: هن لائبريريء نئين ماڊلز کي متعارف ڪرائڻ جي لحاظ کان انتهائي inflexible ٿي. مثال طور، جيڪڏهن توهان کي ڪجهه خاص مڊل ويئر شامل ڪرڻ جي ضرورت آهي، توهان کي هڪ نئين اسيمبلي ٺاهي ۽ بيس ڪلاس مان ورثي ۾ آڻڻو پوندو جيڪو سروس هلائي ٿو، جيڪا انتهائي تڪليف هئي. خوشقسمتيء سان، اهڙا تمام گهڻا ڪيس نه هئا.
Docker ۽ Kubernetes جو دور
اهو وقت اچي ويو آهي جڏهن Docker ۽ Kubernetes جي لهر اسان تائين پهتي، جنهن کي اسان ويجهي کان ڏٺو: آخرڪار، اهو هڪ بهترين موقعو هو ته ٽيڪنالاجيز سان گڏ اڳتي وڌڻ شروع ڪيو، نيٽ ڪور ۾. ان جو مطلب اهو آهي ته اسان کي خدمتن کي هلائڻ لاءِ هڪ نئين انفراسٽرڪچر جي ضرورت پوندي: ڪجهه لائبريريون .Net فريم ورڪ کان .Net Standard ۽ .Net Core ڏانهن لڏي ويون آهن عملي طور تي بغير تبديلين جي، ڪجهه معمولي سڌارن سان. پر سڀ کان وڌيڪ مان چاهيان ٿو ته AspNet Core تي خدمتون شروع ڪرڻ سان لاڳاپيل ڪارڪردگي کي ٻيهر ڪم ڪرڻ.
پهرين شيء جيڪا اسان سمجهي ٿي اها هڪ تصور هئي جيڪا پوئين نسخي جي بنيادي خرابي کي ختم ڪري ڇڏيندي: لچڪ جي کوٽ. تنهن ڪري، اهو فيصلو ڪيو ويو ته سڄي لائبريري سسٽم کي ممڪن طور تي آزاد ۽ ماڊلر ٺاهيو وڃي ۽ هڪ تعمير ڪندڙ جي طور تي ڪارڪردگي لاء ضروري خدمتون گڏ ڪري.
بنيادي مقصد ھڪڙو متحد طريقو ٺاھيو آھي جيڪو بيان ڪري ٿو ته ڊيٽابيس، بسين ۽ ٻين خدمتن سان ڪيئن لهه وچڙ ۾. اسان انضمام کي تڪڙو ۽ بي درد بڻائڻ جي ڪوشش ڪئي، ۽ ڊولپرز انفراسٽرڪچر جي بجاءِ ڪاروباري منطق لکڻ تي ڌيان ڏئي سگھن ٿا - اھو اڳ ۾ ئي تيار آھي. هڪ عام مخزن ٽيمن جي وچ ۾ رابطي جي تجربي کي بهتر ڪرڻ ۾ مدد ڪري ٿو: جڏهن تمام گهڻا اندروني انفراسٽرڪچر استعمال ڪيا ويندا آهن، اهو آسان آهي ته ڪنهن ٻئي ٽيم جي ترقي جي عمل ۾ شامل ٿيڻ ۽ ماهرن جي بدلي ۾.
۽ ڇو اسان کي اوپن سورس جي ضرورت آهي؟
اسان چاهيون ٿا ته اسان جي مهارت جي پختگي ڏيکاري ۽ اعلي معيار جي موٽ حاصل ڪجي: بينڪ کان ٻاهر هڪ شخص پنهنجو پاڻ کي ڪجهه آڻڻ جي قابل هوندو. اسان صنعت ۾ .NET تي microservices ۽ DDD سان ڪم ڪرڻ جي طريقن جي ترقي ۾ پڻ دلچسپي رکون ٿا؛ شايد ڪو ماڻهو فريم ورڪ جي ڪجهه حصن تي قبضو ڪرڻ چاهيندو.
دراصل، ViennaNET
هاڻي اچو ته هڪ ويجهي نظر وٺو. .
ViennaNET.WebApi.*
لائبريرين جو هي سيٽ ”روٽ“ ViennaNET.WebApi تي مشتمل آهي، جنهن ۾ ڪمپني هسٽ بلڊر سروس لاءِ بلڊر ڪلاس، ۽ ترتيب ڏيندڙ ViennaNET.WebApi.Configurators جو هڪ سيٽ. خدمت. ترتيب ڏيڻ وارن مان توھان ڳولھي سگھوٿا ڪنيڪشن لاگنگ، تشخيص، تصديق ۽ اختيار جا قسم، سوگر، وغيره.
ViennaNET.WebApi.Runners.* پڻ اڳ ۾ ترتيب ڏنل سروس ٺاهيندڙن تي مشتمل آهي. اهي پيڪيجز توهان کي هر وقت ياد نه رکڻ جي اجازت ڏين ٿا جڏهن توهان هڪ نئين خدمت ٺاهي رهيا آهيو جنهن کي ترتيب ڏيڻ وارن کي ڳنڍڻ جي ضرورت آهي. بهرحال، اهي ڪنهن به طريقي سان خدمت بلڊر جي ڪارڪردگي کي محدود نٿا ڪن.
ViennaNET.Mediator.*
لائبريريون جيڪي توهان کي اجازت ڏين ٿيون هڪ اندروني وچولي بس ٺاهڻ لاءِ حڪمن ۽ درخواستن لاءِ هڪ خدمت اندر. اهو طريقو توهان کي DI انجڻ جي تعداد کي گهٽائڻ جي اجازت ڏئي ٿو، مثال طور، ڪنٽرولرز ۾. انهي جي ڪري، توهان درخواستن ۾ مختلف سجاڳي شامل ڪري سگهو ٿا، جيڪي انهن جي پروسيسنگ کي متحد ڪري ٿو ۽ ڪوڊ جي مقدار کي گھٽائي ٿو.
ViennaNET.Validation
هڪ اسيمبلي جنهن ۾ طبقن جو هڪ سيٽ شامل آهي انهن مان تصديق جي ضابطن ۽ ترتيبن ٺاهڻ لاءِ. اهو ڊومين جي تصديق کي لاڳو ڪرڻ لاء تمام آسان آهي، ڇاڪاڻ ته اهو توهان کي هر ڪاروباري حالت بيان ڪرڻ جي اجازت ڏئي ٿو هڪ سادي ۽ الڳ قاعدي جي صورت ۾.
ViennaNET.Redis
ريپرس سان گڏ هڪ لائبريري آسان ڪم لاءِ Redis سان گڏ هڪ ان-ميموري ڪيش جي طور تي.
ViennaNET.Specifications
هڪ اسيمبلي جنهن ۾ طبقن شامل آهن جيڪي وضاحت جي نموني کي لاڳو ڪن ٿيون.
اهو سڀ ڪجهه اسان جي سيٽ ۾ ناهي. باقي توهان ڏسي سگهو ٿا . اسان منصوبا بندي ڪري رهيا آهيون ته اسان جي لائبريرين کي جلد ئي OpenSource ڏانهن ڊيٽابيس سان ڪم ڪرڻ لاءِ.
توهان جي توجه جي مهرباني، اسان توهان جي تبصرن ۽ ڇڪڻ جي درخواستن جا منتظر آهيون.
جو ذريعو: www.habr.com