Hola a todos!
Somos una comunidad de desarrolladores .NET en Raiffeisenbank y queremos hablar sobre un conjunto de bibliotecas de infraestructura basadas en .NET Core para crear rápidamente microservicios con un único ecosistema. ¡Lo llevaron al código abierto!
Un poco de historia
Érase una vez un gran proyecto monolítico, que gradualmente se convirtió en un conjunto de microservicios (puede leer sobre las características de este proceso en ). En el proceso, nos encontramos con el problema de que al crear nuevos microservicios, a menudo teníamos que copiar varias soluciones de infraestructura, como configurar el registro, trabajar con una base de datos, WCF, etc. Un equipo trabajó en este proyecto y todos ya estaban acostumbrados a algún enfoque establecido para trabajar con infraestructura. Por lo tanto, separamos el código común en un repositorio separado, empaquetamos las bibliotecas recopiladas en paquetes Nuget y las colocamos en nuestro repositorio interno de Nuget.
Pasó el tiempo, el proyecto se fue fragmentando gradualmente y surgió el deseo de crear nuevos módulos del lado del cliente en un marco JS moderno y ejecutarlos en el navegador. Comenzamos a pasar de WCF/SOAP a REST/HTTP, por lo que necesitábamos nuevas bibliotecas para lanzar rápidamente servicios basados en AspNet WebApi. La primera versión de .Net Framework 4.5 la hizo nuestro arquitecto casi de rodillas en su tiempo libre, pero desde el primer momento permitió lanzar un servicio con tres líneas en Program.cs que contenía autorización (NTLM), registro, Swagger, IoC/DI basado en Castle Windsor, clientes HTTP personalizados que reenvían varios encabezados para proporcionar registro de un extremo a otro durante todo el proyecto. Y todo esto podría configurarse aún más directamente en el archivo de configuración del servicio.
Sin embargo, no todo fue fácil: esta biblioteca resultó ser extremadamente inflexible a la hora de introducir nuevos módulos. Por ejemplo, si necesitaba agregar algún middleware especial, tenía que crear un nuevo ensamblado y heredar de la clase base que ejecuta el servicio, lo cual era extremadamente inconveniente. Afortunadamente, no hubo muchos casos de este tipo.
La era de Docker y Kubernetes
Ha llegado el momento en que nos alcanzó la ola de Docker y Kubernetes, que hemos seguido de cerca: después de todo, era una gran oportunidad para comenzar a avanzar en tecnologías, en .Net Core. Esto significa que necesitaremos una nueva infraestructura para ejecutar servicios: algunas bibliotecas han migrado de .Net Framework a .Net Standard y .Net Core prácticamente sin cambios, algunas con mejoras menores. Pero, sobre todo, quería reelaborar la funcionalidad asociada con el lanzamiento de servicios en AspNet Core.
Lo primero que consideramos fue un concepto que eliminaría el principal inconveniente de la versión anterior: la falta de flexibilidad. Por lo tanto, se decidió hacer que todo el sistema de la biblioteca sea lo más independiente y modular posible y recopilar los servicios necesarios para la funcionalidad como constructor.
El objetivo principal es crear un enfoque unificado que describa cómo interactuar con bases de datos, buses y otros servicios. Intentamos que las integraciones fueran rápidas y sencillas, y que los desarrolladores pudieran concentrarse en escribir la lógica empresarial en lugar de la infraestructura; ya está lista. Un repositorio común ayuda a mejorar la experiencia de interacción dentro de los equipos: cuando se utilizan infraestructuras internas muy similares, es más fácil unirse al proceso de desarrollo de otro equipo e intercambiar conocimientos.
¿Y por qué necesitamos el Código Abierto?
Queremos mostrar la madurez de nuestra experiencia y recibir comentarios de alta calidad: una persona ajena al banco podrá aportar algo de sí misma. También estamos interesados en el desarrollo de prácticas para trabajar con microservicios y DDD en .NET en la industria, tal vez alguien quiera hacerse cargo de ciertas partes del marco.
En realidad, VienaNET
Ahora echemos un vistazo más de cerca. .
VienaNET.WebApi.*
Este conjunto de bibliotecas consta de la "raíz" ViennaNET.WebApi, que contiene la clase de creación para el servicio CompanyHostBuilder, y un conjunto de configuradores ViennaNET.WebApi.Configurators.*, cada uno de los cuales le permite agregar y configurar alguna funcionalidad al archivo creado. servicio. Entre los configuradores puede encontrar conexiones para registro, diagnóstico, tipos de autenticación y autorización, swagger, etc.
ViennaNET.WebApi.Runners.* también contiene creadores de servicios preconfigurados. Estos paquetes le permiten no recordar cada vez que crea un nuevo servicio qué configuradores deben estar conectados. Sin embargo, no limitan de ninguna manera la funcionalidad del creador de servicios.
VienaNET.Mediador.*
Bibliotecas que le permiten crear un bus intermediario interno para comandos y solicitudes dentro de un servicio. Este enfoque le permite reducir la cantidad de inyecciones DI a una, por ejemplo, en los controladores. Debido a esto, puedes agregar varios decoradores a las solicitudes, lo que unifica su procesamiento y reduce la cantidad de código.
ViennaNET.Validación
Un ensamblaje que contiene un conjunto de clases para crear reglas de validación y secuencias a partir de ellas. Es muy conveniente para implementar la validación de dominios, ya que le permite describir cada condición comercial en forma de una regla simple e independiente.
VienaNET.Redis
Una biblioteca con contenedores para trabajar cómodamente con Redis como caché en memoria.
ViennaNET.Especificaciones
Un ensamblado que contiene clases que implementan el patrón Especificación.
Esto no es todo lo que hay en nuestro set. Puedes ver el resto. . Estamos planeando lanzar nuestras bibliotecas para trabajar con bases de datos en OpenSource pronto.
Gracias por su atención, esperamos sus comentarios y solicitudes de extracción.
Fuente: habr.com