Изначально мы сформировали следующие бизнес-требования к архитектуре «Битрикс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 готов обеспечить доступность на уровне двух девяток после запятой. А вероятность потери данных – одна миллиардная процента.   

Два датацентра и mater-master репликация

Весь проект сейчас размещается в 4 датацентрах Amazon (в США и Ирландии). Мы решаем этим сразу две задачи: во-первых, распределяем нагрузку (сейчас российские пользователи работают в одном ДЦ, а американские и европейские — в другом), а во-вторых, резервируем все сервисы — в случае выхода из строя одного из ДЦ, мы просто переключаем трафик на другой. 
  
База в каждом ДЦ является мастером относительно слейва во втором ДЦ и одновременно слейвом — относительно мастера. 
  
Каждый портал (все зарегистрированные в нем сотрудники), заведенный в «Битрикс24» в каждый конкретный момент времени работает только с одним ДЦ и одной базой. Переключение на другой ДЦ осуществляется только в случае какого-либо сбоя. 
  
Базы в разных датацентрах синхронны, но при этом независимы друг от друга: потеря связности между датацентрами может составлять часы, данные синхронизируются после восстановления. 

Мы интенсивно используем master-master репликацию. Если выходит из строя или перезагружается сервер БД, клиенты прозрачно переключаются на второй. 
  
Надежность и отказоустойчивость

Один из важнейших приоритетов в «Битрикс24» – постоянная доступность сервиса и его отказоустойчивость. 
  
В случае аварии на одной или нескольких веб-нодах Load Balancing определяет вышедшие из строя машины и, исходя из заданных параметров группы балансировки (минимально необходимое количество запущенных машин), автоматически восстанавливается нужное количество инстансов. 
  
Если теряется связность между датацентрами, то каждый датацентр продолжает обслуживать свой сегмент клиентов. После восстановления коннективити, данные в базах автоматически синхронизируются. 
  
Если же выходит из строя полностью датацентр, или же, например, происходит сбой на базе, то весь трафик автоматически переключается в работающий датацентр. 
  
Если это вызывает повышенную нагрузку на машины, то CloudWatch определяет возросшую утилизацию CPU и добавляет нужное количество машин уже в одном датацентре в соответствие с правилами для AutoScaling. 
  
При этом у нас приостанавливается мастер-мастер репликация. После проведения нужных работ (восстановительных — в случае аварии, или плановых — мы, например, точно по такой же схеме в какой-то момент осуществили переход со стандартного MySQL на Percona Server — при этом без какого-либо downtime'а для пользователей сервиса), включаем базу в работу и восстанавливаем репликацию. 
  
Если все прошло штатно, трафик снова распределяется на оба датацентра. Если при этом средняя нагрузка стала ниже порогового значения, то лишние машины, которые мы поднимали для обслуживания возросшей нагрузки, автоматически гасятся. 
  
Для облачных сервисов является достаточно большой проблемой вопрос обновления функционала и системного ПО. Иногда они вынуждены временно отключать сервис, предупреждать пользователей, проводить работы в ночное время. Наша архитектура позволяет все это проделывать незаметно для пользователей. 
  
Интегрированные веб-сервисы 

(Интеграция веб интерфейсов в Битрикс24 без дополнительных инструментов) 
  
Технология WebRTC: звонки, видеозвонки, телефония 

Видеозвонки в Битрикс24 - приватные, надежные видеопереговоры внутри компании - реализованы на основе технологии WebRTC. Соединение зашифровано, осуществляется между собеседниками - peer-to-peer, происходит практически прозрачно, «внутри» браузера. 

SIGNALING 
  
Signaling выполняет три простые задачи: 
  
1) Состыковать конфигурации двух браузеров (аудио/видео потоки, кодеки, адреса и порты — в формате SDP) 

2) Обмен паролями для установки зашифрованного соединения между браузерами 

3) Инициация действий — позвонить тому-то (соединить поток клиента А с потоком клиента Б на callbacks в js), положить трубку и т.п. 
  
