Описание архитектуры Календаря VK WorkSpace

Введение

В настоящем документе приведено описание архитектуры продукта Календарь VK WorkSpace.

Данный документ предназначен для технических специалистов, которые внедряют или поддерживают приведенные технологические решения:

системные администраторы;
специалисты по информационной безопасности.

Документ предполагает наличие технических знаний в области проектирования систем, однако будет полезен и специалистам бизнес-подразделений.

Сокращения и определения

Наименование	Определение
БД	База данных
Сайдкар	Разделение функций приложения в отдельный процесс
CalDAV	Протокол для синхронизации данных календаря и адресной книги между почтовым сервером и клиентом
Шардирование	Принцип проектирования базы данных, при котором данные разбиваются на части и размещаются на разных шардах, что способствует масштабируемости приложения

Верхнеуровневая архитектура

Запросы пользователей поступают на балансировщик, который отвечает за прием и распределение пользовательских запросов на бэкенд Календаря VK WorkSpace, в свою очередь балансировщик отправляет запросы на отдачу динамически генерируемых веб-страниц и статических файлов для передачи в веб-клиент.

Бэкенд Календаря VK WorkSpace состоит из множества различных компонентов (будут рассмотрены ниже), которые отвечают за определенную часть бизнес-логики: межсистемное взаимодействие, миграции, отправка уведомлений и т.д.

Примечание

Авторизация и аутентификация пользователей выполняется группой сервисов swa на стороне продукта Почта VK WorkSpace.

Сервисы системы

Сервисы обработки входящих запросов

Все входящие запросы поступают на сервис балансировки и проксирования calendar-nginx, который, в свою очередь, перенаправляет запрос на необходимый сервис.

Сервис calendar-nginx взаимодействует с :

caldavapi — для синхронизации календаря с внешними клиентами по протоколу CalDav;

calendarapi — для обработки входящих запросов и перенаправления на необходимый сервис.

Сервисы бэкенда

Сервисы для синхронизации по CalDAV

Для реализации протокола CalDAV реализован микросервис caldavapi, на который приходят запросы клиентов для синхронизации данных, сaldavapi взаимодействует с сервисами:

icser — при необходимости парсинга ics от клиента;
calendarapi-internal — для выполнения любых действий над данными в БД (calendarpg);
zubr — для авторизации в cube (входит в группу сервисов аутентификации и аторизации swa).

Общая схема сервисов приведена на рисунке ниже:

Описание сервисов приведено в таблице ниже:

Наименование сервиса	Назначение
caldavapi	Сервис, реализующий сетевой протокол CalDAV. Используется для синхронизации календаря с внешними клиентами
calendarapi-internal	Основной API для межсерверного общения
zubr	Cайдкар для работы с профилями пользователей
icser	Cервис для разбора .ics файлов

Сервисы уведомлений

Общая схема сервисов приведена на рисунке ниже:

Описание сервисов приведено в таблице ниже:

Наименование сервиса	Назначение
calendarapi	Основной API для межсерверного общения
calendar-notifyapi	Сервис уведомлений. Получает информацию о создании и изменении настроек оповещений событий. Складывает их в очередь
calendar-notifier-zubr	Прокси-сервис для доступа к Tarantool. Содержит в себе логику работы с шардированием
calendar-notify-tnt-queue	Очередь рассылки уведомлений Календаря
calendar-notifyd	Демон, разбирающий очередь уведомлений. Получает актуальные на текущий момент оповещения и передает в почтовую и push-системы

Сервисы переговорных комнат

Общая схема сервисов приведена на рисунке ниже:

Описание сервисов приведено в таблице ниже:

Наименование сервиса	Назначение
confroom	Сервис переговорных комнат (проверка занятости и доступности переговорных комнат)
confroompg	База данных переговорных комнат календаря

Сервисы обработки .ics запросов

Общая схема сервисов приведена на рисунке ниже:

Описание сервисов приведено в таблице ниже:

Наименование сервиса	Назначение
icser	Cервис для разбора .ics файлов
ics-router	Балансировщик нагрузки между сервисами icser
calendarapi-internal	Основной API для межсерверного общения
calendarpg	БД Календаря

Базовые сценарии использования календаря

Работа пользователя через веб-интерфейс

Пользователь открывает веб-версию календаря (с мобильного устройства или через браузер) и редактирует событие в собственном календаре (например, удаляет событие):

Пользователь выполняет действие (например, удаление события).
Формируется GraphQL-запрос, который отправляется на сервер.
Запрос проходит через сервисы балансировки pub и в calendar-nginx и попадает в calendarapi.
Далее calendarapi через балансировщик направляет запрос в calendar-nginx.
Затем calendarapi-internal отправляет запрос в calendar-storage для сохранения изменения в базе данных calendarpg.

Межсерверное взаимодействие

Другим источником событий является взаимодействие с внешним сервером:

Запросы внешнего сервера попадают на сервис calendarapi-internal (gRPC).
Далее calendarapi-internal отправляет запрос в calendar-storage для сохранения изменения в базе данных calendarpg.

Взаимодействие через CalDAV-клиенты

Пользователь может работать с календарём через CalDAV-клиенты (Mozilla Thunderbird, стандартный клиент macOS и др):

Пользователь отправляет запрос в формате XML (CalDAV).
Запрос проходит через calendar-nginx в сервис CalDAV API.
Далее caldavapi отправляет запрос для авторизации пользователя в сервис swa.
Если пользователь авторизован, caldavapi отправляет событие в calendarapi-internal.
Далее calendarapi-internal отправляет запрос в calendar-storage для сохранения изменения в базе данных calendarpg.

Обработка ICS-файлов

Изменения в календаре могут приходить через ICS-письма (файлы с описанием события: время начала, название, участники, описание и т. д.):

Почтовый сервис ics-processor отправляет ICS-файл в сервис Каледаря ics-router.
Затем ics-router выполняет парсинг ICS-файла и извлекает необходимые данные.
Преобразованные данные отправляются по gRPC в calendarapi-internal.
Далее calendarapi-internal отправляет запрос в calendar-storage для сохранения изменения в базе данных calendarpg.

Взаимодействие с ботом Супераппа VK WorkSpace

Пользователь может подтверждать или отклонять участие в событии через ботов:

Пользователь нажимает кнопку в сообщении бота (кнопки «Иду», «Не иду»).
Запрос пользователя отправляется в сервис сalendarbot-processor.
Далее сalendarbot-processor отправляет gRPC-запрос в calendarapi-internal.
Далее calendarapi-internal отправляет запрос в calendar-storage для сохранения изменения в базе данных calendarpg.

Уведомления о событиях

После создания события формируются уведомления (приглашения и напоминания):

Сервисы calendarapi и calendarapi-internal отправляют запрос в сервис calendar-notifyapi.
Далее calendar-notifyapi сохраняет запросы в очередь calendar-notify-tnt-queue.
В фоновом режиме сервис calendar-notifyd вычитывает очередь и отправляет уведомления:
- email-приглашения — пользователям;
- запросы в calendarbot-api — для отображения приглашений в Teams.

Переговорные комнаты

Для работы с переговорными комнатами используется отдельный сервис confroom.

Особенности:

Проверка доступности и занятости переговорок.
Отдельная база данных confroompg для хранения данных о переговорках.
Работает по REST-модели.