Ola a todos!
Somos unha comunidade de desenvolvedores .NET en Raiffeisenbank e queremos falar dun conxunto de bibliotecas de infraestrutura baseadas en .NET Core para crear rapidamente microservizos cun único ecosistema. Trouxérono a Open Source!
Un pouco de historia
Érase unha vez un gran proxecto monolítico, que pouco a pouco se converteu nun conxunto de microservizos (podes ler sobre as características deste proceso en ). No proceso, atopamos o problema de que ao crear novos microservizos, moitas veces tiñamos que copiar varias solucións de infraestrutura, como configurar o rexistro, traballar cunha base de datos, WCF, etc. Un equipo traballou neste proxecto, e todos xa estaban afeitos a algún enfoque establecido para traballar con infraestruturas. Polo tanto, separamos o código común nun repositorio separado, envolvemos as bibliotecas recollidas en paquetes Nuget e colocámolas no noso repositorio interno de Nuget.
Pasou o tempo, o proxecto fragmentouse gradualmente e houbo o desexo de crear novos módulos do lado do cliente nun marco JS moderno e executalos no navegador. Comezamos a pasar de WCF/SOAP a REST/HTTP, polo que necesitabamos novas bibliotecas para lanzar rapidamente servizos baseados en AspNet WebApi. A primeira versión do .Net Framework 4.5 foi realizada polo noso arquitecto case de xeonllos no seu tempo libre, pero fóra da caixa permitiu lanzar un servizo con tres liñas en Program.cs que contiña autorización (NTLM), rexistro, Swagger, IoC/DI en base a Castle Windsor, clientes HTTP personalizados que reenvían varias cabeceiras para proporcionar un rexistro de extremo a extremo en todo o proxecto. E todo isto podería configurarse máis directamente no ficheiro de configuración do servizo.
Porén, non todo foi suave: esta biblioteca resultou ser extremadamente inflexible en canto á introdución de novos módulos. Por exemplo, se necesitaba engadir algún middleware especial, tiña que crear un novo conxunto e herdar da clase base que executa o servizo, o que era extremadamente inconveniente. Afortunadamente, non houbo moitos casos deste tipo.
A era de Docker e Kubernetes
Chegou o momento no que nos chegou a onda de Docker e Kubernetes, que observamos de preto: ao cabo, foi unha gran oportunidade para comezar a avanzar máis nas tecnoloxías, en .Net Core. Isto significa que necesitaremos unha nova infraestrutura para executar os servizos: algunhas bibliotecas migraron do .Net Framework a .Net Standard e .Net Core practicamente sen cambios, algunhas con pequenas melloras. Pero, sobre todo, quería reelaborar a funcionalidade asociada ao lanzamento de servizos en AspNet Core.
O primeiro que consideramos foi un concepto que eliminaría o principal inconveniente da versión anterior: a falta de flexibilidade. Por iso, decidiuse facer todo o sistema bibliotecario o máis independente e modular posible e recoller os servizos necesarios para a funcionalidade como construtor.
O obxectivo principal é crear un enfoque unificado que describa como interactuar con bases de datos, autobuses e outros servizos. Tentamos que as integracións sexan rápidas e sinxelas, e os desenvolvedores puideron concentrarse en escribir a lóxica empresarial en lugar da infraestrutura: xa está listo. Un repositorio común axuda a mellorar a experiencia de interacción dentro dos equipos: cando se usan infraestruturas internas moi similares, é máis fácil unirse ao proceso de desenvolvemento doutro equipo e intercambiar coñecementos.
E por que necesitamos o código aberto?
Queremos mostrar a madurez da nosa experiencia e recibir comentarios de alta calidade: unha persoa allea ao banco poderá aportar algo de si. Tamén nos interesa o desenvolvemento de prácticas para traballar con microservizos e DDD en .NET na industria; quizais alguén queira facerse cargo de certas partes do framework.
En realidade, ViennaNET
Agora imos ver máis de cerca. .
ViennaNET.WebApi.*
Este conxunto de bibliotecas está formado pola "raíz" ViennaNET.WebApi, que contén a clase de constructor para o servizo CompanyHostBuilder, e un conxunto de configuradores ViennaNET.WebApi.Configurators.*, cada un dos cales permite engadir e configurar algunha funcionalidade ao creador. servizo. Entre os configuradores pódense atopar conexións para rexistro, diagnóstico, tipos de autenticación e autorización, swagger, etc.
ViennaNET.WebApi.Runners.* tamén contén creadores de servizos preconfigurados. Estes paquetes permítenche non lembrar cada vez que creas un novo servizo que configuradores precisan estar conectados. Non obstante, non limitan de ningún xeito a funcionalidade do creador de servizos.
ViennaNET.Mediator.*
Bibliotecas que permiten crear un bus intermediario interno para comandos e solicitudes dentro dun servizo. Este enfoque permítelle reducir o número de inxeccións de DI a unha, por exemplo, nos controladores. Debido a isto, pode engadir varios decoradores ás solicitudes, o que unifica o seu procesamento e reduce a cantidade de código.
ViennaNET.Validación
Un conxunto que contén un conxunto de clases para crear regras de validación e secuencias a partir delas. É moi cómodo para implementar a validación de dominios, xa que permite describir cada condición empresarial en forma dunha regra sinxela e separada.
ViennaNET.Redis
Unha biblioteca con envoltorios para traballar cómodamente con Redis como caché na memoria.
ViennaNET.Especificacións
Un conxunto que contén clases que implementan o patrón de especificación.
Isto non é todo o que hai no noso conxunto. Podes ver o resto . Estamos planeando lanzar as nosas bibliotecas para traballar con bases de datos en OpenSource en breve.
Grazas pola túa atención, agardamos os teus comentarios e solicitudes de extracción.
Fonte: www.habr.com