Практический опыт миграции больших проектов на Битрикс на микросервисную архитектуру
C 2007 года мы делаем проекты на bitrix framework. В том числе большие и сложные, с посещаемостью от 100000 уникальных посетителей в сутки.
Если продукт растет, рано или поздно вы придете к микросервисам. При работе с монолитом и единым фреймворком кажется, что это лучшее решение - одинаковый стек для любой части продукта. Но в этом и проблема, вы ограничены этим стеком и не можете применять новые современные решения.
Кроме того, в монолите все части проекта зависимы друг от друга и если в одном месте что-то пошло не так, это отражается на работе всего продукта.
Вы зависите от рынка разработчиков, если вдруг он качнулся и разработчики на вашем стеке стали стоить дорого, в случае с монолитом гораздо сложнее подключить разработчиков на более выгодных условиях для вас.
Кроме того, в монолите все части проекта зависимы друг от друга и если в одном месте что-то пошло не так, это отражается на работе всего продукта.
Вы зависите от рынка разработчиков, если вдруг он качнулся и разработчики на вашем стеке стали стоить дорого, в случае с монолитом гораздо сложнее подключить разработчиков на более выгодных условиях для вас.
В какой момент пора переходить на микросервисы
Как правило, понимание о необходимости перехода на микросервисы приходит в момент, когда продукт уже вовсю работает, есть много живых пользователей и продукт является частью бизнеса, т.е зарабатывает деньги.
Скорее всего к этому моменту вы уже попробовали разные средства оптимизации, перешли на более производительную СУБД, решили вопрос с кешированием, но все равно чувствуете, что упираетесь в потолок и что-то постоянно тормозит или падает.
Скорее всего к этому моменту вы уже попробовали разные средства оптимизации, перешли на более производительную СУБД, решили вопрос с кешированием, но все равно чувствуете, что упираетесь в потолок и что-то постоянно тормозит или падает.
В этот момент нужно взять таймаут, собрать команду и вместе задуматься об изменениях.
В нашем случае миграция требовалась на огромных проектах - монолитах на Битриксе. С большой нагрузкой, посещаемостью и множеством сервисов типа email-маркетинга, рассылок с отчетами, десятками интеграций с разными сервисами.
В процессе и после миграции все сервисы должны были работать как прежде, только лучше и быстрее. А все изменения нужно сделать так, чтобы ничего не упало, при этом старые модули приложения постепенно заменились новыми незаметно для пользователей.
В процессе и после миграции все сервисы должны были работать как прежде, только лучше и быстрее. А все изменения нужно сделать так, чтобы ничего не упало, при этом старые модули приложения постепенно заменились новыми незаметно для пользователей.
Так как же перейти с монолита на Битриксе на микросервисы?
Каждый случай уникален, поэтому расскажем как миграция происходила у нас и объясним, почему именно так.
Этапы миграции:
Плюсы:
Минусы:
В результате:
Процесс перехода выполнен бесшовно для пользователей. На новой платформе пользователи отметили существенно более высокую скорость работы интерфейса. После обновления кодовой базы повысилось качество и прозрачность работы приложения и процессов разработки.
Достигнута основная цель - Битрикс исключен из приложения вместе с рудиментами: не используемые сервисы, лишние таблицы БД и т.д.
Выполнен переход к современной платформе разработки и архитектуре приложения.
Этапы миграции:
- Создание нового бекенда API. Мы решили выполнить переход на Laravel. В первую очередь мы решили перенести бизнес-логику приложения на новый бекенд API. Заодно, избавившись от старого кода и оптимизируя новый. В процессе предыдущей разработки было очень много легаси, который остался от разных команд.
- Создание полностью нового фронтенда для работы с новым бекендом API
- Вынос отдельных критических сервисов типа файлового хранилища в микросервис. Чтобы использовать его параллельно в монолите на битрикс и новом бекенде API и новом фронтенде.
- В процессе перехода на микросервисы, пока не готов новый фронтенд, Битрикс становится чистым фронтендом. Логика реализованная на новом бекенде заменяет логику монолита. В компонентах Битрикса обращения к внутреннему API bitrix framework заменяются на обращения к новому API бекенда. Битрикс получает данные уже от нового бекенда api, но шаблоны использует пока еще свои.
- Бизнес-логика приложения переносится целиком на новый бекенд API, весь старый код в компонентах Битрикса заменяется вызовами к новому бекенд API.
- По готовности нового фронтенда, который уже работает с новым бекенд API, переключаем главный домен на работу с новым фронтендом и исключаем из схемы битрикс целиком.
Плюсы:
- Пользователи переходят единовременно на новый интерфейс с новым фронтендом и бекендом.
- Имеем чистую и обновленную кодовую базу на Laravel.
- Архитектура полностью готова чтобы дальше дробить бекенд API на микросервисы.
- Команды и разработчики могут гибко комбинироваться и работать независимо: фронтендеры, бекендеры и тд.
Минусы:
- Процесс сложный и долгий. Многие процессы должны выполняться одновременно и довольно четко. Например, придется обеспечивать параллельную работу монолита, нового бекенда api, использующие одну БД. Выполнять различные синхронизации и костыли чтобы все работало как единое целое. Для этого мы использовали различные синхронизации через очереди. Что добавило сложности, но позволило обеспечить стабильную параллельную работу монолита и нового бекенда API.
- Требуется выполнять работы по созданию нового фронтенда вместе с большим объемом других задач. Идея была в том, чтобы перенести старый интерфейс из Битрикс один в один на новый фронтенд. Однако, в процессе, были внесены десятки различных улучшений, что замедлило работу.
- Требуется тщательный контроль релизов и максимальное покрытие тестами. Это необходимо с учетом кратно возрастающей сложности переходного периода.
В результате:
Процесс перехода выполнен бесшовно для пользователей. На новой платформе пользователи отметили существенно более высокую скорость работы интерфейса. После обновления кодовой базы повысилось качество и прозрачность работы приложения и процессов разработки.
Достигнута основная цель - Битрикс исключен из приложения вместе с рудиментами: не используемые сервисы, лишние таблицы БД и т.д.
Выполнен переход к современной платформе разработки и архитектуре приложения.