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

потому что тогда «воторой» микросервис должен иметь специальную «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.

Есть, конечно, шанс, что на модули вы поделите систему неправильно и хрен там потом что куда вынесешь

Не шанс а наоборот закономерность. Люди всегда движутся по пути наименьшего сопротивления.

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

Можно, но сложнее. Просто из-за наличия физических ограничений. Вот ТС например хочет сотворить какую-то дичь, но архитектура препятствует. А был бы у него «модульный монолит» он бы давно захерачил свои left join без всяких вопросов.

вместо запроса к бд дергается апи

в бд то всё равно запрос уходит 🤡🤡🤡

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

Не обязательно

Про кэширование надо 7 раз подумать прежде чем делать.

7 раз подумать

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

Вот ТС например хочет сотворить какую-то дичь, но архитектура препятствует.

Здесь дичь является дичью только потому, что кто-то изначально налажал с микросервисной архитектурой и неправильно выделил функциональные модули. Если б микросервисы были спроектированы по другому, то и ходить в БД чужого сервиса не нужно бы было. А всё потому, что архитектура — это сложно и чем больше в ней движущихся частей, тем сложнее.

он бы давно захерачил свои left join без всяких вопросов.

Возможно, это было бы правильным решением в данном случае.

Почему кеширование? Может я захардкодить результат решил.

Я про инвалидацию кэша если данные часто изменяются или идет массовое изменение.

Что у тебя там, НСИ или прочие справочники в виде файлов который подсасываются при старте?

А какая разница? В том то и фича, сегодня таблица, завтра чтение из файла, а потом вообще агрегация из ещё 10 сервисов.

Если б микросервисы были спроектированы по другому, то и ходить в БД чужого сервиса не нужно бы было

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

Возможно, это было бы правильным решением в данном случае

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

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

Я что-то потерялся. Данные всегда связаны, но какой из этого вывод?

если у конторы нет толкового архитектора

Предлагаю принять это за базовый сценарий. Чем сложнее тема, тем меньше людей, которые в ней разбираются.

Если б микросервисы были спроектированы по другому, то и ходить в БД чужого сервиса не нужно бы было

Данные всегда связаны, но какой из этого вывод?

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

лепить апи на каждый чих.

Точно. Но, если взаимосвязь-разделение в данных отражено в разделении на микросервисы, то чихать придётся не очень часто.

Все же в микросервисной архитектуре БД должна быть спрятана за API.

Если нужны какие-то сложные запросы, которые плохо ложатся на API, то остается еще вариант построения read-only реплики данных сервиса в хранилище другого сервиса или в каком-то общедоступном хранилище/индексе. Суть в том, что такая конструкция не нарушает монополизм сервиса-владельца на изменение данных, не мешает эволюции его схемы, но при этом позволяет использовать готовые языки запросов.

В плане построения есть два варианта – или сам сервис каким-то образом строит свою реплику (это ближе к традиционному CQRS), или сервис предоставляет журнал изменений и потребитель по нему отстраивает себе ровно то, что ему нужно (это уже Eventsourcing).

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

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

Можно SQL плейн-текстом в POST-запросах слать.

Как ОП и просил, пошли бест практисы построения микросервисов) Я в лорчике не сомневался)

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

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

Нужно не проблему прямого доступа к БД решать. А проблему сложного добавления ручки.

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

Реплика не повторяет схему внутренней БД сервиса. Это внешнее представление, адаптированное под нужды тех, кто делает в него запросы. К эволюции ее схемы нужно относиться так же, как к эволюции API.