На конференциях эта тема (монолит vs микросервисы) обсуждается с завидной регулярностью, но обычно в техническом ключе. Кто-то любит консистентность монолита, кто-то гибкость микросервисов, какие-то инструменты удобнее, какие-то нет.
Очень мало обсуждается вопрос команд и их взаимодействия, а ведь это самое главное при выборе. Я написал небольшую заметку в одном телеграм-канале, и в результате последующих обсуждений незаметно выросла целая статья на Хабр.
Поехали.
Итак, главное — это организационная структура компании и процессы взаимодействия команд. Да-да, как всегда, не технологии, а люди. Сейчас я работаю в Каруне, до этого работал в компаниях поменьше, видел, как набивались шишки, поэтому могу сравнить.
Одна команда
Когда команда одна, не очень большая (two pizza team), то никто никому не мешает. Код ревью, рефакторинг, деплой проходят быстро и весело. Бизнес сфокусирован на цели и работает как единое целое. Целью, кстати, зачастую является проверка гипотезы, нужен ли вообще этот проект кому-то или нет.
Для одной команды нет большого смысла дробить программу на части: пусть это будет один бинарник (или набор php-файлов), который билдится из одного репозитория. С одной единственной базой данных. Разделение кода на несколько полностью независимых логических единиц со своими хранилищами будет тормозить процесс, не давая никаких преимуществ.
В монолите очень просто писать код, дебажить, тестировать и т.д. — всё перед глазами.
Единственное, что лучше сделать — это внутри монолита поддерживать хотя бы какую-то модульность, чтобы в будущем было легче это отделять. И в данных тоже: хотя база одна, никто не мешает сделать несколько схем (термин PostgreSQL).
Две-три команды
Команда разработки рано или поздно вырастает и вынуждена разделиться на две, иначе ей будет слишком сложно управлять. В правильной организации команды делятся не по технологиям (а-ля фронтенд и бекенд), а по бизнес-направлениям.
Чтобы две разные по смыслу команды могли работать быстро и эффективно, им необходимо разделить все процессы. Они не должны согласовывать действия друг друга по каждому чиху: ждать чьего-то рефакторинга, смены фреймворка, апрува другого лида, ожидания билда, тестов, деплоя, и бог знает чего. Надо откатить что-то — откатываешь и не боишься конфликтов в коде. Надо накатить — накатываешь в любой момент.
Я абсолютно уверен, что это возможно только тогда, когда код этих команд полностью независим, базы данных независимы, а билд и деплой идут в отдельные приложения.
Это уже можно назвать микросервисами, но с большой-пребольшой натяжкой. Скорее, это сервисы. Пока ещё нет ни смысла, ни возможности дробить программы на совсем уж мелкие части, потому что это несёт дополнительные расходы. Даже если очень хочется.
Пока что управлять кодом, тестировать и деплоить очень легко. Не нужен даже никакой kubernetes, нужен лишь достаточно бородатый админ.
Дофига команд
Когда команд много, они, разумеется, также должны быть независимыми друг от друга, чтобы time-to-market был минимальным. Это ключевой момент, и он остается неизменным с самого рождения проекта и до самого его конца. При этом в полный рост встают такие проблемы, как:
- А как нам сделать тестовое окружение, чтобы посмотреть на этот зоопарк полностью или частично (сэкономить ресурсы)
- А как нам создавать и потом управлять таким количеством баз данных
- А как нам поддерживать актуальную документацию всех API и взаимодействий через Kafka
- А не надо ли нам сделать отдел солюшн-архитекторов, которые будут способны разобраться, где чьё, и куда
- А как насчет единой системы логирования, метрик и трейсинга
- А не надо ли сделать генератор бойлерплейта для нового сервиса
- А если всё упадёт, как найти того, кто это всё будет чинить
- Ой, а фронтенд тоже надо делить на независимые части, иначе команды ждут друг друга
Обычно появляется ещё одна, особая, платформенная команда, которая пытается упростить всё, что можно.
И вот когда сервисов много, и всё поставлено на промышленные рельсы, тогда можно дробить код на логические части как угодно: хоть по микросервису на каждый бизнес чих. И это начнёт приносить свои плоды:
- Никакой DDD и прочие заумные практики разработчикам уже не нужны (микросервисы и так обеспечивают bounded contexts), на код ревью тоже не будет много споров из-за неправильных абстракций, ведь там скорее всего будет лишь несколько эндпоинтов и пара табличек. Качество кода, если честно, становится вообще не особо важным, лишь бы работало и было протестировано. Навороченные многофункциональные фреймворки не нужны. Поэтому, кстати, для микросервисов очень популярен язык Go — работает быстро, памяти ест мало. Да, крутых абстракций нет — но в микросервисах не очень-то и надо.
- Баз данных много, но они очень просты. Если база падает, то сразу понятно, почему.
- Редко, когда больше 1-2 человек работает над одним и тем же кодом, поэтому merge-конфликты — большая редкость.
UPDATE про DDD: Я имею в виду, что в случае микросервисов разделение предметной области на подобласти больше не делается в коде, а продумывается на уровень выше. Больше не нужно поддерживать дисциплину в коде одного приложения, чтобы разделять там логику на части. Если взаимодействие между микросервисами продумано, то сам код каждого из них тривиален
Что будет, если поступать наоборот
Если начать с микросервисов в компании из трех человек, то сразу нужно пилить много инфраструктурных и организационных моментов, перечисленных выше. Т.е. дело не в том, что лучше выбрать, кубер или другое решение, дело тупо в цене: много, много, очень много работы без малейшего бизнес-результата. Вся команда только этим и будет заниматься.
Если не перейти на микросервисы в огромной компании, то у вас будут миллионы строк кода в одном приложении, базы данных адового размера, над которыми ночами чахнут десятки дба, а главное — выкатить и откатить код будет прям событием, как спуск Титаника на воду. 100% будет навороченная система управления ветками и фича-флагами, в которой фиг разберешься. Т.е. код-то писать просто, но на проде ему появиться очень сложно.
Взять хотя бы VK. Я честно не понимаю, как они работают, у них вся логика в одном монолите на KPHP (около 8 млн строк, насколько я слышал), который компилируется в С++, который тоже, блин, надо компилировать! Т.е процесс долгий и непростой. А что если надо откатить баг, а за это время 100 человек уже написали овердофига нового кода? Что откатывать, что нет? А что если надо выкатить хот фикс, чтобы устранить дыру в безопасности? Сколько это займёт, полдня? Ребята из VK, поделитесь плиз, как вы это делаете, какой у вас time-to-market?? Ну очень любопытно.
Исключения
Бывают, конечно, исключения, как и везде. Иногда сразу ясно, что какая-то часть системы должна быть отдельной, и иначе никак. Например, если делаете рекламную сеть, то панель управления рекламными кампаниями и собственно система показа рекламного баннера, скорее всего, сразу должны быть двумя отдельными сервисами. Просто потому, что рекламный баннер точно будет хайлоад системой, иначе в нём никакого бизнес-смысла вообще нет.
Еще слышал про кейсы с ERP системами, где констистентность настолько важна, что разделять на микросервисы получится просто намного дороже, если вообще возможно.
Вывод
Бизнесу практически всегда нужен хороший time-to-market — отсюда всё остальное и вытекает. Микросервисы, необходимые технологии, независимость команд, и так далее.
Комментарии (61)
Leetc0deMonkey
11.07.2023 11:36+13Ждём Windows и Linux на микросервисах. А то выросло поколение, не понимает как можно успешно разрабатывать огроменные монолиты в тысячи разработчиков. Магия какая-то, не иначе!
TsarS
11.07.2023 11:36+1Ну всегда можно сказать, что Windows или Linux это просто один большой микросервис, а не монолит)
varanio Автор
11.07.2023 11:36Leetc0deMonkey
11.07.2023 11:36+23И? Монолит, если что, это не свалка неструктурированного говнокода, где разработчики толкаются локтями и у них постоянные мерж-конфликты. Монолит точно так же разбивается на модули, изоляции, и прочие сферы ответственности. Монолит, если что, это не "гигантский экзешник", который компилится 3 часа "где-то там на сервере сборок". Монолит точно так же разбивается на библиотеки/сборки, которые собираются отдельно и легко могут подменяться на лету когда надо. И, (шок!), эти модули могут даже выполняться на сторонних машинах, в т.ч. координироваться брокерами сообщений и балансировщиками нагрузки. С т.з. разработки разницы между монолитом и микросервисами, вобщем-то, нет никакой. Но, как оно обычно бывает в айти, взяли старые концепции, намарафетили, и продают теперь под новыми названиями.
creker
11.07.2023 11:36Если отдельный модули исполняются на разных машинах, то это, по определению, уже не монолит. Монолит это именно что огромный клубок кода, который компилится хер знает сколько. Это все естественно разбито на модули, библиотеки. Используются билд кэши и прочие оптимизации, чтобы инкрементальный билд в большинстве случаев эту проблему сгладил, если у нас компилируемый язык какой-то. Но по итогу это все равно огромная пачка бинарей, которая деплоится и запускается целиком на одной машине.
Разработка именно что отличается кардинально между этими подходами. Именно по этой причине во многом микросервисы рождаются из масштабов не только приложения, но и команды.
Так что это у вас скорее какие-то странные понятия монолита и микросервисов.
shashurup
11.07.2023 11:36+17>Компилится хер знает сколько
Меня вот, если честно, всегда это веселит. Компилятор, вообще, за нас делает кучу работы по проверке кода. Эту работу, при растаскивании монолита на микросервисы часто, в итоге, приходится делать каждый раз "руками" (в смысле головой), о чем, как правило, на этапе растаскивания никто не думает - волшебное слово "микросервис" оно ведь даже лучше чем "пожалуйста", все контракты после этого начинают соблюдаться автоматически :)
Leetc0deMonkey
11.07.2023 11:36+6Если отдельный модули исполняются на разных машинах, то это, по определению, уже не монолит.
А если этот модуль - сетевая СУБД? Десктопный клиент на Делфи значит уже не монолит?
Разработка именно что отличается кардинально между этими подходами. Именно по этой причине во многом микросервисы рождаются из масштабов не только приложения, но и команды.
Вот я и задаюсь вопросом, как же тогда 20-30-40 лет назад писались программы? Они были маленькими и простыми? Побольше и посложнее типичного инет-магазина. Или в 2020ых команда из 10 разработчиков вдруг решила что она "масштабная", и микросервисы это спасение в таком "огромном" коллективе?
Так что это у вас скорее какие-то странные понятия монолита и микросервисов.
Они не странные, они общепринятые. Странно натягивать принципы модульной разработки и разделения ответственности, принципы распределенных приложений, которым 30 с лишним лет, на модное современное понятие микросервисов. То что называют микросервисами это лишь разновидность того что называют монолитом. А не какое-то сакральное откровение и эпохальный прорыв в принципах коллективной разработки.
thevlad
11.07.2023 11:36-1Разница вроде бы довольно очевидна. Чтобы обновить монолит надо обновить какой-то бинарник на всех инстансах. Чтобы обновить микросервис надо обновить один сервис. Это помимо возможных потенциальных плюшек в виде более простой масштабируемости и отказоустойчивости.
Да и для начала хорошо бы определится, что такое "монолит", а то так можно любой дистрибутив линуха монолитом назвать. Вот вам и ядро монолитное, и процессы разные, но они ведь тоже на принципах модульной разработки и разделения ответственности основаны, значит и это все "монолит".
Опять же если не считать все "монолитом", то самая разумная аналогия, это когда мы считаем, что механизмы межпроцессного взаимодействий(IPC) ОС внутри одного инстанса, заменены на сетевые.
Goron_Dekar
11.07.2023 11:36+1А если не бинарник? Если это скриптовый монолит, и для его обновления надо править скрипты на всех инстансах? А если не скрипты, а конфиги?
Как и во всем в этом мире, грань между "монолитом" и "микросервисами" размыта. И любой проект при поспешном росте (а другого сейчас нет) сваливается в эту серую зону, где вроде бы и модули/сервисы разделены, и архитектура описана, и ответственности между командами поделены, но иногда надо поправить что-то во всех инстансах.
slonopotamus
11.07.2023 11:36+7Чтобы обновить монолит надо обновить какой-то бинарник на всех инстансах. Чтобы обновить микросервис надо обновить один сервис.
Чтобы обновить монолит, надо обновить один бинарник на всех серверах где он крутится. Чтобы обновить микросервис, надо обновить один бинарник на всех серверах, где он крутится. Да ваш микросервис - монолит!
KReal
11.07.2023 11:36А если этот модуль — сетевая СУБД? Десктопный клиент на Делфи значит уже не монолит?
Получается, что нет, а просто "клиент" в клиент-серверной архитектуре. И мы можем как выкатить новую версию клиента, не трогая сервер БД, так и обновить сервер, не трогая тысячи клиентов.
Leetc0deMonkey
11.07.2023 11:36+2Вот так и приходим к тому что нет никаких монолитов и микросервисов. Есть только правильно спроектированное приложение, и неправильно.
sved
11.07.2023 11:36+2Одно из главных недостатков микросервисов - это крайне неудачное название и отсутствие чёткого научного определения термина.
Мне кажется логично определить так: микросервис - это сервис, который "владеет" одним или нескольким хранилищем и является единственной точкой входа к этому хранилищу. То есть в БД никто кроме этого сервиса не лезет.
Отсюда очевидны как недостатки (проблема с производительностью и консистентностью), так и преимущества (возможность кэширования и обновление БД без оглядки на другие команды) данной архитектуры.
vlad4kr7
11.07.2023 11:36+1миксросервису не обязательно ходить в базу. Он может работать с другими сервисами, в том числе и "внешними", как адаптер или мультиплексор
creker
11.07.2023 11:36Современные ОС и так, по сути, микросервисные. Кругом службы, которые переплетены между собой IPC механизмами. Уж какие-нить macOS и iOS точно. Там на mach ports и всяческих надстройках над ними вроде XPC держится буквально все.
panzerfaust
11.07.2023 11:36Т.е. код-то писать просто, но на проде ему появиться очень сложно.
У меня противоположный опыт. Количество умельцев организовать красивую архитектуру сервиса прям скажем невелико. Поэтому виденные мной монолиты были хрустальными вазами, балансирующими на краю стола. Писать там код нифига не просто. Бывает, что даже либу обновить для фикса CVE - это уже эпик на 2 недели. А уж джаву апнуть с уютной восьмерки - это вообще "давайте в следующем году".
varanio Автор
11.07.2023 11:36ну значит у вас была дикая зависимость между микросервисами, а значит это не микросервисы, а что-то другое
hlogeon
11.07.2023 11:36+1Хорошо, что написали статью. Полностью согласен. Имею опыт и в крупных компаниях с десятками команд и в быстрорастущих стартапах и в совсем молодых. Польностью согласен с мыслями. Сколько стрел и мечей уже было сломано в спорах с бизнесом и коллегами на эту тему.... Про DDD, конечно, жирненько получилось, если не читать комментарии, можно и не понять мысль
varanio Автор
11.07.2023 11:36сам уже пожалел, что упомянул ddd
Kopilov
11.07.2023 11:36Это data driven development или что-то другое?
cross_join
11.07.2023 11:36На выбор:
- Design Develop Destroy (выкрасить и выбросить)
- Davai Davai Davai (Go, go, go !)
- Damn Dumb Domain (программист-бухгалтер)
shashurup
11.07.2023 11:36+4Вообще, как по мне, основная мысль здесь вообще не про микросервисы а про следствие одного давно озвученного наблюдения о том, что структура кода очень часто согласуется с организационной структурой проекта. И это не следствие какого-то волшебного и контринтуитивного эффекта - при повторении в коде орг структуры (ну или наоборот, при структурировании организации вокруг кода) проще эффективно организовать работу. Никто не любит тратить время на всякие согласования между подразделениями и, в итоге, модули в коде имеют тенденцию максимально изолироваться, что ускоряет разработку и поставку фич. Само собой, иногда и перегибы случаются и мы получаем странных кентавров с невнятнымы АПИ, но тут ведь не только деление на модули определяется орг структурой, но и наоборот тоже и результат получается вполне сносным.
PuerteMuerte
11.07.2023 11:36+1А что если надо откатить баг, а за это время 100 человек уже написали овердофига нового кода? Что откатывать, что нет? А что если надо выкатить хот фикс, чтобы устранить дыру в безопасности? Сколько это займёт, полдня?
Это больше вопрос конкретно модульности, нежели "микросервисности" как таковой. Микросервисы, это всего лишь один частный способ обеспечивания модульности. Модульное приложение, когда его различные компоненты разрабатываются разными командами, но имеют между собой согласованные и стабильные контракты взаимодействия, в общем случае сопровождаются точно так же относительно легко, как и микросервисы.
thevlad
11.07.2023 11:36Как по мне микросервисы это и есть модульность для вэба. Если бы можно было раскатать все на небольшое количество инстансов, то эту модульность вполне можно обеспечивать другими стандартными средствами. Но если надо раскатывать все на много инстансов, модульность через микросервисы становится просто удобнее и эффективнее.
PuerteMuerte
11.07.2023 11:36+3Как по мне микросервисы это и есть модульность для вэба.
Микросервисы - это очень высокоуровневая модульность. Я вряд ли ошибусь, если скажу, что в даже в большинстве случаев, где есть микросервисы, модульность можно было обеспечивать с намного более тесной связностью модулей и намного меньшим оверхедом.
Но если надо раскатывать все на много инстансов
Понимаете, тут подвох в том, что микросервисы, это не про горизонтальное, а про вертикальное масштабирование. Это вообще лютая подстава с их стороны. Простой пример: вот у вас есть что-то продающий сайт, у него есть микросервис авторизации, есть микросервис просмотра каталога, есть микросервис заказа, есть микросервис оплаты. На вашем очень хорошем сайте стопицот посетителей в день, и у вас на авторизацию ложится стопицот запросов, также стопицот запросов на сервис каталога, и (спасибо воронке продаж) всего лишь пицот на заказы, и сто на оплаты. Вы-то, конечно, можете их по инстансам раскидать, но... у вас любой клиент, прошедший весь путь до оплаты, будет юзать все четыре инстанса последовательно. Вы
ничего не выиграетенехило так проиграете по производительности и по пожиранию вашего баланса облачным провайдером в сравнении с монолитом, который запущен в нескольких инстансах, где каждый инстанс обрабатывает только какого-то одного своего клиента, закинутого на него балансировщиком.thevlad
11.07.2023 11:36Как по мне приведенный пример это как раз и есть про "несколько инстансов". В общем, случаи если у вас есть один сервис который дает 100 RPS, и 4 последовательных сервиса дающих 100 RPS, то на то и выйдет за минусом сетевого оверхеда. Вопрос лишь в том, что обычно микросервисы выполняют меньше работы и более специализированы, и могут быть проще оптимизированы.
Второй вопрос, это деплой монолита, если микросервис может быть обновлен, при условии сохранения обратной совместимости, усилиями одной команды, то с монолитом на тысячу инстансов это уже проблема. Да и предсказуемость лучше, когда старые сервисы постепенно выводятся и заменяются на новые.
BugM
11.07.2023 11:36Любой сервис на тысячу инстансов это сложно. И не важно как вы его сделали.
У микросервисов на самом деле есть проблема умножения РПС. Наиболее микросервисные штуки умудряются довести коэффициент РПС до 50. Может бывает и больше, но я только 50 видел.
И потом получаем мужественную борьбу с десятком тысяч РПС. А откуда он взялся вообще непонятно никому. На балансерах в которые идут пользователи видны нормальные сотни РПС.
thevlad
11.07.2023 11:36+1До микросервисов надой пройти путь, а вернее дорасти. Большие проекты не просто так пришли к этой концепции, потому что кому-то захотелось поиграть в абстракции и поупражняться в архитектуре. А то что, это превратилось в карго культ, и любое Рога&Копыта - хочет так же, хотя им это и не нужно. Да это объективный факт, с этим трудно спорить.
Leetc0deMonkey
11.07.2023 11:36+2До микросервисов надой пройти путь, а вернее дорасти.
Ну вот я 20 лет в индустрии, занимался тем что называют сейчас микросервисами, когда они назвались distributed, DCOM, CORBA и всё такое. Но я не дорос, а 20 летний синьйор, для которого модульность монолита это откровение (а что, так бывает? и без мерж-конфликтов?) - он дорос, да.
Большие проекты не просто так пришли к этой концепции
В том-то и дело что вы не Гугл. Микросервисы действительно имеют свою нишу где swarm load balancing начинает приносить выгоду. Но это точно не уровень типичного интернет-магазина.
UserAd
11.07.2023 11:36Зато в резюме смотрится внушительно "сервис с нагрузкой 100500RPS", правда на самом деле это оказывается 100RPS в базарный день от клиентов, но у нас же 50 микросервисов обменивающихся информацией и производящих синхронизацию данных.
Видел решение когда на каждое изменение в микросервисе юзеров всем остальным рассылался апдейт данных на случай если они у себя что-то меняют. Было около 20 подписчиков каждый из которых был запущен в нескольких экземплярах для надежности.
Politura
11.07.2023 11:36Во-первых, для поддержания оной модульности в монолите нужна очень сильная рука, ибо без нее у разных команд периодически будет стремление сделать как проще, особенно когда сроки горят. Во-вторых, все монолиты, с казалось-бы красивой модульностью что я видел, в них модули в итоге все работали с одной базой данных. Да, есть слой бизнес-логики, разбитый на отдельные модули, есть слой работы с базой данных, разбитый на модули, но база данных одна. А приводит это к тому, что разные модули работают с одними и теми-же таблицами. Есть всякие красивые запросы на много таблиц, ну а что, клево-же, очень быстро, достаем все данные. И как итог, все равно высокая связанность. Надо добавить поле в базу данных - в любом случае весь монолит надо прогонять всеми-всеми тестами, ибо может вылезти боком в неожиданном месте.
Микросервисы же изначально делают так, чтоб каждый сервис работал со своей базой данных и никого туда напрямую не пускал. Как итог, все эти обновления когда надо что-то поменять в структуре данных, проходят гораздо быстрее и легче. Ну если не пилить на совсем уже микро-микро сервисы, тогда появляются отельные головные боли с распределенными транзакциями. Вообще, на мой взгляд, микросервисы должны быть не слишком мелкими, довольно крупными.
Теперь дальше проблемы монолитов с модулями: одной команде надо переехать на новый фреймворк. А остальным не надо. Начинается бодание. Потом головная боль, когда все переезжают к определенному сроку. Одной команде надо обновить СУБД. А какой-то другой команде очень надо оставаться на старой. Опять головная боль.
Ndochp
11.07.2023 11:36Не знаю как там в большом программировании, а в 1С чем дальше тем больше бьют по рукам пытающихся работать с объектной моделью. И всех загоняют в табличную. Где да, "всякие красивые запросы на много таблиц" которые отдаются в нормальную СУБД, которая на фильтрах, соединениях и выборках собаку съела и быстро отдает результат.
А идеи "а давайте выдернем табличку с фильтром, потом результат отдадим как фильтр в выборку из другой таблички, потом соединим на клиенте с выборкой из третьей" остались в конце девяностых или даже раньше. Не надо оборачивать каждую таблицу в сервис и делать по сети десяток запросов эмулируя работу планировщика запроса СУБД. У вас это получится хуже, чем у профессионалов.Politura
11.07.2023 11:36Я и не говорил, что надо на каждую табличку свой сервис делать.
А так, в 1с еще с 90х был язык запросов, позволяющий работать с объектами. В 7.7 был, наверняка и в 7.5 был, но уже точно не помню. Если до сих пор он все данные тащит на клиента и там работает с ними, вынуждая вас работать с таблицами на прямую, когда нужна производительность то это очень печально. Для вас, как разработчиков. В мире не-1с обычно есть слой ORM, который преобразует запросы к объектным моделям в нормальный sql запрос который и выполняется в базе. Я очень люблю дотнетовский linq - язык работы с коллекциями объектов, вот он нормально ложится на sql, и даже если, для какого-то хитрого запроса orm не справляется - его можно расширить самому.
Ndochp
11.07.2023 11:36Нет, я не об этом. Я про то, что если у вас в каждом сервисе своя БД, то вы не можете построить эффективный запрос использующий данные из всех этих БД и будете изобретать свой планировщик запросов поверх микросервисов.
Ну то есть грубо говоря, сначала выберете все заказы на сегодня в одном микросервисе, потом схлопните этот список заказов до списка уникальных контрагентов, потом в другом микросервисе будет выяснять телефоны и контактых лиц контрагентов чтобы вывести менеджеру табличку, кому он должен сегодня звонить.
Вместо того, чтобы сджойнить таблицу заказов с таблицей контактной информации по контрагенту и уложить это в одно сетевое обращение к одной БД.
PuerteMuerte
11.07.2023 11:36Микросервисы же изначально делают так, чтоб каждый сервис работал со своей базой данных и никого туда напрямую не пускал.
Я не могу сказать, что это какое-то достоинство или недостаток, это просто особенность реализации, которая иногда может быть уместна, иногда нет. Хорошо, если микросервисы настолько модульные, что могут себе позвоить иметь разные базы данных. А если данные между собой имеют логическую связность? Ну, например, вот у нас есть микросервис филиалов, вот у нас есть микросервис заказов, микросервис клиентов. Заказы связаны с филиалами и клиентами, клиенты - с филиалами. Работая в одной базе, вы можете обеспечить целостность данных на уровне базы данных. Например, банально не дать удалить клиента, у которого есть заказы. Раскидав это по разным базам, ключей у вас больше не будет, контроль целостности данных вы будете обеспечивать самописными и весьма нетороплиывыми костылями, микросервис клиента будет дёргать микросервис заказов, проверяя, есть ли там заказы по текущему клиенту, чтобы разрешать или запрещать удаление, и т.д.
Politura
11.07.2023 11:36Ну я сразу и написал, что люблю сервисы по крупнее, по мне так если пара команд работает над одним сервисом, то это еще нормально. Хотя в любом случае, когда начинаешь нарезать на сервисы, без межсервисного взаимодействия не обойтись, но можно постараться нарезать так, чтоб такого взаимодействия было как можно меньше.
В целом же, серебряной пули нет, везде есть свои достоинства и свои недостатки, надо четко понимать, что делаешь и зачем именно, а не гоняться за хайпом.
ErshoffPeter
11.07.2023 11:36Вот и представьте, что у вас есть таблица клиентов, таблица заявок и таблица заказов и все микросервисы вашего приложения их используют - правильно я понимаю, что все эти три неслабых таблицы вы будете реплицировать между всеми микросервисами?
kalbas
11.07.2023 11:36+2Чтобы time-to-market был минимальным, нужно параллелизовывать работы как можно круче. Чтобы программистов привлекали к проработке задачи как можно раньше, чтобы программисты всех частей (бэк, фронты, хер знает кто еще) в первую очередь согласовывали между собой контракт, а потом уже начинали что-то делать, естественно параллельно, чтобы опсы заранее знали о крупных фичах и планировали инфраструктурные апгрейды под релизы как можно раньше, чтобы тестировщики начинали накидывать тест-кейсы когда задача спроектирована, а не когда разработка закончила, чтобы техподдержка так же была в курсе того, что ее вскоре ожидает, могла как-то к этому подготовиться, например внести какие-нибудь предложения по разработке дополнительного тулинга для них.
А микросервисы к time-to-market докидывают не так уж много, по сравнению с монолитом: простые миграции хранилищ, да возможность без лишних согласований завезти нужные версии инструментов и библиотек, это важно, но с этим сталкиваешься далеко не на каждой фиче. Возможность говнокодить в микросервисе и вовсе может сыграть злую шутку при его разрастании. MSA -- это не про размеры сервисов, это про микроинтерфейсы к сущностям и необходимый минимум ручек для каждой из них. Их может быть три-пять, но с таким адом внутри, что лучше было не говнокодить с самого начала.
cross_join
11.07.2023 11:36В правильной организации разработчики делятся на core platform и functional modules.
И весь этот горький катаклизм... микрокомпонентный хайп уже был минимум дважды. И дважды обходился дорого.
varanio Автор
11.07.2023 11:36Спасибо, почитаю, статья выглядит интересной.
Одна из целей писания на хабр - получение обратной связи через коменты. Мне не раз так вправляли мозги
Ps. Классный ник
alexxz
11.07.2023 11:36-1Кажется, автор никогда не работал над монолитами, но яростно их осуждает используя чужое мнение.
varanio Автор
11.07.2023 11:36кажется, лучше писать конкретные аргументы, чем делать странные предположения
alexxz
11.07.2023 11:36+1Справедливо. Единственный пример и аргумент автора в статье против монолита - "Я честно не понимаю". Так надо задавать вопросы, а не фантазировать как "десятки ДБа чахнут над перегруженными базами".
Монолиты в своей среде - весьма структурированы и разделяемы на модули (иначе бы просто не выжили). У каждого разработчика есть возможность заглянуть (в один клик) в код соседей и улучшить его и научиться новому (соблюдая кодекс чести). Каждый разработчик может всё и можно исправить за один чих кучу компонентов. И задеплоить их одновременно, а не синхронизировать работы в куче команд.
Касательно десятков ДБА, так в микросервисной среде их будет не меньше. Базы есть, присматривать за ними надо. А вопросы перегруженных БД - так это вопросы архитектуры проекта и модулей. В микросервисном подходе получить перегруженную БД ничуть не сложнее.
varanio Автор
11.07.2023 11:36изменить код соседей да, легко, а вот быстро сбилдить, прогнать тесты и выкатить - не получится, плюс потребует синхронизации с другими командами
Утрированный пример: если есть отдельный микросервис, с помощью которого можно поменять цвет кнопки, или там, комиссию чего-нибудь, то от идеи "поменяй на красный" до продакшена пройдет 10 минут. В случае монолита может быть что угодно: от просто долгого билда, до фриза всех фич пока "идет рефакторинг чего-то там" или работы с бд. Суть в том, что в монолите зачастую ты не можешь просто и быстро выкатить. С точки зрения доступности кода - да, монолит лучшеvaranio Автор
11.07.2023 11:36я имею в виду монолит большого размера, где 5-10 или даже 50 команд над ним работают
alexxz
11.07.2023 11:36В вашем утрированном примере подготовлена база, что цевет кнопки "зашит" в одном микро-сервисе. Попробую подыграть вам в вашем утрированном примере. А что если для изменения цвета кнопки надо знать платная ли у пользователя подписка, а информации о профиле в этом месте нет? То есть надо не константу поменять, а условие хождения к соседнему микросервису добавить, а в запросе про цвет кнопки даже user-id отсутствует...
PS не все языки программирования требуют компиляции. А тесты монолита делятся на модули в соответствии с делением кода.
varanio Автор
11.07.2023 11:36условие хождения к соседнему микросервису добавить,
зависимости бывают, конечно, бывают и на другие команды. Но очень часто бывает и без зависимостей: данные собирать из существующих топиков кафки, эндпоинтов и т.д. Очень важно тут разделение на доменные области, чтобы команда "владела" необходимыми микросервисами.
А в монолите по определению всё зависит от всего.PS не все языки программирования требуют компиляции. А тесты монолита делятся на модули в соответствии с делением кода.
если монолит такой, что можно быстро внести изменения в какую-то часть и выкатить за 10 минут, ни с кем вообще не согласовывая, то это ОК, микросервисы не нужны.
На практике же пока что не видел такого.ErshoffPeter
11.07.2023 11:36Представьте себе, что для изменения в таком монолите, например, достаточно перепрописать одну хранимую процедуру в общей базе данных (при условии, что её интерфейс не изменился) и всё встанет на своё место. Я пилит монолит в масштабпх банка (АБС) порядка 10 лет и каждую неделю выпускали по версии, при необходимости могли делать изменения ежедневно.
Leetc0deMonkey
11.07.2023 11:36А в монолите по определению всё зависит от всего.
Да не может в монолите всё зависеть от всего. Монолит это такие же микросервисы, но с теснейшей бинарной связью вместо сетевой. Что имеет свои преимущества. И недостатки.
PuerteMuerte
11.07.2023 11:36Утрированный пример: если есть отдельный микросервис, с помощью которого можно поменять цвет кнопки, или там, комиссию чего-нибудь, то от идеи "поменяй на красный" до продакшена пройдет 10 минут
В общем случае внести простое изменение в монолит по трудоёмкости занимает ровно столько, сколько и в микросервис. Ну потому что ответственная за модуль команда берёт и вносит это изменение, а потом просто собирают всё вместе и публикуют. Да, есть какой-то выигрыш собственно по времени публикации, но это делает бездушный робот, и в общем-то пофигу, десять там минут оно занимает или сорок. Фризить все фичи - ну как бы такой необходимости на современных системах контроля версий уже нет. Есть какая-то опубликованная текущая версия, в её ветку вносятся только протестированные и согласованные изменения. Т.е. мейнтейнеры сделали у себя, потом смерджились с идущей на публикацию веткой, ну и оно там пошло в прод.
Leetc0deMonkey
11.07.2023 11:36то от идеи "поменяй на красный" до продакшена пройдет 10 минут.
Вы правда считаете что это что-то хорошее? Даже если в монолите это можно сделать (а это действительно можно), то выкатывать в прод(!) не прошедшее все этапы согласований, тестирований и т.д... ну у меня просто нет слов...
TsarS
Мне казалось, что DDD это несколько больше, чем просто физическое разнесение архитектуры по сервисам.
varanio Автор
Если рассматривать код микросервиса, то дефакто всё DDD вырождается к правильному наименованию. Всё остальное идет на уровне архитектуры взаимодействия микросервисов и распределения их по командам.
RA_ZeroTech
Правило думали.
Микросервисы это обеспечивают как раз потому, что есть такие «заумные» практики как DDD. Которые и помогают понять, как разделить предметную область на подобласти, а их уже на сервисы.
varanio Автор
Я имею в виду, что в случае микросервисов разделение предметной области на подобласти больше не делается в коде, а продумывается на уровень выше. И это делается более явно, и это проще, чем поддерживать дисциплину в коде одного приложения, чтобы разделять там логику на части.
Т.е. наличие микросервисов - это и есть DDD
RA_ZeroTech
Верно, так и должно быть. Сначала идёт проектирование (DDD), а потом уже код.
Возможно, ошибочно сложилось впечатление, что от Вас посыл был несколько в обратном, что DDD не нужен. Хотя такая методология как раз и дает ответы на вопросы. Чтобы потом не приходилось переписывать код множество раз.
varanio Автор
добавил уточнение в статью