Hej alle!
Vi er et fællesskab af .NET-udviklere hos Raiffeisenbank, og vi vil gerne tale om et sæt infrastrukturbiblioteker baseret på .NET Core til hurtigt at skabe mikrotjenester med et enkelt økosystem. De bragte det til Open Source!
Lidt historie
Engang havde vi et stort monolitisk projekt, som gradvist blev til et sæt mikrotjenester (du kan læse om funktionerne i denne proces i ). I processen stødte vi på det problem, at vi ved oprettelse af nye mikrotjenester ofte skulle kopiere forskellige infrastrukturløsninger – såsom opsætning af logning, arbejde med en database, WCF mv. Et team arbejdede på dette projekt, og alle var allerede vant til en etableret tilgang til at arbejde med infrastruktur. Derfor adskilte vi den fælles kode i et separat lager, pakkede de indsamlede biblioteker ind i Nuget-pakker og placerede dem i vores interne Nuget-depot.
Tiden gik, projektet blev gradvist fragmenteret, og der var et ønske om at skabe nye klientside-moduler på et moderne JS-framework og køre dem i browseren. Vi begyndte at flytte fra WCF/SOAP til REST/HTTP, så vi havde brug for nye biblioteker for hurtigt at kunne lancere tjenester baseret på AspNet WebApi. Den første version på .Net Framework 4.5 blev lavet af vores arkitekt næsten på knæ i sin fritid, men ud af boksen gjorde det muligt at lancere en tjeneste med tre linjer i Program.cs, der indeholdt autorisation (NTLM), logning, Swagger, IoC/DI baseret på Castle Windsor, tilpassede HTTP-klienter, der videresender forskellige headers for at levere ende-til-ende-logning gennem hele projektet. Og det hele kunne konfigureres yderligere direkte i servicekonfigurationsfilen.
Men ikke alt var glat: dette bibliotek viste sig at være ekstremt ufleksibelt med hensyn til at introducere nye moduler. For eksempel, hvis du skulle tilføje noget speciel middleware, skulle du oprette en ny assembly og arve fra den basisklasse, der kører tjenesten, hvilket var ekstremt ubelejligt. Heldigvis var der ikke ret mange sådanne sager.
Docker og Kubernetes æra
Tiden er kommet, hvor bølgen af Docker og Kubernetes nåede os, som vi fulgte nøje: Det var trods alt en fantastisk chance for at begynde at bevæge sig 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 migreret fra .Net Framework til .Net Standard og .Net Core praktisk talt uden ændringer, nogle med mindre forbedringer. Men mest af alt ønskede jeg at omarbejde funktionaliteten forbundet med at lancere tjenester på AspNet Core.
Det første, vi overvejede, var et koncept, der ville fjerne den største ulempe ved den tidligere version: mangel på fleksibilitet. Derfor blev det besluttet at gøre hele bibliotekssystemet så uafhængigt og modulært som muligt og samle de services, der er nødvendige for funktionalitet som konstruktør.
Hovedmålet er at skabe en samlet tilgang, der beskriver, hvordan man interagerer med databaser, busser og andre tjenester. Vi forsøgte at gøre integrationer hurtige og smertefri, og udviklere kunne koncentrere sig om at skrive forretningslogik frem for infrastruktur – den er allerede klar. Et fælles lager hjælper med at forbedre oplevelsen af interaktion i teams: Når meget ens interne infrastrukturer bruges, er det lettere at deltage i udviklingsprocessen for et andet team og udveksle ekspertise.
Og hvorfor har vi brug for Open Source?
Vi ønsker at vise modenheden af vores ekspertise og modtage feedback af høj kvalitet: en person uden for banken vil være i stand til at bringe noget af sig selv. Vi er også interesserede i udviklingen af praksisser for at arbejde med mikrotjenester og DDD på .NET i branchen; måske vil nogen overtage visse dele af rammeværket.
Faktisk ViennaNET
Lad os nu se nærmere. .
ViennaNET.WebApi.*
Dette sæt af biblioteker består af "roden" ViennaNET.WebApi, der indeholder builder-klassen til CompanyHostBuilder-tjenesten, og et sæt konfiguratorer ViennaNET.WebApi.Configurators.*, som hver især giver dig mulighed for at tilføje og konfigurere nogle funktioner til den oprettede service. Blandt konfiguratorerne kan du finde forbindelser til logning, diagnostik, autentificering og autorisationstyper, swagger mv.
ViennaNET.WebApi.Runners.* indeholder også forudkonfigurerede tjenestebyggere. Disse pakker giver dig mulighed for ikke at huske, hver gang du opretter en ny tjeneste, hvilke konfiguratorer der skal tilsluttes. De begrænser dog ikke servicebyggerens funktionalitet på nogen måde.
ViennaNET.Mediator.*
Biblioteker, der giver dig mulighed for at oprette en intern mellemliggende bus til kommandoer og anmodninger inden for en tjeneste. Denne tilgang giver dig mulighed for at reducere antallet af DI-injektioner til én, for eksempel i controllere. På grund af dette kan du tilføje forskellige dekoratører til anmodninger, hvilket forener deres behandling og reducerer mængden af kode.
ViennaNET.Validation
En samling, der indeholder et sæt klasser til at skabe valideringsregler og sekvenser ud fra dem. Det er meget praktisk at implementere domænevalidering, da det giver dig mulighed for at beskrive hver forretningstilstand i form af en enkel og separat regel.
ViennaNET.Redis
Et bibliotek med indpakninger til praktisk arbejde med Redis som en in-memory cache.
ViennaNET.Specifikationer
En samling, der indeholder klasser, der implementerer specifikationsmønsteret.
Det er ikke alt, der er i vores sæt. Du kan se resten . Vi planlægger snart at frigive vores biblioteker til at arbejde med databaser til OpenSource.
Tak for din opmærksomhed, vi ser frem til dine kommentarer og pull-anmodninger.
Kilde: www.habr.com