Hej alla!
Vi Àr en gemenskap av .NET-utvecklare frÄn Raiffeisenbank och vi vill berÀtta om en uppsÀttning infrastrukturbibliotek byggda med .NET Core för snabb skapande av mikrotjÀnster med en enhetlig ekosystem. Vi har slÀppt det som Open Source!
Lite historia
En gĂ„ng hade vi ett stort monolitiskt projekt som gradvis förvandlades till en uppsĂ€ttning mikrotjĂ€nster (om denna process kan du lĂ€sa i ). Under processen stötte vi pĂ„ problemet att skapa nya mikrotjĂ€nster ofta innebar att vi behövde kopiera olika infrastrukturlösningar â som instĂ€llningar för loggning, arbete med databaser, WCF osv. Detta projekt jobbades av ett team, och alla var redan vana vid en etablerad metod för arbete med infrastrukturen. DĂ€rför isolerade vi den gemensamma koden i ett separat repository, paketerade de insamlade biblioteken som Nuget-paket och placerade dem i vĂ„rt interna Nuget-lager.
Tiden gick, projektet splittrades sakta, och vi fick en önskan att skapa nya moduler av klientdelen med moderna JS-ramverk och köra dem i webblÀsaren. Vi började övergÄ frÄn WCF/SOAP till REST/HTTP, sÄ vi behövde nya bibliotek för snabb lansering av tjÀnster baserade pÄ AspNet WebApi. Den första versionen pÄ .Net Framework 4.5 gjordes av vÄr arkitekt knappt pÄ fritiden, men den tillÀt redan frÄn början att med tre rader i Program.cs starta en tjÀnst som innehöll autentisering (NTLM), loggning, Swagger, IoC/DI baserat pÄ Castle Windsor, konfigurerade HTTP-klienter som vidarebefordrade olika huvuden för att sÀkerstÀlla spÄrbar loggning genom hela projektet. Allt detta kunde dessutom konfigureras direkt i konfigurationsfilen för tjÀnsten.
Men allt var inte helt smidigt: detta bibliotek visade sig vara extremt oflexibelt nÀr det gÀllde att införa nya moduler. Till exempel, om det var nödvÀndigt att lÀgga till ett sÀrskilt middleware, var man tvungen att skapa en ny samling och Àrva frÄn basklassen som startade tjÀnsten, vilket var oerhört obekvÀmt. Lyckligtvis var sÄdana fall inte sÄ mÄnga.
Docker- och Kubernetes-eran
Det har kommit en tid dÄ Àven vi har blivit pÄverkade av vÄgen av Docker och Kubernetes, som vi har följt noggrant: det har varit ett utmÀrkt tillfÀlle att gÄ vidare med teknologier i .Net Core. Det betyder att vi behöver en ny infrastruktur för att lansera tjÀnster: en del bibliotek har överförts frÄn .Net Framework till .Net Standard och .Net Core praktiskt taget utan förÀndringar, medan andra har fÄtt nÄgra förbÀttringar. Men vi ville framför allt omarbeta funktionaliteten kopplad till lansering av tjÀnster pÄ AspNet Core.
Det första steget var att övervÀga ett koncept som skulle eliminera den största nackdelen med den tidigare versionen: bristen pÄ flexibilitet. DÀrför beslutades det att göra hela systemet av bibliotek sÄ oberoende och modulÀrt som möjligt, och bygga de funktionella tjÀnsterna som en konstruktor.
Det primĂ€ra mĂ„let Ă€r att skapa en enhetlig metod för hur man interagerar med databaser, bussar och andra tjĂ€nster. Vi har försökt göra integrationerna snabba och smĂ€rtfri sĂ„ att utvecklarna kan fokusera pĂ„ att skriva affĂ€rslogik snarare Ă€n infrastruktur â den Ă€r redan klar. Det gemensamma arkivet hjĂ€lper till att förbĂ€ttra interaktionen inom teamen: nĂ€r mycket liknande interna infrastrukturer anvĂ€nds blir det lĂ€ttare att delta i en annan teams utvecklingsprocess och dela kunskap.
Och varför behöver vi Open Source?
Vi vill visa mognad i vÄr expertis och fÄ kvalitativ feedback: en person utanför banken kan bidra med egna insikter. Vi Àr ocksÄ intresserade av att utveckla arbetsmetoder med mikrotjÀnster och DDD pÄ .NET inom industrin, kanske finns det nÄgon som vill ta vissa delar av ramverket för sig sjÀlv.
Faktiskt, ViennaNET
Nu lÄt oss gÄ igenom allt mer i detalj. .
ViennaNET.WebApi.*
Detta bibliotekspaket bestÄr av "roten" ViennaNET.WebApi, som innehÄller en klassbyggare för tjÀnsten CompanyHostBuilder, och flera konfigurerare ViennaNET.WebApi.Configurators.*, dÀr varje enskild möjliggör tillÀgg och konfiguration av viss funktionalitet i den skapade tjÀnsten. Bland konfigurerarna finns funktioner för loggning, diagnostik, autentisering och auktorisering, swagger etc.
HÀr finns ViennaNET.WebApi.Runners.* som innehÄller förkonfigurerade byggare för tjÀnster. Dessa paket gör det möjligt att slippa tÀnka pÄ vilka konfigurerare som mÄste kopplas varje gÄng du skapar en ny tjÀnst. Samtidigt begrÀnsar de inte funktionaliteten hos tjÀnstebyggen.
ViennaNET.Mediator.*
Bibliotek som möjliggör skapandet av en intern meddelandebuss för kommandon och förfrÄgningar inom tjÀnsten. Detta tillvÀgagÄngssÀtt minskar antalet DI-injektioner till en, till exempel i kontroller. Genom detta kan olika dekorerare lÀggas till förfrÄgningar, vilket förenar deras bearbetning och minskar mÀngden kod.
ViennaNET.Validation
En samling som innehÄller en uppsÀttning klasser för att skapa valideringsregler och sekvenser av dem. Mycket praktiskt för att genomföra domÀnvalidering, eftersom det gör det möjligt att beskriva varje affÀrsvillkor i form av en enkel och separat regel.
ViennaNET.Redis
Ett bibliotek med omslag för att enkelt arbeta med Redis som in-memory cache.
ViennaNET.Specifications
En samling som innehÄller klasser som implementerar mönstret "Specifikation".
Detta Àr lÄngt ifrÄn allt som finns i vÄrt paket. Du kan se resten . Snart planeras det att vÄra bibliotek för databashantering ska bli OpenSource.
Tack för uppmÀrksamheten, vi ser fram emot dina kommentarer och pull requests.
KĂ€lla: habr.com
