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