Открыть список
Как стать автором
Обновить

Комментарии 30

микросервисы VS монолит
— когда я слышу такую постановку вопроса, всегда хочется задать участникам дискуссии вопрос: а про SOA вы что то слышали? К чему это полярное мышление окрашивающее все в два цвета — черный и белый? Вся дискуссия сводится к тому что то что для одного черное, для другого белое и никто не говорит о масштабах задачи. У одного в голове условный Twitter (хотя систем такого масштаба не так уж и много), у другого в голове условная офисная CRM
Про SOA есть внутри, я про это тоже упоминал, а именно в формате батла было специально выбрано 2 разных подхода, просто чтобы не уходить в дебри архитектурных подходов.
статья интересная, спасибо.

итого получается
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?) либо маятник снова качнется в другую сторону, когда поймут что проблемы микросервисов достаточно серьёзные.

Жертвуешь ты архитектурой системы или нет — зависит от того, как проложены границы микросервисов.
Если на каждое второе действие вы синхронно запрашиваете все свои микросервисы (а иногда еще и по кругу А -> B -> C -> A ->D -> B -> A), то, вероятно, границы проложены неверно.
В прилично же раскроенных микросервисах разработка намного проще и быстрей
Не бывает прилично раскроенных микросервисов, бывают простые бизнес-задачи.
Но в таких случаях, когда границы контекста ясны, никто не мешает сделать и 2 отдельных монолита.
В реальном большом бизнесе границы настолько размыты, что выделять контексты архитектор будет первые полгода. А потом после пары месяцев разработки, пойдет переделывать потому что на самом деле все не так.

Ну это и печально, когда бизнес не хочет или не может объяснить как он работает — архитектору приходится придумывать свои схемы. Натягивание совы на глобус никогда не бывает гладким.
В прилично же раскроенных микросервисах разработка намного проще и быстрей


за счет чего? Допустим мне чтобы вмёржить 100 строк кода, надо пройти ревью в трёх репозиториях. Быстрее разрабатывать отдельный микросервис который ни от чего не зависит, но интегрироваться намного медленнее.
Если вам нужно мерджить в 3 репозитория, то скорей всего у вас таки проблемы с границами.
Обычно вы работаете с одним сервисом и до тех пор, пока не рушите его АПИ, вы ничем не ограничены.
Если вам нужно мерджить в 3 репозитория, то скорей всего у вас таки проблемы с границами.
Обычно вы работаете с одним сервисом и до тех пор, пока не рушите его АПИ, вы ничем не ограничены.


на активной фазе разработки апи тоже часто меняется, а ещё есть контракты которые тоже надо обновлять, ещё есть общие подпроекты
Начинать с микросервисов (особенно если вы только ищете свой продукт и не ясно что в итоге получится) такая себе затея.
Еще раз, микросервисы — это о масштабировании разработки. У вас есть продукт с работающей экномикой, у вас есть понимание куда и как вы хотите расти, у вас растет команда и люди начинают мешать друг другу. Вы хорошо понимаете как работает ваш продукт, где в нем проходят границы бизнесс-процессов и что из него можно вынести в независимый сервис (да еще и в перспективе переюзать этот сервис в других своих продуктах) и вы постепенно распиливаете монолит на сервисы.
Начинать с микросервисов (особенно если вы только ищете свой продукт и не ясно что в итоге получится) такая себе затея.
Еще раз, микросервисы — это о масштабировании разработки. У вас есть продукт с работающей экномикой, у вас есть понимание куда и как вы хотите расти, у вас растет команда и люди начинают мешать друг другу. Вы хорошо понимаете как работает ваш продукт, где в нем проходят границы бизнесс-процессов и что из него можно вынести в независимый сервис (да еще и в перспективе переюзать этот сервис в других своих продуктах) и вы постепенно распиливаете монолит на сервисы.


