Системная архитектура
Микросервисные принципы, положенные в основу архитектуры Платформы «Эра», обеспечивают высочайшие показатели качества реализуемых на её основе программных решений.
О микросервисной архитектуре
Архитектура Платформы «Эра» полностью соответствует понятию "Микросервисная архитектура" – она состоит из небольших и легко изменяемых модулей — микросервисов (ролей), каждый из которых выполняет определенную функцию и взаимодействует с другими через API. Микросервисная архитектура особенно эффективна для крупных систем, где необходимо обеспечить быструю разработку и поддержку разнообразных функций. Микросервисная архитектура предоставляет имеет следующие преимущества:
Высокая отказоустойчивость: при падении одного сервиса остальные продолжают работать.
Гибкость: возможность быстро внедрять новые технологии и легко откатывать изменения.
Простота: меньшее количество кода облегчает понимание работы системы и сокращает время на разработку.
Лёгкость внедрения нового кода: быстрый деплой из-за небольшого количества кода.
Масштабируемость: возможность добавлять и расширять необходимые сервисы без влияния на всю систему.
Платформа состоит микросервисов, каждый из которых несет определённую роль.
Роль: Autoprovision (ap)
Назначение: Обрабатывает запросы от устройств, поступающие по протоколам TFTP и PNP. Active-Active применяется для процессов TFTP. Active-Passive для процессов PNP и управления кэшем MAC-адресов.
Роль: Back to back UserAgent (b2b)
Назначение: Роль, организующая коммутацию между SIP устройствами, путем создания двусторонних диалогов. Производит маршрутизацию и вызов соответствующих устройств с организацией медиа-потока между ними. Резервируется и масштабируется в режиме Active-Active.
Роль: Broker (broker)
Назначение: Системный брокер сообщений. Обеспечивает прием и сохранение данных без нарушения порядка поступления. Резервируется в режиме Active-Passive.
Роль: Border Gate’s Media Gate (bgmg)
Назначение: Пограничный медиа-шлюз, замыкающий медиа потоки на внешних интерфейсах. Может быть зарезервирована на одном сервере в режиме Active-Active с непересекающимися настройками нескольких экземпляров.
Роль: Domain Folder Syncrhonizator (dfsync)
Назначение: Служебная роль, обеспечивающая синхронизацию файлов каталога: SYNC между различными серверами системы. Принципиально не резервируется, накрывая экземплярами всю сеть серверов.
Роль: Conference SIP Service (conf)
Назначение: Реализует сервис конференц-связи по SIP. Резервируется и масштабируется в режиме Active-Active.
Развертывание с разным уровнем отказоустойчивости
Развертывание на одном сервере
Резервирование Active-Passive — это архитектура, в которой основной экземпляр платформы (Active) выполняет всю рабочую нагрузку, а резервный экземпляр платформы (Passive) находится в ожидании. Резервная система включается только в случае сбоя основной. Такой подход используется для геораспределенного резервирования при использовании двух дата-центров. В отличие от Active-Active систем, переключение в Active-Passive может занять некоторое время, что может привести к кратковременному простою.
Развертывание на двух серверах в режиме active-active
Развертывание на двух серверах в режиме active-passive
Микросервисы платформы целиком и полностью обслуживаются одним физическим или виртуальным сервером. Микросервис-оркестратор следит за работоспособностью остальных компонентов платформы. Преимуществом архитектуры является простота развертывания и обслуживания, а также бэкапирования и переноса на другой сервер.
В рамках этой архитектуры микросервисы размещены на двух серверах и работают в режиме active-active. Это позволяет существенно увеличить доступность сервисов, предоставляемых платформой. В случае отказа одного из серверов обслуживание продолжается на втором активном сервере. Также возможно разделение нагрузки между активными серверами. Подобная архитектура используется в рамках одного дата-центра с постоянным и быстрым сетевым доступом между серверами.
Слои платформы «Эра»
Мастер домен платформы
После установки платформы через веб интерфейс становится доступно приложение Рут. Через приложение Рут можно авторизоваться в мастер домене и зайти в приложение Настройки. В приложении Настройки мастер-домена доступна функция создания дочерних доменов и назначения в них администратора.
Рабочий домен платформы без продуктового слоя
Через веб интерфейс платформы доступно приложение Рут, через которое можно авторизоваться в рабочем домене. В рабочем домене доступно приложение Настройки, в котором к функции создания дочернего рабочего домена добавляются функции настройки АТС: подключения, аккаунты, маршрутизация, мониторинг. Из приложения настройки доступно приложение Редактор сценариев.
Рабочий домен платформы с продуктовым слоем
При установке в рабочий домен продуктового слоя, к платформе добавляется функция разработки и со исполнения пакетов. В составе продуктового слоя к платформе добавляются системные пакеты, содержащие в том числе приложения, реализующие собственную бизнес-функциональность. Становится доступной возможность до установить в платформу какой-либо пакет, разработанный вне данного экземпляра системы, либо разработать собственный проектный пакет.
Мастер домен платформы с продуктовым слоем
Продуктовый слой можно установить в мастер домен. В этом случае через системный пакет в мастер домене реализуются бизнес-функции мониторинга производительности, а через приложение Билдер становится возможным до устанавливать и разрабатывать собственные пакеты.
Слои платформы «Эра»
Платформенный (коммуникационный) слой
Микросервисы, которые обеспечивают как внутренние сервисы самой платформы, так и ряд сервисов, которые предоставляют непосредственную функциональность связанную с коммуникациями.
Продуктовый слой
Микросервисы, которые исполняются под управлением платформы и реализуют функциональность контакт-центра, а также приложения и микросервисы (Builder), предназначенные для создания проектных приложений.
Проектный слой
Приложения, разрабатываемые в соответствии с требованиями конкретного проекта, исполняемые в среде продуктового слоя, а также проектные микросервисы.
Видео о технологиях и архитектуре платформы
В видео дается описание технологического стека и архитектуры платформы Эра, а также указывается на использование различных технологий и инструментов, таких как Erlang, Mnesia, PostgreSQL, ClickHouse, Docker, микросервисная архитектура, REST API, ETL и других.
Содержание этого видео
Серверы работают под управлением операционной системы Linux. Поддерживаются российские операционные системы, которые есть в реестре российского ПО. Развертывается через докер-контейнер. Широкий спектр поддерживаемых СУБД, между которыми распределяются данные в зависимости от специфики работы. Все real-time данные, которые обеспечивают работу системы, хранятся в очень производительной СУБД Mnesia, которая распределяется между серверами кластера, если их несколько, и обеспечивает очень большое количество операций в секунду. Все настройки, архивы и прочие жизненно важные данные, как правило, хранятся в Postgres. При этом архивы хранятся в таблицах с партициями. При удалении старых разговоров или какой-то еще устаревшей информации, достаточно удалить partition. Это происходит мгновенно. Файлы сразу с диска удаляются и не приводят к фрагментации и последующему торможению базы данных.

