#lafest Дмитрий Моряков. Изоляция микросервисов по данным при | mtsepkov

#lafest Дмитрий Моряков. Изоляция микросервисов по данным при миграции с монолита. Понятный доклад о процессе распила монолита в изолированные микросервисы. К сожалению, без примеров. На абстрактном уровне процесс понятен, а дьявол как всегда сидит в деталях, потому что оказывается, что система внутри сильно связана и с этим надо как-то разбираться. Дальше тезисы.

Монолит. Общая БД - ограничение масштабирования. А интеграция - через БД. Микросервисы: у каждого своя БД и взаимодействие через АПИ - для масшабируемости. Можно запустить много экземпляров.

Как менять? Варианты пилотного проекта.
* Делаем в микросервисах новое, ставим рядом. Оно хорошо, но не получается распилить.
* Поставить новую систему в параллельную работу, а потом переключить. Дорого, не всегда есть время.
* Вырезаем из монолита критичную часть и делаем микросервисами.
Рассматривали именно третий сценарий, когда монолит сильно не справляется, и критичную часть надо выделить для ее масштабирования.

Роль аналитика
* Реверс инжиниринг - анализ БД, сбор требований. С документацией обычно проблемы. Есть средства не только для БД, но и для кода и логов, но практически БД - не дорого и достаточно.
* Моделирование: предметная область, процессы AsIs
* Проектирование: бизнес-процессы ToBe на основании решений по архитектуре. Управление зависимостями.

И дальше в докладе было детальное описание по стадиям.
* Построить модель предметной области
* Описать бизнес-процессы AsIs - выдерживая модель
* Выделить микросервисы
* Спроектировать новые бизнес-процессы: монолит обеспечивал транзакционность работы по запросу пользователя, а в микросервисной архитектуре исполнение идет асинхронно по нескольким сервисам, и это требует перестройки процессов
* Детальное проектирование микросервисов.

Нотации.
* Процессы - BPMN. Процессы, и их ассоциация с хранилищами. Описание коллаборации: межпроцессный обмен, service task, очереди сообщений.
* Предметная область:
Domain-Subdomain - удобная, но слабая, только верхнего уровня. Работает на простых областях.
UML диаграмма классов - хорошая, но с трудом понимается всей командой, особенно бизнесом.
** ER-диаграммы, с дополнением сущность-связь EA для отложения вложенности доменов
Инструментарий - EA (он использовал его), Visual Paradigm, iServer. На большой БД нужны отчеты по БД.

Диаграмма: два БП, в одном пишем хранилище, в другом - читаем. Направленная связь записи/чтения - по варианту использования use case. Вся модель - в репозитории, и это дает возможности проверять модель, группировать информацию.

Итерационный процесс, чтобы добиться изоляции.
* Бизнес-процессы формулировать в сущностях предметной области
* Названия хранилищ - в соответствии с сущностями предметной области
* Отчеты по репозитарию
* Изоляция: хранилище ассоциировано с одним вариантом использования.
* Персистентность данных - только в конечных состояниях.
* Избегаем update, создаем новые данные

Самый страшный монолит можно распилить. Вопрос - сколько сил вкладывать в детальное проектирование и моделирование.

В вопросах - как интегрировать с системами ведения задач после начала разработки. Ответ: однократную выгрузку, например, для создания задач в Jira, сделать легко, а вот изменения отслеживать сложно. Именно поэтому он предлагает методику только для пилота. На описание полной системы не хватит ресурсов аналитиков. Но кусочки отпиливать по-очереди можно.