Hej alle sammen!
Vi er et fællesskab af .NET-udviklere fra Raiffeisenbanken, og vi ønsker at fortælle om et sæt infrastrukturbiblioteker i .NET Core til hurtig oprettelse af mikrotjenester med en fælles økosystem. Vi har gjort det til Open Source!
Lidt historie
Engang havde vi et stort monolitisk projekt, som langsomt blev til et sæt mikrotjenester (om de særpræg ved denne proces kan læses i ). I processen stødte vi på problemet med, at vi ofte måtte kopiere forskellige infrastrukturløsninger - såsom opsætning af logging, arbejde med databaser, WCF osv. Et hold arbejdede på dette projekt, og alle var allerede blevet vant til en vis etableret tilgang til infrastrukturarbejdet. Derfor isolerede vi den fælles kode i et separat repository, pakkede de samlede biblioteker ind som NuGet-pakker og placerede dem i vores interne NuGet-arkiv.
Tiden gik, projektet blev gradvist opdelt, og der blev et ønske om at oprette nye moduler af frontend-delen med et moderne JS-rammeværk og lancerede dem i browseren. Vi begyndte at skifte fra WCF/SOAP til REST/HTTP, så vi havde brug for nye biblioteker til hurtigt at kunne starte tjenester baseret på AspNet WebApi. Den første version på .Net Framework 4.5 blev lavet af vores arkitekt næsten i fritiden, men den kunne allerede out-of-the-box aktivere en tjeneste med tre linjer i Program.cs, som indeholdt godkendelse (NTLM), logging, Swagger, IoC/DI baseret på Castle Windsor, konfigurerede HTTP-klienter, der videresender forskellige overskrifter for at sikre end-to-end logging i hele projektet. Og det hele kunne yderligere konfigureres direkte i tjenestens konfigurationsfil.
Men alt var ikke problemfrit: dette bibliotek viste sig at være ekstremt ufleksibelt med hensyn til implementering af nye moduler. For eksempel, hvis der var behov for at tilføje et specielt middleware, måtte man oprette en ny samling og arve fra basis klassen der driver tjenesten, hvilket var uhandy. Heldigvis var sådanne tilfælde ikke så mange.
Docker- og Kubernetes-æraen
Tiden er kommet, hvor bølgen af Docker og Kubernetes også har nået os, som vi har fulgt nøje: det er en fantastisk mulighed for at tage skridt videre med teknologierne i .Net Core. Det betyder, at vi får brug for en ny infrastruktur til at køre tjenester: nogle biblioteker er blevet overført fra .Net Framework til .Net Standard og .Net Core stort set uden ændringer, mens andre er blevet forbedret en smule. Men det, vi helst ville have, var at redesigne funktionaliteten, der er relateret til kørsel af tjenester på AspNet Core.
Først og fremmest blev der overvejet et koncept, der kunne fjerne hovedproblemet fra den tidligere version: mangel på fleksibilitet. Derfor blev det besluttet at gøre hele systemet af biblioteker så uafhængigt og modulært som muligt og samle de nødvendige funktionaliteter til tjenester som en byggeklods.
Hovedmålet er at skabe en ensartet tilgang, der beskriver, hvordan man interagerer med databaser, busser og andre tjenester. Vi har stræbt efter, at integrationerne skulle være hurtige og smertefri, så udviklerne kunne koncentrere sig om at skrive forretningslogik, ikke infrastruktur – den er allerede klar. Det fælles repository hjælper med at forbedre oplevelsen af samarbejde inden for teamene: når meget lignende interne infrastrukturer anvendes, er det lettere at deltage i udviklingsprocessen af et andet team og udveksle ekspertise.
Og hvorfor har vi brug for Open Source?
Vi ønsker at vise modenhed i vores ekspertise og få kvalitetsfeedback: en person uden for banken kan tilføre noget unikt. Vi er også interesserede i udviklingen af praksisser relateret til mikrotjenester og DDD på .NET i branchen, muligvis ønsker nogen at tage visse dele af rammeværket med sig.
Egentlig, ViennaNET
Lad os nu se nærmere på alt dette. .
ViennaNET.WebApi.*
Dette bibliotekssæt består af 'roden' ViennaNET.WebApi, der indeholder en builder-klasse for tjenesten CompanyHostBuilder, samt et sæt konfigureringsværktøjer ViennaNET.WebApi.Configurators.*, som hver især muliggør tilføjelse og konfiguration af en bestemt funktionalitet i den oprettede tjeneste. Blandt konfigureringsværktøjerne kan man finde tilslutning til logging, diagnosticering, autenticering og autorisering, swagger mm.
Her indeholder ViennaNET.WebApi.Runners.* forudindstillede service-builders. Disse pakker gør det muligt ikke at skulle huske, hvilke konfigureringsindstillinger der skal tilsluttes, hver gang man opretter en ny service. De begrænser dog ikke funktionaliteten af service-builders.
ViennaNET.Mediator.*
Biblioteker, der gør det muligt at oprette en intern bus-mediator til kommandoer og forespørgsler inden for servicen. Denne tilgang reducerer antallet af DI-injektioner til én, for eksempel i controllere. Derved kan man tilføje forskellige dekoratører til forespørgslerne, hvilket ensarter deres behandling og reducerer mængden af kode.
ViennaNET.Validation
En samling, der indeholder et sæt klasser til oprettelse af valideringsregler og sekvenser af dem. Meget praktisk til implementering af domænevalidering, da den gør det muligt at beskrive hver forretningsbetingelse som en enkelt og simpel regel.
ViennaNET.Redis
Et bibliotek med wrappers for nem håndtering af Redis som in-memory cache.
ViennaNET.Specifications
En samling, der indeholder klasser, der implementerer mønsteret 'Specification'.
Dette er langt fra alt, hvad der er i vores samling. Det resterende kan ses . Snart planlægges vores biblioteker til databasestyring at blive open source.
Tak for opmærksomheden, vi ser frem til jeres kommentarer og pull requests.
Kilde: habr.com