В случае, если Postgres не хватает, либо требуется интеграция с внешними BI-системами, мы поддерживается работа с KAFKA и Clickhouse. Это позволяет обеспечить и дополнительный уровень отказоустойчивости, и очень высокую производительность при построении отчетов.

Снаружи абсолютно вся функциональность, которую мы видим из приложений, и даже чуть больше, доступна через REST API, как по HTTPS, так и через WebSocket, в том числе, через их безопасные версии HTTPS и VSS.

Архитектура микросервисная и с точки зрения сервисов можно разделить систему на два слоя. Первый слой, нижний, это слой платформы, где обеспечена вся работа с данными, коммуникациями, телефонией. Там порядка 50 микросервисов. разработанных на языке Erlang и работающих под управлением OTP. И сверху есть продуктовые сервисы. К ним относятся все, что связано с call-центром, все пользовательские приложения и все, что мы можем разработать на Билдере. Там используется язык TypeScript, и эти микросервисы работают под управлением платформы Node.js. Как план минимум, все эти микросервисы, порядка сотни штук, могут находиться на одном сервере.
При этом этот сервер будет подключаться и к провайдерам, к нему будут подключаться абоненты, он будет интегрироваться с внешними системами и с ним же будут работать пользователи. Понятно, что здесь будет минимум по отказу устойчивости, но этот сервер в состоянии обслужить достаточно высокую нагрузку. В случае, если нам одного сервера не хватает, а это может произойти по двум причинам, либо не хватает вычислительных ресурсов, либо нам нужна дополнительная отказоустойчивость. то мы можем развернуть кластер из двух серверов. В этом случае внешние системы и пользователи могут работать как с одним, так и с другим в зависимости от конфигурации. И при попадании одного из серверов происходит автоматическое переключение на другой. Если нужно гарантированно сохранять текущие разговоры, то нужно четыре и более сервера, потому что необходимо разделить медиа и сигнализацию телефонии.

