Реализация простого мессенджера в рамках курса по микро-сервисной архитектуре.
Назначение: роутинг клиентских запросов к остальным сервисам бэкенда.
Для общения клиентов с этим сервисом выбран подход REST API:
- паттерн клиент-сервис вполне подходит для реализации публичного API
- не подразумевается пересылка больших объемов данных
- возможность кэшировать данные о пользователях
- простота реализации
Все остальные сервисы не имеют прямого взаимодействия с клиентами и ориентированы на выполнение действий между собой.
Поэтому для реализации взаимодействия между внутренними сервисами выбран протокол gRPC.
Назначение: аутентикация и авторизация пользователей.
Функционал данного сервиса будет триггериться Gateway сервисом при запросе ресурсов клиентом.
Также Auth сервис будет получать данные о пользователях от Profile сервиса.
Сервис работает с профилями пользователей, данные о пользователях хранит в MySql
- регистрация нового пользователя
- редактирование профиля пользователя
- поиск пользователя по никнейму
Сервис отвечает за работу с друзьями пользователя, данные хранит в MySql (может быть стоит рассмотреть графовую БД)
- добавление пользователя в друзья
- удаление пользователя из друзей
- подтверждение/отклонение запроса в друзья
- просмотр списка своих друзей (в том числе неподтвержденных)
Сервис обеспечивает обработку сообщений пользователей, данные хранит в Cassandra
- написать сообщение другу
- получить сообщение из чата с пользователем
Сервис сообщений видимо будет подписан на события о входе пользователя в мессенджер. При получении события сервис должен отправить пользователю новые сообщения. Аналогичным образом сервис управления друзьями при получении события о входе пользователя должен отправить ему новые запросы на дружбу. Для этих целей видимо придется использовать какой-то брокер сообщений.