Шаблоны микросервисов
My Frameworks | создано: 01.05.2019 | опубликовано: 03.08.2021 | обновлено: 03.06.2024 | просмотров: 9685
В статье речь пойдет про Nimble Framework. Шаблоны позволяют ускорить процессы, потому что исключают рутину. Не за чем делать одно и тоже много раз, можно просто использовать наработки и опыт других людей. Причем сфера применения шаблонов абсолютно не важна. Как часто вы создаете микросервисы?
Описание и предназначение
Шаблон Nimble Framework позволяет максимально быстро развернуть новое решение (solution), в котором будут настроены проекты (projects) и подключено (установлено) всё то, что требуется для старта процесса разработки, чтобы приступить непосредственно к решению поставленной задачи. Другими словами, позволяет упростить создание микросервиса (backend-сервера для SPA) на базе ASP.NET Core, которые готовы к дальнейшему расширению или какому-либо другому преобразованию, например, установка дополнительных nuget-пакетов. Когда микросервисы объединены в одну систему (МСА), они не могут быть не связаны между собой. Для облегчения этой задачи "введение нового сервиса в систему" также и предназначен шаблон, в который заложены базовые инфраструктурные функции и возможности.
В проектах, созданные из шаблона используется Coding Convention описанный компанией Microsoft, потому как определяет основные правила именования методов, переменных, полей, функций. А также Identifier names | Microsoft Docs для именование идентификаторов от той же самой компании Microsoft. Все проекты шаблонов построены на платформе разных версий .NET
Подходы к написанию кода
Стоит отметить, что основной функционал заложенный в шаблон (способы описанные ниже) легко вернуть к исходному (чистый ASP.NET Core MVC) из сгенерированного проекта простым удалением двух сборок из списка nuget-пакектов и пару папок. Таким образом, превратив проект в "голый", но при этом содержащий все заложенные в него инфраструктурные механизмы: логирование, мониторинг, подключение к системе, регистрация в AuthorizationService и т.д.
Способ "Быстрый"
Следуя из названия способа напрашивается вывод, что можно разрабатывать API сервиса очень быстро, и, на самом деле, так оно и сесть. Разработка методов CRUD получается очень быстрой. Такой подход используется для простых (или относительно простых сущностей). Пример использования "скоростного" подхода с детальным описанием и подробными комментариями.
Пример использования
Требуется быстро "поднять" сервис, который будет иметь одну сущность, например, "DocumentType" для использования как справочник (то есть, только для чтения по идентификатору и получение постраничного списка). Вторая сущность "Message", для которой требуется элементарный CRUD без каких-либо излишество в бизнес-логики. Создание контроллеров DocumentTypeController и MessagesController на базе уже реализованных ReadonlyControllerBase и WritableControllerBase займет не более получаса при использовании данного способа.
Способ "Правильный"
Способ, который должен браться за основу. Реализация функционала построена на базе Mediatr (близко к паттерну CQRS), что позволяет реализовать Vertical Slice Architecture (VSA). Использование VSA позволяет гибко и эффективно использовать подход разделяющий такие понятия как Query и Command, тем самым дает возможность масштабировать возможности "вертикально".
Преимущества большие, потому что вы сможете использовать обработчики Query и Command (паттерн CQRS) обрабатывать удобным (правильным, подходящим, эффективным, выбранным на основании условия, в конце-концов) способом для достижения максимального результата. Более того, такое понятие pipeline, заложенное в VSA, дает очень гибкой настройки процесса обработки запросов. Следовательно, вы можете "вклеить" специализированные обработчики, например, логирование, кэширование, обработку транзакций и прочите необходимые "полезности" на уровне базовых реализаций - на уровне шаблона.
На рисунке ниже, все методы работают по одному принципу, но сами обработчики разные, причем в некоторых вариантах диаметрально противоположные. От ORM до StoredProcedure при необходимости. Даже не смотря на то, что StoredProcedure - это шаг к двухзвенной архитектуре (а это 100 шагов назад в истории разработки).
Подсказка
Заметьте, что всегда можно удалить одну сборку, которая реализует способ "Быстрый" и установить другую, которая реализует способ "Правильный", чтобы расширить возможности реализации бизнес-логики. Более того, можно использовать обе сборки параллельно.
Для чего шаблон?
Основа для старта
Шаблон создается как отправная точка для разработки нового микросервиса (backend или API), в котором заложены основы некоторых механизмов и подходов с примерами их использования в том числе. Использование шаблона универсализирует эти самые механизмы и подходы при использовании в разных микросервисах, созданных на базе одного и того же шаблона. Разработчику проще ориентироваться в "знакомом" проекте, например, использовать один и тот же способ делать запросы к базе данных, в также дорабатывать расширения для шаблона, делиться ими с другими разработчиками в других проектах (в контексте командной разработки).
Универсальность
Попробуем выделить основные аспекты, которые позволяет решить или существенно упростить использование шаблона:
- Шаблон включает нужные для всех микросервисов сборки и пакеты. Нужные новые - поставь, не нужные какие-то - удали. Часто добавляешь? Добавь в шаблон и т.д.;
- Шаблон включает (или может включать) общие (базовые) настройки на стандартных механизмов:
- Настройки подключения к MassTransit (через RabbitMQ);
- Настройки подключения к ELK для логирования;
- Настройки .editorconfig для среды разработки;
- Настройки CI/DC;
- Настройка подключения к Database;
- Шаблон включает общий (базовый) функционал:
- Расширения (extensions) для примитивных типов в C# (например, IsEmpty());
- Демонстрационные примеры использования тех или иных механизмов (изучив которые, можно просто удалить);
- Мониторинг на основе принятых в компании договоренностей;
- Работу с сервером аутентификации и авторизации OAuth2.0;
- Обеспечение защиты методов на базе встроенного в ASP.NET Core механизма авторизации и аутентификации (например, атрибут Authorize) настроенного на сервер авторизации;
- Универсальную структуру проектов в компании, которая поможет проще "входить" разработчикам в проект, и более осознано ориентироваться в проекте, построенных на базе одного или нескольких шаблонов.
Развитие
Существует два варианта дальнейшего развития использования шаблонов для разного типа проектов.
- Расширять возможности одного шаблона через сборки (nuget-пакеты).
Принцип 1
Cоздал новый микросервис из одного общего шаблона, установил nuget-пакеты те, которые тебе нужны, чтобы реализовать бизнес-логику. Например, потребовался доступ к шине сообщений - уставил какой надо nuget-пакет.
- Увеличивать количество шаблонов с реализацией конкретных возможностей.
Принцип 2
Cоздал проект из конкретного типа шаблона. Например, потребовался доступ к шине сообщений - взял за основу TemplateWithRabbitMQ.
Общая инфрастуктура
Каждый из микросервисов является частью системы, а система должна уметь разворачивать сервисы, собирать логи, мониторить и прочие обязательные в таких случаях манипуляции. Если данный функционал обязателен для каждого сервиса, то не глупо его писать (реализовывать) каждый раз сначала? Если говорить в контексте микросервисной архитектуры, то все микросервисы, так или иначе "похоже" друг на друга, с точки зрения инфраструктуры использования. Следовательно, заложив основу можно из одного общего создать другой шаблон более специализированный, который предназначен для более узкого круга задач: прокси сервис, gateway-сервис и т.д. Другое дело, если существует потребность создать шаблоны для разных платформ: ASP.NET Core, WPF, WinForm и т.д.
Заключение
В связи с выше сказанным, хочу предложить вашему вниманию свой шаблон, вернее сказать шаблоны, для микросервисов, который я назвал Nimble Framework. Его исходные тексты можно найти в github, где помимо исходных файлов еще куча полезной информации.
Версии шаблонов
- Для ASP.NET Core 2.х больше не поддерживается
- Для ASP.NET Core 3.0 больше не поддерживается
- Для ASP.NET Core 3.1 доступны сборка без исходных файлов. Поддержка прекратится с выходом новой версии.
- Для ASP.NET 5.х доступны сборка без исходных файлов.
- Nimble Framework 6.0: Для ASP.NET 6.0 Full API
- Nimble Framework 6.0: Для ASP.NET 6.0 Minimal API
- Nimble Framework 6.1: Для ASP.NET 6.0 с поддержкой OpenIddict (реализация закончена, идет формирование шаблонов)