В настоящем документе приведено описание архитектуры продукта Календарь VK WorkSpace.
Данный документ предназначен для технических специалистов, которые внедряют или поддерживают приведенные технологические решения:
- системные администраторы;
- специалисты по информационной безопасности.
Документ предполагает наличие технических знаний в области проектирования систем, однако будет полезен и специалистам бизнес-подразделений.
Наименование | Определение |
|---|---|
БД | База данных |
Сайдкар | Разделение функций приложения в отдельный процесс |
CalDAV | Протокол для синхронизации данных календаря и адресной книги между почтовым сервером и клиентом |
Шардирование | Принцип проектирования базы данных, при котором данные разбиваются на части и размещаются на разных шардах, что способствует масштабируемости приложения |
Запросы пользователей поступают на балансировщик, который отвечает за прием и распределение пользовательских запросов на бэкенд Календаря VK WorkSpace, в свою очередь балансировщик отправляет запросы на отдачу динамически генерируемых веб-страниц и статических файлов для передачи в веб-клиент.
Бэкенд Календаря VK WorkSpace состоит из множества различных компонентов (будут рассмотрены ниже), которые отвечают за определенную часть бизнес-логики: межсистемное взаимодействие, миграции, отправка уведомлений и т.д.
Все входящие запросы поступают на сервис балансировки и проксирования calendar-nginx, который, в свою очередь, перенаправляет запрос на необходимый сервис.
Сервис calendar-nginx взаимодействует с:
- caldavapi — для синхронизации календаря с внешними клиентами по протоколу CalDav;
- calendarapi — для обработки входящих запросов и перенаправления на необходимый сервис.
Для реализации протокола CalDAV реализован микросервис caldavapi, на который приходят запросы клиентов для синхронизации данных, caldavapi взаимодействует с сервисами:
- icser — при необходимости парсинга ics от клиента;
- calendarapi-internal — для выполнения любых действий над данными в БД (calendarpg);
- zubr — для авторизации в cube (входит в группу сервисов аутентификации и аторизации swa).
Общая схема сервисов приведена на рисунке ниже:
Описание сервисов приведено в таблице ниже:
Наименование сервиса | Назначение |
|---|---|
caldavapi | Сервис, реализующий сетевой протокол CalDAV. Используется для синхронизации календаря с внешними клиентами |
calendarapi-internal | Основной API для межсерверного общения |
zubr | Сайдкар для работы с профилями пользователей |
icser | Сервис для разбора .ics файлов |
Общая схема сервисов приведена на рисунке ниже:
Описание сервисов приведено в таблице ниже:
Наименование сервиса | Назначение |
|---|---|
calendarapi | Основной API для межсерверного общения |
calendar-notifyapi | Сервис уведомлений. Получает информацию о создании и изменении настроек оповещений событий. Складывает их в очередь |
calendar-notifier-zubr | Прокси-сервис для доступа к Tarantool. Содержит в себе логику работы с шардированием |
calendar-notify-tnt-queue | Очередь рассылки уведомлений Календаря |
calendar-notifyd | Демон, разбирающий очередь уведомлений. Получает актуальные на текущий момент оповещения и передает в почтовую и push-системы |
Общая схема сервисов приведена на рисунке ниже:
Описание сервисов приведено в таблице ниже:
Наименование сервиса | Назначение |
|---|---|
confroom | Сервис переговорных комнат (проверка занятости и доступности переговорных комнат) |
confroompg | База данных переговорных комнат календаря |
Общая схема сервисов приведена на рисунке ниже:
Описание сервисов приведено в таблице ниже:
Наименование сервиса | Назначение |
|---|---|
icser | Сервис для разбора .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-клиенты (Mozilla Thunderbird, стандартный клиент macOS и др):
- Пользователь отправляет запрос в формате XML (CalDAV).
- Запрос проходит через calendar-nginx в сервис CalDAV API.
- Далее caldavapi отправляет запрос для авторизации пользователя в сервис swa.
- Если пользователь авторизован, caldavapi отправляет событие в calendarapi-internal.
- Далее calendarapi-internal отправляет запрос в calendar-storage для сохранения изменения в базе данных calendarpg.
Изменения в календаре могут приходить через ICS-письма (файлы с описанием события: время начала, название, участники, описание и т. д.):
- Почтовый сервис ics-processor отправляет ICS-файл в сервис Каледаря ics-router.
- Затем ics-router выполняет парсинг ICS-файла и извлекает необходимые данные.
- Преобразованные данные отправляются по gRPC в calendarapi-internal.
- Далее calendarapi-internal отправляет запрос в calendar-storage для сохранения изменения в базе данных calendarpg.
Пользователь может подтверждать или отклонять участие в событии через ботов:
- Пользователь нажимает кнопку в сообщении бота (кнопки «Иду», «Не иду»).
- Запрос пользователя отправляется в сервис calendarbot-processor.
- Далее calendarbot-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-модели.