Монолиты и микросервисы: граница между ними

Тварь я быдлокодящая, или софтваре архитект?

У меня микросервисная архитектура или все еще монолит?

Тебе не пофиг какой ярлык вешать? =) Архитектура это то что закладывается ещё до существования чего либо, а не то что само собой вырастает. Если ты писал монолит, а получились микросервисы значит у тебя эмм гибкое кастомное решение подстраивающееся под актуальные нужны способное эволюционировать даже на уровне принципиально разных подходов как получилось так и работает, сегодня так, а завтра сяк. Это не плохо, но это не архитектура.

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

В принципе, да, смогу. Скажем, есть воркеры, которые не взаимодействуют с БД и не требуют дергания моделей из «монолита».

На ярлыки пофигу, это правда. Но любопытно попытаться сжать смысл в какое-то одно понятие.

У тебя пограничное состояние, код монолит, а программы работают независимо, программы работают независимо, но зависят от некого ядра общих подсистем. Архитектура построения программного комплекса/программы монолитная, архитектура работы программного комплекса подобна микросервисной. Химера

переписать на другом стеке технологий за относительно короткое время, существенно не меняя при этом остальной код

Так можно договориться, что и шаблон DI делает из монолита набор микросервисов. Если не обращать внимания на «другой стэк технологий».

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

У меня уже микросервисы или все еще монолит?

Микросервис - это прежде всего наличие своего API, ну или какой-то своей отдельной очереди входных заданий соответствующего формата. Ну т.е. это достаточно изолированный кусок прикладной логики с фиксированным внешним интерфейсом, который можно внутри править-сопровождать-ДЕПЛОИТЬ независимо от остальной части кода и, как правило, отдельными разработчиками. Разные микросервисы, в принципе, могут внутри использовать и какие-то общие вспомогательные библиотеки или фреймворки. Одно другому не мешает.

Маньяна и всё.

«Маньяна» это «сига-сига»?

как получилось так и работает, сегодня так, а завтра сяк. Это не плохо, но это не архитектура.

Схрена ли не архитектура? Как раз-таки:

гибкое кастомное решение подстраивающееся под актуальные нужны способное эволюционировать даже на уровне принципиально разных подходов

UPD. Блин, Ctrl+Enter случайно нажал. Так вот, вот это враньё:

Архитектура это то что закладывается ещё до существования чего либо, а не то что само собой вырастает.

Хорошая архитектура получается только в результате рефакторингов, т.е. эволюционно. «Большая работающая система всегда получается из маленькой работающей системы.» (c)

А вот с этим согласен полностью:

Тебе не пофиг какой ярлык вешать? =)

можешь ли ты один из своих воркеров переписать на другом стеке технологий за относительно короткое время

Микросервисы кмк про ограничение зоны ответственности, а не про размер

Смотря как посмотреть. Задачи откуда прилетают в очередь, юзер руками пишет? Тогда монолит. Откуда-то ещё? Микросервис. Размер значения имхо не имеет, есть ограниченная зона ответственности, чётко обозначенные входы и выходы, вот и всё.

А так это все слова, главное чтоб код был рабочий и понятный. Дальше хоть унитазом назови

Микросервисы и точки отказа.
вроде обсудили уже

Воркеры запускаются на разных машинах. То есть условный main-app запускается на трех тачках, а воркеры еще + на 6. Формально это один и тот же app, у которого даже один и тот же Dockerfile для сборки образа, но разные CMD в нем. Это если чуть больше технических деталей накинуть.

Задачи в очередь прилетают в процессе исполнения бизнес-логики. Например, юзер регается и ему нужно пульнуть два письма: подтверди почту и велкам-письмо. Задача может быть в формате {"email": "blabla@localhost", "user_id": "<UUID>", "category": "welcome-email"}. Далее ее подхватывает то, что рендерит письмо далее в очередь на отправку.

Либо, у юзера обновилось нечто, что требует выполнения цепочки действий: достиг определенного уровня аккаунта -> пересчитать какие-то данные -> проверить, что все ок -> пульнуть нотификации разного рода -> записать в лог. Отдельные операции могут быть параллельными (порой даже 3-4 независимых операции).

Когда что-то ломается, нужно ли тратить несколько часов на выяснение какой из компонентов виноват? Если нет, то ещё не микросервисы.

То ли у нас внятные ответы сервисов и обработка точек отказа решают проблему эту проблему, то ли правда еще не микросервисы =)

Cервис является микросервисом если у тебя микросервисная архитектура.

Как говорили классики: микросервисы как секс у подростков — все про них говорят, но ни у кого их нету.

У меня есть! Секс, не микросервисы.

Жесткого и четкого однозначного ответа, конечно, не будет.

В целом смысл микросервисов в кадровом разделении, за которым следует кодовое.

Т.е. люди собираются в кучку и отгораживаются от остальных своим API, которое они обеспечивают.

Когда весь код размазан на всех, то это уже не очень: в одном месте починили, другое отломалось. Просто оно запускается больше чем на одном сервере, вот и всё.

Когда на одного разработчика 20 микросервисов, а всего разработчиков 4 штуки, то я бы тоже не назвал это микросервисами, это просто плохо написанный проект, который глючит, тормозит и рассыпается.

Микросервисы — это такая бюрократия, от которой должно становиться менее больно, чем оно есть сейчас.

