Распил монолита

Зачем

Ускорение разработки. Если согласно плану какая-то часть вашего приложения будет активно развиваться на протяжении следующего года, разработку можно ускорить путем извлечения ее в сервис.
Решение проблем с производительностью, масштабируемостью и надежностью. Если определенная часть вашего приложения ненадежна или имеет проблемы с производительностью или масштабируемостью, будет полезно преобразовать ее в сервис.
Возможность извлечь какие-то другие сервисы. Иногда из-за зависимостей между модулями извлечение одного сервиса упрощает извлечение другого.

Сервисы лучше писать не монолитчику - он и так довел монолит до текущего состояния
С недоверием относитесь к переиспользованию функционала? Наоборот, любой функционал должен дублироваться.

Что вынести в первую очередь в сервис\модуль, а что можно оставить?

Метрики для приоритизации:
- Бизнес-критичность
- Интенсивность изменений
- Инновационность
- Объем транзакций (обращений)
- Уровень зависимостей
- Утилизация ресурсов
- Сложность сервиса
Имеет смысл извлечь сервис, функции, которого постоянно эволюционируют и имеют критическое значение с точки зрения бизнеса. Если извлечение не приносит существенной выгоды, не стоит тратить на него время.
Возможна высокая трудоемкость распила всего монолита и лучше делать только новые сервисы вокруг монолита, а монолит не распиливать.
Существующие модули слабо зависимые и часто изменяемые

ФБ - функциональный блок - бизнес-возможность - поддомен DDD.

нужно решить, как разбить доменную модель монолита на отдельные модели (ФБ), одна из которых будет принадлежать сервису
Для вынесения функциональности придется разорвать зависимости
- объектные ссылки, и, возможно, разделить существующие классы
- модифицировать структуру базы данных
при извлечении сервиса вы разделяете то, что прежде было ACID-транзакциями. Вы должны внимательно следить за сохранением согласованности, для этого иногда применяются
- повествования Event Sourcing
- Рефакторинг БД
Чтобы ограниченные контексты отделять друг от друга и начать процесс выделения микросервисов из монолитного решения, мы использовали такой подход, как создание внутри приложения внешних API

Что извлекать первым: код или БД?
- если можно изменять монолит, БД
- иначе - код
Feature Toogle typical workflow:
- Identify a piece of the monolith functionality to migrate to a microservice.
- Wrap the functionality with a feature flag. Re-deploy the monolith.
- Build and deploy the microservice
- Test the microservice
- Then ok, disable the feature on the monolith by switching the feature flag
- Repeat until the migration is complete
Провести нагрузочное тестирование
Для реверс-инжиниринга: gor

Делится на: