Комментарии 25
Вам придется заново сделать анализ потребностей бизнеса для правильной “нарезки”:
А можно как-то это проиллюстрировать примером? Ведь есть уже работающая система, все проанализировано, спроектировано, реализовано и оттестировано. Чем бизнес недоволен, что не является non-functional requirements?
Из практики обычно получается так, что в монолите многое сложилось «исторически» и почему так уже никто не помнит. То есть много функций работает и на них не обращают внимания, а они со временем обрастают разными зависимостями. Например, сервис, который должен заниматься расшифровкой, заодно работает с архивами и в базу данных кладет файлы и в папочки на FTP скидывает какие-то вещи. Такой сервис получает много причин сломаться и при создании микросервисов надо понять, что у него внутри, чтобы не тащить AS IS, а подойти к «распилке» с толком.
Это все "детали реализации", нет? При чем тут бизнес?
Архитектура же от бизнеса строится, т.е. архитектура это производное от бизнеса. В зависимости от стратегии и устройства всей компании будет делаться нарезка.
В зависимости от стратегии и устройства всей компании будет делаться нарезка.
С трудом представляю себе, каким образом следующее описание связано с "устройством компании":
сервис, который должен заниматься расшифровкой, заодно работает с архивами и в базу данных кладет файлы и в папочки на FTP скидывает какие-то вещи.
Вот мы переводим это дело на микросервисы. Что тут может дополнительно дать анализ "потребностей бизнеса"?
Ну как минимум можно узнать у бизнеса, зачем вообще нужно выкладывать файлы на FTP. Может это выкладывание сложилось исторически и им уже три года никто не пользуется. Это бывает полезно даже в том случае, когда вы сами распиливаете свой собственный монолит.
Кроме того, автор пишет: «Кроме этого, до начала работ желательно договориться с командой, писавшей монолит, чтобы они выделили время на ваши вопросы по коду.» — что намекает на то, что перевод на монолит осуществляет отдельная команда и в таком случае сделать повторный анализ бизнес-требований полезнее вдвойне, новые разработчики находятся вне контекста и не смогут грамотно спроектировать систему, не погрузившить в оный.
Кроме того, автор пишет: «Кроме этого, до начала работ желательно договориться с командой, писавшей монолит, чтобы они выделили время на ваши вопросы по коду.» — что намекает на то, что перевод на монолит осуществляет отдельная команда и в таком случае сделать повторный анализ бизнес-требований полезнее вдвойне, новые разработчики находятся вне контекста и не смогут грамотно спроектировать систему, не погрузившить в оный.
Ну как минимум можно узнать у бизнеса, зачем вообще нужно выкладывать файлы на FTP
Я бы хотел рассмотреть пример, желательно близкий к реальности, как это все происходит.
Пока это все мне видится так — технический долг превысил критическую массу и система начала тонуть, люди разбегаются, документации нет. У бизнеса возникают проблемы, бизнес хватается за голову и нанимает/вызывает авральную команду. Этой новой команде, конечно же, придется начать с анализа потребностей бизнеса.
Если же все в относительном порядке, просто возникли проблемы с масштабируемостью монолита, то можно заглянуть в существующую документацию и оттуда узнать про то, какие потребности бизнеса и каким образом реализованы. Понятно, можно что-то уточнить. Но "заново сделать анализ"?
В реальности будет примерно так:
1. Шифрование и распаковка важны для бизнеса? Часто используются?
1.1. Нет, используются редко, нет нагрузки, используются всегда вместе. Значит оставляем их вместе, не закладываем масштабирование.
1.2. Да, важны. Бизнес живет на обработке входящих документов, которые бывают зашифрованы и заархивированы. Кроме этого, архивация требуется многим другим отделаем. Значит, делает на шифрование и архивирование отдельные микросервисы со своими SLA и подходом к масштабированию.
1. Шифрование и распаковка важны для бизнеса? Часто используются?
1.1. Нет, используются редко, нет нагрузки, используются всегда вместе. Значит оставляем их вместе, не закладываем масштабирование.
1.2. Да, важны. Бизнес живет на обработке входящих документов, которые бывают зашифрованы и заархивированы. Кроме этого, архивация требуется многим другим отделаем. Значит, делает на шифрование и архивирование отдельные микросервисы со своими SLA и подходом к масштабированию.
Очень интересная и полезная статья, я бы еще почитал подробнее об распределении ответственности команд между микросервисами. Спасибо за информацию. Будем изучать
В большинстве случаев срабатывает microservices.io/patterns/decomposition/service-per-team.html, но надо примерять к своей реальности и делать корректировки. Плюс, рекомендую использовать InnerSource, потому что этот подход хорошо сочетается с микросервисами.
НЛО прилетело и опубликовало эту надпись здесь
Конечно много людей используют микросервисы как дань моде, но на самом деле необходимость есть, в основном в действительно больших проектах с большим количеством разработчиках. Только наступает эта необходимость в каждом проекте по-разному, где-то может вообще не наступить, это чувствуется. Когда становится сложнее вносить правки, когда команды мешают друг-другу, когда сложность и запутанность кода выросла на столько, что джуна подпустить к проекту это долгий и сложный процесс, когда сами разработчики тупят или делают баги из-за чрезмерной запутанности. Еще есть технические причины, например когда по мере роста нагрузки нужно прооптимизировать какое-то место, но не получается из-за связности с другими частями, и это требует глубокого рефакторинга, затем повторить через месяц в другом месте. Ну и конечно же производительность — микросервисами дешевле и проще горизонтально масштабироваться.
В общем просто из-за моды это деньги на ветер, решение должно созреть на объективной почве.
В общем просто из-за моды это деньги на ветер, решение должно созреть на объективной почве.
Как обычно надо оценить какие бонусы получит бизнес (в конце статьи пару ссылок на эту тему) и посчитать расходы. Если первое больше, чем второе, то стоит переходить :)
Вот сколько статей уже перечитал про переход от монолита к микросервисам — никто и нигде не упоминал такую очень важную вещь как переиспользование кода.
В монолите содержится много разных utility классов, включая бизнес-логику, которые используются в разных частях (которые в итоге должны быть разными микросервисами). И как вот с этим быть? Копипастить код? Конечно нет, ведь бизнес-логика постоянно развивается. Выносить в подключаемые библиотеки? Во-первых это сработает только если все сервисы на одном языке. А во-вторых это сильно усложняет внесение правок в эти библиотеки — ведь раньше можно было сделать find usages по монолиту, а теперь по куче сервисов, да еще и отвечают за них разные люди. Использовать отдельный микросервис с бизнес-логикой? Тогда это будет монолит в миниатюре.
Если кто-то владеет информацией как решаются такие вопросы, или просто ссылкой на неё — буду благодарен.
В монолите содержится много разных utility классов, включая бизнес-логику, которые используются в разных частях (которые в итоге должны быть разными микросервисами). И как вот с этим быть? Копипастить код? Конечно нет, ведь бизнес-логика постоянно развивается. Выносить в подключаемые библиотеки? Во-первых это сработает только если все сервисы на одном языке. А во-вторых это сильно усложняет внесение правок в эти библиотеки — ведь раньше можно было сделать find usages по монолиту, а теперь по куче сервисов, да еще и отвечают за них разные люди. Использовать отдельный микросервис с бизнес-логикой? Тогда это будет монолит в миниатюре.
Если кто-то владеет информацией как решаются такие вопросы, или просто ссылкой на неё — буду благодарен.
навскидку в голову приходит два варианта: монорепозиторий или библиотеки. только библиотек или общих элементов будет по количеству языков, на которых пишутся микросервисы.
а в чем усложнение внесения правок в библиотеки? применяя версионирование можно существенно облегчить себе жизнь
Если у вас во многих микросервисах встречается одинаковая логика, возможно, вы неправильно нарезали зоны ответственности между сервисами и стоит их пересмотреть.
Вообще, если рассматривать классический подход к микросервисам, то между ними не должно быть разделяемого кода. Такой подход не всегда оправдан, часто удобнее все-таки часть кода сделать разделяемой. Как это будет реализовано — вопрос дискуссионный. Как вам кажется удобным для вашего кейса — так и делайте. И да, в любом случае такое разделение будет привносить дополнительное неудобство в разработку. Но микросервисы — это вообще не про удобство разработки, а про повышение гибкости системы в целом, возможности масштабирования отдельных ее частей. Дополнительная гибкость в любой системе всегда связана с дополнительной сложностью ее поддержки.
Вообще, если рассматривать классический подход к микросервисам, то между ними не должно быть разделяемого кода. Такой подход не всегда оправдан, часто удобнее все-таки часть кода сделать разделяемой. Как это будет реализовано — вопрос дискуссионный. Как вам кажется удобным для вашего кейса — так и делайте. И да, в любом случае такое разделение будет привносить дополнительное неудобство в разработку. Но микросервисы — это вообще не про удобство разработки, а про повышение гибкости системы в целом, возможности масштабирования отдельных ее частей. Дополнительная гибкость в любой системе всегда связана с дополнительной сложностью ее поддержки.
Если у вас не монорепа, то find usage никак не сделать. Это естественное ограничение микросервисной архитектуры. Вынос в библиотеки может помочь, но к этому решению сразу прибавляется проблемы с версионированием библиотеки. Я пока не увидел общего решения этой задачи.
Если это какая-то общая либа, тянуть ее через пакетный менеджер. Не смущает же что системные библиотеки или фреймворки подключены одни и те же на разных микросервисах.
Это почему это нельзя использовать одну бд для нескольких микросервисов?
Если релиз включает интеграционное тестирование то никаких ограничений на это нет.
Тоже самое про переиспользование кода. Выделение пакетов или общий репозиторий решает эту проблему начисто.
Если релиз включает интеграционное тестирование то никаких ограничений на это нет.
Тоже самое про переиспользование кода. Выделение пакетов или общий репозиторий решает эту проблему начисто.
Потому что Shared DB усложнит управление микросервисной архитектурой, плюсы и минусы есть здесь microservices.io/patterns/data/shared-database.html. Если нужна «общая» база, то лучше закрыть базу сервисом, тогда хотя бы будет видно, кто, что и когда пишет/читает из базы на уровне API, а не на уровне логов БД.
Выделение пакетов помогает, но добавляет сложности с управлением версиями этих пакетов. Это не значит, что выделение пакетов плохо, но у подхода есть свои минусы.
Выделение пакетов помогает, но добавляет сложности с управлением версиями этих пакетов. Это не значит, что выделение пакетов плохо, но у подхода есть свои минусы.
создавайте кросс-функциональные команды
Часто под этим понимают «все отвечают за всё», а это уже вопрос совладения компанией, а не работа по найму. Мотивация совершенно другая.
Лучше подразумевать под этим то, чем они на самом деле являются en.wikipedia.org/wiki/Cross-functional_team, т.е. самодостаточная команда, которая может выпустить сервис без привлечения внешних сил.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Скрытые расходы при переходе на микросервисы