Ciao a tutti!
Siamo una comunità di sviluppatori .NET della Raiffeisenbank e vogliamo parlarvi di un insieme di librerie infrastrutturali su .NET Core per la creazione rapida di microservizi con un'ecosistema unificata. È stato reso Open Source!
Un po' di storia
Un tempo avevamo un grande progetto monolitico, che si stava trasformando gradualmente in un insieme di microservizi (puoi leggere delle caratteristiche di questo processo in ). Durante il processo ci siamo imbattuti nel problema che, nella creazione di nuovi microservizi, dovevamo spesso copiare diverse soluzioni infrastrutturali – come la configurazione del logging, il lavoro con i DB, WCF, ecc. Su questo progetto ha lavorato un unico team, e tutti si erano già abituati a un approccio consolidato nella gestione dell'infrastruttura. Perciò abbiamo estratto il codice comune in un repository separato, abbiamo impacchettato le librerie raccolte in pacchetti Nuget e le abbiamo collocate nel nostro repository Nuget interno.
Col tempo, il progetto si frazionava sempre di più, e nacque il desiderio di creare nuovi moduli per la parte client utilizzando un moderno framework Js e di avviarli nel browser. Iniziammo a passare da WCF/SOAP a REST/HTTP, quindi ci servivano nuove librerie per il rapido avvio dei servizi basati su AspNet WebApi. La prima versione su .Net Framework 4.5 fu realizzata dal nostro architetto quasi 'in un lampo' nel tempo libero, ma già 'di serie' permetteva con tre righe in Program.cs di avviare un servizio che includeva l'autenticazione (NTLM), il logging, Swagger, IoC/DI basato su Castle Windsor, client HTTP configurati per inoltrare vari header per garantire il logging completo dell'intero progetto. E tutto ciò poteva essere ulteriormente configurato direttamente nel file di configurazione del servizio.
Tuttavia, non tutto andava per il verso giusto: questa libreria si rivelò estremamente rigida per l'inserimento di nuovi moduli. Ad esempio, se era necessario aggiungere un middleware specifico, bisognava creare un nuovo assembly e derivare dalla classe base che avviava il servizio, il che era estremamente scomodo. Fortunatamente, tali casi non erano molto numerosi.
L'era di Docker e Kubernetes
È arrivato il momento in cui anche noi siamo stati coinvolti dalla rivoluzione di Docker e Kubernetes, che avevamo seguito con attenzione: era un'opportunità fantastica per avanzare nelle tecnologie verso .Net Core. Questo significa che ci servirà una nuova infrastruttura per avviare i servizi: alcune librerie sono migrate da .Net Framework a .Net Standard e .Net Core praticamente senza modifiche, altre con piccoli miglioramenti. Ma soprattutto, desideravamo ristrutturare le funzionalità legate all'avvio dei servizi su AspNet Core.
La prima idea considerata è stata quella di eliminare 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. Abbiamo cercato di rendere le integrazioni rapide e indolori, così gli sviluppatori possono concentrarsi sulla scrittura della logica aziendale, piuttosto che sull'infrastruttura, che è già pronta. Un 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 competenze.
E perché ci serve l'Open Source?
Vogliamo mostrare la maturità della nostra expertise e ricevere feedback di qualità: una persona al di fuori della banca potrà apportare il proprio contributo. Inoltre, ci interessa lo sviluppo delle pratiche lavorative con microservizi e DDD su .NET nell'industria, e forse qualcuno vorrà portare con sé determinate 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 costruttrice per il servizio CompanyHostBuilder, e un insieme di configuratori ViennaNET.WebApi.Configurators.*, ognuno dei quali consente di aggiungere e configurare alcune funzionalità nel servizio creato. Tra i configuratori si possono trovare integrazioni per il logging, la diagnostica, il tipo di autenticazione e autorizzazione, swagger, ecc.
Allo stesso modo, ViennaNET.WebApi.Runners.* contiene costruttori di servizi preconfigurati. Questi pacchetti consentono di non dover ricordare ogni volta quali configuratori è necessario collegare quando si crea un nuovo servizio. Inoltre, non limitano in alcun modo la funzionalità del costruttore di servizi.
ViennaNET.Mediator.*
Librerie che consentono di creare un bus interno per comandi e richieste all'interno del servizio. Questo approccio riduce il numero di iniezioni DI a una sola, ad esempio, nei controller. Grazie a ciò, è possibile aggiungere vari decoratori alle richieste, unificando così la loro elaborazione e riducendo la quantità di codice.
ViennaNET.Validation
Un'assembly che contiene un insieme di classi per la creazione di regole di convalida e sequenze da esse. È molto utile per implementare la convalida del dominio, poiché consente di descrivere ogni condizione aziendale come una semplice e separata regola.
ViennaNET.Redis
Una libreria con wrapper per un'interazione facile con Redis come cache in memoria.
ViennaNET.Specifications
Un'assembly che contiene classi che implementano il pattern 'Specifica'.
Questa non è affatto tutta la nostra offerta. Puoi vedere il resto . Presto sarà disponibile in OpenSource le nostre librerie per lavorare con i database.
Grazie per l'attenzione, attendiamo i vostri commenti e pull request.
Fonte: habr.com
