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

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

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

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

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

Как заполнить двумерный массив?

Все очень непонятно, попробуйте понятнее сформулировать вопрос.

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

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

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

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

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

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

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

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

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

Как выбрать учителя по php?

Евгений Иванов, я прошу прощения, конечно, но мне кажется у Вас проблемы психологического характера. И это не попытка задеть. Повторюсь: Вы придумали сами себе проблему, присволи ей уровень сложности "запредельно", возвели в степень и вынесли на обсуждение с целью получить помощь. Вам эту помощь предоставляют в виде ответов и рекомендаций, но Вы продолжаете существовать в плоскости запредельной проблемы, которую сами выдумали. Поймите, у меня нет задачи задеть Вас, и я не сомневаюсь в крутости курсов, о которых Вы говорите, но это все похоже на анекдот из разряда настолько плохо, что хорошо. Сейчас бы учить php по оксфордским курсам, Вам самому не смешно? Или учить php с учителем? Если бы я был потенциальным работодателем я бы в последнюю очередь рассматривал кандидата, у которого был учитель по php, это звучит очень смешно, поверьте. Просто уберите этот барьер в Вашей голове и рассмотрите хотя бы вариант, что Вы можете неправильно расценивать ситуацию.

Как выбрать учителя по php?

Евгений Иванов, а с чего Вы взяли, что там была шутка? это плюс-минус общая формула, если Вы знакомы с основными конструкциями то просто пропустите это шаг, или я не понимаю, что Вы имели в виду)

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

На счет насмешек над курсами "php за час" или за 3 минуты - зря Вы так. Смысл ведь в том, что такие курсы наиболее быстро введут в курс дела новичка касательно синтаксиса и основных конструкций - большего от этих курсов не требуется.

В общем, я не до конца понимаю, что именно Вам не понравилось в ответе и каков Ваш уровень.

Для чего нужен составной ключ в mysql?

Артём, смотрите, есть связи вида один ко многим и есть связи вида многие ко многим. Если сделать так: Photos(id, name, user_id) - это будет связь один ко многим, то есть одна картинка/фотка привязана только к одному пользователю(но один и тот же пользователь может быть привязан к множеству картинок). А теперь представьте если нужно обозначить ситуацию, когда одна картинка может иметь отношение не только к одному пользователю, а к большому количеству. Тогда вы уже не сможете указать идентификатор пользователя так Photos(id, name, user_id), вам придется создавать новую таблицу вида, который был указан мною в ответе, и там уже каждая фотография может быть привязана к любому количеству пользователей. А каждая строка в этой новой таблице будет содержать уникальную связку, которая и будет являться составным ключом.