это всё понятно. Я говорю с точки зрения девелопера, и какие у этого есть проблемы. Например есть проблемы когда нужно интегрироваться, а если нужно сделать вещь которая затрагивает 10 микросервисов, то нужно общаться с 10ю командами, делать пулл реквесты или вынуждать это делать эти команды. Это не так просто.

Начинать с микросервисов (особенно если вы только ищете свой продукт и не ясно что в итоге получится) такая себе затея.


микросервисы могут активно меняться и интегрироваться с другими не только во время распилов монолита или переходов. Мне кажется вы рассуждаете «паттернами идеального мира» где всё происходит прям как в какой-то книге написано.
Если у вас задача, которая требует изменения в 10 сервисах, то в случае монолита это будет точно такое-же большое изменение, обсудить которое вам придется все с теми же людьми с теми же проблемами. Но большинство задач не такие, в большинстве случаев вы будете работать только с одним сервисом, который по сравнению с монолитом гораздо меньше (проще держать в голове контекст происходящего и возможные последствия изменений).

По поводу изменений в сервисах, да может быть такое, что нужно что-то менять. Но снова, не нужно добавлять в сервис новые обязанности, только потому, что на первый взгляд не понятно кто должен эту новою работу выполнять. Придерживайтесь того же SRP, Low coupling/High cohesion как и при написании кода, делайте сервисы слабо связанными и сфокусированными на одной бизнес-задаче и не создавайте себе дополнительных сложностей.

ИМХО, вполне допустимо сделать новый сервис, который будет делать какую-то очень тупую и специализированную работу. Обычно в команде есть какая-то заготовка для быстрого старта сервиса. Реализуйте необходимое в новом сервисе и посмотрите как это интегрируется с вашей системой. Выбросить такой сервис намного безболезненней чем выпиливать что-то из монолита.
Реализуйте необходимое в новом сервисе и посмотрите как это интегрируется с вашей системой.
Выбросить такой сервис намного безболезненней чем выпиливать что-то из монолита.

Вот эту самую интеграцию и надо выпиливать в обоих случаях. Нет большой разницы, выпиливать вызов service->method() или httpClient->request('GET', 'service/method').

В больших командах разница есть. В теории никто не мешает писать монолит так, чтоб модули пересекались по минимуму, но на практике чем больше проект и больше команда — тем чаще срезаются углы, растет coupling и вот это вот все. Сервисы же физически разграничены. Косячить тоже можно, но это трудней
По поводу изменений в сервисах, да может быть такое, что нужно что-то менять. Но снова, не нужно добавлять в сервис новые обязанности, только потому, что на первый взгляд не понятно кто должен эту новою работу выполнять. Придерживайтесь того же SRP, Low coupling/High cohesion как и при написании кода, делайте сервисы слабо связанными и сфокусированными на одной бизнес-задаче и не создавайте себе дополнительных сложностей.


открыл на днях Фаулера, его статью о микросервисах. В разделе «Микросервисы это будущее?» он пишет что пока рано говорить, т.к. сейчас недостаточно данных судить об успешной адаптации кроме тех. гигантов.
то что вы говорите, конечно верно, но проблемы отладки (более широко — удобства разработки), тестирования и особенно простоты интеграции остаются и пока что видятся фундаментальными ограничениями технологии как таковой, которые возможно нельзя обойти в принципе. Вот эти вещи «SRP, Low coupling/High cohesion» скорее облегчают жизнь, но интеграция и масштабный девопс никуда не деваются, потому что микросервисы это распределённая система со всеми вытекающими сложностями
Микро-сервисы намного проще разрабатывать чем монолит, как раз за счет сильно ограниченного контекста. Сервисы проще и меньше. Да, более сложный мониторинг и легче отстрелить себе ногу, если не думать что делаешь.
А так Jaeger \ DataDog вполне позволяют легко отлаживать систему в сборе. Отдельные же сервисы отлаживаются точно так-же как и монолитные приложения.
Микро-сервисы намного проще разрабатывать чем монолит, как раз за счет сильно ограниченного контекста.


