Платформа
Технологии и архитектура
Раздел для тех, кому нужно понять, как платформа устроена внутри: специалистов заказчика, проектировщиков интеграций, служб информационной безопасности. Описание даётся на уровне подсистем и их взаимодействия.
Состав подсистем
Платформа разделена на независимо масштабируемые службы. Отказ одной не останавливает остальные: при недоступности медиаслужбы переписка работает, при перегрузке поиска сообщения доставляются как обычно.
| Служба | Назначение | Критичность |
|---|---|---|
| Пограничный слой | Терминация TLS, ограничение частоты обращений, защита от перегрузок | Высшая |
| Служба сеансов | Аутентификация, устройства, токены | Высшая |
| Служба сообщений | Приём, порядок, доставка, подтверждения | Высшая |
| Служба уведомлений | Доставка push-уведомлений на устройства | Высокая |
| Медиаслужба | Звонки, встречи, вещание | Высокая |
| Служба файлов | Загрузка, предпросмотр, версии | Средняя |
| Служба поиска | Индексация и запросы | Средняя |
| Служба каталога | Справочники организаций, синхронизация SCIM | Средняя |
| Служба модерации | Обращения, фильтры, решения | Средняя |
| Хранилище ключей | Ключи шифрования данных при хранении | Высшая, изолирована |
Протокол обмена
Клиент и сервер обмениваются двоичными кадрами по постоянному соединению; при его недоступности используется резервный режим на основе последовательных запросов. Каждое сообщение получает монотонно возрастающий номер в пределах диалога, что даёт устойчивый порядок независимо от последовательности доставки.
- Идемпотентность. Повторная отправка того же сообщения при неясном результате не создаёт дубликата: сервер распознаёт клиентский идентификатор.
- Догрузка пропущенного. Клиент запрашивает диапазон номеров, а не всю историю.
- Экономия трафика. Сжатие полезной нагрузки и словарь часто повторяющихся полей.
- Подтверждения. Три состояния: принято сервером, доставлено устройству, прочитано.
Медиатракт
Применяется сервер выборочной пересылки: участник отправляет один поток в нескольких качествах, сервер раздаёт каждому получателю подходящее, не перекодируя. Это даёт низкую задержку и предсказуемую нагрузку. Транскодирование включается только там, где иначе нельзя: вещание с приготовлением нескольких качеств, телефонные подключения, запись со сведением дорожек.
Управление полосой распределённое: клиент оценивает свой канал и запрашивает нужное качество, сервер учитывает суммарную нагрузку и приоритет говорящего. При деградации первым снижается видео, звук сохраняется до последнего.
Хранилища
- История переписки — распределённая база, сегментирование по пользователю, синхронная репликация между двумя площадками и асинхронная на третью.
- Объектное хранилище — файлы, записи, вложения; три копии, ежедневная сверка контрольных сумм.
- Поисковый индекс — отдельный кластер, перестраиваемый без остановки доставки сообщений.
- Служебные данные — справочники, настройки, права; реляционная база с журналом изменений.
- Журналы — неизменяемое хранилище с ограниченным доступом, срок 12 месяцев.
Клиентские приложения
Общее ядро на системном языке реализует протокол, шифрование, локальную базу и очередь отправки — одна и та же логика на всех платформах, что исключает расхождение поведения. Интерфейс строится нативными средствами каждой платформы: это даёт привычные жесты, корректную работу со вспомогательными технологиями и меньший расход батареи.
Веб-версия использует то же ядро, собранное в WebAssembly, поэтому криптографические операции выполняются одинаково с приложениями, а ключи не покидают браузер. Локальная история в веб-версии хранится в браузерном хранилище в зашифрованном виде и может быть отключена режимом ограниченного доступа.
Порядок обновлений
Серверные обновления выкладываются постепенно: сначала на служебный контур, затем на 5 процентов пользователей, затем полностью. Изменения протокола сохраняют совместимость минимум на две версии назад, чтобы клиент без обновления продолжал работать. Клиентские обновления выходят раз в две недели, критические исправления — вне расписания.