Комментарии 4
Вроде как микросервисный угар прошёл год или два назад. Возможно в вашем случае действительно всё настолько ужасно (в качестве/культуре кода), но проблема не в том что это монолит
Я без негатива, но когда начинают яро поносить что-то по умолчанию (монолит или PHP) трудно пройти мимо)
Привет! На счет угара относительно согласен) Мне кажется, что по хорошему он прошел еще раньше. Компания сама вошла в него тоже не вчера, просто до этого никто с нашей стороны не афишировал подобные изменения, а так как моя команда находится на их острие, то родилось и это вступление, и этот текст)
Спасибо за комментарий! Что касается ужаса монолита - тут статья больше не о том, что он ужасен, а о нашем переходе к другому решению - к SOA, а не к микросервисам) Да, в нашем случае монолит оказался бутылочным горлышком, но что мы делаем с бутылочными горлышками? Стараемся от них избавиться
Плюсом: явно же, что ту же проблему с доездом товаров со склада на сайт можно было решить и в монолите (как и многое другое), но в момент оценки трудозатрат на рефакторинг и вынос логики в отдельный сервис с большим отрывом победило второе решение. Благодаря выбранному вектору разработки у нас и сайт начал быстрее работать - с открытия страницы товара за 3 секунды до >1 секунды.
Но, повторюсь, это все можно было сделать и в монолите, и с PHP) Все же я старался не хаять что-то, а рассказать о предпосылках и конкретных решениях
PS. Для меня самого оказалось удивительным, что для разработчиков тема распила монолита все еще актуальна... И на Highload, и на митапах ко мне подходили коллеги (не один-два) и консультировались на этот счет. Так что я тоже думал, что тема себя изжила, но она все еще подает признаки жизни :D
Я работал на этом проекте, еще до перехода на микросервисы. С моей точки зрения проблемы там были совсем не из-за того, что монолит.
- Логика в сущности. Класс товара занимал кажется 3000 строк, и были еще другие связанные классы, тоже большие.
- Правило, что в репозитории должен быть только один метод, который возвращает список сущностей по фильтру. В результате все критерии фильтрации сущностей сливались в один большой фильтр, и для админки, и для пользовательской части.
- Подход, часто встречающийся в проектах Symfony, когда из контроллера в шаблон twig передаются вообще все данные для рендеринга страницы. Включая данные для меню и другой информации в заголовке и футере. Это приводило к тому, что были базовые контроллеры, которые устанавливали сотни глобальных переменных для twig с загрузкой некоторых из базы, хотя для любой страницы требовалась только часть из них, с соответствующей обвязкой для всего этого, которые потом рендерились неизвестно где с передачей некоторых полей переменной в другие шаблоны. Twig нетипизированный, и в PHPStorm нет поддержки PHPDoc-style комментариев в twig-шаблонах, поэтому найти где что выводится и поменять как нужно было довольно сложно и занимало время.
- Потом поверх этого решили добавить что-то похожее на Clean Code, с разделением на application layer/infrastructure layer/... с передачей DTO из одного слоя в другой, поля в которых назывались так же как в сущности/другом DTO, и было много кода, который просто копирует их туда-сюда. И всякими другими правилами. Теоретически у этого может и есть какие-то плюсы, но на практике я их не заметил.
Еще много чего можно написать.
Потом я перешел на другой проект в той же компании, там тоже монолит, но сложностей в поддержке не было.
Мне кажется, улучшения связаны не с переходом на микросервисы, а с тем, что просто переписали нормально. Если поместить все новые микросервисы в один проект, и заменить сетевые вызовы на рантайм-вызовы, их функциональность не изменится, ведь так?, но это будет такой же монолит.
Автору - если интересно, посмотрите исходники вашего проекта PAS, как там организованы контроллеры, валидация и логика. По моему опыту, такой подход неплохо работает в любых проектах.
Все таки перечисленные проблемы относятся к монолиту, а именно к тому, как он строился все это время) вы правы в своих пунктах! И именно поэтому оказалось дешевле монолит распилить, чем пересобирать или отрефачить, потому что построить архитектуру кодовой базы сервиса силами одной команды мне точно кажется легче, чем держать в согласованном состоянии код монолита силами всех наших команд
Да, возникают проблемы с взаимоотношениями между сервисами, это тоже правда, но таков путь)
А ребята из PAS меня уже позвали к себе посмотреть на сервис, так что непременно, спасибо за наводку!
Страх и Ненависть в Ви.Tech: от монолита к не микросервисам