Если их все можно поочерёдно кильнуть без проблем, то это система на сервисах, но ещё не микросервисах.

Вырубаешь часть воркеров. Если есть смысл дальше функционировать, то не монолит. Если может работать n воркеров каждого типа, то вообще красиво. Если при этом можно грохнуть раббит, то ты совсем крут. А если при всём этом можно разобраться что в системе происходит...

Если при этом можно грохнуть раббит, то ты совсем крут.

Ты имеешь в виду, что раббит кластером запущен или что сервисы дополнительно хранят свою собственную историю/очередь?

Ну тут фишка же в том, что ты избавляешься от одной точки отказа, а в случае если все ходит через раббит, то он и есть эта точка. С кластеризацией там тоже не все так гладко как хотелось бы, да у нас он недавно в единичном экземпляре тихо подвисал без всякой видимой причины. Так или иначе задумываешься о том, чтобы делать систему действительно распределённой, раз уж в это влез.

У меня есть! Секс, не микросервисы.

Спалился, подросток %)

Ключевая особенность микросервисов — отдельная бд у каждого. Если это не так, у тебя монолит из кучи бинарников.

Ключевая особенность микросервисов — отдельная бд у каждого.

Аргументируйте.

гибкое кастомное решение подстраивающееся под актуальные нужны способное эволюционировать даже на уровне принципиально разных подходов

Нет-нет, так звучало гораздо лучше!

Пойду в маркетологи :D Свободная касса!

Совсем не обязательно должна быть БД у сервиса. Может быть сервису вообще не нужно ничего хранить.

который использует RabbitMQ и вокруг построено 10 разных воркеров

Это не микросервисы. Для микросервисов у каждого должна быть своя RabbitMQ (если это имеет смысл). А общаться они должны друг с другом непосредственно.

Разница в том, что в микросервисной архитектуре ты разделяешь компоненты по доменам (бизнес и иногда техническим). Как правило, каждый сервис изолирует данные, соответствующие его домену, и позволяют доступ к ним только через API (соответственно, авторизуя «пользователей»). Однако, изредка на это забивают болт и используют общую базу в целях оптимизации. Как именно ты делаешь API, будь то например Rest, GraphQL или pub/sub — не принципиально.

Я бы сказал, что у тебя уже микросервисы.

А как RMQ как event bus?

А общаться они должны друг с другом непосредственно.

Не должны. В event-driven системах общая очередь — это must, а сервисы напрямую не общаются вообще.

RMQ как event bus

Ну так у каждого сервиса должна быть своя event bus.

Ну так у каждого сервиса должна быть своя event bus.

Тогда это не будет ничем отличаться от REST. Смысл в том, чтобы сгенерировать сообщение, положить его в общую очередь, а там уже заинтересованные лица как-то отреагируют на него. То есть принципиальная разница в том, что при «отправке сообщения» ты не паришься кому его отправить. Ты просто говоришь как бы в космос.

Смысл в том, чтобы сгенерировать сообщение, положить его в общую очередь

С хрена ли очередь должна быть общая. Сервис кладёт свои события в свою очередь. А кто там подписался ему до лампочки.

А, в этом смысле. Почему бы и нет.

Смысл микросервисов в том чтобы иметь независимые друг от друга компоненты. Которые можно развивать в независимом темпе независимыми командами. Единственная точка пересечения это апи. Общая бд ломает всю независимость. Ты не можешь развивать свою схему — поломаешь другим всё. Нужно согласовывать релизы разных компонентов. В общем вернулись к тому самому монолиту.

Если сервис не использует БД, это хорошо. Речь про те, что используют.

В реальной жизни микросервисы не просто так запускаются, а совместно работают, трансформируя некое глобальное «состояние». Только теперь оно у вас не в одном месте в виде прозрачной и всем одинаково понятной схемы БД, а размазано тонким слоем по API, соглашениям вызовов и неформальным контрактам среди микросервисов. Так что пуризм это хорошо и красиво, но не всегда полезно.

А никто не говорил, что оно полезно. Проблем много разных вылезает. Это просто подход к построению архитектуры со своими плюсами и минусами. Использовать сервисы с общей базой это тоже подход, тоже со своими плюсами и минусами. Использовать монолит - то же самое.

Если кратко расписать, как я это вижу:

Монолит: легко начинать писать, до определённого размера оптимальный подход, легко масштабировать, не требуют выделенной инфраструктуры для логгирования и метрик, не требуют выделенной инфраструктуры для запуска (типа куба).

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

Микросервисы с разными базами: оптимальная архитектура для масштабирования, оптимальное распределение задач между людьми или командами, система перестаёт упираться при росте в отдельные компоненты.

Естественный путь развития ПО - из первого подхода к последнему. Начинать сразу с последнего можно, но это требует больших капитальных вложений (к примеру микросервисы невозможно представить в проде без нормальной инфраструктуры для сбора логов, метрик, трейсов).

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

Почему я придрался - все апологеты микросервисов подчёркивают, что база должна быть разная. Иначе это уже не то, что они называют микросервисами и «продают». Соблюдать терминологию считаю правильным. А так - сервисная архитектура и 20 лет назад была известна.

Микросервисы в том числе нужны, чтобы решать организационные проблемы. Когда команда контролирует всё, уйти от ответственности уже так просто не получится. База тормозит - а почему она тормозит, её же никто кроме вас не использует, решайте проблему с тормозами.