Разработка технического задания на доработку опытного образца системы дополнительными функциональными модулями
Зарегистрируйся в два клика и получи неограниченный доступ к материалам,а также
промокод
на новый заказ в Автор24. Это бесплатно.
В ходе разработки технического задания на доработку опытного образца было решено разделить документ на разделы/главы:
Организация хранилища
Организация базы данных хранилища
Шифрование
Авторизация и аутентификация
Реализация просмотра некоторых форматов файлов
В ходе написания главы об организации хранилища было выявлено, что эта глава неразрывно связано со второй «Организация базы данных хранилища». При попытке написания совмещенных глав, экспертный отдел выразил серьезную критику в плане перегруженности системы при таком подходе.
Использование факторов защиты доступа при старой схеме выглядели достаточно громоздкими и ненадежными, что в итоге привело к эксперименту над выявлением оптимального варианта и написанию обоснованности применения данного подхода в этой главе технического задания. Результаты экспериментов показаны на рисунке 9.
В эксперименте использовалось:
несколько реальных хранилищ, которых было разное количество объектов, разных размеров
база данных по этим хранилищам, на каждое хранилище своя таблица в базе данных
Для выведения данных по директориям использовался простой вывод html размети с содержимым директории. Оценка правильности эксперимента прошла вручную, а сам эксперимент проводился в автоматическом режиме в цикле из 1000 итераций.
После этого все единогласно пришли к мнению необходимости реорганизации хранилища и введении использования базы данных для отделения физической структуры хранения от логической пользовательской структуры.
Однако, несмотря на объединение глав, было решено разделить серверное API на отдельные группы, иными словами было решено внедрить новые модули называемыми микросервисами, чтобы каждый из микросервисов мог работать самостоятельно, что позволило бы придать большую масштабируемость сервису, а значит сократить время как на отладку и поддержку, так и на расширение возможностей.
Краткое содержание раздела «Организация хранилища»:
При тестировании опытного образца использовалось прямое использование ресурсов файлового хранилища. Для тестирования самой концепции этот подход весьма оправдан, однако использование его в коммерческом продукте является недопустимым по нескольким причинам:
Небезопасно для всего сервера, так как доступ к хранилищу осуществляется по http протоколу, на сервере используется php, и это создает значительную дыру в безопасности. Любой пользователь, загрузив php файл и обратившись к нему по get запросу сможет исполнить php код файла прямо на сервере, а действия выполняемого кода непредсказуемы.
Небезопасно для пользовательских данных, иными словами конфиденциальность данных при таком подходе нельзя гарантировать, посредством php кода можно получить доступ к данным. В этом случае доступ к данным возможно получить даже просто зная прямой адрес до директории/файла.
Создает дополнительную нагрузку на файловую систему, которая выражается в большей потребности в вычислительных возможностей серверов. Для того чтобы дать пользователю информацию о текущей директории, для начала ее необходимо просканировать.
Создает шанс нерациональной нагрузки на файловую систему
Зарегистрируйся, чтобы продолжить изучение работы
. Известно, что чем больше объектов в директории (поддиректории или файлы), тем больше времени требуется на обработку и представление списка данных, а это все вычислительные ресурсы. Плюс к этому, если речь идет о представлении данных в просмотрщике (клиентское приложение для работы с сервисом), то стоит упомянуть что рендер GUI тоже требует определенных ресурсов (CPU, GPU, RAM) и чем больше объем данных отправлен на отрисовку тем больше вычислительных ресурсов будет употреблено.
Поэтому необходимо использовать иной метод для организации хранилища:
Физическая структура хранение данных отделена от логической пользовательской структуры. То есть пользовательская структура является по сути виртуальной и никак не сходится с адресацией физического хранения. Для этого в базе данных каждого пользователя появились новые данные.
Необходим лимит на количество объектов в одной директории в 1000 единиц.
Необходима самостоятельная организация файловой системы
Необходимо использование базы данных для хранения информации о логической структуре хранилища пользователя
Эти требования формируют следующие пункты организации файлового хранилища:
Каждый пользователь должен иметь свою собственную директорию с файлами, доступ к директории на уровне пользователя должен иметь только тот пользователь, за которым закреплена эта директория, однако любой пользователь, имея ссылку на файл другого пользователя, при учете что файл открыт для просмотра владельцем (исходным пользователем), может получить доступ к файлу на уровне просмотра
Все файлы и папки в хранилище пользователя должны хранится только по внутренним именам, то есть по числовым идентификаторам и так как установлен лимит на 1000 объектов в директории, то пределы числовых идентификаторов могут быть [0, 999]
Для обеспечения мнимой безлимитности на количество объектов в хранилище необходимо использовать четырехуровневую поочередную вложенность, то есть первый файл в хранилище будет располагаться по относительному пути 0/0/0/0 где первые три нуля это имена папок а последний это имя файла, а последний файл будет иметь относительны путь 999/999/999/999. Таким образом, лимитом на количество файлов в хранилище будет являться 1000 в степени 4 то есть 1 000 000 000 000 объектов.
При таком подходе к организации хранилища доступ к файлу по логической структуре будет невозможен, а значит, шанс прямого доступа к файлам снизится, а с учетом проверки пользователя на факт владения директорией шанс будет близок к нулю.
Однако в данном случае возникает сложность в представлении структуры пользователю. Это возможно решить путем использования базы данных, в которой все имеются записи относительно логической и физической структуры пользовательского хранилища. При этом пользователь в режиме просмотра структуры будет получать информацию только из базы данных, а при конкретных операциях с данными (копирование/удаление, скачивание и прочее) информация будет поступать из хранилища.
Таким образом, при организации вышеописанной файловой системы возможно:
Более быстрый ответ сервера на запросы пользователя
Большая защищенность данных пользователя
Меньшая нагрузка на хранилище за счет снижения количества файловых операций
При работе пользователя с сервером необходимо осуществить конечное соединение пользователя с тем сервером, на котором расположена его директория
50% дипломной работы недоступно для прочтения
Закажи написание дипломной работы по выбранной теме всего за пару кликов. Персональная работа в кратчайшее время!
