Применение Vault к другим сервисам

Vault — это сервис управления файлами в Vizend. В Vault структура данных файлов делится на ссылочные файлы и физические файлы.

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

По моему опыту обслуживания функциональности Vault, она, кажется, классифицируется на три основных типа.

Vault делится на три основных типа хранения.

Тип хранения

1) Личное хранилище: Stash

• Личное хранилище с структурой папок

2) Общее хранилище: Cabinet / Clip

Используется как 'общее хранилище вложений' для объявлений, вложений к постам и т. д.

• Cabinet: Концепция набора (контейнера) Clips

• Clip: Концепция набора ClipFiles (ссылочные файлы)

• Область применения/единица может варьироваться в зависимости от логики бизнеса сервиса (devlime, vizend, BanJangNote и т. д.).

• Вы можете рассмотреть 'всё сервисное хранилище как 1 cabinet'.

• Также возможно разделить шкаф для каждой доски объявлений.

3) Хранение фото: MiniAlbum / Minipix

• Minipix : Хранение фото “название сервиса”

• Миниальбом: Фактический домен (административная единица)

Общая концепция: 'Репозиторий справочных файлов'

Три репозитория (Stash / Clip / Photo) имеют следующее общеесправочный файлСохранение.

• Сохранённый файл

• Stash: StashFile

• Clip: ClipFile

• MiniAlbum: PhotoFile

Все они являются фактическими файлами VaultFileЭто ссылка, на которую указывает. Поэтому, даже если вы многократно копируете файл ссылки,Фактическая емкость хранения не увеличивается немедленно..

Проблемы, с которыми столкнулись при применении к другим услугам

Когда я был ответственным за Vault, я взял на себя задачу фактически применить Vault к другой услуге. Название этой услуги - 'BanJangNote'. BanJangNote можно назвать приложением для управления персоналом и в настоящее время оно находится в стадии разработки в первой половине 2026 года. (Из-за соображений безопасности приношу извинения за ограничения в предоставлении подробных описаний услуг.)

Функции, необходимые от Vault в заметках классного руководителя, включали Мои документы и подачу документов для объявлений.

Сначала я думал, что будет легко реализовать Vault здесь, но возникли некоторые ограничения в применении.

Во-первых, мои документы должны были быть применены с использованием Stash, который по сути является структурой папок.

В заметке классного руководителя был специфический тип документа, который необходимо было сохранить в моих файлах, который не вписывался в структуру папок. Однако,Vault является одной из услуг MSA и должна функционировать как общая услуга, поэтому мы не могли изменить домен Vault Stash только потому, что он применяется к другой услуге.Поэтому необходимо было применить это к заметке классного руководителя, сохраняя структуру Stash.

1. Парадокс универсальности Vault

Итак, после долгих раздумий я решил реализовать метод, при котором папки создаются заранее, и логика изменения и удаления папок не предоставляется пользователю. После решения этой проблемы меня ждала другая проблема. Поскольку Vault предлагает только функции сохранения и загрузки/скачивания, мне нужно было решить, сохранять ли метаданные для каждого загруженного файла в документной области, структурированной аналогично бэкенду Vault в BanJangNote. Чтобы Vault эффективно управлял файловым управлением, также была необходима структура для сохранения метаданных, и чтобы решить это, CEO добавил столбец формата строки JSON к каждому clipfile, stashfile и photofile. Например, при загрузке фото удостоверения личности в stashfile я добавил метаданные вместе с файлом, такие как fileMetaData = "{ documentType: /"ID_CARD/" }". Это позволило нам исключить необходимость отдельно проектировать и применять документную область в бэкенде BanJangNote.

2. Бэкенд к бэкенду против фронтенда к бэкенду

Существует два способа использовать функцию хранилища в других сервисах:

1. Прямой вызов бэкенда хранилища в клиентской форме из бэкенда другого сервиса

2. Импорт и вызов компонента управления состоянием API фронта хранилища из фронта другого сервиса

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

3. Объем Кабинета и Клипа

Кабинет — это коллекция Клипов, а Клип — это коллекция Клипфайлов. Эта проблема стала самой большой сложностью для меня, когда я отвечал за Хранилище. Я получил много запросов о том, как определить объем Кабинетов и Клипов в разных сервисах.

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

Поэтому мы применили это в следующем потоке при внедрении тетради классного руководителя.

структура

• Запись классного руководителя — это клип объявления и клип представления документадля отделения

• кабинет — это вся тетрадь классного руководителяПоделиться 1 элементом

• cabinetKey и cabinetId должнывсегда быть одинаковыми

поток

1) Лидер (руководитель группы) создает объявление

1. RegisterJobPost в бэкенде BanJangNote (пример)

2. При регистрации изображения в объявлении вызовите registerClipFiles

3. Сохраните возвращаемый clipId в соответствующем JobPost в бэкенде BanJangNote при успешной операции

2) Руководитель группы нажимает на объявление → отправить

1. FindJobPostDetail в бэкенде BanJangNote (пример)

2. Отправить → Список документов → Нажмите на ID

3. Загрузка файла или 'Загрузить из моих документов'

• При загрузке файла

- Вызовите registerClipFiles

- Сохраните возвращенный clipId и clipFileIds в jobApplication (пример)

- Используйте registerClipFile, если соответствующий тип документа отсутствует в jobApplication, или используйте addClipFile, если он существует

• При загрузке из Моих документов

- Используйте registerClipFilesFromstash

- Если возможно проверить stashFolderId конкретного документа, обрабатывайте с помощью registerClipFilesFromstash без сохранения метаданных, а затем сохраните в бэкенде заметок капитана

3) Лидер команды проверяет документы кандидатов

1. Запросите jobApplication из бэкенда заметок капитана, который включает clipId → извлеките clipId

2. Запросите clipFileIds из бэкенда хранилища и используйте downloadFile(s) для предварительного просмотра миниатюры

Обзор

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

ЛИ ДЭВИД