3й этап - перевод frontend части интернет-магазина на новый современный технический стек. Современные технологии - Vue, React и т. п. легче кастомизируются и поддерживаются, лидеры рынка используют их в реализации своих проектов, однако, для работы с этими технологиями требуется API, чтобы выдавать нужные данные для формирования страниц. После перехода на микросервисную архитектуру не составит проблем реализовать API, чтобы передавать нужные данные на frontend и заменить его на современный стек. При этом есть другой путь - реализация API для перехода на другой стек frontend-а внутри Bitrix, но более оптимальным будет последовательное движение по обозначенным выше шагам с постепенным переходом на микросервисную архитектуру и уходом от “коробочного” решения frontend-части.
А как же масштабируемость и балансировка кластера? Вообще битрикс себя очень хорошо ведет и многое что можно разнести по разным серверам и т.д.
Не могу ничего сказать, однако микросервисы решение ровно такое же....
Да, в статье вы правы, если мы берем DNS - то тут битрикс не вывезет и т.д, но и статья - откровенная реклама микросервисов, которых уже написались с 2015 года.
Лучше бы написали на чем вы пишите - laravel, lumen, yii? Какие метрики у вас сейчас и какие были на битриксе? А так - статья реклама - фактов 0
Вадим, приветствую, спасибо за комментарий.
bitrixVM: решение верное (в рамках монолита), но так же требующее devops для обслуживания и настройки. Разделение на фронт+бек приложения даёт больше гибкости в использовании микросервисов и их балансировке. Волшебной кнопки "сделать хорошо и дёшево", к сожалению, не существует.
Если ИМ выходит на федеральный уровень, то нас уже не спасает шардирование БД или кеша - требуются решения, в которые заложено масштабирование. К примеру:
- ElasticSearch (поиск)
- Couchbase (кеширование)
- Kafka (очереди)
- gRPC (RPC С балансировкой)
- Log storage/engine (мониторинг)
Данные сервисы подразумевают не просто написание новых модулей, а скорее отказ от существующих.
В рамках Битрикса можно выделить и слабые стороны:
- ORM и DBAL: крайне слабое решение в отношении формирования как запросов, так и (де)гидрации объектов
- IoC или service locator (как вариант): отсутствует как понятие
- Локализация: требует оптимизации по слиянию, для уменьшения iops
- Отсутствие понятия репозиториев и хранения "рабочих" сущностей в рамках запроса, что порождает лишние выборки одних и тех же данных
У вас статья рекламная. Чтобы плясать на якобы уже почти трупе огромной системы - могли бы хотя бы статейку в оборот не пускать) ох уж эта "нативность" 🤣
Рина, приветствую. Хотел бы уточнить, что не статья рекламная, а вы перешли по баннеру, который продвигает данную статью. Что касается контента статьи, мы разбираем как именно можно масштабировать систему построенную на Битрикс и в каких случаях.