ViennaNET: un set de biblioteci pentru backend

Bună ziua tuturor!

Suntem o comunitate de dezvoltatori .NET la Raiffeisenbank și vrem să vorbim despre un set de biblioteci de infrastructură bazate pe .NET Core pentru a crea rapid microservicii cu un singur ecosistem. L-au adus la Open Source!

ViennaNET: un set de biblioteci pentru backend

Un pic de istorie

Am avut odată un mare proiect monolitic, care s-a transformat treptat într-un set de microservicii (puteți citi despre caracteristicile acestui proces în acest articol). În acest proces, ne-am confruntat cu problema că atunci când creăm noi microservicii, a trebuit adesea să copiem diverse soluții de infrastructură - cum ar fi configurarea înregistrării, lucrul cu o bază de date, WCF etc. O echipă a lucrat la acest proiect și toată lumea era deja obișnuită cu o abordare consacrată a lucrului cu infrastructura. Prin urmare, am separat codul comun într-un depozit separat, am împachetat bibliotecile colectate în pachete Nuget și le-am plasat în depozitul nostru intern Nuget.

Timpul a trecut, proiectul sa fragmentat treptat și a existat dorința de a crea noi module pe partea clientului pe un cadru JS modern și de a le rula în browser. Am început să trecem de la WCF/SOAP la REST/HTTP, așa că aveam nevoie de noi biblioteci pentru a lansa rapid servicii bazate pe AspNet WebApi. Prima versiune pe .Net Framework 4.5 a fost realizată de arhitectul nostru aproape în genunchi în timpul liber, dar din cutie a făcut posibilă lansarea unui serviciu cu trei linii în Program.cs care conținea autorizație (NTLM), logging, Swagger, IoC/DI bazat pe Castle Windsor, clienți HTTP personalizați care transmit diferite antete pentru a oferi jurnalizare end-to-end pe întregul proiect. Și toată chestia asta ar putea fi configurată în continuare direct în fișierul de configurare a serviciului.

Cu toate acestea, nu totul a fost bine: această bibliotecă s-a dovedit a fi extrem de inflexibilă în ceea ce privește introducerea de noi module. De exemplu, dacă trebuia să adăugați niște middleware speciale, trebuia să creați un nou ansamblu și să moșteniți de la clasa de bază care rulează serviciul, ceea ce era extrem de incomod. Din fericire, nu au fost foarte multe astfel de cazuri.

Era Docker și Kubernetes

A sosit momentul în care a ajuns la noi valul Docker și Kubernetes, pe care l-am urmărit îndeaproape: până la urmă, a fost o șansă grozavă să începem să mergem mai departe de-a lungul tehnologiilor, în .Net Core. Aceasta înseamnă că vom avea nevoie de o nouă infrastructură pentru a rula serviciile: unele biblioteci au migrat de la .Net Framework la .Net Standard și .Net Core practic fără modificări, unele cu îmbunătățiri minore. Dar mai ales am vrut să reprocesez funcționalitatea asociată cu lansarea serviciilor pe AspNet Core.

Primul lucru pe care l-am luat în considerare a fost un concept care ar elimina principalul dezavantaj al versiunii anterioare: lipsa de flexibilitate. Prin urmare, s-a decis ca întregul sistem de biblioteci să fie cât mai independent și modular posibil și să colecteze serviciile necesare funcționalității ca constructor.

Scopul principal este de a crea o abordare unificată care să descrie cum să interacționați cu bazele de date, autobuzele și alte servicii. Am încercat să facem integrările rapide și fără durere, iar dezvoltatorii s-au putut concentra pe scrierea logicii de afaceri, mai degrabă decât a infrastructurii - este deja gata. Un depozit comun ajută la îmbunătățirea experienței de interacțiune în cadrul echipelor: atunci când sunt utilizate infrastructuri interne foarte similare, este mai ușor să vă alăturați procesului de dezvoltare a unei alte echipe și să faceți schimb de expertiză.

Și de ce avem nevoie de Open Source?

Dorim să arătăm maturitatea expertizei noastre și să primim feedback de înaltă calitate: o persoană din afara băncii va putea aduce ceva de la sine. De asemenea, suntem interesați de dezvoltarea practicilor de lucru cu microservicii și DDD pe .NET în industrie, poate cineva va dori să preia anumite părți ale cadrului.

De fapt, ViennaNET

Acum să aruncăm o privire mai atentă. Codul sursă complet este postat aici.

ViennaNET.WebApi.*

Acest set de biblioteci constă din „rădăcină” ViennaNET.WebApi, care conține clasa de constructor pentru serviciul CompanyHostBuilder, și un set de configuratoare ViennaNET.WebApi.Configurators.*, fiecare dintre care vă permite să adăugați și să configurați anumite funcționalități la serviciu. Printre configuratoare puteți găsi conexiuni pentru logare, diagnosticare, tipuri de autentificare și autorizare, swagger etc.

ViennaNET.WebApi.Runners.* conține, de asemenea, generatori de servicii preconfigurați. Aceste pachete vă permit să nu vă amintiți de fiecare dată când creați un serviciu nou care configuratori trebuie conectați. Cu toate acestea, ele nu limitează în niciun fel funcționalitatea constructorului de servicii.

ViennaNET.Mediator.*

Biblioteci care vă permit să creați o magistrală intermediară internă pentru comenzi și solicitări în cadrul unui serviciu. Această abordare vă permite să reduceți numărul de injecții DI la una, de exemplu, în controlere. Datorită acestui fapt, puteți adăuga diverși decoratori la solicitări, ceea ce unifică procesarea acestora și reduce cantitatea de cod.

ViennaNET.Validare

Un ansamblu care conține un set de clase pentru crearea regulilor de validare și secvențe din acestea. Este foarte convenabil pentru implementarea validării domeniului, deoarece vă permite să descrieți fiecare condiție de afaceri sub forma unei reguli simple și separate.

ViennaNET.Redis

O bibliotecă cu pachete pentru lucrul convenabil cu Redis ca cache în memorie.

ViennaNET.Specificaţii

Un ansamblu care conține clase care implementează modelul Specification.

Acesta nu este tot ce este în setul nostru. Puteti vedea restul în depozitul GitHub. Intenționăm să lansăm bibliotecile noastre pentru a lucra cu baze de date în OpenSource în curând.

Vă mulțumim pentru atenție, așteptăm cu nerăbdare comentariile și solicitările dvs. de tragere.

Sursa: www.habr.com