Как общаются микросервисы в реальных проектах?

Question

[Meised]

Знаю, что Rabbit MQ или Kafka используются для того чтобы гарантировать что запрос который куда-то ушел, вернет ответ. А как собственно реализуют общение микросервисов? Сделать для каждого сервиса свой сервер и кидать запросы через REST? Или использовать gRPC? Тогда на каком этапе подключаются брокеры сообщений? Или запросы как-то идут в брокер, а уже из него в нужные сервисы, как тогда это реализовывают?

Comments

[Jony2Good]

Все зависит от того, какую архитектуру нужно построить. Каждый проект может иметь свои особенности. И в коротком сообщении этого не описать. Слишком общий вопрос. По практике внедрения rmq можно построить общение микросервисов так, что они будут общаться только через брокер (EDD), как синхронно (request-reply) так и асинхронно. Опять же, чтобы приступить к этой работе нужно обладать пониманием работы микросервисов так как много подводных камней. Особенно когда начинаются не просто запросы типа дай это или дай то, а распределенные транзакции, оплаты заказов, доставки, бронирование и оплата такси и так далее. Нужно конкретизировать вопрос. Сейчас, по моему никому не нужному мнению, он слишком общий.

[Виктор Кожухарь]

Почитайте, например, про связку паттернов CQRS и Event Sourcing.
Тогда вы примерно поймёте, как это работает

Answer 1

[Сергей Горностаев]

По-разному, под каждую систему или даже под каждый сценарий взаимодествия выбираются свои способы. Довольно часто явление, когда внешнее API - REST, внутреннее синхронное - gRPC, асинхронное - Kafka.

Answer 2

[Everything_is_bad]

Как общаются микро-сервисы в реальных проектах?

вот через упомянутые тобой Rabbit MQ или Kafka и общаются, не понятна проблема.
Общая рекомендация, поучаствовать сначала хотя бы в создании монолита, а только потом можно будет смотреть в сторону микросервисов.

Comments

[Meised]

Как раз сейчас работаю над учебным приложением, сделал API для общения с клиентом, хотел узнать как в будущем сделать микро-сервисы.
Вопрос не по теме, не кидайте камнями. Сейчас у меня готова минимально рабочая версия сайта, стоит ли мне полностью её завершить, добавить тесты, кеширование, и прочие штуки. И уже полностью готовую версию сайта разделить на микро-сервисы?

[Everything_is_bad]

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

[Meised]

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

[Василий Банников]

Meised, нельзя сказать, стоит ли разделять на микросервисы, если нет требований.

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

[Drno]

Meised, лично мой совет - чем проще тем лучше
если для проекта нет смысла делить его на микросервисы - то этого делать ненужно

Answer 3

[Ипатьев]

Как правильно написал Сергей Горностаев, всё зависит от задачи.
Например, у вас маркетплейс, и в нем микросервис отзывов о товаре. Это совершенно некритичный функционал, и поэтому никакие очереди тут разумеется не нужны.
Фактически, фронт может даже напрямую к нему обращаться, и выводить заглушку, если отзывы недоступны.
Ну или внутри, при формировании страницы товара, код может дёрнуть микросервис и поставить заглушку, если тот недоступен. Дергать опять же можно по-разному, но для универсальности можно делать тот же REST, причём во внутреннем контуре даже без SSL (и его накладных расходов).

Брокеры же нужны там, где важна целостность. Например оповещения, по почте или СМС. Закинул оповещение в очередь, и дальше оно всё равно уйдет пользователю даже если конкретно в этот момент сервис отправки недоступен.

Answer 4

[Алексей Клестов]

Микросервисы ненужны.
А если нужны (нужна аргументация их полезности игнорируя маркетинг коучей по микросервисам) то ненжны очереди так как и без них два процесса смогут общаться по любому удобному протоколу ... http grpc и т.д.
Очереди нужны как удобный уровень абстракции от потребителя сообщения.
На практике - rest как удобный и читаемый человеком протокол.
Если просадки то переходим на уровень погеморойней grpc.
В общем усложнять себе жизнь все предпочитают поэтапно, если такое позволительно.

Comments

[Константин Казначеев]

Обоснуйте что они не нужны? Вы видимо не работали на реально высоко нагруженных проектах

[Алексей Клестов]

Люблю холивары.
Да ненужны. Если нет обоснованной причины их делать.
Слепо делать ради моды наивно думая что они магически что-то изменят и решат всё сами собой , глупо.
Микросервисы сами по себе не решают вопросы масштабируеемости и прочих красивых маркетинговых слов для впаривания клиенту за вкусные деньги.

[Steel_Balls]

Константин Казначеев,

Вы видимо не работали на реально высоко нагруженных проектах

Да-да-да...
А до изобретения микросервисов не существовало высоконагруженных проектов в начале 2000-х, да?

[Алексей Клестов]

Steel_Balls,
Скажу больше. В 90-х курсовые писал с распределенными сетевыми вычисленими.
Так на ход ноги студента.
И это до времени модных коучей что красиво впаривают лохам прорывные методологии что магически решают все проблемы.

[Сергей Горностаев]

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

[Сергей Горностаев]

Steel_Balls, настолько нагруженных как сейчас не существовало.

[Steel_Balls]

Сергей Горностаев, ну и что, что не существовало.
Я на коленке без микросервисов 5 лет назад делал сервис на 5-7 серверах, которые держали нагрузку в 20-24 тысячи запросах в секунду.
Вполне себе высокие нагрузки, я считаю. Горизонтальное масштабирование при желании позволяет повышать нагрузку сколь угодно много.
Без микросервисов

[Сергей Горностаев]

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

[Steel_Balls]

Сергей Горностаев, ну да, соглашусь

[Константин Казначеев]

Steel_Balls, так 5 лет назад это не начало 00х)))
Что-то вы во времени потерялись)))

[Константин Казначеев]

Алексей Клестов, то что они не всегда нужны полностью с вами согласен. Порой вполне достаточно монолита

[Алексей Клестов]

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

[Steel_Balls]

Константин Казначеев, я потому и отметил специально, что даже 5 лет назад вполне легко можно было писать без микросервисов. Как и в начале 2000-х.

Answer 5

[Василий Банников]

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