Всім привіт!
Ми є спільнотою .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
Настав час, коли і до нас докотилася хвиля з 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
Складання, що містить класи, що реалізують патерн «Специфікація».
Це далеко не все, що є у нашому наборі. Решту можна подивитися . Скоро планується вихід OpenSource наших бібліотек для роботи з базами даних.
Дякуємо за увагу, чекаємо на ваші коментарі та pull request-ів.
Джерело: habr.com