Как организовать передачу данных между микросервисами (при наличии общей БД)?

Question

[Александр Михайленко]

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

Она предполагает что фронт часть - это один большой сервис, у которого есть так называемые "модули" это по факту другие АПИ сервисы которые расширяют функционал системы.
И логика такова что у сервиса будет единая база клиентов, что бы была только одна точка регистрации у клиента и кроме этого в общем базе будут храниться лимиты для каждого АПИ (количество запросов в месяц, согласно тарифу, который выбирает клиент системы).
Вопрос в следующем: как корректней всего должны общаться между собой АПИ сервисы, что бы они имели всегда актуальные данные из общей БД ?, это по факту текущие лимиты и права доступа.

П.С Авторизация всегда будет проходить через общую базу и центральный АПИ (он будет точкой входа всех приложений). Но так как у каждого сервиса свои особые отличия и назначения, то после авторизации каждый сервис использует свою БД для хранения данных. При это все это закреплено за пользователем

Comments

[stratosmi]

Это не микросервисная.

[d'Ivan]

Сложно как то все.

Answer 1

[luna3956]

У Вас есть главный(центральный) апи, главная база и дополнительные апи со своими базами.

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

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

По сути это почти одно и то же, различие в том, что во втором случае в "глазах" фронта у вас будет один единственный центральный апи

Comments

[Александр Михайленко]

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

Вопрос такой, допустимо что например апи сервис 2 один раз узнает лимиты, а потом они передаются в его базу и там уже проверяются, локально только на том апи ? такое дублирование имеет место быть ?

[luna3956]

Александр Михайленко, постараюсь максимально развернуто:

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

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

Вот смотрите, предположим Вы сделали так:

Вопрос такой, допустимо что например апи сервис 2 один раз узнает лимиты, а потом они передаются в его базу и там уже проверяются, локально только на том апи ? такое дублирование имеет место быть ?

Как только пользователь обратился к сервису 2 в этот момент вы проверяете локально(так как продублировали лимиты и права из центральной в локальную) и если все нормально, то вы отдаете пользователю данные и уменьшаете доступные лимиты на единичку(условно говоря, для примера, на деле может быть иная логика). После локального уменьшения оставшихся лимитов у вас образовался рассинхрон с центральной базой: там до сих пор лимит не изменен. Что вы можете сделать: либо оформить этот процесс в одну транзакцию, чтобы избежать несогласованности данных(в таком случае вы получите то о чем я изначально говорил - центральный апи в любом случае будет задействован, просто в данном случае запрос не сразу через него пошел + получили лишнее дублирование данных), либо же вы можете изменить лимит локально, а изменение в центральной базе сделать асинхронным - то есть поставить такую задачу в очередь и она выполнится позже. Недостаток в том, что рано или поздно скорее всего наступит момент, когда лимит на дополнительном апи будет исчерпан, а в центральной базе все еще нет. Тут уже вопрос, насколько для вас это критично.

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

И еще пару слов про дублирование:
В распределенных системах и вообще в высоконагруженных проектах дублирование данных - это самый распространенный и простой прием, позволяющий решить много проблем. Главное, использовать его осмысленно. Дублирование - это самая простая оптимизация.

[Александр Михайленко]

luna3956, Спасибо большое!, все больше понимаю суть всей ситуации.
И сразу отвечаю на вопрос, зачем центральный АПИ: идея в том, что на общей фронт части в определенные моменты нужно будет подтягивать данные из разных сервисов (АПИ), и центральная АПИ служит не только как шлюз регистрации но и как "переходник", что бы получать данные и приводить их в единый формат.
Так как предполагается что один из сервисов будет на Node.js + MongoDB, центральный же это php+ postgre и еще один сервис это php+mysql
это все вытекло из нескольких бизнес задач:
1. единый сервис для разных веб приложений
2. единая регистрация
3. единая тарификация + шлюз оплаты

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

[luna3956]

Александр Михайленко,

дея в том, что на общей фронт части в определенные моменты нужно будет подтягивать данные из разных сервисов (АПИ), и центральная АПИ служит не только как шлюз регистрации но и как "переходник", что бы получать данные и приводить их в единый формат

Так и используйте ее в этих целях, зачем вам единая БД?
В каждом сервисе пусть будет своя локальная база со своими данными и с правами и лимитами, обращайтесь напрямую к этим сервисам за их данными. А когда возникает необходимость получения данных из нескольких сервисов и нужно привести их к единому формату - делайте это через отдельный сервис(который у вас сейчас главный), собирайте на нем пачку данных и отдавайте на фронт, либо же вообще делайте это на стороне клиента - то есть отправили с клиента n запросов на n api, и в клиенте же привели их к нужному формату и отобразили. Тут уже больше зависит от того, какое звено менее нагружено, там это и можно делать. Если же для клиента это "тяжело", то как сказал выше - пусть этим и занимается этот центральный апи.

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

[Александр Михайленко]

luna3956, Единый АПИ сейчас в схеме только для того, что бы иметь доступ к БД с клиентами со всего сервиса по сути и биллинг клиента. Вся загвоздка для меня в том что если человек регистрируется в расширении для браузера например, или отдельном фронте, это все попадает в единую базу и кроме этого, при авторизации если человек зашел то имеет доступ сразу ко всей сети сервисов. Вот поэтому идея центрального АПИ и сохраняется, единая точка авторизации, регистрации.
Если все будет на "чистых микросервисах" то где хранить клиентов, их оплату ? я достаточно много видимо не понимаю в микросервисах)

[luna3956]

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

[Александр Михайленко]

luna3956, Авторизация будет только через центральный АПИ (как единая точка входа на всех сервисы). А логика авторизации заключается в JWT токене.
Все апи знают секретное слово. Центральный АПИ генерирует токен, а потом при обращении уже на сторонние АПИ, токен расшифровуется на предмет того, что он мог такой быть и с него как раз получается инфа о лимитах клиента на текущий момент.
Все, вот как дальше уже не знаю, пока только ваши идеи мне понравились, насчет синхронизации лимитов, потому что они все таки нужны будут в центральном фронте видны, как только пользователь туда зайдет

[luna3956]

Александр Михайленко, тут уже не столь важен механизм, если на стороннем апи можно определить авторизованность - то задача сильно упрощена. Делайте запросы сразу на эти сторонние апи, а когда нужно скомпоновать данные с нескольких апи - делайте это через центральный. Единственная задача - это синхронизации данных в центральной и локальных базах. Тут уже как выше говорил - либо реализуете обращения как одну транзакцию(преимущества - избегаем несогласованности, недостатки - увеличивается время запроса и задействуется центральный сервер), либо же обращаетесь к стороннему апи, отдаете пользователю данные и ОТЛОЖЕННО актуализируете данные в центральной базе. Как вариант приходит на ум следующее: чтобы избежать ситуации, когда лимит исчерпан, а на центральной базе он еще есть, можно поставить заглушку на каждом локальном апи и проверять - если для какого-то пользователя например лимит близится к завершению(допустим осталось 20 обращений), то начать делать операции транзакционно(то есть синхронно обновлять информацию в бд, разумеется, перед этим не забыть проверить очередь, в которой могут поджидать не примененные изменения для этой базы), а пока предел лимита еще далеко, то выполнять изменения на центральной базе отложенно.

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

[Александр Михайленко]

luna3956, Понял, спасибо большое за уделенное время! Вы мне очень помогли) у меня есть теперь более цельная картина и представление о том какие варианты решения есть вообще. Этот опыт очень ценен!)

[luna3956]

Александр Михайленко, удачи Вам)