Обмен данными между микросервисами

Чтоб завести целый отдел под это и создавать иллюзию бурной деятельности. Ты как в первый раз

Покажите уже эти великолепные сложные продукты, которые вы пишите с рассуждениями про микросервисы и хайлоад.

Просто интересно, а то редко попадаются.

Ты увел все в сторону технички, а мой пойнт - микросервисы это про организацию процессов разработки и развертывания в условиях разграничения зон ответственности.

Разделение БД - только вершина. Понятно, что можно хранить в одной БД данные (да даже в одном неймспейсе, кто же запретит то).

Но там вопрос у автора: «Мы тут это, лазим к соседям в данные, чето неудобно становится, че делать? Мб напрямую в БД к ним лазить?»

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

PS По техничке спорить нет смысла, все сильно зависит от профиля нагрузки системы и SLA на эндпойнты.

возможность выборочного масштабирования частей системы.

К количеству команд это вообще не имеет отношения.

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

Не могу не согласиться со сроками, но таки вменяемому бизнесу, масштабирование и переиспользование готового кода тоже очень заходит, сокращение издержек сЭр ¯_(Oo)_/¯

архитектурной чухни

@

только у идиотов

@

прочая клоунада

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

flow данных удлиняется, и самое главное — «сайт начинает тормозить ШО *****» — и оно понятно, поди пройдись по десятку микросервисов, каждый сходит в свою БД, потом распарсь и перепакуй JSON и т.д. и попробуй не удесятерить latency (10 просто для красного словца).

Ля классик. В параллель на несколько сервисов отправить запросы как джва байта переслать а вот когда у тебя цепочка из 10 сервисов один из которых может оказаться проприетарной чОрной коробкой которая уже EOL или с политикой вендора «идите на***» то этого бревна предпочитают не замечать.

[1]: Не обязательно один физический инстанс БД. Партишининг и в т.ч. шардинг никто не отменял.

Без вертикального и/или горизонтального шардирования и например разделения экшнов на write/read и readonly (когда идемпотентный метод лезет в readonly реплику) независимо от архитектуры все встанет колом при большом объеме записей).

[2]: Существует множество историй успехов high-load на монолитах. Грамотное DBA и кеширование — ключ.

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

позволяет гибко масштабировать эти инстансы

никак не доходит природа удивительной популярности этой мантры.

Они ж не в вакууме. Им всё равно надо где-то данные брать. В чем соль запускать 1000 Питонов «в зависимости от нагрузки», если они все попрутся по одному и тому же каналу, в одну и ту же БД?

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

Они ж не в вакууме. Им всё равно надо где-то данные брать. В чем соль запускать 1000 Питонов «в зависимости от нагрузки», если они все попрутся по одному и тому же каналу, в одну и ту же БД?

Очевидно же, что основные тормоза тут будут не в бд.

Вообще неочевидно

Ты к тому, что если сервис на питоне, то и с бд какую-нить фигню наворотили?

Если по классике, то приватные REST методы. Если подумать, то вероятно тебе не нужны микросервисы. Они вообще мало кому нужны. Отличный пример это forgejo (монолит) vs sourcehut (микросервисы). Язык тот же, задачи те же, подходы разные.

давай я тебя отправлю в настоящее ММО, вот там весело с базой и это только самый тупой пример :)

а уж если оно на питоне написано макакой))))

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

По-разному бывает зависимо от архитектуры всего хозяйства

Сделать типовую апишку для каждого сервиса с его БД, или даже подключаться к базам соседних сервисов - это норма

Можно еще через какую-нибудь кафку реализовать взаимодействие, но вряд ли это будет проще - скорее для случаев когда нужна асинхронность

1. Вы так говорите, как будто масштабирование невозможно при монолите. Возможно и легко реализуемо.

2. «Переиспользование кода» в микросервисах тоже самое - не им изобретено, в монолитах переиспользование библиотек практикуется 100500 лет. А вот была шумная тема про переиспользование самих сервисов, НО кроме авторизации, я нормальных примером такого не видел. Всегда особенности и всегда приходится копипастить и примерно такое же, но всё равно другое.

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

Я для своего продукта выбрал монолит и горя не знаю +).

Им всё равно надо где-то данные брать. В чем соль запускать 1000 Питонов «в зависимости от нагрузки», если они все попрутся по одному и тому же каналу, в одну и ту же БД?

Я пришёл к выводу, что микросервисы придумали поставщики вычислительных «облаков», где возможности баз данных, сети, процессора и диска легко наращиваются или убавляются в зависимости от сиюминутных потребностей. В принципе, удобно придумано: пользовательская нагрузка прибавилась -> запустили ещё микросервисов, нагрузка от пользователей ушла -> отключили часть микросервисов. Монолит постоянно бы работал на полную, пиковую мощность.

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

Можно и монолит разными командами пилить, достаточно гитом раскидать подпапки, но зачем?

Зачем что? Монолит, разными командами или подпапки?

просто, зачем?

Самая лучшая это ЖТуча(JCloud). А вот REST API мы только для слива используем, или фонового обновления, или интеграции со сторонними сервисами. Так-то можно и rpc какой-нибудь, но там надо рекламу и обнаружение прикручивать.

Монолит постоянно бы работал на полную, пиковую мощность.

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

нагрузка от пользователей ушла -> отключили часть микросервисов.

Например микросервис авторизации, ага)

Чтобы!

Если два сервиса сильно связаны, их имеет смысл объединить в один.

А вообще, про микросервисы лучше всего сказано здесь: https://rsdn.org/forum/flame.comp/8472657.1