С точки зрения потребления ресурсов процессора, основных показателей мы выделяем три основных показателя. Это количество звонков в секунду ЦПС, количество сессий IVR, которые разговаривают с нашими абонентами в автоматическом режиме и количество живых разговоров, где мы выполняем коммутацию и, как правило, ведем запись. С точки зрения оперативной памяти, больше всего ее потребляют большие кол-листы. Если у нас в кол-листах миллионы контрагентов, то, как правило, мы их либо сразу загружаем при старте компании, либо плавно и постепенно. С точки зрения места на диске, понятно, что здесь основное место занимают записанные разговоры, ну и плюс растущие со временем базы данных.

В рамках одного из проектов было успешно проведено нагрузочное тестирование. Онлайн были подключены 600 операторов, непрерывно работала исходящая компания с ЦПС 80 звонков в секунду и шли входящие по 6 штук в секунду. Таким образом, одновременно было активных более 2000 разговоров. За 72 часа теста мы совершили более 20 миллионов звонков. Всю эту нагрузку обслуживали 4 из 16 ядерных сервера, на которых ядра были загружены примерно на треть.
Обеспечение доступности
Микросервисная архитектура «Эра» позволяет при развертывании решения разнести микросервисы по различным серверам, обеспечивая таким образом сохранение доступности системы при аппаратном сбое.

