Ciao a tutti!
Siamo una comunità di sviluppatori .NET della Raiffeisen Bank e vogliamo parlarvi di un insieme di librerie infrastrutturali su .NET Core per la rapida creazione di microservizi con un'unica ecosistema. Lo abbiamo reso Open Source!
Un po' di storia
Una volta avevamo un grande progetto monolitico che si stava gradualmente trasformando in un insieme di microservizi (sulle peculiarità di questo processo è possibile leggere in ). Durante il processo ci siamo trovati di fronte al problema che, quando creavamo nuovi microservizi, dovevamo spesso copiare varie soluzioni infrastrutturali – come la configurazione del logging, il lavoro con il DB, WCF e così via. Su questo progetto lavorava un solo team, e tutti erano già abituati a un approccio consolidato al lavoro con l'infrastruttura. Pertanto, abbiamo estratto il codice comune in un repository separato, abbiamo raccolto le librerie in pacchetti Nuget e le abbiamo inserite nel nostro repository Nuget interno.
Il tempo passava, il progetto si frantumava gradualmente, e nasceva il desiderio di creare nuovi moduli per la parte client con un moderno framework Js e di eseguirli nel browser. Abbiamo iniziato a passare da WCF/SOAP a REST/HTTP, quindi avevamo bisogno di nuove librerie per avviare rapidamente servizi basati su AspNet WebApi. La prima versione su .Net Framework 4.5 è stata realizzata dal nostro architetto quasi durante il tempo libero, ma già permetteva di avviare un servizio con tre righe in Program.cs, che conteneva autenticazione (NTLM), logging, Swagger, IoC/DI basato su Castle Windsor, clienti HTTP configurati per inoltrare vari header per garantire un logging end-to-end in tutto il progetto. E tutto questo poteva essere ulteriormente configurato direttamente nel file di configurazione del servizio.
Tuttavia, non tutto è andato liscio: questa libreria risultava estremamente rigida nell'implementazione di nuovi moduli. Ad esempio, se era necessario aggiungere un middleware speciale, era necessario creare un nuovo assembly e derivarsi dalla classe base che avviava il servizio, il che era estremamente scomodo. Fortunatamente, tali casi non erano molto numerosi.
Era l'epoca di Docker e Kubernetes
È arrivato il momento in cui anche noi siamo stati coinvolti nella tendenza di Docker e Kubernetes, che abbiamo seguito con attenzione: era un'ottima opportunità per progredire con le tecnologie verso .Net Core. Questo significa che avremo bisogno di una nuova infrastruttura per lanciare i servizi: alcune librerie sono migrati da .Net Framework a .Net Standard e .Net Core praticamente senza modifiche, altre con piccoli miglioramenti. Ma soprattutto, volevamo rielaborare la funzionalità legata al lancio dei servizi su AspNet Core.
Il primo passo è stato considerare un concetto che eliminasse il principale svantaggio della versione precedente: la mancanza di flessibilità. Pertanto, è stato deciso di rendere l'intero sistema di librerie il più indipendente e modulare possibile, assemblando i servizi necessari come un costruttore.
L'obiettivo principale è creare un approccio unificato che descriva come interagire con database, bus e altri servizi. Ci siamo sforzati di rendere le integrazioni rapide e senza problemi, in modo che gli sviluppatori potessero concentrarsi sulla scrittura della logica aziendale e non sull'infrastruttura, che è già pronta. Il repository comune aiuta a migliorare l'esperienza di interazione all'interno dei team: quando si utilizzano infrastrutture interne molto simili, è più facile integrarsi nel processo di sviluppo di un altro team e scambiare expertise.
E perché abbiamo bisogno dell'Open Source?
Vogliamo dimostrare la maturità della nostra expertise e ricevere un feedback di qualità: una persona esterna alla banca può portare qualcosa di nuovo. Siamo anche interessati all'evoluzione delle pratiche di lavoro con microservizi e DDD su .NET nel settore, magari qualcuno vorrà portare con sé alcune parti del framework.
In effetti, ViennaNET
Ora vediamo tutto in dettaglio. .
ViennaNET.WebApi.*
Questo insieme di librerie consiste nel "nucleo" ViennaNET.WebApi, che contiene una classe costruttore per il servizio CompanyHostBuilder, e un insieme di configuratori ViennaNET.WebApi.Configurators.*, ognuno dei quali permette di aggiungere e configurare una certa funzionalità nel servizio creato. Tra i configuratori, si possono trovare l'integrazione del logging, la diagnostica, il tipo di autenticazione e autorizzazione, Swagger, ecc.
ViennaNET.WebApi.Runners.* contiene costruttori di servizi preconfigurati. Questi pacchetti permettono di non dover ricordare ogni volta, creando un nuovo servizio, quali configuratori devono essere collegati. Tuttavia, non limitano in alcun modo la funzionalità del costruttore di servizi.
ViennaNET.Mediator.*
Librerie che consentono di creare un bus interno per la mediazione di comandi e richieste all'interno del servizio. Questo approccio permette di ridurre il numero di iniezioni DI a una sola, ad esempio nei controller. In questo modo è possibile aggiungere vari decoratori alle richieste, uniformando la loro gestione e riducendo il codice.
ViennaNET.Validation
Pacchetto contenente un insieme di classi per la creazione di regole e sequenze di validazione. È molto comodo per implementare la validazione di dominio, poiché consente di descrivere ogni condizione aziendale come una semplice e singola regola.
ViennaNET.Redis
Libreria con wrapper per un uso semplice di Redis come cache in memoria.
ViennaNET.Specifications
Pacchetto che contiene classi che implementano il pattern "Specificazione".
Questo non è tutto ciò che abbiamo nel nostro pacchetto. Puoi vedere il resto . Presto è prevista la pubblicazione delle nostre librerie per il lavoro con i database in OpenSource.
Grazie per l'attenzione, attendiamo i vostri commenti e pull request.
Fonte: habr.com
