Hallo allemaal!
Wij zijn de .NET-ontwikkelaarsgemeenschap van Raiffeisenbank en we willen vertellen over een set infrastructuurbibliotheken op .NET Core voor het snel creƫren van microservices binnen een uniforme ecosysteem. We hebben het als Open Source gepresenteerd!
Een beetje geschiedenis
Ooit hadden we een groot monolithisch project, dat geleidelijk aan veranderde in een set microservices (over de bijzonderheden van dit proces kun je lezen in ). Tijdens dit proces werden we geconfronteerd met het probleem dat we bij het creƫren van nieuwe microservices vaak verschillende infrastructurele oplossingen moesten kopiƫren, zoals loggingsinstellingen, databasebeheer, WCF, enz. Aan dit project werkte ƩƩn team, en iedereen was al gewend aan een bepaalde gevestigde manier van werken met de infrastructuur. Daarom hebben we de gemeenschappelijke code in een aparte repository samengevoegd, en de verzamelde bibliotheken verpakt in NuGet-pakketten en opgeslagen in onze interne NuGet-opslag.
De tijd verging, het project werd geleidelijk opgesplitst, er ontstond de wens om nieuwe modules voor de clientzijde te creƫren met een moderne JS-framework en ze in de browser te starten. We begonnen de overstap van WCF/SOAP naar REST/HTTP, en hebben nieuwe bibliotheken nodig voor het snel opstarten van services op basis van ASP.NET WebAPI. De eerste versie op .NET Framework 4.5 werd bijna in een ad hoc opstelling door onze architect in zijn vrije tijd gemaakt, maar bood al direct de mogelijkheid om met drie regels in Program.cs een service te starten die autorisatie (NTLM), logging, Swagger, IoC/DI op basis van Castle Windsor en geconfigureerde HTTP-clients bevatte, die verschillende headers doorstuurden voor end-to-end logging in het hele project. En dit kon bovendien verder worden geconfigureerd in het configuratiebestand van de service.
Echter, niet alles ging van een leien dakje: deze bibliotheek bleek extreem inflexibel voor de implementatie van nieuwe modules. Bijvoorbeeld, als er een bijzondere middleware moest worden toegevoegd, moest er een nieuwe assembly worden gemaakt en moest er worden geƫrfd van de basisclass die de service startte, wat zeer onhandig was. Gelukkig waren dergelijke gevallen niet al te talrijk.
Het tijdperk van Docker en Kubernetes
De tijd is aangebroken dat de golf van Docker en Kubernetes ons heeft bereikt, waar we aandachtig naar hebben gekeken: het was een geweldige kans om verder te gaan met technologieƫn, zoals .Net Core. Dit betekent dat we een nieuwe infrastructuur nodig hebben om services te implementeren: een deel van de bibliotheken is zonder wijzigingen overgezet van .Net Framework naar .Net Standard en .Net Core, en een deel met kleine verbeteringen. Maar het grootste doel was om de functionaliteit, die verband houdt met het opstarten van services op AspNet Core, opnieuw te ontwerpen.
Als eerste werd het concept overwogen dat het belangrijkste nadeel van de vorige versie zou wegnemen: gebrek aan flexibiliteit. Daarom werd besloten om het hele systeem van bibliotheken zo onafhankelijk en modulair mogelijk te maken en de benodigde services als een bouwpakket samen te stellen.
Het belangrijkste doel is om een uniforme benadering te creĆ«ren die beschrijft hoe te communiceren met databases, bus-systemen en andere services. We hebben geprobeerd de integraties snel en pijnloos te maken, zodat ontwikkelaars zich konden concentreren op het schrijven van bedrijfslogica in plaats van infrastructuur ā die is al klaar. De gezamenlijke repository helpt de samenwerking binnen teams te verbeteren: wanneer zeer vergelijkbare interne infrastructuren worden gebruikt, is het gemakkelijker om in het ontwikkelproces van een ander team te stappen en expertise uit te wisselen.
En waarom hebben we Open Source nodig?
We willen de volwassenheid van onze expertise tonen en kwaliteitsvolle feedback ontvangen: een persoon van buiten de bank kan iets waardevols bijdragen. Ook zijn we benieuwd naar de ontwikkeling van praktijken voor het werken met microservices en DDD op .NET in de industrie, misschien wil iemand bepaalde delen van het framework meenemen.
Eigenlijk, ViennaNET
Laten we alles nu eens in detail bekijken. .
ViennaNET.WebApi.*
Deze set bibliotheken bestaat uit de 'root' ViennaNET.WebApi, die een builder-klasse bevat voor de service CompanyHostBuilder, en een set configurators ViennaNET.WebApi.Configurators.*, waarvan elke configurator de mogelijkheid biedt om bepaalde functionaliteit toe te voegen en te configureren in de te creƫren service. Onder de configurators vindt u verbindingen voor logging, diagnosticering, typen van authenticatie en autorisatie, swagger, enz.
Hier bevat ViennaNET.WebApi.Runners.* vooraf geconfigureerde servicebuilders. Deze pakketten maken het gemakkelijk om bij het creƫren van een nieuwe service, niet telkens te bedenken welke configurators moeten worden aangesloten. Ze beperken de functionaliteit van de servicebuilder niet.
ViennaNET.Mediator.*
Bibliotheken waarmee je een interne bus-mediator voor commando's en verzoeken binnen de service kunt maken. Deze aanpak vermindert het aantal DI-injecties tot Ć©Ć©n, bijvoorbeeld in de controllers. Dit maakt het mogelijk om verschillende decorateurs aan verzoeken toe te voegen, wat hun verwerking uniform maakt en de hoeveelheid code vermindert.
ViennaNET.Validation
Een assembly die een set klassen bevat om validatieregels en -sequenties te creƫren. Ze zijn zeer handig voor het implementeren van domeinvalidatie, omdat ze het mogelijk maken om elke bedrijfsvoorwaarde als een eenvoudige en afzonderlijke regel te beschrijven.
ViennaNET.Redis
Een bibliotheek met wrappers voor gemakkelijke interactie met Redis als in-memory cache.
ViennaNET.Specifications
Een assembly die klassen bevat die het 'Specification' patroon implementeren.
Dit is lang niet alles wat we in onze set hebben. De rest kan worden bekeken . Binnenkort is de open-source release van onze bibliotheken voor databankwerkzaamheden gepland.
Bedankt voor uw aandacht, we kijken uit naar uw opmerkingen en pull requests.
Bron: habr.com