отдельный микросервис проще разрабатывать чем монолит, а всю систему — сложнее.

А так Jaeger \ DataDog вполне позволяют легко отлаживать систему в сборе


это разве отладка? Дистрибютед трейсинг это разве тоже самое как если бы я поставил точку останова в приложении?

Отдельные же сервисы отлаживаются точно так-же как и монолитные приложения.


чтобы запустить локально, нужно воссоздать на локальной машине не только сам сервис но и другие сервиса с которым этот микросервис общается. А ещё это могут быть AWS ресурсы, не на все из которых есть докер аналоги. И даже если это возможно, это куда более накладно. Ничего себе «точно так же» ))
отдельный микросервис проще разрабатывать чем монолит, а всю систему — сложнее.

это разве отладка? Дистрибютед трейсинг это разве тоже самое как если бы я поставил точку останова в приложении?

Если ваши сервисы хорошо изолированы, то чаще всего вы и работать будете с одним. И поставить точку останова вы сможете. К сожалению очень часто путают (микро-)сервисную архитектуру и распределенный монолит. А трейсинг как раз поможет понять в каком из сервисов искать проблему.

чтобы запустить локально, нужно воссоздать на локальной машине не только сам сервис но и другие сервиса с которым этот микросервис общается. А ещё это могут быть AWS ресурсы, не на все из которых есть докер аналоги. И даже если это возможно, это куда более накладно. Ничего себе «точно так же» ))

Не завязывайтесь на 3rd-party напрямую и не будет проблем. В крайнем случае вы сможете напилить свой адаптер для локальной работы, если вендор не предоставляет такой возможности.
Ну и вовсе не обязательно поднимать локально все сервисы, общепринятая практика поднимать контейнер только с одним сервисом, а все остально брать с dev окружения.
Если ваши сервисы хорошо изолированы, то чаще всего вы и работать будете с одним. И поставить точку останова вы сможете. К сожалению очень часто путают (микро-)сервисную архитектуру и распределенный монолит. А трейсинг как раз поможет понять в каком из сервисов искать проблему.


и что покажет трейсинг? что какой-то сервис в цепочке вернул 500-ку или 400-ку? А если они вернули 200 но результат неправильный? Трейсинг это же не дебаг ) А в логах могут не печататься респонзы ) А причина неправильно посчитанного значения может быть как в одном сервисе так и в нескольких и даже в их взаимодействии. И чтобы это понять, нужно реально продебажить. Ну или добавлять логи в несколько сервисов и деплоить и смотреть )
Вы упорно делаете вид будто бы отладка системы из кучи компонентов и связей между ними это тоже самое что и отладка одного приложения. Так это же просто неправда, и что мы тут обсуждаем вообще?

Вы можете дебажить и несколько сервисов. Это менее удобно конечно, но эта возможность есть.
Из своего опыта скажу, что такой необходимости у меня не возникало, обычно все ограничивается одним сервисом
Вариант — половина кода в монолите, половина — в микросервисах не рассматривается? В любом проекте полно кода, которые так и просятся в микросервис
ИМХО, это наиболее вероятный исход. С монолита по чуть-чуть выпиливают независимые части, когда становятся ясными их границы
Недавно общался с человеком (на собеседовании), который сказал, что они пытаются перейти на микросервисы потому что джанго орм не справляется с их сложными запросами. Не вдаваясь в дебри (а тут возникает очень много вопросов) выяснилось, что ребята не знали про то какие существуют эффективные способы хранения деревьев в базе данных. В итоге они думали, что именно микросервисы им помогут справиться с нагрузкой.
чем больше людей тем хуже показывают себя монолиты в частности при мерже наступает локальный ад
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
Местоположение
Россия
Сайт
www.ontico.ru
Численность
11–30 человек
Дата регистрации

Блог на Хабре