Динамический ресайзинг изображений (Image Previewer)
Сервис принимает URL с параметрами метода, ширины, высоты, схемы и адреса исходного изображения. Поддерживаются три базовых режима: Fill заполняет контейнер с сохранением пропорций и возможной обрезкой, Fit вписывает изображение целиком с пустыми зонами, Stretch растягивает картинку до нужных размеров без сохранения пропорций.
Для кэширования выбран подход Cache-Aside: приложение сначала ищет готовое изображение в кэше, а при промахе обращается к источнику, генерирует результат и сохраняет его. Так кэш заполняется только реально востребованными вариантами, а при проблемах с кэшем сервис всё равно может работать с origin напрямую.
Из-за ограниченного места для хранения используется LRU: самые давно неиспользуемые изображения вытесняются первыми, а часто запрашиваемые остаются ближе к началу структуры. В архитектуре собственного CDN это выглядит как цепочка клиент, граничный кэш, Image Previewer, локальный SSD-кэш и origin, где можно хранить один оригинал, а нужные версии создавать по запросу.
Коротко
- Image Previewer работает как прокси: принимает запрос, проверяет кэш, при промахе скачивает оригинал, меняет размер и сохраняет результат.
- Fill обрезает лишнее ради заполнения, Fit сохраняет всё изображение с пустыми зонами, Stretch растягивает картинку без сохранения пропорций.
- Cache-Aside выбран потому, что кэш заполняется только востребованными изображениями, а сервис не становится полностью зависимым от кэша.
- LRU удаляет самые давно неиспользуемые файлы и подходит для сценариев, где чаще повторно запрашивают недавно использованные изображения.
- Архитектура с edge cache, локальным SSD-кэшем и origin позволяет хранить один оригинал и генерировать версии под устройства на лету.
FAQ
Зачем нужен динамический ресайзинг изображений, если можно заранее подготовить версии для mobile, tablet и desktop?
Он позволяет хранить один оригинал и создавать нужный размер только по запросу. Это снижает объём хранения и упрощает поддержку новых размеров и форматов.
Чем методы Fill, Fit и Stretch отличаются друг от друга при изменении изображения под заданный контейнер?
Fill заполняет контейнер и может обрезать края, Fit показывает всё изображение целиком с пустыми областями, Stretch точно подгоняет размеры, но искажает пропорции.
Почему для такого сервиса выбран Cache-Aside с LRU, а не Read-Through или другие схемы кэширования?
Cache-Aside оставляет приложению возможность обращаться к источнику напрямую и не превращает кэш в единую точку отказа. LRU помогает удалять редко используемые варианты при ограниченном месте.
Читайте также
Как тимлид заменил десятки вкладок на файловую систему и Claude Code- Проблемы с производительностью веб-сервисов: как находить и устранять
- Как я делаю бэкапы домашней системы Linux: практичный пример rsync + btrfs с максимальным сжатием
- От хаоса к системе: как выстроить процесс Discovery (часть 1)
- Ваша LLM стримит в никуда: разбираемся, как работать с дисконнектами в FastAPI
- Динамический image proxy для ресайзинга изображений: Для сайтов с большим количеством изображений можно не хранить отдельные версии под каждый размер экрана, а генерировать нужную вариацию по запросу. Сервис работает как прокси: принимает параметры размера и метода обработки, проверяет готовый результат в кэше, при промахе скачивает оригинал, ресайзит его и сохраняет финальный файл.
[Техническая архитектура / Изображения и CDN]
Зарегистрированные пользователи видят только два тезиса.
Зарегистрироваться
Image Previewer — пример сервиса, который на лету меняет размер изображений, работает как умный прокси и снижает необходимость хранить много готовых версий одного файла. Ключевая схема: запрос, проверка кэша, загрузка оригинала при промахе, ресайзинг, сохранение результата и отдача пользователю.