Bonjour à tous !
Nous sommes une communauté de développeurs .NET de Raiffeisenbank et nous souhaitons parler d'un ensemble de bibliothèques d'infrastructure sur .NET Core pour la création rapide de microservices avec un écosystème unifié. Nous l'avons rendu open source !
Un peu d'histoire
Nous avions autrefois un grand projet monolithique, qui se transformait progressivement en un ensemble de microservices (vous pouvez lire sur les particularités de ce processus dans ). Au cours du processus, nous avons été confrontés au problème selon lequel, lors de la création de nouveaux microservices, nous devions souvent copier différentes solutions d'infrastructure – comme la configuration du logging, la gestion des bases de données, WCF, etc. Une seule équipe a travaillé sur ce projet, et tout le monde s'était déjà habitué à une certaine approche établie pour travailler avec l'infrastructure. C'est pourquoi nous avons extrait le code commun dans un dépôt séparé, avons emballé les bibliothèques en packages NuGet et les avons placées dans notre dépôt NuGet interne.
Le temps passait, le projet se fragmentait lentement, et il y avait un désir de créer de nouveaux modules pour la partie client sur un framework JS moderne et de les lancer dans le navigateur. Nous avons commencé à passer de WCF/SOAP à REST/HTTP, il nous fallait donc de nouvelles bibliothèques pour un déploiement rapide de services basés sur AspNet WebApi. La première version sur .Net Framework 4.5 a été réalisée par notre architecte presque à la hâte pendant son temps libre, mais elle permettait déjà, en quelques lignes dans Program.cs, de lancer un service intégrant l'authentification (NTLM), le logging, Swagger, IoC/DI basé sur Castle Windsor, ainsi que des clients HTTP configurés pour transmettre divers en-têtes afin d'assurer un logging transversal sur l'ensemble du projet. Et tout cela pouvait être en outre configuré directement dans le fichier de configuration du service.
Cependant, tout n'était pas rose : cette bibliothèque s'est avérée extrêmement rigide en termes d'intégration de nouveaux modules. Par exemple, si l'ajout d'un middleware particulier était nécessaire, il fallait créer un nouvel assemblage et hériter de la classe de base lançant le service, ce qui était extrêmement peu pratique. Heureusement, de tels cas étaient plutôt rares.
L'ère de Docker et Kubernetes
Le moment est venu où la vague de Docker et Kubernetes nous a également atteint, que nous avons regardée de près : c'était une excellente occasion de progresser avec les technologies vers .Net Core. Cela signifie que nous aurons besoin d'une nouvelle infrastructure pour déployer des services : une partie des bibliothèques a migré de .Net Framework à .Net Standard et .Net Core presque sans changements, tandis qu'une autre a bénéficié de petites améliorations. Mais le plus important était de repenser la fonctionnalité liée au déploiement des services sur AspNet Core.
La première étape a été de considérer un concept permettant d'éliminer le principal inconvénient de la version précédente : le manque de flexibilité. Il a donc été décidé de rendre tout le système de bibliothèques aussi indépendant et modulaire que possible, en assemblant les services nécessaires comme un constructeur.
L'objectif principal est de créer une approche unifiée décrivant comment interagir avec les bases de données, les bus et d'autres services. Nous avons fait en sorte que les intégrations soient rapides et sans douleur, permettant aux développeurs de se concentrer sur l'écriture de la logique métier plutôt que sur l'infrastructure – elle est déjà prête. Le dépôt commun contribue à améliorer l'expérience d'interaction au sein des équipes : lorsque des infrastructures internes très similaires sont utilisées, il est plus facile de s'investir dans le processus de développement d'une autre équipe et d'échanger des expertises.
Et pourquoi avons-nous besoin d'Open Source ?
Nous voulons montrer la maturité de notre expertise et obtenir des retours de qualité : une personne extérieure à la banque pourra y apporter sa contribution. Nous sommes également intéressés par le développement des pratiques liées aux microservices et DDD sur .NET dans l'industrie, peut-être que certaines personnes souhaiteront récupérer certaines parties du framework.
En fait, ViennaNET
Examinons tout cela plus en détail. .
ViennaNET.WebApi.*
Cet ensemble de bibliothèques est composé de la « racine » ViennaNET.WebApi, contenant la classe constructeur pour le service CompanyHostBuilder, ainsi qu'un ensemble de configurateurs ViennaNET.WebApi.Configurators.*, chacun permettant d'ajouter et de configurer certaines fonctionnalités dans le service créé. Parmi les configurateurs, on trouve des connexions pour la journalisation, le diagnostic, les types d'authentification et d'autorisation, swagger, etc.
ViennaNET.WebApi.Runners.* contient des bâtisseurs de services préconfigurés. Ces paquets permettent de ne pas avoir à se souvenir à chaque fois des configurateurs à connecter lors de la création d'un nouveau service. Cela n'entrave en rien la fonctionnalité du bâtisseur de services.
ViennaNET.Mediator.*
Des bibliothèques permettant de créer un bus intermédiaire interne pour les commandes et les requêtes au sein du service. Cette approche permet de réduire le nombre d'injections DI à une seule, par exemple, dans les contrôleurs. Grâce à cela, il est possible d'ajouter différents décorateurs aux requêtes, ce qui unifie leur traitement et réduit le code.
ViennaNET.Validation
Une assemblée contenant un ensemble de classes pour créer des règles de validation et des séquences à partir de celles-ci. Très utile pour mettre en œuvre la validation de domaine, car elle permet de décrire chaque condition commerciale sous forme de règle simple et distincte.
ViennaNET.Redis
Une bibliothèque avec des wrappers pour un travail pratique avec Redis en tant que cache in-memory.
ViennaNET.Specifications
Une assemblée contenant des classes qui implémentent le patron "Spécification".
Ce n'est pas tout ce que nous avons dans notre ensemble. Vous pouvez voir le reste . La sortie de nos bibliothèques pour le travail avec les bases de données en open source est prévue prochainement.
Merci pour votre attention, nous attendons vos commentaires et vos pull requests.
Source : habr.com
