Lachestry

Фармакология и торговля лекарственными препаратами

Прямо всю логику ИМ каждый раз делаете с нуля? Или у вас какое то полукоробочное решение есть?

А вы на битрикс реализовывали? и точки были как поддомены или просто на продакте наличие в магазине отображали?

Количество точек кратно увеличивает сложность. В том то и фишка, что на одной онлайн витрине держать условные 100к+ симпл ску не такая проблема, а когда нужно поддержать актуальность еще в тысячах оффлайн точек, в сабсторах И так далее - задача попадает на другой уровень.

Привет, к сожалению, NDA. Это сеть федерального уровня, топ 3 в своей категории.

Согласен с мнением, что метрики и прозрачные дашборды есть лучший способ показать прозрачность работы и ее эффективность.

Классно было бы дальше развивать по регионам

Сергей, а можете сказать какой RPS на такой витрине? А также как быстро отрабатывает загрузка каталога/продуктовы страниц? И по продуктам, мы говорим о простых продуктах с минимумом аттрибутов/опций?

Я поясню, как это происходит у нас. Приходит клиент, с уже ощутимой проблемой производительности, например долгая загрузка категорий/страниц продуктов, и мы действуем от этих вводных, анализируя что к этому привело и что можно улучшить.

Инхауз девопс не самое бюджетное вложение, для поддержки коробки, как мне кажется. Также не очень понятно как девопсом решить вопрос оптимизации, а тем более доработок?

Тут я не спорю, шаблоны, невысокая стоимость реализации и количество подрядчиков говорят в пользу платформы

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

Рина, приветствую. Хотел бы уточнить, что не статья рекламная, а вы перешли по баннеру, который продвигает данную статью. Что касается контента статьи, мы разбираем как именно можно масштабировать систему построенную на Битрикс и в каких случаях.

Вадим, приветствую, спасибо за комментарий.

bitrixVM: решение верное (в рамках монолита), но так же требующее devops для обслуживания и настройки. Разделение на фронт+бек приложения даёт больше гибкости в использовании микросервисов и их балансировке. Волшебной кнопки "сделать хорошо и дёшево", к сожалению, не существует.

Если ИМ выходит на федеральный уровень, то нас уже не спасает шардирование БД или кеша - требуются решения, в которые заложено масштабирование. К примеру:
- ElasticSearch (поиск)
- Couchbase (кеширование)
- Kafka (очереди)
- gRPC (RPC С балансировкой)
- Log storage/engine (мониторинг)

Данные сервисы подразумевают не просто написание новых модулей, а скорее отказ от существующих.

В рамках Битрикса можно выделить и слабые стороны:
- ORM и DBAL: крайне слабое решение в отношении формирования как запросов, так и (де)гидрации объектов
- IoC или service locator (как вариант): отсутствует как понятие
- Локализация: требует оптимизации по слиянию, для уменьшения iops
- Отсутствие понятия репозиториев и хранения "рабочих" сущностей в рамках запроса, что порождает лишние выборки одних и тех же данных

Привет, а можете аргументировать свой ответ? Был ли опыт использования платформы и что бы вы предложили в кейсах, рассмотренных в статье?

Зависимость есть в любом случае, как и от внутренней команды разработки и процессов так и зависимость/риски от работы с внешним подрядчиком. Я бы все таки смотрел от потребности решить те или иные задачи оперативно/эффективно.

Antonio, добрый день.
Во-первых, спасибо за проявленный интерес к нашему сайту и клиентам, раз даже пошли снимать метрики🙏
Насчет них - реализация данного решения была на другом проекте. На Ригле также есть в планах.
Если интересно дообсудить - можно в ЛС или по почте (тоже с сайта можно взять).

Vlad, все верно, речь идет о запросе.