Комментарии 18
Жаль, что опять не упомянута проблема монолитов наиболее сильно толкающая людей к его распиливанию его на части.
Это замедление процесса разработки. Когда надо десятки минут на сборку проекта и несколько часов на прогон всех тестов. Когда багофикс, который ты сделал за пол часа растягивается не несколько часов, а то и дней, ибо прежде чем делать PR, надо протестить изменения локально, а значит локально все поднять, и пусть процесс как правило автоматизирован, но занимает много времени. Ок, все работает делаем PR. Даже если его быстро отревьюили, надо ждать часы, пока ваш CI его соберет, прогонит все юнит тесты, развернет, прогонят базовые интеграционные тесты, только после этого его можно будет замержить. И на смотря на такую строгость не понимаю как, но периодически сборка, или тесты ломаются из-за изменений замерерженных часом раньше. Сидишь ждешь, пока их пофиксят, потом мержишься с последним мастером, проверяешь, что все работает, просишь ревьюверов отптичить PR, ибо изменений не было.
Это багофикс. Какие-нибудь большие изменения, на 15+ файлов отдельная головная боль. Ибо никто не любит ревьюить большие PR-ы. И если в своей команде найти ревьюверов все еще легко, но большие изменения часто залазят в область владения других команд и тут может не повезти. Плюс, чем дольше PR висит, тем больше шансов, что автомерж не сработает, надо мержить последние изменения в свой PR вручную.
Сейчас, конечно, придут разные люди и расскажут как правильно надо делать монолиты, что дизайн кривой и надо много репозиториев, а не монорепозиторий, но на практике в разных конторах я видел именно эти проблемы, толкающие людей уходить от монолитов.
Угу, вот только все монолиты, что я видел, были модульные. Однако модули все также лежат в одном репозитории. И хоть ты сам обычно тестишь только свои изменения перед тем как сделать PR, Дженкинс, или какой там аналог его используется, будет прогонять все тесты для всего монолита, прежде чем дать тебе замержить. Было бы интересно узнать о тех, у кого монолит лежит по разным репозиториям и для мержа не надо прогонять все тесты по всему монолиту.
Однако в целом я считаю, что в большинстве случаев начинать стоит с монолита, ибо бенефитов от монолита пока он маленький больше чем от микросервисов. Просто надо держать в голове, что монолиты имеют тенденцию расти, что с годами превращается в проблему.
Неплохой вариант - прогонять все тесты затронутых неймспейсов.
Вообще все тесты прогонять уже в фоне.
Не знаю на счет интернет магазинов, если у них репозитории огромные с большой кодовой базой, то вероятно тоже могут иметь подобные проблемы. А вот онлайн банкинг, которым сейчас пользуются сотни кредит юрионов а США как-раз имеет в основе монолит с вышеописанными проблемами, я это знаю точно, ибо сам не один год с ним проработал.
Еще раз. Проблемы замедления разработки, что я привел, зависят в первую очередь от размера репозитория и количества вовлеченных человек. Не от того, насколько идеальная архитектура. Вот сейчас глянул монолит с которого списывал проблему и от которого уже несколько лет отрезают кусочки: за последний месяц было замержено 480 пул реквестов от 118 человек и это август - период отпусков у кучи народа. Еслиб каждая команда из этих 118 человек сидела бы в своем изолированном репозитории - замерженных пул реквестов было-бы в несколько раз больше.
Подобные проблемы вообще не проблемы монолита, а любого крупного проекта. Лет десять назад я какоето время работал фулл-тайм контрибьютором в LLVM, когда у него репозиторий еще был в svn, вот там на любые изменения уходило очень много времени, ибо мало того, что только сборка идет час, так надо было проверять на куче разных физических устройств с разными архитектурами (и собирать тоже под них). Проверил, все нормально, твои изменения отревьюены и одобрены, закоммитил, а на следующий день к тебе пишет Крис Латтнер, мол ты знаешь, я ревертнул твой коммит, тк на наших внутренних тестовых окружениях в Эпле, такие-то тесты упали. Пустить к энвам мы тебя не можем, ибо nda, но вот дать тексты ошибок и стектрейсы можем. И что-то мне подсказывает, все эти проблемы у них там сейчас все также есть.
Все микросервисы которые я вижу в последнее время тоже лежат в монорепе.
Я подобное видел только в одном стартапе, где одна команда занималась всем проектом и выбрала делать его на микросервисах просто из-за внутренних хотелок, а не каких-то реальных оснований. Тому проекту микросервисы были просто не нужны. Полагаю, что небольшие конторы с одной-двумя командами могут так делать.
В крупных конторах, которые наелись проблем и с микросервисами, и с монолитами, обычно жизнь любого сервиса, хоть мико, хоть макро, начинается с регистрации его на девпортале. При этом портал сам сгенерирует для него новый репозиторий.
Это в идеальном мире монолит распиленный на модули имеет приемлемую связанность. Код придерживается принципов solid и т.д.
В жизни обычно все по другому ) особенно когда проходит n времени и монолит проходит через n людей
В статье хотели сделать акцент на проверку соответствия возможностей команды и планируемой архитектуре. Разговор не о том, что у микросервисов и монолитов нет проблем - везде есть свои за и против. Просто в определенном классе задач, приведенном в статье, монолит более эффективен, чем микросервисы. И конкретно при миграции легаси приложений монолит почти всегда выйгрывает. Согласны?
"оптимальное распределение ресурсов" - вот тут или я не понял или это не совсем верно. Т.к. наверняка многие микросервисы породят отдельные запросы данных, которые в монолите были бы получены всего 1 раз. А если ещё и кеши этих данных имеются разные, то можем получить вообще весёлое поведение.
Нормальные люди не бросаются в крайности а делают приложения модульными
Я работал на проекте, который представлял из себя "микросервисный монолит". Это было соединение всех минусов с двух сторон. Фактически просто все библиотеки вызывались по http, сервисы делились по случайному признаку.
Думаю, что если правильно приготовить монолит (можно дополнительно разделить монолит по доменам), то микросевисы станут сильно менее полезными. А вот если микросервисы сделать неудачно, то это похоронит проект.
Я думаю, первое реальное отличие монолита от микросервисов - это CI/CD. Ну чисто физически, если монолит - это один war-ник условно, то как вы братцы не садитесь, чтобы что-то попробовать его надо собрать и поднять где-то. При распределенной команде задача собрать "логический" конфиг, который состоит из измененной фичи "А", написанной разрабом X и фичи "Б", написанной разрабом Y на версии 123 на микросервисах решить намного легче, чем на монолите. Более того, каждый разраб, в целом, может даже локально собрать себе такой конфиг, или гибридно: что-то крутится у себя, то что правил сам, а что-то в общей "работоспособной" среде. Это просто следует из того, что монолит один, а микросервисы - это много.
Второе отличие - у микросервисов будет "интеграционный слой", в котором будет как-то реализовано общение микросервисов. В монолите это также может быть, но спрятано от посторонних глаз :)
Все остальное в реальности зависит от кривизны рук команды, а не от архитектуры.
Масштабирование - весьма условная вещь, если все это в конечном итоге живете на ограниченном пуле физических ресурсов. Все эта танцы с бубном не имеют никакого значения, если вы уперлись в полку CPU. В статье упомянут кейс, когда малозначимая функция может сожрать все ресурсы и спровоцировать "падение" всей системы - да, есть есть. Но есть и обратная сторона медали - заниматься масштабированием пипеткой, когда у тебя 100 сервисов тоже сложно. Т.е. это если наперед знать, что там проблема, то можно быстро пофиксить. А так чуда нет. К примеру, 10 сервисов, 4 ядра. Всем дали все. Один "плохой" сервис занял 4 ядра - система умерла. А-а-а, плохо. Выдали всем лимит, не больше одного ядра в одни руки. Тогда другой "хороший" сервис взял одно ядро и умер, потому что ему объективно надо больше. Следующая итерация. Хорошему сервису можно два ядра, остальным - одно. И так до победного конца. В реале с монолитом легко достичь того же самого, так как можно на балансере наверху развести сервисы по нодам и важности. Условно "хорошие" сервисы живут на всех нодах, а "плохие" - на двух. Так как в реальной жизни не требуется так детально масштабировать каждый сервис и достаточно сформировать пулы эквивалентных сервисов.
Время установки: да нет никакой разницы. В реальной жизни любое приложение живет на куче нод, и несложно накатывать изменения понодово, сведя время даунтайма к нулю.
--------------
Я бы исходил в первую очередь из процеса разработки. Если микросервисы ускорят процесс - давайте заплатим цену за доп. интеграционный слой. Если нет - можно не усложнять, так как одной "единицей" оперировать инонгда проще, чем 100.
Как-то автор обошёл проблему целостности и согласованности данных для распределённых систем, и что делать если возникла какая-то ошибка при изменении данных в каком-то месте распределённой системы. И как лепить транзакционность операции на этих микросервисах в распределённой системе... Вот это я считаю основным гемороем микросервисов и преимуществом монолита, в которой всё делается само собой с помощью JTA.
Монолитная и микросервисная архитектура. Сравнение