Hei!
Vi er et fellesskap av .NET-utviklere i Raiffeisenbank og vi ønsker å snakke om et sett med infrastrukturbiblioteker basert på .NET Core for raskt å lage mikrotjenester med ett enkelt økosystem. De brakte det til åpen kildekode!
En bit av historien
En gang i tiden hadde vi et stort monolittisk prosjekt, som gradvis ble til et sett med mikrotjenester (du kan lese om funksjonene til denne prosessen i ). I prosessen møtte vi problemet at når vi opprettet nye mikrotjenester, måtte vi ofte kopiere ulike infrastrukturløsninger – som å sette opp logging, jobbe med en database, WCF m.m. Ett team jobbet med dette prosjektet, og alle var allerede vant til en etablert tilnærming til å jobbe med infrastruktur. Derfor skilte vi den felles koden inn i et eget depot, pakket inn de innsamlede bibliotekene i Nuget-pakker og plasserte dem i vårt interne Nuget-depot.
Tiden gikk, prosjektet ble gradvis fragmentert, og det var et ønske om å lage nye klientsidemoduler på et moderne JS-rammeverk og kjøre dem i nettleseren. Vi begynte å gå fra WCF/SOAP til REST/HTTP, så vi trengte nye biblioteker for raskt å lansere tjenester basert på AspNet WebApi. Den første versjonen på .Net Framework 4.5 ble laget av arkitekten vår nesten på kne på fritiden, men ut av esken gjorde det det mulig å lansere en tjeneste med tre linjer i Program.cs som inneholdt autorisasjon (NTLM), logging, Swagger, IoC/DI på basert på Castle Windsor, tilpassede HTTP-klienter som videresender ulike overskrifter for å gi ende-til-ende logging gjennom hele prosjektet. Og hele denne greia kan konfigureres videre direkte i tjenestekonfigurasjonsfilen.
Imidlertid var ikke alt glatt: dette biblioteket viste seg å være ekstremt lite fleksibelt når det gjelder å introdusere nye moduler. For eksempel, hvis du trengte å legge til noe spesiell mellomvare, måtte du opprette en ny sammenstilling og arve fra basisklassen som kjører tjenesten, noe som var ekstremt upraktisk. Heldigvis var det ikke så veldig mange slike saker.
Tiden til Docker og Kubernetes
Tiden har kommet da bølgen av Docker og Kubernetes nådde oss, som vi fulgte nøye med: tross alt var det en flott sjanse til å begynne å bevege seg videre langs teknologiene, i .Net Core. Dette betyr at vi trenger en ny infrastruktur for å kjøre tjenester: noen biblioteker har migrert fra .Net Framework til .Net Standard og .Net Core praktisk talt uten endringer, noen med mindre forbedringer. Men mest av alt ønsket jeg å omarbeide funksjonaliteten knyttet til lansering av tjenester på AspNet Core.
Det første vi vurderte var et konsept som ville fjerne hovedulempen med den forrige versjonen: mangel på fleksibilitet. Derfor ble det besluttet å gjøre hele biblioteksystemet så uavhengig og modulært som mulig og samle de nødvendige tjenestene for funksjonalitet som konstruktør.
Hovedmålet er å skape en enhetlig tilnærming som beskriver hvordan man samhandler med databaser, busser og andre tjenester. Vi prøvde å gjøre integrasjoner raske og smertefrie, og utviklere kunne konsentrere seg om å skrive forretningslogikk i stedet for infrastruktur – den er allerede klar. Et felles depot bidrar til å forbedre opplevelsen av samhandling i team: når svært like interne infrastrukturer brukes, er det lettere å bli med i utviklingsprosessen til et annet team og utveksle ekspertise.
Og hvorfor trenger vi åpen kildekode?
Vi ønsker å vise modenhet av vår ekspertise og motta tilbakemeldinger av høy kvalitet: en person utenfor banken vil kunne bringe noe av seg selv. Vi er også interessert i utvikling av praksis for arbeid med mikrotjenester og DDD på .NET i bransjen, kanskje noen ønsker å overta visse deler av rammeverket.
Faktisk, ViennaNET
La oss nå se nærmere. .
ViennaNET.WebApi.*
Dette settet med biblioteker består av "root" ViennaNET.WebApi, som inneholder byggmesterklassen for CompanyHostBuilder-tjenesten, og et sett med konfiguratorer ViennaNET.WebApi.Configurators.*, som hver lar deg legge til og konfigurere noen funksjonalitet til den opprettede service. Blant konfiguratorene kan du finne tilkoblinger for logging, diagnostikk, autentisering og autorisasjonstyper, swagger, etc.
ViennaNET.WebApi.Runners.* inneholder også forhåndskonfigurerte tjenestebyggere. Disse pakkene lar deg ikke huske hver gang du oppretter en ny tjeneste hvilke konfiguratorer som må kobles til. De begrenser imidlertid ikke funksjonaliteten til tjenestebyggeren på noen måte.
ViennaNET.Mediator.*
Biblioteker som lar deg lage en intern mellomledd buss for kommandoer og forespørsler innenfor en tjeneste. Denne tilnærmingen lar deg redusere antall DI-injeksjoner til én, for eksempel i kontrollere. På grunn av dette kan du legge til forskjellige dekoratører til forespørsler, noe som forener behandlingen og reduserer mengden kode.
ViennaNET.Validation
En sammenstilling som inneholder et sett med klasser for å lage valideringsregler og sekvenser fra dem. Det er veldig praktisk for å implementere domenevalidering, da det lar deg beskrive hver forretningstilstand i form av en enkel og separat regel.
ViennaNET.Redis
Et bibliotek med innpakninger for praktisk arbeid med Redis som en cache i minnet.
ViennaNET.Spesifikasjoner
En sammenstilling som inneholder klasser som implementerer spesifikasjonsmønsteret.
Dette er ikke alt som er i settet vårt. Du kan se resten . Vi planlegger å frigi bibliotekene våre for arbeid med databaser til OpenSource snart.
Takk for oppmerksomheten, vi ser frem til dine kommentarer og henvendelser.
Kilde: www.habr.com