Комментарии 32
микросервисы VS монолит— когда я слышу такую постановку вопроса, всегда хочется задать участникам дискуссии вопрос: а про SOA вы что то слышали? К чему это полярное мышление окрашивающее все в два цвета — черный и белый? Вся дискуссия сводится к тому что то что для одного черное, для другого белое и никто не говорит о масштабах задачи. У одного в голове условный Twitter (хотя систем такого масштаба не так уж и много), у другого в голове условная офисная CRM
статья интересная, спасибо.
итого получается
1) административная неповоротливость, множество команд
2) сложно и медленно разрабатывать когда система вне стадии MVP
3) сложно тестировать и убедиться в надёжности
4) сложно дебажить
итого получается
1) административная неповоротливость, множество команд
2) сложно и медленно разрабатывать когда система вне стадии MVP
3) сложно тестировать и убедиться в надёжности
4) сложно дебажить
Монолит на java, это идеальный монолит. Обычно на практике монолит реализован на OEBS, Siebel, ЦФТ, Colvir, etc. И если там, к примеру пилит 5+ команд, с отладкой и тестированием все грустно. С развертыванием отдельных контуров — еще грустнее.
В целом, серебряных пуль не бывает, и с монолитом, и с микросервисами нужно вдумчиво работать.
В целом, серебряных пуль не бывает, и с монолитом, и с микросервисами нужно вдумчиво работать.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Всегда удивлял этот аргумент. Серьезно, вы готовы пожертвовать (а в большинстве случаев микросервисы — это «жертва») архитектурой системы ради процессов разработки?
думаю что в некоторых случаях без этого не обойтись. Если система большая то не выйдет менять один и тот же или всего 3-5 репозиториев
открыл рандомную популярную книгу про микросервисы, Monolith to microservices, Sam Newman
samnewman.io/books/monolith-to-microservices
похоже эти все проблемы известны уже давно
Chapter 5: Growing Pains
More Services, More Pain
Breaking Changes
Reporting
Monitoring and Troubleshooting
Local Developer Experience
Running Too Many Things
End-to-end Testing
Global Verses Local Optimization
Robustness and Resiliency
Orphaned Services
мне так видится что отрасль постепенно делает своего рода Тик-так (как у Интела): сначала вводит какое-то новшество чтобы решать проблемы, потом фиксит проблемы которые дало это новшество…
Так было например с NoSQL и озерами данных. Было время когда все повально кинулись туда, наклепали NoSQL, баз на хадупе и тд, а потом маятник качнулся в другую сторону, и сам же Google, который был пионером big data, сделал Spanner и мотивом было «лучше транзакции и ACID будут с задержками в распределенной субд чем если снова и снова писать велосипеды для транзакций поверх NoSQL» (не дословно, можно открыть и почитать их white paper). Вот эти проблемы — непонятная надежность, дебаг, тестирование, должны привести к тому что либо будут найдены решения (service mesh?) либо маятник снова качнется в другую сторону, когда поймут что проблемы микросервисов достаточно серьёзные.
НЛО прилетело и опубликовало эту надпись здесь
Не бывает прилично раскроенных микросервисов, бывают простые бизнес-задачи.
Но в таких случаях, когда границы контекста ясны, никто не мешает сделать и 2 отдельных монолита.
В реальном большом бизнесе границы настолько размыты, что выделять контексты архитектор будет первые полгода. А потом после пары месяцев разработки, пойдет переделывать потому что на самом деле все не так.
Но в таких случаях, когда границы контекста ясны, никто не мешает сделать и 2 отдельных монолита.
В реальном большом бизнесе границы настолько размыты, что выделять контексты архитектор будет первые полгода. А потом после пары месяцев разработки, пойдет переделывать потому что на самом деле все не так.
Согласен. На мой взгляд, если не брать условный вариант: «У нас собралась команда супер-пупер чуваков, которые 30 лет в разработке, знают от Кобола, через Брейнфак и Джулию до Раста и все эти 30 лет они работали одной дружной командой», то единственный реальный кейс применения (микро)сервисов в веб разработке — это что-то вроде следующего:
- Пилим PoC/MVP
- Получаем кучу прибыли\инвестиций\клиентов
- Набираем лучших специалистов (и не особо важно на каких стеках, ведь таких не больно и много)
- Грамотно продумываем, какие части монолита можно выпилить безболезненно, под корень и надолго
- Постепенно начинаем пилить это разными командами, возможно, на разных стеках
- В итоге, когда выпиленные части монолита отлично работают в продакшене как микросервисы и код из монолита удален полностью, мы получаем буст в скорости разработки немного похожий на линейный по сравнению с количеством разработчиков. Иначе, увеличив количество разработчиков в 10 раз (с 10 до 100, например), мы бы в ЛУЧШЕМ случае ускороили разработку в 1.5 — 2 раза, но в большинстве случаев, бизнес бы умер.
В прилично же раскроенных микросервисах разработка намного проще и быстрей
за счет чего? Допустим мне чтобы вмёржить 100 строк кода, надо пройти ревью в трёх репозиториях. Быстрее разрабатывать отдельный микросервис который ни от чего не зависит, но интегрироваться намного медленнее.
Если вам нужно мерджить в 3 репозитория, то скорей всего у вас таки проблемы с границами.
Обычно вы работаете с одним сервисом и до тех пор, пока не рушите его АПИ, вы ничем не ограничены.
на активной фазе разработки апи тоже часто меняется, а ещё есть контракты которые тоже надо обновлять, ещё есть общие подпроекты
Начинать с микросервисов (особенно если вы только ищете свой продукт и не ясно что в итоге получится) такая себе затея.
Еще раз, микросервисы — это о масштабировании разработки. У вас есть продукт с работающей экномикой, у вас есть понимание куда и как вы хотите расти, у вас растет команда и люди начинают мешать друг другу. Вы хорошо понимаете как работает ваш продукт, где в нем проходят границы бизнесс-процессов и что из него можно вынести в независимый сервис (да еще и в перспективе переюзать этот сервис в других своих продуктах) и вы постепенно распиливаете монолит на сервисы.
это всё понятно. Я говорю с точки зрения девелопера, и какие у этого есть проблемы. Например есть проблемы когда нужно интегрироваться, а если нужно сделать вещь которая затрагивает 10 микросервисов, то нужно общаться с 10ю командами, делать пулл реквесты или вынуждать это делать эти команды. Это не так просто.
Начинать с микросервисов (особенно если вы только ищете свой продукт и не ясно что в итоге получится) такая себе затея.
микросервисы могут активно меняться и интегрироваться с другими не только во время распилов монолита или переходов. Мне кажется вы рассуждаете «паттернами идеального мира» где всё происходит прям как в какой-то книге написано.
НЛО прилетело и опубликовало эту надпись здесь
Реализуйте необходимое в новом сервисе и посмотрите как это интегрируется с вашей системой.
Выбросить такой сервис намного безболезненней чем выпиливать что-то из монолита.
Вот эту самую интеграцию и надо выпиливать в обоих случаях. Нет большой разницы, выпиливать вызов service->method() или httpClient->request('GET', 'service/method').
НЛО прилетело и опубликовало эту надпись здесь
По поводу изменений в сервисах, да может быть такое, что нужно что-то менять. Но снова, не нужно добавлять в сервис новые обязанности, только потому, что на первый взгляд не понятно кто должен эту новою работу выполнять. Придерживайтесь того же SRP, Low coupling/High cohesion как и при написании кода, делайте сервисы слабо связанными и сфокусированными на одной бизнес-задаче и не создавайте себе дополнительных сложностей.
открыл на днях Фаулера, его статью о микросервисах. В разделе «Микросервисы это будущее?» он пишет что пока рано говорить, т.к. сейчас недостаточно данных судить об успешной адаптации кроме тех. гигантов.
то что вы говорите, конечно верно, но проблемы отладки (более широко — удобства разработки), тестирования и особенно простоты интеграции остаются и пока что видятся фундаментальными ограничениями технологии как таковой, которые возможно нельзя обойти в принципе. Вот эти вещи «SRP, Low coupling/High cohesion» скорее облегчают жизнь, но интеграция и масштабный девопс никуда не деваются, потому что микросервисы это распределённая система со всеми вытекающими сложностями
НЛО прилетело и опубликовало эту надпись здесь
Микро-сервисы намного проще разрабатывать чем монолит, как раз за счет сильно ограниченного контекста.
отдельный микросервис проще разрабатывать чем монолит, а всю систему — сложнее.
А так Jaeger \ DataDog вполне позволяют легко отлаживать систему в сборе
это разве отладка? Дистрибютед трейсинг это разве тоже самое как если бы я поставил точку останова в приложении?
Отдельные же сервисы отлаживаются точно так-же как и монолитные приложения.
чтобы запустить локально, нужно воссоздать на локальной машине не только сам сервис но и другие сервиса с которым этот микросервис общается. А ещё это могут быть AWS ресурсы, не на все из которых есть докер аналоги. И даже если это возможно, это куда более накладно. Ничего себе «точно так же» ))
НЛО прилетело и опубликовало эту надпись здесь
Если ваши сервисы хорошо изолированы, то чаще всего вы и работать будете с одним. И поставить точку останова вы сможете. К сожалению очень часто путают (микро-)сервисную архитектуру и распределенный монолит. А трейсинг как раз поможет понять в каком из сервисов искать проблему.
и что покажет трейсинг? что какой-то сервис в цепочке вернул 500-ку или 400-ку? А если они вернули 200 но результат неправильный? Трейсинг это же не дебаг ) А в логах могут не печататься респонзы ) А причина неправильно посчитанного значения может быть как в одном сервисе так и в нескольких и даже в их взаимодействии. И чтобы это понять, нужно реально продебажить. Ну или добавлять логи в несколько сервисов и деплоить и смотреть )
Вы упорно делаете вид будто бы отладка системы из кучи компонентов и связей между ними это тоже самое что и отладка одного приложения. Так это же просто неправда, и что мы тут обсуждаем вообще?
Вариант — половина кода в монолите, половина — в микросервисах не рассматривается? В любом проекте полно кода, которые так и просятся в микросервис
НЛО прилетело и опубликовало эту надпись здесь
Недавно общался с человеком (на собеседовании), который сказал, что они пытаются перейти на микросервисы потому что джанго орм не справляется с их сложными запросами. Не вдаваясь в дебри (а тут возникает очень много вопросов) выяснилось, что ребята не знали про то какие существуют эффективные способы хранения деревьев в базе данных. В итоге они думали, что именно микросервисы им помогут справиться с нагрузкой.
чем больше людей тем хуже показывают себя монолиты в частности при мерже наступает локальный ад
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Микросервисы VS монолит: баттл адептов