sudo docker-compose down --volumes sudo docker-compose up docker image prune
-
HTTP-server — принимает http-запросы от клиента, передаёт роутеру очередей
-
Queue router — делегирует запросы очередям (несколько очередей для уменьшения нагрузки на них, по сути инстансы одного класса)
-
Service queue — очередь сервера, то же инстансы одинаковые
-
Service auth — работает с токенами. Под его управлением БД с id всех пользователей и их токенами, если пользователь аутентифицирован, API:
- Запрос аутентифицирован ли пользователь.
- Запрос аутентификации по логину и паролю.
- Запрос на выход из аккаунта
- Запрос на добавление нового пользователя
- Запрос на обновление access токена
- Swagger:
-
Service users — работает с данными пользователей. API:
- Запрос на создание пользователя
- Создание его в БД
- Запрос auth сервиса на создание пользователя
- Запрос на данные пользователя по id
- Проверка id
- id === id в запросе - все данные отдаём
- иначе только общедоступные
- Запрос всех пользователей
- Запрос в БД
- Запрос существует ли пользователь
- Запрос в БД
- Запрос id пользователя по нику
- Запрос в БД
- Запрос на изменение данных пользователя
- Проверка id
- Запрос в БД Swagger: https://app.swaggerhub.com/apis/lerakrya8/Users/1.0.0
- Запрос на создание пользователя
-
Service post — работает с постами. API:
- Запрос постов для пользователя (Ленты)
- Запрос в friens сервис друзей пользователя
- Запрос в БД постов на основе выборки друзей
- Запрос всех постов
- Запрос постов пользователя
- Запрос в БД постов
- Запрос на создание поста
- Проверка id
- Запрос в БД на создание
- Запрос на изменение поста
- Проверка id
- Запрос на изменение поста в БД
- Запрос на удаление поста
- Проверка id
- Запрос на удаление поста в БД
- Запрос определённого поста из БД
- Запрос постов для пользователя (Ленты)
- Service frends — работа с социальными отношениями между людьми. Скорее всего хранить как строку. API:
- Запрос на изменение отношения с другим пользователем (add or delete)
- Запрос в БД на изменение (если id валиден)
- Запрос на выборку друзей пользователя
- Запрос в БД друзей
- Запрос на взаимоотношения между пользователями (один другому кто, друг, никто, подписчик)
- Запрос в БД друзей
- Запрос на статистику пользователя (сколько друзей, подписоты, на сколько он человек подписан) 2. Запрос в БД (храним как счётчики, не считаем каждый раз)
- Swagger: https://app.swaggerhub.com/apis/NoSql/FriendsServer/1.0.0
- Запрос на изменение отношения с другим пользователем (add or delete)
Протокол схож с http. Первая строка запроса - номер запроса (номер определяется http-сервером), вторая - приоритетность, далее тип запроса, далее id пользователя, который послал запрос (он авторизирован, если -1 - то запрос анонимен), далее пустая строка, далее тело запроса если существует. Пример:
123423
/api/auth/add/
4
{
"username": "Filechka322",
"password": "qwerty",
"id": 23
}
Если тела нет, то после id две пустые строки:
123423
/api/auth/add/
4
Каждый сервис сам определяет названия ручек (endpoint) и те данные, которые ему необходимы для осуществления запроса. Ответ от каждого сервиса приходит в отдельный сокет http сервера, то есть сервисы имеют сокет для связи с очередью и сокет для связи с сервером, из очереди достаём запрос, ответ кидаем в http-сервер. Пример ответа:
123423
{
"response": "success create user"
}
Запрос сервиса на http:
/api/итдручка
{
"username": "Filechka322",
"password": "qwerty",
"id": 23
}
Поток блокирует БД только если есть все данные для запроса в БД, иначе просто ждёт.
Неполадки на серверах можно «компенсировать» с помощью Null object pattern
Полезные ссылки:
- JSONparser: юзаем из boost
- PostgreSQL for C/C++: сайт
- Swagger: для каждого сервиса в их описаниях