Хотелось бы развивать приложения в сторону сервисной архитектуры, когда часть логики вынесена в отдельное приложение(сервис). Это бы позволило масштабировать только нужный функционал, а не сразу весь монолит. К тому же можно перейти на новый уровень переиспользования решения, когда сразу рядом с приложением разворачивается готовы сервис.
Почему с платформой
-
Чтобы переиспользовать одни и те же компоненты в монолитном приложении и в сервисах. Это сократило бы время на разработку сервисов и время на вхождение. Схожие принципы, схожий код - меньше времени на обучение, легче переводить разработчика с монолитной архитектуры на сервисную.
-
Чтобы избежать проблем с интеграцией, когда команда разрабатывает свое решение без зависимостей от платформы, а потом оказывается что надо бы чтобы монолит то мог обратиться к сервису.
Что хотелось бы получить
- Аналог веб-хоста с жизненным циклом, системой модулей и поддержкой аргументов командной строки
- Инструмент для взаимодействия с другими сервисами с поддержкой задач, запросов(мб RPC) и событий
- Единую авторизацию между сервисами и основным приложением, с сохранением ролей и пермишенов
- Проверку состояния сервиса(проверка жизни сервиса)
- Реализацию IFileManager для удаленного хранилища данных, например, для ftp
- Поддержку цепочки задач\запросов с возможностью проследить всю цепочку и по возможности отменить
- Распределенное кэширование
- Работа с базой данных
- Возможность запуска на windows и linux
- Генерация docker image
В идеале разобрать существующие модули так, чтобы в сервис не тянулся весь системный UI. И в целом получить бы достаточно легкие сервисы без того потребления памяти, что есть в монолитном приложении, когда оно на старте без нагрузки съедает почти 2Гб.
Пример
Если рассматривать проблему в диаграммах, то я ее вижу следующим образом. Сейчас у нас есть монолит с api gateway(оранжевые блоки), с веб-клиентом(желтые блоки) и сервисам(фиолетовые блоки. Сервисы - это сервисы BarsUp, например, IDataStore или IFileManager и все сервисы с бизнес логикой.
Монолит
Если добавить сюда тот сервис, который генерирует BarsUp.Designer, то получается что отличий между сервисом и монолитом не так и много. В целом это монолит без кастомного и генерируемого UI.
Монолит и “сервис”
Хотелось бы облегчить сервис и придать ему конкретики. Т.е. выкинуть блоки с api и UI и оставить только логику соответствующую конкретному сервису.
BarsUp.Designer
BarsUp.Designer умеет генерировать серверный метод, аргументы и клиентский код для его вызова. В идеале получить возможность реализации интерфейса в отдельном приложении и вызывать его через MQ.