Описание потоков данных Диска VK WorkSpace

Схема взаимодействия сервисов приведена на рисунке ниже:

Описание потоков данных приведено в таблице ниже:

Последовательность взаимодейтсвия сервисов при загрузке файла:

1. Клиент при загрузке файла рассчитывает хэш на своей стороне и передает его в cld-uploader. Сервис cld-uploader проверяет авторизацию пользователя в swa и загружает файл на свой локальный диск и рассчитывает хэш.
2. Если хэши не сходятся, cld-uploader вернет ошибку. Если валидация пройдена,бинарный файл отправляется в сервис streamer, который формирует запрос в nylon по протоколу Tarantool.
3. Сервис nylon формирует в mpairdb запрос на поиск свободной дисковой пары на запись файла. После чего возвращает в streamer два ID, на которые и начинает загрузку на указанную дисковую пару.
4. Далее выполняется запись во временную директорию в s3storage, затем перемещается в нужную директорию (по хэшу).
5. По завершении загрузки бинарного файла streamer передает в nylon информацию — на какой паре лежит файл с определенны хэшом. Информация сохраняется в mfiledb. Обмен с базами данных осуществляется по протоколу Tarantool.
6. После чего информация о новом файле отправляется в cld-kavdb. Это необходимо для дальнейшей проверки файла на вирусы.
7. Сервис mvcheker с установленной периодичностью выполняет опрос сервиса cld-kavdb на наличие новых файлов.
8. В случае наличия новых файлов в cld-kavdb mvcheker отправляет запрос на получение файла в streamer и передает его на проверку сторонней антивирусной системе по протоколу ICAP.
9. Если найден вирус в отправленном файле, mvcheker отправляет файл в nylon.
10. Сервис nylon передает полученный файл с вирусом в mfiledb для установки соответствующих флагов.
11. Далее выполняется обновление пользовательского дерева и сохранение метаданных. Клиент отправляет информацию в сервис fcloud и далее в сервис lightning.
12. Через сервис cld-jet выполняется сохранение информации и обновление дерева пользователя в metadata-storage.

Схема взаимодействия сервисов приведена на рисунке ниже:

Описание потоков данных приведено в таблице ниже:

Последовательность взаимодейтсвия сервисов при чтении файла из домашней директории:

1. Клиент (пользователь) передает данные о пути в дереве метаданных и авторизационные данные в сервис cloclo через pub.
2. После подтверждения авторизации в swa путь до файла передается в сервис cld-jet.
3. В ответе на запрос cld-jet возвращает путь и хеш файла.
4. Сервис cloclo формирует ответ с кодом состояния HTTP 301. В редиректе клиенту возвращается токен, в котором содержится информация о хэше, пути и пользователе, который инициировал скачивание.
5. В ответ клиент возвращает токен в cloclo, где токен валидируется и извлекается хэш.
6. Внутри сервиса cloclo выполняется внутреннее перенаправление на указанный URI. Редирект отправляется в streamer, потом — в nylon.
7. Сервис nylon отправляет запрос в mfiledb для получения данных о местонахождении файла в s3storage.
8. Запрос возвращается в streamer и инициируется скачивание файлов из s3storage.
9. Затем бинарный файл через streamer отправляется клиенту.

Схема взаимодействия сервисов приведена на рисунке ниже:

Описание потоков данных приведено в таблице ниже:

Последовательность взаимодейтсвия сервисов при чтении файла по ссылке:

1. При открытии ссылки пользователем выписывается токен.
2. Затем, при нажатии кнопки Скачать, клиент передает в сервис cloclo токен, путь к файлу внутри ссылки и авторизационные данные пользователя (при наличии).
3. После проверки авторизации из cloclo отправляется запрос с weblink_id (две последние части ссылки с доступом к файлу) в cld-weblinkdb.
4. Ответ с UID владельца ссылки и путем до файла возвращается в cloclo и перенаправляется в cld-jet.
5. Из cld-jet в cloclo возвращается путь до файла и хэш.
6. На основе этих данных cloclo генерирует токен, который передает клиенту с кодом состояния HTTP 301.
7. В ответ клиент возвращает токен в cloclo, где токен валидируется и извлекается хэш.
8. Внутри сервиса cloclo через nginx выполняется внутреннее перенаправление на указанный URI.
9. Сервис nylon отправляет запрос в mfiledb для получения данных о местонахождении файла в s3storage.
10. Запрос возвращается в streamer и инициируется скачивание файлов из s3storage.
11. Затем бинарный файл через streamer отправляется клиенту.

Схема взаимодействия сервисов приведена на рисунке ниже:

Описание потоков данных приведено в таблице ниже:

Последовательность взаимодействия сервисов при чтении файла из архива:

1. Путь до директории (или токен, если скачивание производится по ссылке) передается через fcloud в сервис cld-zipapi.
2. Сервис cld-zipapi передает запрос клиента в swa для подтверждения авторизации, после подтверждения авторизации сервис cld-zipapi формирует запрос в cld-jet для получения списка хэшей файлов в директории.
3. Сервис cld-zipapi преобразовывает список хэшей в токен и записывает соотношение токена и полученных хэшей в cld-zipdb, и передает токен клиенту через fcloud.
4. Вторым запросом от клиента токен передается в сервис zipper для получения по токену списка хешей в cld-zipdb.
5. Полученную информацию zipper отправляет в streamer с запросом выгрузки необходимого списка хэшей.
6. Сервис streamer отправляет запрос в mfiledb через сервис nylon, для получения местонахождения файлов в s3storage а затем выгружает их из нужных дисковых пар.
7. Формирование zip-архива выполняется налету и передается клиенту.

Схема взаимодействия сервисов приведена на рисунке ниже:

Описание потоков данных приведено в таблице ниже:

Последовательность удаления файла пользователем:

1. Клиент (пользователь) отправляет запрос на удаление файла
2. Сервис fcloud передает запрос на сервис lightning и отдает статические файлы клиенту.
3. Сервис lightning передает запрос клиента в swa для подтверждения авторизации, после подтверждения авторизации запрос на удаление передается на сервис cld-jet.
4. Далее сервис cld-jet передает запрос в metadata-storage для удаления из дерева метаднных.
5. metadata-storage удаляет всю информацию о файле — с этого момента пользователь не видит файл у себя в директории.

Последовательность удаления файла по истечении периода времени:

1. Сервис toucher в асинхронном режиме работы циклически по очереди запрашивает информацию о деревьях метаданных каждого пользователя в metadata-storage и обновляет touch_time по хэшам файлов, и выполняет запись данных в mfiledb через nylon.
2. Если файл перестает откликаться на запросы сервиса toucher — начинает увеличиваться touch_time файла.
3. Если touch_time достигает срока в полгода, запускается процесс удаления файла из s3storage.
4. Процесс удаления файла инициирует сервис haron по данным touch_time, полученным из mfiledb через nylon.
5. По истечении полугода в параметре touch_time сервис haron удаляет файл в s3storage и с дисковой пары.