Проектная работа Image previewer service

Общее описание

Сервис предназначен для изготовления preview (создания изображения с новыми размерами на основе имеющегося изображения).

Пример превьюшек в папке examples

Архитектура

Сервис представляет собой web-сервер (прокси), загружающий изображения, масштабирующий/обрезающий их до нужного формата и возвращающий пользователю.

Основной обработчик

http://cut-service.com/fill/300/200/www.audubon.org/sites/default/files/a1_1902_16_barred-owl_sandra_rothenberg_kk.jpg

<---- микросервис ----><- размеры превью -><--------- URL исходного изображения --------------------------------->

В URL выше мы видим:

• http://cut-service.com/fill/300/200/ - endpoint нашего сервиса, в котором 300x200 - это размеры финального изображения.
• www.audubon.org/sites/default/files/a1_1902_16_barred-owl_sandra_rothenberg_kk.jpg - адрес исходного изображения; сервис должен скачать его, произвести resize, закэшировать и отдать клиенту.

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

• Работаем только с HTTP.
• Ошибки удалённого сервиса или проксируем как есть, или логируем и отвечаем клиенту 502 Bad Gateway.
• Поддержка JPEG является минимальным и достаточным требованием.

Важно: необходимо проксировать все заголовки исходного HTTP запроса к целевому сервису (www.audubon.org в примере).

Сервис должен сохранить (кэшировать) полученное preview на локальном диске и при повторном запросе отдавать изображение с диска, без запроса к удаленному HTTP-серверу.

Поскольку размер места для кэширования ограничен, то для удаления редко используемых изображений необходимо использовать алгоритм "Least Recent Used".

Конфигурация

Основной параметр конфигурации сервиса - разрешенный размер LRU-кэша.

Он может измеряться как количеством закэшированных изображений, так и суммой их байт (на выбор разработчика).

Развертывание

Развертывание микросервиса должно осуществляться командой make run (внутри docker compose up) в директории с проектом.

Тестирование

Реализацию алгоритма LRU нужно покрыть unit-тестами.

Для интеграционного тестирования можно использовать контейнер с Nginx в качестве удаленного HTTP-сервера, раздающего вам заданный набор изображений.

Необходимо проверить работу сервера в разных сценариях:

• картинка найдена в кэше;
• удаленный сервер не существует;
• удаленный сервер существует, но изображение не найдено (404 Not Found);
• удаленный сервер существует, но изображение не изображение, а скажем, exe-файл;
• удаленный сервер вернул ошибку;
• удаленный сервер вернул изображение;
• изображение меньше, чем нужный размер; и пр.

Разбалловка

Обязательные требования

• Наличие юнит-тестов на ключевые алгоритмы (core-логику) сервиса.
• Наличие валидных Dockerfile и Makefile для сервиса.
• Ветка master успешно проходит пайплайн в CI-CD системе (на ваш вкус, Circle CI, Travis CI, Jenkins, GitLab CI и пр.). Пайплайн должен в себе содержать:
  • запуск последней версии golangci-lint на весь проект с конфигом, представленным в данном репозитории;
  • запуск юнит тестов командой вида go test -race -count 100;
  • сборку бинаря сервиса для версии Go не ниже 1.14.

При невыполнении хотя бы одного из требований выше - максимальная оценка за проект 4 балла (незачёт), несмотря на, например, полностью написанный код сервиса.

Дополнительные требования

• Реализован HTTP-сервер, проксирующий запросы к удаленному серверу - 2 балла.
• Реализована нарезка изображений - 2 балла.
• Кэширование нарезанных изображений на диске - 1 балл.
• Ограничение кэша одним из способов (LRU кэш) - 1 балл.
• Прокси сервер правильно передает заголовки запроса - 1 балл.
• Написаны интеграционные тесты - 3 балла.
• Тесты адекватны и полностью покрывают фукнционал - 1 балл.
• Проект возможно собрать чере make build, запустить через make run и протестировать через make test - 1 балл.
• Понятность и чистота кода - до 3 баллов.

Зачёт от 10 баллов ( Максимум - 15 баллов )

Использование сторонних библиотек для core-логики допускается, но:

• вы должны иметь представление о том, что происходит внутри.
• точно ли подходит данная библиотека для решения вашей задачи?
• не станет ли библиотека узким местом сервиса?
• не полезнее ли написать функционал, которые вы хотите получить от библиотеки, самому?

---

Для упрощения проверки вашего репозитория, рекомендуем использовать значки GitHub (GitHub badges), а также Go Report Card.

---

Авторы ТЗ:

• Дмитрий Смаль
• Антон Телышев