На чем написан битрикс24
Мой МеморизИТ
В русскоязычном сегменте Интернета существует такой интересный феномен, как Битрикс.
Для обывателя — это такая серьезная система, «продукт», на котором нужно разрабатывать серьезные проекты: корпоративные порталы, интернет магазины и даже CRM системы. Все очень серьезно, почти как опыты нацистов над инопланетянами (на канале Рен-тв сразу после рекламы).
Для программиста, который прочитал хоть одну книгу про программирование, Битрикс — это так называемый «плохокод», просто-напросто огромное количество PHP файлов, написанных в разном стиле, которые подключаются «инклудом» и что-то там выводят.
Эта статья для обывателя (потребителя). Как правило, такой обыватель, прежде чем сделать выбор CMS, читает статьи под названием «плюсы и минусы Битрикса», которые пишут люди, далекие от программирования. Данная статья написана программистом, потому плюсов тут быть не может.
1. Архитектура
Я испытываю чувство унижения, чувство несправедливости и обмана, когда снова и снова приходится делать какие-то доработки Битрикс сайта.
Дело в том, что умные люди со всего мира пытаются упорядочить, систематизировать и усовершенствовать архитектурные решения в программировании. Из-под пера лучших программистов рождаются «паттерны»: это некие чертежи и схемы участков больших систем, не привязанные к конкретному языку программирования. Это очень ценная информация, опыт предков, данный молодым программистам, чтобы они не теряли время на решение возникающих проблем архитектуры (то самое чувство, когда хочется взять и написать все с нуля).
Битрикс — это полное отсутствие архитектуры. Это просто набор десятков или сотен тысяч файлов с кусками кода, которые никак не связаны между собой. В хороших системах данные крутятся вокруг контроллера, модели и представления, там есть определенные «типы», — это данные, которые наследуют интерфейсы и прочие вещи, благодаря которым программист, не вникая в бизнес-логику конкретного сайта, может понять, как распоряжаться этими данными в каждом новом проекте. Это все опыт десятилетий.
В Битриксе же все написано так называемой «лапшой»: это когда школьник садится за компьютер на уроке информатики и записывает свою мысль от начала и до конца в виде кода в одном файле. Таких школьников в классе 30 и каждый написал свой компонент в своем стиле. Потом встает вопрос, как это все связать в систему? Чтобы понять, откуда берутся те или иные данные в «продукте» 1С Битрикс, нужно делать поиск по коду в файловой системе. Иногда, чтобы все сломать, достаточно поменять местами два компонента, которые обмениваются данными друг с другом через какой-то костыль, который придумал программист (порой общение между компонентами происходит через сессию или другую глобальную переменную).
2. Код
Это просто унизительно, продавать за деньги систему, в которой HTML код перемешан с JS, PHP и CSS. Ниже я приведу функцию «продукта». Чтобы ее поняли и люди, далекие от программирования, еще ниже будет пояснение. Эта функция — метод класса (. ) ядра (. ) Битрикса, который вызывается, как статический (. ) и ему передается 21 аргумент по ссылке (. ).
(пересчитал еще раз — 22, по штуке на каждого нового программиста, который дописывал этот метод)
Чем это плохо? Что чувствует программист, видя это? Объясню: вот приходите вы в банк, платите 200 рублей, чтобы вам заполнили платежное поручение (ведь вы занятой человек, у вас нет времени). Вы отдаете деньги, но эти бюрократы заявляют, что чтобы воспользоваться любой услугой банка, в том числе «заполнение поручения», вам нужно заполнить анкету: ИНН, номер паспорта и прочие многоциферные штуки. У вас возникает недоумение: но я же заплатил деньги, чтобы мне было комфортно и удобно, чтобы ничего не надо было заполнять? Но ведь у банка напротив вообще не нужно заполнять никаких поручений, можно просто бесплатно ввести один 4-значный код для проведения платежа!
Банком напротив являются бесплатные фреймворки, а вашим банком — расхваливаемый маркетологами платный Битрикс.
Вы не найдете ни одного программиста, который бы перешел с фреймворков на Битрикс.
3. Обман.
Не хотелось бы писать тут слишком много. Скажу кратко: если вы выбрали 1С Битрикс, чтобы его просто так взять и связать с 1С своего предприятия стандартным модулем — у вас ничего не получится. И много чего другого у вас не получится просто взять и сделать стандартным модулем. У вас все получится, только если вы ничего не будете менять в скачанном архиве, состоящем из тысяч каких-то PHP файлов. Все доработки — это боль, тлен и тысячи трудочасов программиста, который знает программирование на уровне языка разметки и написания сценариев, а не архитектуры.
Заключение
Статья написана программистом и описывает то, что у Битрикса под капотом. Снаружи это действительно удобно и презентабельно. В итоге, это можно охарактеризовать, как продукт хороших маркетологов, которые работают без хороших программистов.
Чтобы статья была менее провокационной, скажу также, что современным бесплатным фреймворкам наоборот, не хватает маркетологов: их продукты имеют высокий порог вхождения и доступны только узкой группе лиц, они никогда не станут народными, как Битрикс.
Минусы Битрикса, или Битрикс глазами программиста : 1 комментарий
Добавить комментарий Отменить ответ
Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.
Архитектура Битрикс24
Изначально мы сформировали следующие бизнес-требования к архитектуре Битрикс24:
Эти бизнес-требования обозначили два больших «фронта» работ: формирование масштабируемой отказоустойчивой облачной платформы разработки и выбор технологической платформы для инфраструктуры проекта.
Битрикс24 представлен в виде веб-кластера взаимозаменяемых серверов. При увеличении посещаемости можно быстро добавить в кластер новые серверы; в случае выхода из строя одного или нескольких серверов кластера все продолжает работать на оставшихся серверах, система продолжает беспрерывно обслуживать клиентов. Поддержка облачных файловых хранилищ решает проблему синхронизации статического контента, а реализация поддержки master-master репликации в MySQL позволяет строить географически распределенные веб-кластеры.
Отказоустойчивая архитектура
В качестве платформы мы используем Amazon AWS, однако, возможно размещение и на других платформах.
Автоматическое масштабирование
Приложение (веб) масштабируется у нас не вертикально (увеличение мощности сервера), а горизонтально (добавляем новые машины).
Для этого мы используем связку Elastic Load Balancing + CloudWatch + Auto Scaling. Все клиентские запросы (HTTP и HTTPS) поступают на один или несколько балансировщиков Amazon (ELB). Рост и снижение нагрузки мониторится через CloudWatch. Есть две интересные метрики – состояние нод EC2 (% CPU Utilization) и балансировщика (время latency – в секундах).
При увеличении нагрузки стартуют новые серверы, при ее уменьшении – они автоматически выключаются. Тем самым мы снижаем себестоимость (ненужные серверы не работают вхолостую).
Статический контент пользователей сервиса
При создании каждого нового портала в Битрикс24 для него создается персональный аккаунт в Amazon для хранения данных в S3. Тем самым данные каждого портала полностью изолированы друг от друга. При этом само хранилище S3 очень надежно.
Данные в S3 реплицируются в несколько точек. При этом в территориально распределенные точки (разные датацентры). Каждое из устройств хранилища мониторится и быстро заменяется в случае тех или иных сбоев.
Когда вы загружаете новые файлы в хранилище, ответ об успешной загрузке вы получите только тогда, когда файл будет полностью сохранен в нескольких разных точках. Обычно данные реплицируются в три и более устройств – для обеспечения отказоустойчивости даже в случае выхода из строя двух из них.
Архитектура S3 устроена таким образом, что Amazon готов обеспечить доступность на уровне двух девяток после запятой. А вероятность потери данных – одна миллиардная процента.
15 датацентров и master-master репликация
Весь проект сейчас размещается в 15 датацентрах в разных странах мира. Данные клиентов размещаются на территории той страны, в которой это требуется по закону. Мы решаем этим сразу две задачи: во-первых, распределяем нагрузку (например российские пользователи работают в одном ДЦ, а американские и европейские – в другом), а во-вторых, резервируем все сервисы: в случае выхода из строя одного из ДЦ, мы просто переключаем трафик на другой.
База в каждом ДЦ является мастером относительно слейва во втором ДЦ и одновременно слейвом – относительно мастера.
Каждый портал (все зарегистрированные в нем сотрудники), заведенный в «Битрикс24» в каждый конкретный момент времени работает только с одним ДЦ и одной базой. Переключение на другой ДЦ осуществляется только в случае какого-либо сбоя.
Базы в разных датацентрах синхронны, но при этом независимы друг от друга: потеря связности между датацентрами может составлять часы, данные синхронизируются после восстановления.
Мы интенсивно используем master-master репликацию. Если выходит из строя или перезагружается сервер БД, клиенты прозрачно переключаются на второй.
Надежность и отказоустойчивость
Один из важнейших приоритетов в «Битрикс24» – постоянная доступность сервиса и его отказоустойчивость.
В случае аварии на одной или нескольких веб-нодах Load Balancing определяет вышедшие из строя машины и, исходя из заданных параметров группы балансировки (минимально необходимое количество запущенных машин), автоматически восстанавливается нужное количество инстансов.
Если теряется связность между датацентрами, то каждый датацентр продолжает обслуживать свой сегмент клиентов. После восстановления связности данные в базах автоматически синхронизируются.
Если же выходит из строя полностью датацентр, или же, например, происходит сбой на базе, то весь трафик автоматически переключается в работающий датацентр.
Если это вызывает повышенную нагрузку на машины, то CloudWatch определяет возросшую утилизацию CPU и добавляет нужное количество машин уже в одном датацентре в соответствии с правилами для AutoScaling.
При этом у нас приостанавливается мастер-мастер репликация. После проведения нужных работ (восстановительных – в случае аварии, или плановых – мы, например, точно по такой же схеме в какой-то момент осуществили переход со стандартного MySQL на Percona Server – при этом без какого-либо downtime’а для пользователей сервиса), включаем базу в работу и восстанавливаем репликацию.
Если все прошло штатно, трафик снова распределяется на датацентры. Если при этом средняя нагрузка стала ниже порогового значения, то лишние машины, которые мы поднимали для обслуживания возросшей нагрузки, автоматически останавливаются.
Для облачных сервисов является достаточно большой проблемой вопрос обновления функционала и системного ПО. Иногда они вынуждены временно отключать сервис, предупреждать пользователей, проводить работы в ночное время. Наша архитектура позволяет все это проделывать незаметно для пользователей.
Технология WebRTC: звонки, видеозвонки, телефония
Видеозвонки в Битрикс24 – приватные. Надежные видеопереговоры внутри компании реализованы на основе технологии WebRTC. Соединение зашифровано, осуществляется между собеседниками peer-to-peer, происходит практически прозрачно, «внутри» браузера.
SIGNALING
Signaling выполняет три простые задачи:
Т.е. через signaling браузеры соединяются друг с другом, что позволяет совершать видеозвонки.
Звонить легко и просто получается в локальной сети. Но когда сотрудники в разных сетях, да еще за файерволами – браузеры не смогут установить соединение без посторонней помощи:
Видеоконференции
В видеоконференции, используя WebRTC, каждый браузер держит видеопоток каждого участника.
WebRTC и телефония
В Битрикс24 выполнена интеграция со «шлюзами» для возможности совершения звонков на обычные телефонные номера из/в компанию.
Технология Композитный сайт для ускорения работы
В Битрикс24 используется уникальная технология «Композитный сайт», реализованная в платформе «1С-Битрикс». Она объединяет в себе высокую скорость загрузки статического сайта и все возможности динамического сайта.
Страница портала разделяется на 2 составляющие: статическую и динамическую. Статическая часть кешируется и отображается мгновенно. Пользователь сразу видит содержимое и может работать с ним. Динамическая часть подгружается в фоновом режиме и кешируется в браузере посетителя. В результате пользователь мгновенно получает контент страницы.
Цель технологии «Композитный сайт» – ускорить выдачу страницы пользователю за счёт выделения, последующей обработки и довыдачи зон с динамическим контентом с помощью дополнительного ajax-запроса.
Суть технологии «Композитный сайт» заключается в том, что в шаблонах компонентов, из которых создаётся динамичная страница, размечаются специальные зоны. В этих зонах содержится динамичный контент. При обращении пользователя к странице система создаёт кеш статической части страницы, в которые вставлен специальный JS, обращающийся к серверу за актуальными данными. При повторном обращении пользователя система отдаёт созданный файл кеша, а затем довыдаёт динамичный контент.
REST API Битрикс24
Партнеры «1С-Битрикс» могут создавать собственные приложения для сервиса. При разработке приложения доступны REST-методы для:
Все приложения для «Битрикс24» можно разделить на 3 типа:
Обычно загружаются в виде архива, который содержит в себе весь необходимый html, стили, javascript, картинки. Точкой входа такого приложения считается файл index.html. Инсталлятором – install.html (при его наличии).
При регистрации приложения в Маркетплейс24 указываются прямые ссылки на точку входа и инсталлятор этого приложения, которые будут открыты в интерфейсе Битрикс24.
Приложения используют только API, и никак не интегрируются в интерфейс Битрикс24. Внешние приложения служат для получения данных, которые будут использоваться, например, для ваших web-, desktop- или мобильных приложений.
В целях безопасности для отображения на портале приложение вставляется в IFRAME рабочей области. В IFRAME загружается ссылка, указанная при регистрации приложения. Если приложение было загружено в виде архива, то ссылка берется с сайта 1С-Битрикс.
Авторизация приложения осуществляется посредством протокола OAuth 2.0. Для приложений, интегрирующихся в интерфейс Битрикс24 (открывающихся в IFRAME), авторизация проводится автоматически.
Из IFRAME нельзя получить доступ к родительскому окну. Это большой плюс с точки зрения безопасности, но минус с точки зрения разработки. Использование в приложении специальной JavaScript-библиотеки позволит частично обойти ограничения, связанные с работой приложения внутри IFRAME, и дает дополнительный интерфейс для вызова методов REST API на стороне клиента.
Все эти технологии позволили нам создать такой сервис, который используют более 4 000 000 компаний, и постоянно его развивать!
Битрикс24 помогает бизнесу работать. Бесплатно. Неограниченно. Онлайн.
Архитектура Битрикс24 — взгляд изнутри
12 апреля мы запустили большой новый проект — «Битрикс24»: социальный интранет, SaaS-сервис, объединяющий в себе классические инструменты командной работы (календари, задачи, CRM, работа с документами) и социальные коммуникации («лайки», социальный поиск, мгновенные сообщения и многое другое).
Первый прототип этого сервиса был запущен еще в феврале прошлого года. На одном сервере, без каких-либо особенных возможностей для масштабирования, без резервирования на уровне датацентра… 🙂 Только концепт.
Этой публикацией мы откроем серию постов, в которых хотели бы рассказать вам, что было сделано за год разработки, какой получилась итоговая архитектура проекта; что мы делаем для того, чтобы обеспечить настоящие «24» часа работы проекта в сутки; какие изменения пришлось сделать в платформе разработки «1С-Битрикс»; особенности работы в облаке Amazon и многое другое.
Очень хотим, чтобы наш опыт оказался полезен для всех разработчиков, которые только планируют запускать или уже эксплуатируют и поддерживают крупные веб-проекты и сервисы.
Итак, первый пост — об архитектуре проекта в целом. Поехали!
В процессе разработки самой идеи «Битрикс24» мы сформулировали для себя несколько бизнес-задач:
Эти бизнес-требования в итоге сформировали два больших «фронта» работ: формирование масштабируемой отказоустойчивой (забегая немного вперед — «облачной») платформы разработки и выбор технологической платформы для инфраструктуры проекта.
Платформа разработки «1С-Битрикс»
Традиционное устройство веб-приложений очень плохо масштабируется и резервируется. В лучшем случае — мы можем разнести по разным серверам само приложение, кэш и базу. Можем как-то масштабировать веб (но при этом должны будем решить вопрос синхронизации данных на веб-серверах). Кэш и база масштабируются уже хуже. А о распределенном гео-кластере (для резервирования на уровне датацентров) речь вообще не идет.
Огромным шагом в развитии платформы «1С-Битрикс» стало появление модуля «Веб-кластер» в версии 10.0 весной прошлого года.
Мы подробно писали о нем на Хабре. Кратко повторю основные возможности:
В итоге мы получили возможность представить наш проект в виде веб-кластера взаимозаменяемых серверов. Все выглядело очень и очень неплохо: при увеличении посещаемости можно было быстро добавить в кластер новые серверы; в случае выхода из строя одного или нескольких серверов кластера все продолжало работать на оставшихся серверах, система продолжала беспрерывно обслуживать клиентов.
Но до идеала было еще далеко, оставались «узкие» места:
В платформе «1С-Битрикс» версии 11.0, вышедшей осенью 2011 года, мы решили и эти задачи. Поддержка облачных файловых хранилищ решила проблему синхронизации статического контента, а реализация поддержки master-master репликации в MySQL позволила строить географически распределенные веб-кластеры.
И мы вплотную подошли ко второй большой задаче…
Платформа для разворачивания инфраструктуры
Если честно, выбор был не очень сложным. 🙂
«Облако» или не «облако» — такой вопрос даже не стоял. 🙂
Собственное или арендуемое оборудование требует достаточно серьезных вложений в инфраструктуру на старте проекта. Масштабировать физические «железки» достаточно сложно (долго и дорого). Администрировать (особенно в разных ДЦ) — неудобно.
Какое именно? Мы выбрали Amazon AWS.
Все наши сайты работают в Амазоне достаточно давно. Нам нравится то, что есть множество уже готовых сервисов, которые можно просто брать и использовать в своем проекте, а не изобретать собственные велосипеды: облачное хранилище S3, Elastic Load Balancing, CloudWatch, AutoScaling и многое другое.
В очень упрощенном виде вся архитектура «Битрикс24» выглядит примерно так:
Web – автоматическое масштабирование
Приложение (веб) масштабируется у нас не вертикально (увеличение мощности сервера), а горизонтально (добавляем новые машины).
Для этого мы используем связку Elastic Load Balancing + CloudWatch + Auto Scaling. Все клиентские запросы (HTTP и HTTPS) поступают на один или несколько балансировщиков Amazon (ELB). Рост и снижение нагрузки мониторим через CloudWatch. Есть две интересные метрики – состояние нод EC2 (% CPU Utilization) и балансировщика (время latency – в секундах).
Мы в качестве основной характеристики используем данные о загрузке машин, так как latency может варьироваться не только из-за реальной нагрузки, но и по каким-то иным причинам: сетевые задержки, ошибки в приложении и т.п. В таком случае возможны «ложные» срабатывания, и тогда мы крайне неэффективно будем добавлять новые машины.
Сейчас в итоге автоматически стартуют новые машины, если средняя утилизация CPU (в терминах Амазона) превышает 60%, и автоматически останавливаются и выводятся из эксплуатации, если средняя нагрузка менее 30%.
Мы достаточно долго экспериментировали с этими пороговыми значениями и сейчас считаем их оптимальными. Если верхний порог ставить больше (например, 70-80%), то начинается общая деградация системы – пользователям работать некомфортно (долго загружаются страницы). Нижний порог меньше — система балансировки становится не очень эффективной, машины долго могут работать вхолостую.
Статический контент пользователей сервиса
В описанной выше схеме веб-ноды по сути становятся «расходным материалом». Они могут в любой момент стартовать и в любой момент гаситься. А это значит, что никакого пользовательского контента на них быть не должно.
Именно поэтому при создании каждого нового портала в «Битрикс24» для него создается персональный аккаунт в Амазоне для хранение данных в S3. Тем самым данные каждого портала полностью изолированы друг от друга.
При этом само хранилище S3 очень надежно. Сам Амазон подробно описывает его устройство (и, в принципе, нет поводов им не верить).
Данные в S3 реплицируются в несколько точек. При этом – в территориально распределенные точки (разные датацентры).
Каждое из устройств хранилища мониторится и быстро заменяется в случае тех или иных сбоев.
Когда вы загружаете новые файлы в хранилище, ответ об успешной загрузке вы получите только тогда, когда файл будет полностью сохранен в нескольких разных точках.
Обычно данные реплицируются в три и более устройств – для обеспечения отказоустойчивости даже в случае выхода из строя двух из них.
Иными словами, с надежностью – все хорошо. Тот же Амазон, например, говорит о том, что их архитектура S3 устроена таким образом, что они готовы обеспечить доступность на уровне двух девяток после запятой. А вероятность потери данных – одна миллиардная процента.
Два датацентра и master-master репликация
Весь проект сейчас размещается в двух датацентрах. Мы решаем этим сразу две задачи: во-первых, распределяем нагрузку (сейчас российские пользователи работают в одном ДЦ, а американские и европейские — в другом), а во-вторых, резервируем все сервисы — в случае выхода из строя одного из ДЦ, мы просто переключаем траффик на другой.
Чуть-чуть подробнее — как это все устроено.
База в каждом ДЦ является мастером относительно слейва во втором ДЦ и одновременно слейвом — относительно мастера.
Важные настройки в MySQL для реализации этого механизма — auto_increment_increment и
auto_increment_offset. Они задают смещения значений для полей auto_increment — для того, чтобы избежать дублирования записей. Грубо говоря, в одном мастере — только четные ID, в другом — только нечетные.
Каждый портал (все зарегистрированные в нем сотрудники), заведенный в «Битрикс24» в каждый конкретный момент времени работает только с одним ДЦ и одной базой. Переключение на другой ДЦ осуществляется только в случае какого-либо сбоя.
Базы в разных датацентрах синхронны, но при этом независимы друг от друга: потеря связности между датацентрами может составлять часы, данные синхронизируются после восстановления.
Надежность, надежность, надежность
Один из важнейших приоритетов в «Битрикс24» – постоянная доступность сервиса и его отказоустойчивость.
Помните простую схему сервиса? В итоге (все равно упрощенно, но тем не менее :)) она выглядит примерно так:
В случае аварии на одной или нескольких веб-нодах Load Balancing определяет вышедшие из строя машины и, исходя из заданных параметров группы балансировки (минимально необходимое количество запущенных машин), автоматически восстанавливается нужное количество инстансов.
Если теряется связность между датацентрами, то каждый датацентр продолжает обслуживать свой сегмент клиентов. После восстановления коннективити, данные в базах автоматически синхронизируются.
Если же выходит из строя полностью датацентр, или же, например, происходит сбой на базе, то весь траффик автоматически переключается в работающий датацентр.
Если это вызывает повышенную нагрузку на машины, то CloudWatch определяет возросшую утилизацию CPU и добавляет нужное количество машин уже в одном датацентре в соответствие с правилами для AutoScaling.
При этом у нас приостанавливается мастер-мастер репликация. После проведения нужных работ (восстановительных — в случае аварии, или плановых — мы, например, точно по такой же схеме в какой-то момент осуществили переход со стандартного MySQL на Percona Server — при этом без какого-либо downtime’а для пользователей сервиса), включаем базу в работу и восстанавливаем репликацию.
Если все прошло штатно, траффик снова распределяется на оба датацентра. Если при этом средняя нагрузка стала ниже порогового значения, то лишние машины, которые мы поднимали для обслуживания возросшей нагрузки, автоматически гасятся.
Этот первый пост я постарался сделать «легким», обзорным. 🙂 Если бы вместил все то, чем хочется поделиться, в один текст и рассказал обо всем нашем опыте сразу, то получилось бы слишком много букв. 🙂
Мне кажется более логичным сделать серию тематических постов. Темы которые, мы уже готовим:
Что наиболее интересно для вас? Можно провести спонтанное голосование и отмечать прямо в комментариях. 🙂
Ну и конечно — пробуйте сам «Битрикс24»! Первый тариф — бесплатный. Если его лимитов или функционала не хватит — можно будет перейти на старшие тарифы. 🙂
Подключайтесь — и работайте с удовольствием!