Усім прывітанне!
Мы супольнасць .NET-распрацоўшчыкаў Райффайзенбанка і мы жадаем распавесці пра набор інфраструктурных бібліятэк на .NET Core для хуткага стварэння мікрасэрвісаў з адзінай экасістэмай. Вывелі яго ў Open Source!
Трохі гісторыі
Калісьці ў нас быў вялікі маналітны праект, які паступова ператвараўся ў набор мікрасэрвісаў (аб асаблівасцях дадзенага працэсу можна прачытаць у ). У працэсе мы сутыкнуліся з праблемай, што пры стварэнні новых мікрасэрвісаў нам часта даводзілася капіяваць розныя інфраструктурныя рашэнні - накшталт налады лагіравання, працы з БД, WCF і да т.п. Над дадзеным праектам працавала адна каманда, і ўсё ўжо абвыклі да некаторага ўстоянага падыходу працы з інфраструктурай. Таму мы вылучылі агульны код у асобны рэпазітар, сабраныя бібліятэкі загарнулі ў Nuget-пакеты і змясцілі ў наша ўнутранае Nuget-сховішча.
Час ішоў, праект патроху драбніўся, з'явілася жаданне ствараць новыя модулі кліенцкай часткі на сучасным Js-фрэймворку і запускаць іх у браўзэры. Мы пачалі пераходзіць з WCF/SOAP на REST/HTTP, таму нам запатрабаваліся новыя бібліятэкі для хуткага запуску сэрвісаў на базе AspNet WebApi. Першая версія на. Net Framework 4.5 была зроблена нашым архітэктарам ці ледзь не на каленцы ў вольны час, але яна ўжо са скрынкі дазваляла трыма радкамі ў Program.cs запусціць сэрвіс, які ўтрымоўваў аўтарызацыю (NTLM), лагіраванне, Swagger, IoC/DI на базе Castle Windsor, настроеных HTTP-кліентаў, якія пракідваюць розныя загалоўкі для забеспячэння скразнога лагавання ва ўсім праекце. І ўся гэтая справа можна было дадаткова сканфігураваць ужо ў непасрэдна ў файле канфігурацыі сэрвісу.
Аднак не ўсё было гладка: дадзеная бібліятэка атрымалася вельмі нягнуткай у плане ўкаранення новых модуляў. Напрыклад, калі патрабавалася дадаць якое-небудзь адмысловае middleware, тое даводзілася ствараць новую зборку і ўспадкоўвацца ад базавага класа, які запускае сэрвіс, што было вельмі няёмка. Да шчасця, такіх выпадкаў было не вельмі шмат.
Эпоха Docker і Kubernetes
Нетутэйша час, калі і да нас дакацілася хваля c Docker і Kubernetes, за якой мы пільна назіралі: бо гэта быў выдатны шанец пачаць рух па тэхналогіях далей, у .Net Core. А значыць, нам спатрэбіцца новая інфраструктура для запуску сэрвісаў: частка бібліятэк перавандравала з. Net Framework на. Net Standard і. Net Core практычна без змен, частка з невялікімі паляпшэннямі. Але больш за ўсё жадалася перапрацаваць функцыянал, злучаны з запускам сэрвісаў на AspNet Core.
Перш за ўсё разглядаўся канцэпт, які дазваляе прыбраць галоўны недахоп папярэдняй версіі: адсутнасць гнуткасці. Таму было вырашана зрабіць усю сістэму бібліятэк як мага больш незалежнай і модульнай і збіраць неабходныя па функцыянале сервісы як канструктар.
Галоўная мэта - стварыць уніфікаваны падыход, які апісвае, як узаемадзейнічаць з базамі дадзеных, шынамі і іншымі сэрвісамі. Мы пастараліся, каб інтэграцыі былі хуткімі і бязбольнымі, а распрацоўшчыкі маглі сканцэнтравацца на напісанні бізнес-логікі, а не інфраструктуры - яна ўжо гатова. Агульны рэпазітар дапамагае палепшыць вопыт узаемадзеяння ўнутры каманд: калі выкарыстоўваюцца вельмі падобныя ўнутраныя інфраструктуры, то лягчэй уключыцца ў працэс распрацоўкі іншай каманды і абмяняцца экспертызай.
І навошта нам Open Source?
Мы хочам паказаць сталасць экспертызы і атрымаць якасную зваротную сувязь: чалавек, які знаходзіцца па-за банкам, зможа прыўнесці нешта ад сябе. Таксама нам цікава развіццё практык працы з мікрасэрвісамі і DDD на. NET у індустрыі, магчыма, хтосьці захоча забраць пэўныя часткі фрэймворка да сябе.
Уласна, ViennaNET
Цяпер давайце разгледзім усё падрабязней. .
ViennaNET.WebApi.*
Дадзены набор бібліятэк складаецца з «кораня» ViennaNET.WebApi, які змяшчае клас-будаўнік для сэрвісу CompanyHostBuilder, і набору канфігуратараў ViennaNET.WebApi.Configurators.*, кожны з якіх дазваляе дадаць і сканфігураваць некаторы функцыянал у ствараемы сэрвіс. Сярод канфігуратараў можна знайсці падлучэнне лагавання, дыягностыкі, тыпу аўтэнтыфікацыі і аўтарызацыі, swagger-а і т.д.
Тут жа ViennaNET.WebApi.Runners.* змяшчае папярэдне настроеныя будаўнікі сэрвісаў. Гэтыя пакеты дазваляюць не ўспамінаць кожны раз, ствараючы новы сэрвіс, якія канфігуратары неабходна падлучыць. Пры гэтым яны ніяк не абмяжоўваюць функцыянальнасць будаўніка сэрвісаў.
ViennaNET.Mediator.*
Бібліятэкі, якія дазваляюць стварыць унутраную шыну-пасрэднік для каманд і запытаў усярэдзіне сэрвісу. Такі падыход дазваляе скараціць колькасць DI-ін'екцый да адной, напрыклад, у кантролерах. За рахунак гэтага можна дадаваць розныя дэкаратары да запытаў, што ўніфікуе іх апрацоўку і скарачае колькасць кода.
ViennaNET.Validation
Зборка, якая змяшчае набор класаў для стварэння валідацыйных правіл і паслядоўнасцяў з іх. Вельмі зручная для рэалізацыі даменнай валідацыі, бо дазваляе апісаць кожную бізнес-ўмову ў выглядзе простага і асобнага правіла.
ViennaNET.Redis
Бібліятэка з абгорткамі для зручнай працы з Redis у якасці in-memory cache.
ViennaNET.Specifications
Зборка, якая змяшчае класы, якія рэалізуюць патэрн "Спецыфікацыя".
Гэта далёка не ўсё што ёсць у нашым наборы. Астатняе можна паглядзець . Хутка плануецца выхад у OpenSource нашых бібліятэк для працы з базамі даных.
Дзякуй за ўвагу, чакаем вашых каментароў і pull request-аў.
Крыніца: habr.com