Comments 25
Наконец то статья как на старом добром Хабре ) Хотя я не про пхп и ларавел, но получил удовольствие от прочтения. И кое-то новое отметил для себя. Спасибо за хорошо оформленный пост
о технических деталях масштабной работы
Открыл консоль разработчика. Заглавная – 218 запросов, 26Мб. Грузится 30 секунд.
Всё как положено когда говорят о «масштабной работе» – рассыпуха крошечных нежатых скриптов и цсс-ок, картинки 200px шириной, переданные в разрешении 2000х2000, фотки в png, и пр.
Перешёл по первой попавшейся ссылке, в Лекторий, и загрузки картинок не дождался. Плюнул на 70 мегах.
Хваститься тут можно только вижуалом – и то если догрузится. «А как дысал, как дысал».
Да, вы правы: изображения действительно весят больше, чем хотелось бы.
На этапе переноса контента со старого сайта мы столкнулись с ограничениями импорта, и для заказчика в тот момент было важнее сохранить пропорции десятков тысяч изображений.
Варианты оптимизации уже предложены, частично используются на главной странице и скоро будут применены ко всему порталу.
Бюрократия и госуха - зло.
Я посмотрел, что там в Лектории. Там фотографии в разрешении 10000 x 6000px, размерами по 50Mb каждая. Вот такие они, лучшие практики веба в 2025 году.
А зачем redis + memcached, если достаточно первого?
Memcached:
Используется для кэширования.
Показывает лучшие результаты.
Легко масштабируется.
Redis:
Используется для:
работы с множествами;
управления очередями.
Не хотелось держать все яйца в одной корзине, поэтому мы разделили задачи между двумя технологиями.
Зачем? Чтобы обслуживание подороже было? Сложно поднять второй редис?
1 — Redis
1 — Memcached
Или
2 — Redis
Разницы в цене обслуживания нет. При этом Memcached показал лучшую производительность при кэшировании и проще масштабируется при необходимости.
Интересно, а среди причастных к созданию этого продукта есть те, кто, при нхождении в коде запросов к БД в цикле, начинает писать гневные статьи, проклинать "вкатунов" и т.п.?
Ну, при том, что это 20-50 запросов на странице получается в итоге...
Как??? Ну как??? Что нужно было сделать такое, чтобы хоумпага делала 200+ запросов куда-то (за картинками?)
Это даже мне, хроническому рукожопу и ретрограду, интересно.
Причина — в особенностях строения главной страницы сайта.
Её дизайн не является предустановленным: весь контент динамичный. Большая часть элементов формируется из админ-панели, и каждый виджет содержит изображения, события, баннеры, карусели и т.п., что увеличивает количество запросов к S3.
На главной странице не обнаружено 200+ запросов к S3.
Читая, что текст, что ответы, Алексея Постригайло, чувствуется, что общаешься с ЧатомГПТ. Даже не Гемини или Клауд. Именно что с ChatGPT
Там еще менюшка верхняя в 768px обрезается - слово "Конта". Это то, как будет сайт выглядеть на ipad-ах, не очень новых, но с актуальной версией ios/safari (18.x.x), в вертикальной ориентации.
С бутстрапом настройка всей этой адаптивной дичи производится за пару минут на каждый блок (даже такими рукожопами, как я), но это же не модно...
Почитать было интересно хотя бы потому, что статья про подкапотное пространство. Но вот неточностей много.
Мы с архитектором решили разделить систему на три ключевых микросервиса
На схеме нет ни одного микросервиса. Есть монолитный api, есть фронт и есть монолит админки. Не надо ради хайпа все подряд называть микросервисом. Например потому, что у вас по сути одна база данных на все. И масштабировать по отдельности, как заявлено, не получится - компоненты зависимы.
Не надо бояться монолита - это нормальная архитектура для ряда кейсов. И ее можно оптимизировать, о чем вы по сути и пишете.
Судя по всему это самое api отдельное приложение, админка отдельное, разве в этом случае api не масштабируемо? Общая бд возможна, есть даже паттерн Shared database. Возможна репликация бд...
Я же не говорил, что оно не масштабируемо :) Я говорил о том, что это не микросервисы.
Про масштабирование я сказал о том, что оно возможно, но будет осложняться, так как при Shared database
люди из разных команд/доменов будут толкаться локтями в одном пространстве
общую большую БД сложнее и дороже скалировать, так как она будет жрать много в отличие от маленьких баз данных
например, если вырастет нагрузка на API, то она начнет долбить ту самую общую БД, что зааффектит админку и другие части приложения. А graceful degradation тут прикрутить будет труднее, так как все равно нужен будет доступ к общей БД
Ну и так далее.
Основной мой посыл тут в том, что в статье есть ряд допущений. В пример я привел указание применение "микросервисов".
Если же мы говорим про гибкость, то по сути все приложение построено так, чтобы запрос не долетел до БД (как до самой медленной части). И если запросы начнут долетать до БД, то гибкость закончится, так как одна БД плохо масштабируется. Отсюда и начинается реальное деление на сервисы (причем, пока даже без приставки "микро").
Как мы снизили время отклика в 15 раз на новом портале ВДНХ через Laravel + Nuxt и масштабируемую архитектуру