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

Зачем ты делаешь микросервисы если в результате получается неудобно?

А так есть куча вариантов лучше реста. Соап, жсон рпц, жмс, грпц, трифт. Выбирай.

kafka

grpc/rest для слабой нагрузки или с брокерами (kafka/rabbitmq) если очень нагружено

Да но кафка это вроде как «очереди» грубо говоря. А мне нужно так сказать «взять данные из БД другого сервиса» при этом не делая REST «ручки» для получения этих данных, потому что мне например нужно не просто получить какую то запись по ID, а еще и всякие типа LEFT JOIN и все такое… И делать «ручку» под «каждую» такую хотелку ну такое…

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

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

Сделай им единую базу, начальству говори, что у нас микросервисы)

Не уподобляйся Танненбауму, делай монолит.

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

Создай третий микросервис с общими данными.

архитектора на мыло

Сделай им единую базу …

… как микросервис.

Мы json-rpc гоняем через шину. Для ограничения области понятий, типов объектов и методов, которые к ним можно применять - DDD. При этом, что на самом деле лежит за шиной и что система-получатель будет делать с пакетом система-отправитель не знает.

архитектор уже взял деньги и сбежал.

архитектор уже взял деньги и сбежал.

какой талантливый молодой человек!

аналог redis

Так суть микросервисов в том, чтобы не лазить в БД соседнего, а работать по стандартизированному контракту. Чтобы детали реализации всегда можно было изменить (включая структуру БД). Я бы сказал, что либо вы зря взяли микросервисы, либо вы их неправильно готовите.

делай монолит

Без GPL не взлетит.

Обычно сейчас для диалога микросервисов либо они, по старинке, располагаются надо общей бд, либо общаются через gRPC. Кафка оно красиво в теории, но на практике либо дикий оверхед, либо всё сложно и в конце концов от неё становится больше вреда чем пользы.

Никто не мешает тебе сделать рпц-овер-кафка, ну кроме самой кафки.

А смысл микросервисов как раз в том что у тебя вместо запроса к бд дергается апи.

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

… как микросервис.

Ага, и сделай общение с ним через специальный DSL по имени SQL по протоколу MySQL клиента

Идеальный микросервис!

Ага, и сделай общение с ним через специальный DSL по имени SQL по протоколу MySQL клиента

Можно SQL плейн-текстом в POST-запросах слать. А сервис-получатель может даже какую-то валидацию провести, прежде чем в базу передавать этот запрос.

А смысл микросервисов как раз в том что у тебя вместо запроса к бд дергается апи.

Не. Смысл микросервисов в первую очередь в том, что код разделяется. «Дёргание апи вместо запроса к бд» обеспечивает при этом две вещи: 1) что запись в базу может делать только один сервис; 2) совместимость при изменениях в схеме. Но (1) можно обеспечить и по-другому, а (2) может не быть проблемой, если схема хранения стабильна

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

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

А сервис-получатель может даже какую-то валидацию провести

Типа доступа? Можно создать отдельного пользователя в БД.

Можно создать отдельного пользователя в БД.

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

Смысл микросервисов в первую очередь в том, что код разделяется

Это следствие.

Смысл микросервисов в первую очередь в том, что код разделяется.

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

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

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

Писать такое могут одни и те же люди в целом. Вопрос скорее в оперировании нагрузкой в продакшене будет.

Какие есть бестпрактис на этот счет?

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

Или grpc или что-то еще такого же рода.

Различные очереди (RabbitMQ, Kafka) при это не взаимоисключающее явление - они решают другую задачу, не RPC, а обеспечение eventual consistency

GraphQL

Это в основном для клиентов. В том числе потому, что умеет в аггрегацию. Сейчас местами есть сентимент, что ну его нафиг - переизобрели ODATA, но сложнее и с проблемами.

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

Мне кажется многих вводит в заблуждение приставка микро.

Сервис должен охватывать некий business domain целиком, и в зависимости от сложности оного может быть вообще не микро. А если начинать дробить, то получается распределенный монолит, со всеми проблемами, специфичными для распределенных систем, но без преимуществ.

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

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

Это почему микросервисы так хорошо подхватила лоукост разработка.

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

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

Классика чтения маркетинговых материалов без понимания. Если это было правда, то hurd и прочие правили бы балом, а про linux и прочее знали бы только два с половиной гика. Но это

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

так не работает. Вернее работает в простых и примитивных т.е. в маркетинговых случаях.

Одному проще поддерживать один большой и простой

«Лучше быть богатым и здоровым, чем бедным и больным»

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

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

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

Да так и есть, но бывает ситуация, когда надо из одного сервиса сделать «сложную» выборку данных(типа сложный SQL) из другого сервиса. И делать под каждую такую ситацию «специльную» ручку. ну хз…

А мне нужно так сказать «взять данные из БД другого сервиса» при этом не делая REST «ручки» для получения этих данных,

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

Да, вы продолбали архитектуру под чистую. Чините архитектуру либо переползайте не монолит.

поддерживать несколько простых проектов

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

вы неправильно распилили проект на микросервисы

Да. У ОП 10 микросервисов, а нужно было один)

схема хранения стабильна

Смеялись всем отделом маркетинга.

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

По-моему ты как-то не так проектируешь микросервисы. Они должны быть конечными автоматами по-факту.

Если же тебе действительно нужно делать кучу запросов из разных баз и прогнозировать эти запросы ты не можешь, то стоит посмотреть в сторону инструментов для дата-сатанистов. Куда-нибудь в сторону Apache Airflow.

В большинстве случаев лучшие преимущества микросервисов станут ещё лучше, если заменит микросервисы на грамотно разделённый на модули монолит (отдельные модули могут писать разные команды, главное договориться не менять публичный API без предупреждения). Но мы, DevOps’ы тогда без работы останемся, так что я рад торжеству микросервисных микросервисов.

лучше реста.

Соап

Ну так-то пеар реста строился на том что он лучше соапа (типа легковеснее). И те же, кто инвестировал в соап, и вебсервисы просто городили еще один забор из реста и микросервисов. Другое дело что пеар соапа строился на том что… он лучше бинарных RPC и корбы. Пушо «более дружелюбнее» и «человекочитабельнее». Происходит одна и та же фигня: что-то пеарят как более лучшее, и даже человекочитабельное… оно таким бывает ровно до того момента как его начинают генерировать машины для общения с машинами, т.е. огромными, совершенно нечитабельными простынями, будь то соап или рест. А потом история делает круг – и пионеры из гугла начинают в 2010м пеарить эти свои протобуфы, т.е. бинарный протокококол… и пеар строится на чем? на том что оно всяко более лучше чем XML. А потом что? А потом, в 2015 пеарят грпц как что? Как что-то более лучшее чем протобуфы. Деды, которые создавали RPC и корбу за 20 лет до всего этого цирка больных NIH синдромом такие «да вы ж мои инноваторы!»

А мне нужно так сказать «взять данные из БД другого сервиса» при этом не делая REST «ручки» для получения этих данных, потому что мне например нужно не просто получить какую то запись по ID, а еще и всякие типа LEFT JOIN и все такое… И делать «ручку» под «каждую» такую хотелку ну такое…

Я бы расшарил базу данных для первого микросервиса. Из-за прослойки в виде еще одного микросервиса будут только тормоза и проблемы.

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

Соап хорошо вписался в соа, т.к. сомодокументация, валидация, человекопонятность.

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

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

Но для соа, а микросервисы это вариант соа, ничего не поменялось, различные рпц рулят.

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