В первой части мы спроектировали микросервисную архитектуру.
Во второй части разработали RESTful API Service на Golang cо Swagger и авторизацией.
Третья часть была посвящена знакомству с графовой БД Neo4j и работе над микросервисами CategoryService и APIService.
Четвертая часть была посвящена разработке микросервисов.
Мы продолжаем создание системы заметок. На этот раз посмотрим на разработанный File Service, который работает с хранилищем MinIO. Но сначала разберёмся с самим хранилищем и его настройкой.
Знакомство с хранилищем MinIO
MinIO создано для размещения неструктурированных данных, таких как фотографии, видеозаписи, файлы журналов, резервные копии, а также образы виртуальных машин и контейнеров. Небольшой размер позволяет включать его в состав стека приложений. В MinIO также поддерживается распределённый режим (Distributed mode), который предоставляет возможность подключения к одному серверу хранения объектов множества дисков, в том числе расположенных на разных машинах.
MinIO крайне минималистичо, у него нет красивого и функционального UI. Но по части использования ресурсов оно крайне жадное — оперативную память и процессор кушает достаточно много. Также хочу отметить, что такие известные решения, как FreeNAS и TrueNAS под капотом используют именно MinIO.
В MinIO используется внутренний механизм избыточного кодирования (Erasure coding), обеспечивающий системе достаточную устойчивость, чтобы она оставалась работоспособной даже при отказе половины дисков. Также хранилище управляет целостностью и безопасностью данных, используя собственное хеширование и шифрование на стороне сервера.
Производительность MinIO сильно зависит от конфигурации операционной системы и файловой системы, на которой будут храниться файлы. По сути, этот инструмент даёт лишь метод хранения объектов поверх файловой системы и никак не влияет на саму файловую систему. Если у вас есть задача хранить и оперировать миллиардами объектов, необходимо подумать в первую очередь о файловой системе, которая будет использоваться под MinIO.
Использование MinIO Erasure Coding
Erasure Coding — это программная защита данных от повреждения и потери. Как рейд, только намного надёжней. Если классический RAID 6 может позволить себе потерять 2 диска, то MinIO спокойно переживает потерю половины.
Вся информация хранится в виде блоков данных, к которым есть блоки чётности. И вроде это всё уже было сделано много раз, только есть важное «но»: мы можем явно указывать соотношение блоков чётности к блокам данных для хранимых объектов.
Хотите 1:1? Пожалуйста! Хотите 5:2? Без проблем! Очень важная функция, если вы используете сразу несколько нод и хотите найти свой собственный баланс между максимальной безопасностью данных и количеством затраченных ресурсов.
Из коробки MinIO использует формулу N/2 (где N — общее количество дисков), т.е. делит ваши данные между N/2 дисками данных и N/2 дисками чётности. Перевожу на человеческий: можно потерять половину дисков и восстановить данные. Это соотношение задаётся через Storage Class, позволяя вам самостоятельно выбрать, что важнее — надёжность или ёмкость.
Предположим, что у вас инсталляция на 16 дисков и вам надо сохранить файл размером 100 Мб. Если используются настройки по умолчанию (8 дисков под данные, 8 под блоки чётности), то файл в итоге займёт практически двойной объём т.е. 200 Мб. Если отношение дисков будет 10/6, то понадобится 160 Мб. 14/2 — 114 Мб.
Настройка и запуск MinIO
Cкачиваем файлы docker-compose.yml и nginx.conf, после чего можно запускать.
Давайте поближе посмотрим docker-compose файл.
По дефолту здесь 4 сервиса MinIO. Их количество можно увеличить до 16, но мы уменьшим до 2, чтобы сохранить кластер. Большее количество узлов для нас сейчас избыточно. Также здесь описан сервис NGINX, для которого мы скачивали конфигурацию. Он нужен для балансировки запросов между узлами кластера.
Описание сервисов MinIO по сути одинаковое. Давайте посмотрим на minio1:
image с тегом релиза от определенной даты;
два volume, их можно распределить по разным физическим дискам, чтобы обеспечить отказоустойчивость;
наружу выставляется 9000 порт для обращения к API;
указываются переменные среды с логином и паролем доступа к MinIO;
команда для запуска сервера MinIO в URL которой используется синтаксис указания множества серверов: [http://minio{1…2}](http://minio{1…2})/data{1…2} раскрывается как массив http://minio1/data1 и http://minio2/data2;
Далее описан healthcheck, который позволяет мониторить здоровье сервиса. У него есть параметр test. Это Shell-команда, которая вызывает Curl и передает ему URL для проверки того, живёт ли сервис. Делать такую проверку мы будем каждые 30 секунд. Если за 20 секунд сервис не ответит, он будет помечен как нездоровый.
Запустив compose-файл, открываем интерфейс в браузере. Слева в сайдбаре отображены бакеты — корзины, в которых хранятся файлы, справа — список файлов в бакете. Функционал здесь минимален: можно загрузить, расшарить или удалить файл и создать или удалить бакет.
На этом знакомство с MinIO завершено, далее — продолжение разработки системы заметок с нуля.
Исходный код проекта на GitHub
Какая текущая ситуация? Мы разработали все сервисы. Осталось реализовать веб-клиент в виде приложения на Vue.js, а также заняться инфраструктурой системы, такой как Service Discovering и OpenTracing, упаковать все сервисы в docker-контейнеры и настроить CI/CD.
