Hallo almal!
Ons is 'n gemeenskap van .NET-ontwikkelaars by Raiffeisenbank en ons wil praat oor 'n stel infrastruktuurbiblioteke gebaseer op .NET Core om vinnig mikrodienste met 'n enkele ekosisteem te skep. Hulle het dit na Open Source gebring!
'N bietjie geskiedenis
Eens op 'n tyd het ons 'n groot monolitiese projek gehad, wat geleidelik in 'n stel mikrodienste verander het (jy kan lees oor die kenmerke van hierdie proses in ). In die proses het ons die probleem teëgekom dat wanneer ons nuwe mikrodienste skep, ons dikwels verskeie infrastruktuuroplossings moes kopieer – soos die opstel van logging, werk met 'n databasis, WCF, ens. Een span het aan hierdie projek gewerk, en almal was reeds gewoond aan die een of ander gevestigde benadering om met infrastruktuur te werk. Daarom het ons die gemeenskaplike kode in 'n aparte bewaarplek geskei, die versamelde biblioteke in Nuget-pakkette toegedraai en dit in ons interne Nuget-bewaarplek geplaas.
Die tyd het verbygegaan, die projek het geleidelik gefragmenteer, en daar was 'n begeerte om nuwe kliënt-kant modules op 'n moderne JS raamwerk te skep en dit in die blaaier te laat loop. Ons het begin beweeg van WCF/SOAP na REST/HTTP, so ons het nuwe biblioteke nodig gehad om dienste wat op AspNet WebApi gebaseer is vinnig bekend te stel. Die eerste weergawe op die .Net Framework 4.5 is deur ons argitek in sy vrye tyd amper op sy knieë gemaak, maar uit die boks het dit dit moontlik gemaak om 'n diens met drie reëls in Program.cs te loods wat magtiging (NTLM) bevat het. logging, Swagger, IoC/DI op gebaseer op Castle Windsor, pasgemaakte HTTP-kliënte wat verskeie kopskrifte aanstuur om end-tot-end logging deur die hele projek te verskaf. En hierdie hele ding kan direk in die dienskonfigurasielêer verder gekonfigureer word.
Alles was egter nie glad nie: hierdie biblioteek was uiters onbuigsaam in terme van die bekendstelling van nuwe modules. As jy byvoorbeeld spesiale middelware moes byvoeg, moes jy 'n nuwe samestelling skep en erf van die basisklas wat die diens bestuur, wat uiters ongerieflik was. Gelukkig was daar nie baie sulke gevalle nie.
Die era van Docker en Kubernetes
Die tyd het aangebreek dat die golf van Docker en Kubernetes ons bereik het, wat ons fyn dopgehou het: dit was immers 'n wonderlike kans om verder te begin beweeg langs die tegnologieë, in .Net Core. Dit beteken dat ons 'n nuwe infrastruktuur sal benodig om dienste uit te voer: sommige biblioteke het feitlik sonder veranderinge van die .Net Framework na .Net Standard en .Net Core gemigreer, sommige met geringe verbeterings. Maar bowenal wou ek die funksionaliteit wat verband hou met die bekendstelling van dienste op AspNet Core herwerk.
Die eerste ding wat ons oorweeg het, was 'n konsep wat die grootste nadeel van die vorige weergawe sou verwyder: gebrek aan buigsaamheid. Daarom is besluit om die hele biblioteekstelsel so onafhanklik en modulêr moontlik te maak en die dienste te versamel wat nodig is vir funksionaliteit as 'n konstruktor.
Die hoofdoel is om 'n verenigde benadering te skep wat beskryf hoe om met databasisse, busse en ander dienste om te gaan. Ons het probeer om integrasies vinnig en pynloos te maak, en ontwikkelaars kon konsentreer op die skryf van besigheidslogika eerder as infrastruktuur – dit is reeds gereed. 'n Algemene bewaarplek help om die ervaring van interaksie binne spanne te verbeter: wanneer baie soortgelyke interne infrastruktuur gebruik word, is dit makliker om by die ontwikkelingsproses van 'n ander span aan te sluit en kundigheid uit te ruil.
En hoekom het ons oopbron nodig?
Ons wil die volwassenheid van ons kundigheid wys en terugvoer van hoë gehalte ontvang: 'n persoon buite die bank sal iets van homself kan bring. Ons stel ook belang in die ontwikkeling van praktyke om met mikrodienste en DDD op .NET in die bedryf te werk; miskien sal iemand sekere dele van die raamwerk wil oorneem.
Eintlik, ViennaNET
Kom ons kyk nou van nader. .
ViennaNET.WebApi.*
Hierdie stel biblioteke bestaan uit die "wortel" ViennaNET.WebApi, wat die bouerklas vir die CompanyHostBuilder-diens bevat, en 'n stel konfigureerders ViennaNET.WebApi.Configurators.*, wat elkeen jou toelaat om 'n sekere funksionaliteit by die geskepte te voeg en op te stel. diens. Onder die konfigureerders kan u verbindings vind vir aanteken, diagnostiek, verifikasie en magtigingstipes, swagger, ens.
ViennaNET.WebApi.Runners.* bevat ook vooraf gekonfigureerde diensbouers. Hierdie pakkette laat jou toe om nie elke keer wanneer jy 'n nuwe diens skep, te onthou watter konfigureerders gekoppel moet word nie. Dit beperk egter geensins die funksionaliteit van die diensbouer nie.
ViennaNET.Bemiddelaar.*
Biblioteke wat jou toelaat om 'n interne tussengangerbus vir opdragte en versoeke binne 'n diens te skep. Hierdie benadering laat jou toe om die aantal DI-inspuitings tot een te verminder, byvoorbeeld in beheerders. As gevolg hiervan kan u verskeie versierders by versoeke voeg, wat hul verwerking verenig en die hoeveelheid kode verminder.
ViennaNET.Validasie
'n Samestelling wat 'n stel klasse bevat vir die skep van valideringsreëls en rye daaruit. Dit is baie gerieflik vir die implementering van domeinvalidering, aangesien dit jou toelaat om elke besigheidstoestand in die vorm van 'n eenvoudige en aparte reël te beskryf.
WeneNET.Redis
'n Biblioteek met omhulsels vir gerieflike werk met Redis as 'n in-geheue-kas.
ViennaNET.Spesifikasies
'n Samestelling wat klasse bevat wat die spesifikasiepatroon implementeer.
Dit is nie al wat in ons stel is nie. Jy kan die res sien . Ons beplan om binnekort ons biblioteke vir werk met databasisse aan OpenSource vry te stel.
Dankie vir jou aandag, ons sien uit na jou kommentaar en trek versoeke.
Bron: will.com