Всем привет!
Мы сообщество .NET-разработчиков Райффайзенбанка и мы хотим рассказать про набор инфраструктурных библиотек на .NET Core для быстрого создания микросервисов с единой экосистемой. Вывели его в Open Source!
>>> Готовы поделиться второй частью статьи: прошлись по еще не рассмотренным библиотекам для работы с распределенными транзакциями, очередями и БД.
Немного истории
Когда-то у нас был большой монолитный проект, который постепенно превращался в набор микросервисов (об особенностях данного процесса можно прочитать в этой статье). В процессе мы столкнулись с проблемой, что при создании новых микросервисов нам часто приходилось копировать различные инфраструктурные решения – вроде настройки логирования, работы с БД, WCF и т.п. Над данным проектом работала одна команда, и все уже привыкли к некоторому устоявшемуся подходу работы с инфраструктурой. Поэтому мы выделили общий код в отдельный репозиторий, собранные библиотеки завернули в Nuget-пакеты и поместили в наше внутреннее Nuget-хранилище.
Время шло, проект понемногу дробился, появилось желание создавать новые модули клиентской части на современном Js-фреймворке и запускать их в браузере. Мы начали переходить с WCF/SOAP на REST/HTTP, поэтому нам потребовались новые библиотеки для быстрого запуска сервисов на базе AspNet WebApi. Первая версия на .Net Framework 4.5 была сделана нашим архитектором чуть ли не на коленке в свободное время, но она уже из коробки позволяла тремя строчками в Program.cs запустить сервис, который содержал авторизацию (NTLM), логирование, Swagger, IoC/DI на базе Castle Windsor, настроенных HTTP-клиентов, пробрасывающих различные заголовки для обеспечения сквозного логирования во всем проекте. И всё это дело можно было дополнительно сконфигурировать уже в непосредственно в файле конфигурации сервиса.
Однако не всё было гладко: данная библиотека получилась крайне негибкой в плане внедрения новых модулей. Например, если требовалось добавить какое-нибудь особое middleware, то приходилось создавать новую сборку и наследоваться от базового класса, запускающего сервис, что было крайне неудобно. К счастью, таких случаев было не очень много.
Эпоха Docker и Kubernetes
Пришло время, когда и до нас докатилась волна c Docker и Kubernetes, за которой мы пристально наблюдали: ведь это был прекрасный шанс начать движение по технологиям дальше, в .Net Core. А значит, нам понадобится новая инфраструктура для запуска сервисов: часть библиотек перекочевала с .Net Framework на .Net Standard и .Net Core практически без изменений, часть с небольшими улучшениями. Но больше всего хотелось переработать функционал, связанный с запуском сервисов на AspNet Core.
Первым делом рассматривался концепт, позволяющий убрать главный недостаток предыдущей версии: отсутствие гибкости. Поэтому было решено сделать всю систему библиотек как можно более независимой и модульной и собирать необходимые по функционалу сервисы как конструктор.
Главная цель – создать унифицированный подход, описывающий, как взаимодействовать с базами данных, шинами и другими сервисами. Мы постарались, чтобы интеграции были быстрыми и безболезненными, а разработчики могли сконцентрироваться на написании бизнес-логики, а не инфраструктуры – она уже готова. Общий репозиторий помогает улучшить опыт взаимодействия внутри команд: когда используются очень похожие внутренние инфраструктуры, то легче включиться в процесс разработки другой команды и обменяться экспертизой.
И зачем нам Open Source?
Мы хотим показать зрелость экспертизы и получить качественную обратную связь: человек, находящийся вне банка, сможет привнести что-то от себя. Также нам интересно развитие практик работы с микросервисами и DDD на .NET в индустрии, возможно, кто-то захочет забрать определенные части фреймворка к себе.
Собственно, ViennaNET
Теперь давайте рассмотрим всё подробнее. Полный исходный код положили сюда.
ViennaNET.WebApi.*
Данный набор библиотек состоит из «корня» ViennaNET.WebApi, содержащего класс-строитель для сервиса CompanyHostBuilder, и набора конфигураторов ViennaNET.WebApi.Configurators.*, каждый из которых позволяет добавить и сконфигурировать некоторый функционал в создаваемый сервис. Среди конфигураторов можно найти подключение логирования, диагностики, типа аутентификации и авторизации, swagger-а и т.д.
Тут же ViennaNET.WebApi.Runners.* содержит предварительно настроенные строители сервисов. Эти пакеты позволяют не вспоминать всякий раз, создавая новый сервис, какие конфигураторы необходимо подключить. При этом они никак не ограничивают функциональность строителя сервисов.
ViennaNET.Mediator.*
Библиотеки, позволяющие создать внутреннюю шину-посредник для команд и запросов внутри сервиса. Такой подход позволяет сократить количество DI-инъекций до одной, например, в контроллерах. За счёт этого можно добавлять различные декораторы к запросам, что унифицирует их обработку и сокращает количество кода.
ViennaNET.Validation
Сборка, содержащая набор классов для создания валидационных правил и последовательностей из них. Очень удобна для реализации доменной валидации, так как позволяет описать каждое бизнес-условие в виде простого и отдельного правила.
ViennaNET.Redis
Библиотека с обертками для удобной работы с Redis в качестве in-memory cache.
ViennaNET.Specifications
Сборка, содержащая классы, реализующие паттерн «Спецификация».
Это далеко не всё, что есть в нашем наборе. Остальное можно посмотреть в репозитории на GitHub. Скоро планируется выход в OpenSource наших библиотек для работы с базами данных (с ними можно познакомиться во второй части статьи: ViennaNET: набор библиотек для backend’а. Часть 2).
>>> Во второй части статьи прошлись по еще не рассмотренным библиотекам для работы с распределенными транзакциями, очередями и БД.
Спасибо за внимание, ждём ваших комментариев и pull request-ов.