Ciao a tutti!
Siamo una community di sviluppatori .NET della Raiffeisenbank e vogliamo parlare di un insieme di librerie infrastrutturali basate su .NET Core per creare rapidamente microservizi con un unico ecosistema. L'hanno portato all'Open Source!
Un po 'di storia
C'era una volta un grande progetto monolitico, che gradualmente si è trasformato in una serie di microservizi (puoi leggere le caratteristiche di questo processo in ). Nel processo, abbiamo riscontrato il problema che durante la creazione di nuovi microservizi, spesso dovevamo copiare varie soluzioni infrastrutturali, come l'impostazione del logging, l'utilizzo di un database, WCF, ecc. Un team ha lavorato a questo progetto e tutti erano già abituati a un approccio consolidato al lavoro con l'infrastruttura. Pertanto, abbiamo separato il codice comune in un repository separato, abbiamo racchiuso le librerie raccolte in pacchetti Nuget e le abbiamo inserite nel nostro repository Nuget interno.
Il tempo è passato, il progetto si è gradualmente frammentato e c'era il desiderio di creare nuovi moduli lato client su un moderno framework JS ed 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 in ginocchio nel tempo libero, ma fuori dagli schemi ha permesso di lanciare un servizio con tre righe in Program.cs che contenevano l'autorizzazione (NTLM), logging, Swagger, IoC/DI basato su Castle Windsor, client HTTP personalizzati che inoltrano varie intestazioni per fornire la registrazione end-to-end durante l'intero progetto. E tutto questo potrebbe essere ulteriormente configurato direttamente nel file di configurazione del servizio.
Tuttavia, non tutto è andato liscio: questa libreria si è rivelata estremamente poco flessibile in termini di introduzione di nuovi moduli. Ad esempio, se avevi bisogno di aggiungere un middleware speciale, dovevi creare un nuovo assembly ed ereditare dalla classe base che esegue il servizio, il che era estremamente scomodo. Fortunatamente, non ci sono stati molti casi simili.
L'era di Docker e Kubernetes
È giunto il momento in cui ci ha raggiunto l'ondata di Docker e Kubernetes, che abbiamo osservato da vicino: dopotutto, è stata una grande occasione per iniziare a muoversi ulteriormente lungo le tecnologie, in .Net Core. Ciò significa che avremo bisogno di una nuova infrastruttura per eseguire i servizi: alcune librerie sono migrate da .Net Framework a .Net Standard e .Net Core praticamente senza modifiche, alcune con piccoli miglioramenti. Ma soprattutto volevo rielaborare le funzionalità legate al lancio dei servizi su AspNet Core.
La prima cosa che abbiamo preso in considerazione è stata un concetto che eliminasse il principale svantaggio della versione precedente: la mancanza di flessibilità. Si è deciso, quindi, di rendere l'intero sistema bibliotecario il più autonomo e modulare possibile e di raccogliere i servizi necessari alla funzionalità di 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 e gli sviluppatori potevano concentrarsi sulla scrittura della logica aziendale piuttosto che sull'infrastruttura: è già pronta. Un repository comune aiuta a migliorare l'esperienza di interazione all'interno dei team: quando vengono utilizzate infrastrutture interne molto simili, è più facile unirsi al processo di sviluppo di un altro team e scambiare competenze.
E perché abbiamo bisogno dell'Open Source?
Vogliamo dimostrare la maturità delle nostre competenze e ricevere feedback di alta qualità: una persona esterna alla banca potrà portare qualcosa di sé. Siamo anche interessati allo sviluppo di pratiche per lavorare con microservizi e DDD su .NET nel settore, forse qualcuno vorrà farsi carico di alcune parti del framework.
Anzi, ViennaNET
Ora diamo uno sguardo più da vicino. .
ViennaNET.WebApi.*
Questo insieme di librerie è composto dalla “root” ViennaNET.WebApi, contenente la classe builder per il servizio CompanyHostBuilder, e da un insieme di configuratori ViennaNET.WebApi.Configurators.*, ognuno dei quali permette di aggiungere e configurare alcune funzionalità all'oggetto creato servizio. Tra i configuratori puoi trovare connessioni per logging, diagnostica, tipi di autenticazione e autorizzazione, spavalderia, ecc.
ViennaNET.WebApi.Runners.* contiene anche builder di servizi preconfigurati. Questi pacchetti ti permettono di non ricordarti ogni volta che crei un nuovo servizio quali configuratori devono essere collegati. Tuttavia, non limitano in alcun modo la funzionalità del generatore di servizi.
ViennaNET.Mediator.*
Librerie che consentono di creare un bus intermedio interno per comandi e richieste all'interno di un servizio. Questo approccio consente di ridurre il numero di iniezioni DI a una, ad esempio, nei controller. Per questo motivo è possibile aggiungere diversi decoratori alle richieste, il che unifica la loro elaborazione e riduce la quantità di codice.
ViennaNET.Convalida
Un assembly contenente un insieme di classi per creare regole di convalida e sequenze da esse. È molto comodo per implementare la convalida del dominio, poiché consente di descrivere ciascuna condizione aziendale sotto forma di una regola semplice e separata.
ViennaNET.Redis
Una libreria con wrapper per lavorare comodamente con Redis come cache in memoria.
ViennaNET.Specifiche
Un assembly contenente classi che implementano il modello Specifica.
Questo non è tutto ciò che è nel nostro set. Puoi vedere il resto . Stiamo pianificando di rilasciare presto le nostre librerie per lavorare con i database su OpenSource.
Grazie per l'attenzione, attendiamo con ansia i vostri commenti e le vostre richieste di pull.
Fonte: habr.com