Обеспечение масштабируемости
Микросервисная архитектура «Эра» позволяет удовлетворять возрастающие требования к объему использования решения поддерживая её вертикальное или горизонтальное масштабирования.
Напишите нам
Оставьте заявку и мы вам перезвоним. Отправляя сообщение вы соглашаетесь с правилами обработки персональных данных.
  1. Autoprovision (ap) Процессор автопровижена. Обрабатывает запросы от устройств, поступающие по протоколам TFTP и PNP. Active-Active применяется для процессов TFTP. Active-Passive для процессов PNP и управления кэшем MAC- адресов.
  2. Back to back UserAgent (b2b) Роль организующая коммутацию между SIP устройствами, путем создания двусторонних диалогов. Производит маршрутизацию и вызов соответствующих устройств с организацией медиа-потока между ними. Резервируется и масштабируется в режиме Active-Active.
  3. Border Gate’s Media Gate(bgmg) Пограничный медиа-шлюз, замыкающий медиа потоки на внешних интерфейсах. Может быть зарезервирована на одном сервере в режимеActive-Active с непересекающимися настройками нескольких экземпляров.
  4. Broker (broker) Системный брокер сообщений. Обеспечивает прием и сохранение данных без нарушения порядка поступления. Резервируется в режимеActive-Passive.
  5. Call Storage (callstore) Хранилище активных звонков и их контекстов. Накапливает и агрегирует события жизненного цикла звонка. Резервируется в режимеActive-Passive.
  6. Conference SIP Service(conf) Реализует сервис конференц-связи по SIP.Резервируется и масштабируется в режиме Active-Active.
  7. Domain FolderSyncrhonizator (dfsync) Служебная роль, обеспечивающая синхронизацию файлов каталога :SYNC между различными серверами системы. Принципиально не резервируется, накрывая экземплярами всю сеть серверов.
  8. Data Model Server (dms) Сервис модели данных домена. Предоставляет CRUD API для остальных ролей и сервисов для управления экземплярами пользовательских/проектных коллекций. Резервируется в режимеActive-Passive.
  9. Domains Storage (domstore) Универсальное хранилище домена. Используется различными ролями как внутренний сервис. Резервируется в режимеActive-Passive.
  10. Email processor (email) Процессор обмена email-сообщениями с почтовыми серверами. Обеспечивает коммуникацию с почтовыми серверами (IMAP, STMP).Резервируется в режимеActive-Passive.
  11. External SIP Gate (esg) Точка доступа в кластер по SIPдля внешних устройств –провайдеров телефонии, шлюзов и вышестоящими и одноранговыми АТС, находящихся во внешнем номерном плане, не управляемом системой. Резервируется и масштабируется в режиме Active-Active.
  12. File Server (fs) Служебная роль, используемая для резервированного длительного хранения файлов на серверах системы. Резервируется и масштабируется в режиме Active-Active.
  13. Hunt Queue (huntq) Обеспечивает обслуживание очередей (к пользователям и SIP-пользователям).Резервируется в режимеActive-Passive.
  14. Infrastructure Controller (ic) Управляет изменениями в инфраструктуре внутри сайта, распределяет и синхронизирует конфигурации и поддерживает процесс обновления системы внутри сайта. Резервируется в режимеActive-Passive на каждом сайте. Не масштабируется.
  15. Instant messaging processor(im)Процессор обмена быстрыми сообщениями с мессенджерами. Обеспечивает коммуникацию с мессенджерами. Резервируется в режимеActive-Passive.
  16. Interactive Voice ResponseSIP Service (ivr) Сервис авто обслуживания SIP-звонков с помощью преднастроенных администратором IVR-сценариев. Резервируется и масштабируется в режиме Active-Active.
  17. Log Storage (logstore) Обеспечивает длительное хранение лог-файлов со всех серверов и нод. Существует внутри каждого сайта независимо от других. Резервируется в режимеActive-Passive.
  18. Master Domain Center (mdc) Хранилище сущностей домена. Предоставляет другим ролям внутри сайта доступ к данным для организации процессов. Резервируется в режимеActive-Passive.
  19. Meet (meet) Выполняет запуск сервера веб конференций Era Meet.Резервируется в режимеActive-Passive.
  20. Media Gate (mg) Медиа-шлюз, замыкающий медиа-потоки. Резервируется и масштабируется в режиме Active-Active.
  21. Media Gate Controller (mgc) Контроллер группы медиа-шлюзов, расположенных на том-же сайте. Резервируется в режимеActive-Passive.
  22. Master InfrastructureController (mic) Управляет изменениями в инфраструктуре всей системы, управляет распределением и синхронизацией конфигураций и процессом обновления. Резервируется в режимеActive-Passive.
  23. Mixer Controller (mixer) Обеспечивает подготовку, упаковку, сцепку и размещение файлов записей разговоров на основе событий системы. Резервируется и масштабируется в режиме Active-Active.
  24. Microservice controller (msvc) Обеспечивает подъем пользовательских/проектных микросервисов (внешние процессы).В соответствии с настройками сущности.
  25. Middleware (mware) Обеспечивает функции переноса данных между внутренними сервисами внутри сайта, а также контроля корректности работы. Резервируется в режимеActive-Passive.
  26. Prompt Server (prompt) Реализует сервис подключения к существующим разговорам для прослушивания и суфлирования. Резервируется и масштабируется в режиме Active-Active.
  27. Record Mover (recmover) Роль перемещения записей разговоров по доменным хранилищам. Перехватывает события о завершении микширования записей и перемещает записи в соответствии с правилами записи в файловые хранилища соответствующих доменов. Резервируется в режимеActive-Passive.
  28. Redirect SIP Service(redirect) Перенаправляет запросы SIP на один из SIP-гейтов текущего сайта. Обеспечивает возможность использования одного IP-адреса для устройств, подключенных к сайту, повышая его пропускную способность. Резервируется и масштабируется в режиме Active-Active.
  29. Registrar (sr) Хранилище регистраций подключений и устройств пользователей системы и SIP-пользователей. Резервируется в режимеActive-Passive.
  30. RPC Inner (rpci) Служебная роль, обеспечивающая регистрацию активных экземпляров ролей, резервирующихся в режиме Active-Passive.Резервируется в режимеActive-Active, но преимущественно применяется первый доступный экземпляр.
  31. RPC Outer (rpco) Служебная роль, обеспечивающая связь серверов между сайтами без прямого соединения типа full-mesh.Резервируется в режимеActive-Active, но преимущественно применяется первый доступный экземпляр.
  32. Reserver (rsv) Обеспечивает синхронизированное резервирование ресурсов домена на всех сайтах его обслуживания. Резервируется в режимеActive-Passive.
  33. Site Domain Center (sdc) Хранилище сущностей домена. Предоставляет другим ролям доступ к данным для организации процессов. Резервируется в режимеActive-Passive.
  34. Selector ConferenceController (sel) Обеспечивает управление селекторными совещаниями. Резервируется в режимеActive-Passive.
  35. SIP Gate (sg) Точка входа в кластер по SIP для внутренних устройств, определяемых учетными записями SIP-пользователей. Резервируется и масштабируется в режиме Active-Active.
  36. Storage (st) Универсальное хранилище сайта. Используется различными ролями как внутренний сервис. Резервируется в режимеActive-Passive.
  37. States & SubscriptionsStorage (sts) Хранилище состояний и подписок на изменения состояний пользователей системы и SIP-пользователей. Резервируется в режимеActive-Passive.
  38. Service Script Machine (svc) Сервис исполнения служебных сценариев, преднастроенных администратором. Резервируется и масштабируется в режиме Active-Active.
  39. User Center (usr) Обеспечивает логику обслуживания подключений пользователей к системе черезAPI в контексте управления состояниями. Резервируется в режимеActive-Passive.
  40. Voice Mail Server (vmail) Обеспечивает обслуживание голосовых ящиков и работу сервиса голосовой почты. Резервируется в режимеActive-Passive.
  41. Web Server (ws) Предоставляет доступ к APIсистемы через HTTP иWebSocket, а также обслуживает выдачу статических файлов системных и ролевых веб-приложений. Резервируется и масштабируется в режиме Active-Active.
  42. Web Service SubscriptionsStorage (wssubscr) Обслуживает подписки внешних сервисов на получение событий системы через API (HTTP иWebSocket).Резервируется в режимеActive-Passive.
  43. Builder.DataService Обработка данных: импорт, групповые операции и т.д. Резервируется в режимеActive-Passive.
  44. Builder.GeneratorService Обслуживание пакетов: активация, проверка, деактивация, экспорт импорт и т.д. Резервируется в режимеActive-Passive.
  45. Builder.HolderService Фасад пакета builder:распределение вызовов по сервисам-исполнителям Резервируется в режимеActive-Passive.
  46. Callcenter.ACDService Обработка вызовов омниканальными очередями ACDРезервируется в режимеActive-Passive.
  47. Callcenter.CCSService Обслуживание текущих и архивных звонков, разговоров и вызовов (Calls, Connections,Seances)Резервируется в режимеActive-Passive.
  48. Callcenter.Era ConnectorServiceВзаимодействие со слоем платформы в части обработки звонков: получение событий и выполнение команд. Резервируется в режимеActive-Passive.
  49. Callcenter.HolderService Фасад пакета callcenter:распределение вызовов по сервисам-исполнителям Резервируется в режимеActive-Passive.
  50. Callcenter.IvrService Внешнее управление голосовыми сценариями платформы. Резервируется в режимеActive-Passive.
  51. Callcenter.OperatorsService Обеспечение работы CTI-панели пользователей (OperatorStates)Резервируется в режимеActive-Passive.
  52. Callcenter.OutboundService Обслуживание исходящих кампаний. Резервируется в режимеActive-Passive.
  53. Callcenter.ScenarioService Исполнение голосовых сценариев продуктового слоя. Резервируется в режимеActive-Passive.
  54. Callcenter.UsersService Обеспечение работы статусов пользователей (UserStates)Резервируется в режимеActive-Passive.
  55. Email.EMailService Обработка электронных писем Резервируется в режимеActive-Passive.
  56. Email.HolderService Фасад пакета email:распределение вызовов по сервисам-исполнителям. Резервируется в режимеActive-Passive.
  57. Etl.HolderService Фасад пакета etl: распределение вызовов по сервисам-исполнителям. Резервируется в режимеActive-Passive.
  58. Etl.MainService Обслуживание процессов ETL –извлечение, обработка и загрузка данных. Резервируется в режимеActive-Passive.
  59. Helpdesk.HolderService Фасад пакета helpdesk:распределение вызовов по сервисам-исполнителям. Резервируется в режимеActive-Passive.
  60. Helpdesk.TicketsService Обслуживание заявок технической поддержки. Резервируется в режимеActive-Passive.
  61. Im.HolderService Фасад пакета im: распределение вызовов по сервисам-исполнителям. Резервируется в режимеActive-Passive.
  62. Im.MessagesService Обработка сообщений мессенджеров и управление диалогами. Резервируется в режимеActive-Passive.
  63. Im.RoutingService Маршрутизация сообщений мессенджеров. Резервируется в режимеActive-Passive.
  64. Im.ScenarioService Исполнение сценариев обработки сообщений мессенджеров. Резервируется в режимеActive-Passive.
  65. Meet.HolderService Фасад пакета meet:распределение вызовов по сервисам-исполнителям. Резервируется в режимеActive-Passive.
  66. Meet.MeetService Продуктовые надстройки над ВКС: создание комнат, генерация ссылок, рассылка приглашений и т.д. Резервируется в режимеActive-Passive.
  67. Platform.HistoryService Обслуживание универсальной истории объектов, поиск посредствам связи, создание перекрестных ссылок. Резервируется в режимеActive-Passive.
  68. Platform.HolderService Фасад пакета platform:распределение вызовов по сервисам-исполнителям. Резервируется в режимеActive-Passive.
  69. Platform.NotificationsSenderService Рассылка уведомлений пользователям. Резервируется в режимеActive-Passive.
  70. Platform.PerfmonService Мониторинг производительности серверов и сервисов. Принципиально не резервируется, накрывая экземплярами всю сеть серверов.
  71. Platform.WatchdogService Контроль за исполнением всех обращений к продуктовым сервисам, перевод в состояниеtimeoutРезервируется в режимеActive-Passive.
  72. Scenario.HolderService Фасад пакета scenario:распределение вызовов по сервисам-исполнителям. Резервируется в режимеActive-Passive.
  73. Scenario.MainService Генерация кода (компиляция) для продуктовых сценариев всех типов. Резервируется в режимеActive-Passive.
  74. Smart.HolderService Фасад пакета smart:распределение вызовов по сервисам-исполнителям. Резервируется в режимеActive-Passive.
  75. Smart.MainService Обслуживание обращений, контактов и контрагентов. Резервируется в режимеActive-Passive.
  76. Tester.GeneratorService Исполнение генераторов тестовых данных и прочих способов нагрузочного тестирования. Резервируется в режимеActive-Passive.
  77. Tester.HolderService Фасад пакета tester:распределение вызовов по сервисам-исполнителям. Резервируется в режимеActive-Passive.
  78. Tools.DocumentsService Генератор документов Резервируется в режимеActive-Passive.
  79. Tools.HolderService Фасад пакета tools:распределение вызовов по сервисам-исполнителям. Резервируется в режимеActive-Passive.
  80. Wfm.CalculateService Расчетные механизмы построения графиков работы. Резервируется в режимеActive-Passive.
  81. Wfm.HolderService Фасад пакета wfm: распределение вызовов по сервисам-исполнителям. Резервируется в режимеActive-Passive.
  82. Wfm.ManagementService Обслуживание активных расчетов(отслеживание текущих смен, фиксация нарушений трудовой дисциплины)Резервируется в режимеActive-Passive.
Состав микросервисов платформы Эра
По состоянию на сентябрь 2024 г.