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

Question

Я пытаюсь создать микросервисную архитектуру, используя Lumen / Laravel Passport .

У меня есть несколько докеризованных сервисов, которые все работают как отдельный контейнер приложений Lumen на разных виртуальных машинах:

• Служба API-шлюза (интегрирована с Laravel Passport для аутентификации и проверки запросов для дальнейшей обработки)
• Служба чата (служба для сообщений / чатов)
• Служба новостей
• … (и многие другие службы)

Все эти службы имеют свои отдельные базы данных Redis / MySQL и т. Д.

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

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

И для получения этих данных я отправляю несколько запросов в разные сервисы

Вопрос:

ЧтоКакова наилучшая / правильная практика хранения пользовательской информации с использованием архитектуры микросервисов и как правильно извлекать связанные данные для этого пользователя из других микросервисов с минимальными потерями памяти / времени?И где хранить информацию о пользователях, такую ​​как идентификатор, телефоны и т. Д., Чтобы избежать дублирования данных?

Извините за возможное дублирование.Пытаюсь понять ..

Answer 1

Допустим, у вас есть услуги: MS1, MS2, MS3, MS4.Веб-приложение / мобильное приложение обращается к MS1 за информацией.Теперь MS1 необходимо вернуть ответ, содержащий данные, которыми управляют MS2, MS3 и MS4.

Плохое решение - MS1 вызывает MS2, MS3 и MS4 для получения информации, объединяет их и возвращаетокончательные агрегированные данные

Рекомендованное решение

1. Использовать сбор данных изменений на основе журнала (CDC) для генерации событий из баз данных MS2, MS3 и MS4, как и когда базы данныхобновляется соответствующими службами

2. Публикация событий в одной или нескольких темах потоковой платформы (например, Kafka)

3. Использование потоковой обработки, обработкасобытия и создать агрегированные данные для каждого пользователя в кеш и БД MS1

4. обслуживать запросы к MS1 из кеша и / или БД MS1

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

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

Преимущества:

1. Задержка будет меньше улучшать взаимодействие с пользователем, так как ответ предварительно вычисляется
2. Устранена тесная связь с другими микроуслугами.Таким образом, даже если MS2, MS3 или MS4 временно выйдут из строя, ваши пользователи все равно увидят данные, хотя и немного устаревшие, но в большинстве случаев это лучше, чем задержанный ответ или сообщение об ошибке.

Answer 2

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