Т.е. через signaling браузеры состыковываются друг с другом и появляется возможность совершать видеозвонки. 
  
Звонить получается просто в локальной сети, но когда сотрудники в разных сетях, да еще за файерволами — браузеры не смогут установить соединение без посторонней помощи. 
  
1) Для «пробивки» файерволов компании сотрудники обращаются по протоколам STUN/TURN к центральному серверу. 

2) Если «пробить» файерволы не удалось, медиапотоки идут через сторонний сервер, а не peer-to-peer между браузерами (в режиме «relay»). 
  
Видеоконференции 
  
В WebRTC в видеоконференции каждый браузер держит видеопоток каждого участника. 
  
WebRTC и телефония 
  
В Битрикс24 выполнена интеграция со «шлюзами» для возможности совершения звонков на обычные телефонные номер из/в компанию. 
  
Технология Композитный сайт для ускорения работы

В «Битрикс24» используется уникальная технология «Композитный сайт», реализованная в платформе «1С-Битрикс», которая объединяет в себе высокую скорость загрузки статического сайта и все возможности динамического сайта. 
  
Страница веб-ресурса разделяется на 2 составляющие: статическую и динамическую. Статическая часть кешируется и отображается мгновенно. Пользователь сразу видит содержимое и может работать с ним. Динамическая часть подгружается в фоновом режиме и кешируется в браузере посетителя. В результате пользователь мгновенно получает контент страницы. 
  
Цель технологии «Композитный сайт» - ускорить выдачу страницы пользователю за счёт выделения, последующей обработки и довыдачи зон с динамичным контентом дополнительным ajax-запросом. 

Суть технологии «Композитный сайт» - в том, что в шаблонах компонентов, из которых создаётся динамичная страница, размечаются специальные зоны, в которых содержится динамичный контент. При обращении пользователя к странице система создаёт кеш статической части страницы, в которые вставлен специальный JS, обращающийся к серверу за актуальными данными. При повторном обращении того же или другого пользователя система отдаёт созданный файл кеша, а затем довыдаёт динамичный контент. 
  
REST API Битрикс24 

Партнеры «1С-Битрикс» могут создавать собственные приложения для сервиса. При разработке приложения доступны REST-методы для: 

• CRM;
• хранилища данных (инфоблоки);
• уведомлений;
• задач;
• работы с пользователями;
• работы с подразделениями;
• живой ленты;
• календарей;
• телефонии.

Все приложения для «Битрикс24» можно разделить на 3 типа: 
  
1) Приложения, размещаемые в облаке «1С-Битрикс». Обычно загружаются в виде архива, который содержит в себе весь необходимый html, стили, javascript, картинки. Точкой входа такого приложения считается файл index.html. Инсталлятором - install.html, при его наличии. 

2) Приложения, размещаемые на сторонних серверах. При регистрации приложения в Маркетплейс указываются прямые ссылки на точку входа и инсталлятор этого приложения, которые будут открыты в интерфейсе Битрикс24. 

3) Внешние приложения - приложения используют только API, и никак не интегрируются в интерфейс Битрикс24. Внешние приложения служат для получения данных, которые будут использоваться, например, для ваших web-, desktop- или мобильных приложений. 
  
В целях безопасности для отображения на портале приложение вставляется в IFRAME рабочей области. В IFRAME загружается ссылка, указанная при регистрации приложения. Если приложение было загружено в виде архива, то ссылка берется с сайта 1С-Битрикс. 
  
Авторизация приложения осуществляется посредством протокола OAuth 2.0. Для приложений, интегрирующихся в интерфейс Битрикс24 (открывающихся в IFRAME), авторизация проводится автоматически. 
  
Из IFRAME нельзя получить доступ к родительскому окну. Это большой плюс с точки зрения безопасности, но минус с точки зрения разработки. Использование в приложении специальной JavaScript-библиотеки позволит частично обойти ограничения, связанные с работой приложения внутри IFRAME и дает дополнительный интерфейс для вызова методов REST API на стороне клиента.