Hammaga salom!
Biz Raiffeisenbankdagi .NET dasturchilari hamjamiyatimiz va biz bitta ekotizim bilan mikroservislarni tezda yaratish uchun .NET Core asosidagi infratuzilma kutubxonalari to‘plami haqida gapirmoqchimiz. Ular uni Ochiq manbaga olib kelishdi!
Biroz tarix
Bir paytlar bizda katta monolit loyiha bor edi, u asta-sekin mikroservislar to'plamiga aylandi (siz ushbu jarayonning xususiyatlari haqida o'qishingiz mumkin. ). Jarayonda biz yangi mikroservislarni yaratishda biz ko'pincha turli xil infratuzilma echimlarini nusxalashimiz kerak edi, masalan, jurnalni o'rnatish, ma'lumotlar bazasi, WCF va boshqalar bilan ishlash. Ushbu loyihada bitta jamoa ishlagan va hamma allaqachon infratuzilma bilan ishlashda qandaydir o'rnatilgan yondashuvga o'rganib qolgan edi. Shuning uchun biz umumiy kodni alohida omborga ajratdik, to'plangan kutubxonalarni Nuget paketlariga o'rab oldik va ularni ichki Nuget omborimizga joylashtirdik.
Vaqt o'tdi, loyiha asta-sekin parchalanib ketdi va zamonaviy JS ramkasida yangi mijoz modullarini yaratish va ularni brauzerda ishga tushirish istagi paydo bo'ldi. Biz WCF/SOAP-dan REST/HTTP-ga o'tishni boshladik, shuning uchun AspNet WebApi-ga asoslangan xizmatlarni tezda ishga tushirish uchun bizga yangi kutubxonalar kerak edi. .Net Framework 4.5-ning birinchi versiyasini bizning me'morimiz bo'sh vaqtida deyarli tizzalab yasagan, ammo bu dastur.cs-da avtorizatsiyani (NTLM) o'z ichiga olgan uchta qatorli xizmatni ishga tushirishga imkon berdi, logging, Swagger, IoC/DI Castle Windsor negizida, butun loyiha davomida oxirigacha ro'yxatga olishni ta'minlash uchun turli sarlavhalarni yuboradigan moslashtirilgan HTTP mijozlari. Va bularning barchasi to'g'ridan-to'g'ri xizmat konfiguratsiya faylida sozlanishi mumkin.
Biroq, hamma narsa silliq emas edi: bu kutubxona yangi modullarni joriy qilish nuqtai nazaridan juda moslashuvchan emas edi. Misol uchun, agar sizga maxsus o'rta dasturni qo'shish kerak bo'lsa, siz yangi yig'ilish yaratishingiz va xizmatni boshqaradigan asosiy sinfdan meros bo'lishingiz kerak edi, bu juda noqulay edi. Yaxshiyamki, bunday holatlar unchalik ko'p emas edi.
Docker va Kubernetes davri
Docker va Kubernetes to'lqini bizga yetib borgan vaqt keldi, biz buni diqqat bilan kuzatdik: axir, bu .Net Core-da texnologiyalar bo'ylab harakatlanishni boshlash uchun ajoyib imkoniyat edi. Bu shuni anglatadiki, xizmatlarni ishga tushirish uchun bizga yangi infratuzilma kerak bo'ladi: ba'zi kutubxonalar .Net Framework'dan .Net Standard va .Net Core'ga deyarli o'zgarishsiz, ba'zilarida esa kichik yaxshilanishlar bilan ko'chib o'tdi. Lekin, eng muhimi, men AspNet Core-da xizmatlarni ishga tushirish bilan bog'liq funksiyalarni qayta ishlashni xohlardim.
Biz ko'rib chiqqan birinchi narsa, avvalgi versiyaning asosiy kamchiligini olib tashlaydigan kontseptsiya edi: moslashuvchanlikning yo'qligi. Shu sababli, butun kutubxona tizimini iloji boricha mustaqil va modulli qilish va konstruktor sifatida funksionallik uchun zarur bo'lgan xizmatlarni yig'ishga qaror qilindi.
Asosiy maqsad - ma'lumotlar bazalari, avtobuslar va boshqa xizmatlar bilan o'zaro munosabatlarni tavsiflovchi yagona yondashuvni yaratish. Biz integratsiyani tez va og'riqsiz qilishga harakat qildik va ishlab chiquvchilar infratuzilma emas, balki biznes mantig'ini yozishga e'tibor qaratishlari mumkin edi - u allaqachon tayyor. Umumiy ombor jamoalar ichidagi o'zaro hamkorlik tajribasini yaxshilashga yordam beradi: juda o'xshash ichki infratuzilmalardan foydalanilganda, boshqa jamoaning rivojlanish jarayoniga qo'shilish va tajriba almashish osonroq bo'ladi.
Va nima uchun bizga ochiq manba kerak?
Biz o'z tajribamizning etukligini ko'rsatishni va yuqori sifatli fikr-mulohazalarni olishni istaymiz: bankdan tashqarida bo'lgan odam o'zidan nimanidir olib kelishi mumkin. Biz, shuningdek, sanoatda .NET da mikroservislar va DDD bilan ishlash amaliyotlarini ishlab chiqishdan manfaatdormiz, ehtimol kimdir ramkaning ma'lum qismlarini egallashni xohlaydi.
Aslida, ViennaNET
Endi batafsilroq ko'rib chiqaylik. .
ViennaNET.WebApi.*
Ushbu kutubxonalar majmuasi CompanyHostBuilder xizmati uchun quruvchi sinfini o'z ichiga olgan "ildiz" ViennaNET.WebApi va ViennaNET.WebApi.Configurators.* konfiguratorlari to'plamidan iborat bo'lib, ularning har biri yaratilganiga ba'zi funksiyalarni qo'shish va sozlash imkonini beradi. xizmat. Konfiguratorlar orasida siz ro'yxatga olish, diagnostika, autentifikatsiya va avtorizatsiya turlari, swagger va boshqalar uchun ulanishlarni topishingiz mumkin.
ViennaNET.WebApi.Runners.* shuningdek, oldindan sozlangan servis quruvchilarni ham o'z ichiga oladi. Ushbu paketlar konfiguratorlar ulanishi kerak bo'lgan har safar yangi xizmatni yaratganingizda eslab qolishingizga imkon beradi. Biroq, ular xizmat ko'rsatuvchining funksionalligini hech qanday tarzda cheklamaydi.
ViennaNET.Mediator.*
Xizmat ichidagi buyruqlar va so'rovlar uchun ichki vositachi avtobus yaratish imkonini beruvchi kutubxonalar. Ushbu yondashuv sizga DI in'ektsiyalari sonini bittaga kamaytirish imkonini beradi, masalan, kontrollerlarda. Shu sababli, so'rovlarga turli xil dekoratorlarni qo'shishingiz mumkin, bu ularni qayta ishlashni birlashtiradi va kod miqdorini kamaytiradi.
ViennaNET.Validation
Tekshirish qoidalari va ulardan ketma-ketlikni yaratish uchun sinflar to'plamini o'z ichiga olgan yig'ilish. Bu domenni tekshirishni amalga oshirish uchun juda qulay, chunki u har bir biznes holatini oddiy va alohida qoida shaklida tasvirlash imkonini beradi.
ViennaNET.Redis
Xotiradagi kesh sifatida Redis bilan qulay ishlash uchun o'ramlari bo'lgan kutubxona.
ViennaNET. Texnik xususiyatlari
Spetsifikatsiya naqshini amalga oshiradigan sinflarni o'z ichiga olgan yig'ilish.
Bu bizning to'plamimizda hamma narsa emas. Qolganini ko'rishingiz mumkin . Tez orada biz kutubxonalarimizni ma'lumotlar bazalari bilan ishlash uchun OpenSource tizimiga chiqarishni rejalashtirmoqdamiz.
E'tiboringiz uchun rahmat, sharhlaringizni va so'rovlaringizni kutamiz.
Manba: www.habr.com