Hallo iedereen!
Wij zijn een gemeenschap van .NET-ontwikkelaars bij Raiffeisenbank en we willen het hebben over een reeks infrastructuurbibliotheken gebaseerd op .NET Core voor het snel creëren van microservices met één enkel ecosysteem. Ze brachten het naar Open Source!
Een beetje geschiedenis
Er was eens een groot monolithisch project, dat geleidelijk veranderde in een reeks microservices (je kunt lezen over de kenmerken van dit proces in ). Daarbij kwamen we het probleem tegen dat we bij het maken van nieuwe microservices vaak verschillende infrastructuuroplossingen moesten kopiëren - zoals het opzetten van logging, het werken met een database, WCF, enz. Eén team werkte aan dit project en iedereen was al gewend aan een vaste aanpak voor het werken met infrastructuur. Daarom hebben we de gemeenschappelijke code in een aparte repository gescheiden, de verzamelde bibliotheken in Nuget-pakketten verpakt en in onze interne Nuget-repository geplaatst.
De tijd verstreek, het project fragmenteerde geleidelijk en er ontstond een wens om nieuwe modules aan de clientzijde te maken op een modern JS-framework en deze in de browser uit te voeren. We zijn begonnen met de overstap van WCF/SOAP naar REST/HTTP, dus hadden we nieuwe bibliotheken nodig om snel services op basis van AspNet WebApi te kunnen lanceren. De eerste versie op het .Net Framework 4.5 werd door onze architect bijna op zijn knieën in zijn vrije tijd gemaakt, maar out of the box maakte het mogelijk om een service te lanceren met drie regels in Program.cs die autorisatie (NTLM) bevatten, logging, Swagger, IoC/DI op basis van Castle Windsor, aangepaste HTTP-clients die verschillende headers doorsturen om end-to-end logging gedurende het hele project te bieden. En dit hele ding kan verder rechtstreeks in het serviceconfiguratiebestand worden geconfigureerd.
Niet alles verliep echter van een leien dakje: deze bibliotheek bleek uiterst inflexibel wat betreft de introductie van nieuwe modules. Als u bijvoorbeeld speciale middleware moest toevoegen, moest u een nieuwe assembly maken en deze overnemen van de basisklasse waarop de service draait, wat buitengewoon lastig was. Gelukkig waren er niet veel van dergelijke gevallen.
Het tijdperk van Docker en Kubernetes
De tijd is gekomen dat de golf van Docker en Kubernetes ons bereikte, die we nauwlettend in de gaten hielden: het was tenslotte een geweldige kans om verder te gaan met de technologieën, in .Net Core. Dit betekent dat we een nieuwe infrastructuur nodig hebben om diensten uit te voeren: sommige bibliotheken zijn vrijwel zonder wijzigingen gemigreerd van het .Net Framework naar .Net Standard en .Net Core, sommige met kleine verbeteringen. Maar bovenal wilde ik de functionaliteit herwerken die gepaard gaat met het lanceren van services op AspNet Core.
Het eerste dat we overwogen was een concept dat het belangrijkste nadeel van de vorige versie zou wegnemen: gebrek aan flexibiliteit. Daarom werd besloten om het gehele bibliotheeksysteem zo zelfstandig en modulair mogelijk te maken en de diensten te verzamelen die nodig zijn voor de functionaliteit als constructeur.
Het belangrijkste doel is het creëren van een uniforme aanpak die beschrijft hoe te communiceren met databases, bussen en andere diensten. We hebben geprobeerd om integraties snel en pijnloos te maken, en ontwikkelaars konden zich concentreren op het schrijven van bedrijfslogica in plaats van op de infrastructuur; die is al klaar. Een gemeenschappelijke repository helpt de ervaring van interactie binnen teams te verbeteren: wanneer zeer vergelijkbare interne infrastructuren worden gebruikt, is het gemakkelijker om deel te nemen aan het ontwikkelingsproces van een ander team en expertise uit te wisselen.
En waarom hebben we Open Source nodig?
We willen de volwassenheid van onze expertise laten zien en hoogwaardige feedback krijgen: iemand buiten de bank kan iets van zichzelf inbrengen. We zijn ook geïnteresseerd in de ontwikkeling van praktijken voor het werken met microservices en DDD op .NET in de industrie; misschien wil iemand bepaalde delen van het raamwerk overnemen.
Eigenlijk WenenNET
Laten we het nu eens nader bekijken. .
ViennaNET.WebApi.*
Deze set bibliotheken bestaat uit de “root” ViennaNET.WebApi, die de builder-klasse voor de CompanyHostBuilder-service bevat, en een set configurators ViennaNET.WebApi.Configurators.*, waarmee u elk bepaalde functionaliteit aan de gemaakte dienst. Onder de configurators vindt u verbindingen voor loggen, diagnostiek, authenticatie- en autorisatietypes, branie, enz.
ViennaNET.WebApi.Runners.* bevat ook vooraf geconfigureerde servicebouwers. Met deze pakketten hoeft u niet elke keer dat u een nieuwe dienst aanmaakt, te onthouden welke configurators moeten worden aangesloten. Ze beperken echter op geen enkele manier de functionaliteit van de servicebouwer.
ViennaNET.Mediator.*
Bibliotheken waarmee u een interne tussenbus kunt maken voor opdrachten en verzoeken binnen een service. Met deze aanpak kunt u het aantal DI-injecties terugbrengen tot één, bijvoorbeeld in controllers. Hierdoor kunt u verschillende decorateurs aan verzoeken toevoegen, waardoor de verwerking ervan wordt geüniformeerd en de hoeveelheid code wordt verminderd.
ViennaNET.Validatie
Een assemblage die een reeks klassen bevat waarmee validatieregels en reeksen daaruit kunnen worden gemaakt. Het is erg handig voor het implementeren van domeinvalidatie, omdat u hiermee elke bedrijfsconditie in de vorm van een eenvoudige, afzonderlijke regel kunt beschrijven.
WenenNET.Redis
Een bibliotheek met wrappers voor handig werken met Redis als cache in het geheugen.
ViennaNET.Specificaties
Een assembly met klassen die het Specification-patroon implementeren.
Dit is niet alles wat in onze set zit. De rest kun je zien . We zijn van plan om binnenkort onze bibliotheken voor het werken met databases vrij te geven naar OpenSource.
Bedankt voor uw aandacht, we kijken uit naar uw opmerkingen en pull-verzoeken.
Bron: www.habr.com