Bonjour à tous!
Nous sommes une communauté de développeurs .NET chez Raiffeisenbank et nous souhaitons parler d'un ensemble de bibliothèques d'infrastructure basées sur .NET Core pour créer rapidement des microservices avec un écosystème unique. Ils l'ont amené à l'Open Source !
Un peu d'histoire
Il était une fois un grand projet monolithique, qui s'est progressivement transformé en un ensemble de microservices (vous pouvez en savoir plus sur les caractéristiques de ce processus dans ). Au cours du processus, nous avons rencontré le problème que lors de la création de nouveaux microservices, nous devions souvent copier diverses solutions d'infrastructure - telles que la configuration de la journalisation, l'utilisation d'une base de données, WCF, etc. Une équipe a travaillé sur ce projet et tout le monde était déjà habitué à une approche établie du travail avec les infrastructures. Par conséquent, nous avons séparé le code commun dans un référentiel distinct, enveloppé les bibliothèques collectées dans des packages Nuget et les avons placées dans notre référentiel Nuget interne.
Le temps a passé, le projet s'est progressivement fragmenté et il y avait un désir de créer de nouveaux modules côté client sur un framework JS moderne et de les exécuter dans le navigateur. Nous avons commencé à passer de WCF/SOAP à REST/HTTP, nous avions donc besoin de nouvelles bibliothèques pour lancer rapidement des services basés sur AspNet WebApi. La première version sur .Net Framework 4.5 a été réalisée par notre architecte presque à genoux pendant son temps libre, mais elle a permis de lancer un service avec trois lignes dans Program.cs contenant une autorisation (NTLM), logging, Swagger, IoC/DI sur la base de Castle Windsor, des clients HTTP personnalisés qui transmettent divers en-têtes pour fournir une journalisation de bout en bout tout au long du projet. Et tout cela pourrait être configuré davantage directement dans le fichier de configuration du service.
Cependant, tout ne s'est pas bien passé : cette bibliothèque s'est avérée extrêmement rigide en termes d'introduction de nouveaux modules. Par exemple, si vous deviez ajouter un middleware spécial, vous deviez créer un nouvel assembly et hériter de la classe de base qui exécute le service, ce qui était extrêmement gênant. Heureusement, ces cas ne sont pas très nombreux.
L'ère de Docker et Kubernetes
Le moment est venu où nous a atteint la vague de Docker et de Kubernetes, que nous avons surveillée de près : après tout, c'était une excellente occasion de commencer à avancer plus loin dans les technologies, dans .Net Core. Cela signifie que nous aurons besoin d'une nouvelle infrastructure pour exécuter les services : certaines bibliothèques ont migré du .Net Framework vers .Net Standard et .Net Core pratiquement sans modifications, certaines avec des améliorations mineures. Mais je souhaitais surtout retravailler les fonctionnalités associées au lancement de services sur AspNet Core.
La première chose que nous avons envisagée était un concept qui supprimerait le principal inconvénient de la version précédente : le manque de flexibilité. Par conséquent, il a été décidé de rendre l'ensemble du système de bibliothèque aussi indépendant et modulaire que possible et de collecter les services nécessaires à la fonctionnalité en tant que 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 autres services. Nous avons essayé de rendre les intégrations rapides et simples, et les développeurs pourraient se concentrer sur l'écriture de la logique métier plutôt que sur l'infrastructure - elle est déjà prête. Un référentiel 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 rejoindre le processus de développement d'une autre équipe et d'échanger des expertises.
Et pourquoi avons-nous besoin de l’Open Source ?
Nous souhaitons montrer la maturité de notre expertise et recevoir des retours de qualité : une personne extérieure à la banque pourra apporter quelque chose d'elle-même. Nous sommes également intéressés par le développement de pratiques pour travailler avec des microservices et DDD sur .NET dans l'industrie, peut-être que quelqu'un voudra reprendre certaines parties du framework.
En fait, ViennaNET
Maintenant, regardons de plus près. .
VienneNET.WebApi.*
Cet ensemble de bibliothèques se compose de la « racine » ViennaNET.WebApi, contenant la classe de générateur pour le service CompanyHostBuilder, et d'un ensemble de configurateurs ViennaNET.WebApi.Configurators.*, dont chacun vous permet d'ajouter et de configurer certaines fonctionnalités au fichier créé. service. Parmi les configurateurs, vous pouvez trouver des connexions pour la journalisation, les diagnostics, les types d'authentification et d'autorisation, swagger, etc.
ViennaNET.WebApi.Runners.* contient également des générateurs de services préconfigurés. Ces packages vous permettent de ne plus mémoriser à chaque fois que vous créez un nouveau service quels configurateurs doivent être connectés. Cependant, ils ne limitent en aucune façon les fonctionnalités du générateur de services.
ViennaNET.Mediator.*
Bibliothèques qui permettent de créer un bus intermédiaire interne pour les commandes et les requêtes au sein d'un service. Cette approche permet de réduire le nombre d'injections DI à une, par exemple dans les contrôleurs. De ce fait, vous pouvez ajouter différents décorateurs aux requêtes, ce qui unifie leur traitement et réduit la quantité de code.
ViennaNET.Validation
Un assembly contenant un ensemble de classes pour créer des règles de validation et des séquences à partir de celles-ci. Il est très pratique pour mettre en œuvre la validation de domaine, car il permet de décrire chaque condition métier sous la forme d'une règle simple et distincte.
VienneNET.Redis
Une bibliothèque avec des wrappers pour un travail pratique avec Redis comme cache en mémoire.
ViennaNET.Spécifications
Un assembly contenant des classes qui implémentent le modèle de spécification.
Ce n'est pas tout ce qu'il y a dans notre ensemble. Tu peux voir le reste . Nous prévoyons de publier bientôt nos bibliothèques pour travailler avec des bases de données sur OpenSource.
Merci de votre attention, nous attendons avec impatience vos commentaires et demandes de tirage.
Source: habr.com