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

потому что тогда «воторой» микросервис должен иметь специальную «REST API ручку»

ну и что? Это же чисто механическая «проблема», дольше рассуждать будете чем ручку прикручивать. Вам бы стоило, однако, ответить самому себе на несколько основополагающих вопросов. Допустим, у вас есть микросервисы А и Б, и у микровервиса Б есть принадлежащая ему база данных.

1. Имеет ли смысл ваша система, если один из микросервисов отвалился и не работает? То есть может ли продукт работать с урезанной функциональностью. Если ответ нет, то надо ли городить микросервисную архитектуру?

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

Если у вас микросервисы используют одну базу, то это больше не микросервисы.

А что это?

Макросервисы

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

Из недавнего был смешной случай, когда неработающий сервис оплаты делал нерабочим сервис авторизации.

Ну, это ж не повод делать ситуацию ещё хуже.

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

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

kafka

И Докер, Докер не забудь!

Проблема в ДН^H^Hархитектуре. Вопроса получить данные из БД другого сервиса стоять не должно, так как для тебя не существует «БД второго сервиса». Ну а так да, ты работаешь с сущностями на уровне API (REST) а не БД.
Если два сервиса слишком взаимосвязаны, то стоит подумать а не должен ли это быть один сервис.

REST API ручку

ручку

Так, этого в Яндекс 😏

при этом не делая REST «ручки»

Значит тебе не нужны микросервисы - ты не понимаешь зачем они нужны

И делать под каждую такую ситацию «специльную» ручку.

А ещё индексы под эту ручку. И тесты. Как удивителен мир.

этого в Яндекс

Та ладно тебе, все так говорят

А эти «все» сейчас с нами в одной комнате?

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

Тогда это уже не микросервисы

например нужно не просто получить какую то запись по ID, а еще и всякие типа LEFT JOIN и все такое

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

GraphQL

Палка о двух концах, т.к. прокси который будет делать федерацию получается жирный, запрос медленный. ИМХО удобнее кидать много мелких rest запросов и «федерировать» на стороне клиента.

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

Любой проект в начале небольшой. «Перепишем потом» никогда не работает.

До «потом» ещё дожить надо. Это не у всех получается. И попытка применить все best practices сразу, чтобы было как у Гугля, только понижают вероятность дожития.

Поэтому из общих соображений получается так:

1. В начале жизненного пути нужно делать максимально простой в обслуживании монолит.
2. Но попиленный на модули. Оно и по-жизни проще будет, и потом модуль можно будет в микросервис вынести.
3. Есть, конечно, шанс, что на модули вы поделите систему неправильно и хрен там потом что куда вынесешь.
4. Но так и в микросервисной архитектуре можно очень даже запросто облажаться.

Если они не имеют доступ к данным друг-друга, то уже не важно, лазят они в одну большую СУБД или несколько разных. Разве, добавляется возможность положить систему всю целиком, уронив всего один сервер.

Ну и какая разница это отдельные схемы в одной БД, отдельные БД в одной СУБД или отдельные СУБД если данные у тебя не связаны жестко внешними ключами и чужие данные не используются напрямую.

Вообще даже с разных СУБД можно консолидировать данные через FDW или иной db server link или вообще MDM.