Vestry
Распределённая система, работающая с Telegram: четыре backend-сервиса на Rust общаются через gRPC, а за протокольной границей идёт обработка, близкая к агентной.
- Принадлежность
- Заказная работа, сделанная вместе с партнёром и для него. Red Sentra сохраняет роль сопровождения. Партнёр и коммерческие условия остаются приватными.
- Доступность
- Приватный продукт. Исходный код приватный.
- Стек
- Rust / MTProto / gRPC / Protocol Buffers
Задача
Работа с Telegram на уровне протокола не прощает ошибок. Сессии имеют состояние, лимиты применяются по-настоящему, а клиент живёт долго. Всё, что относится к нему как к обычной интеграции запрос-ответ, быстро ломается трудно диагностируемым образом.
Система
Четыре backend-сервиса на Rust с разделённой ответственностью общаются через gRPC, а контрактом служат Protocol Buffers. Слой, смотрящий в MTProto, изолирован от остального, поэтому поведение протокола и его сбои не протекают в сервисы, делающие продуктовую работу.
Моя роль
Backend и системная инженерия: декомпозиция сервисов, gRPC-контракты между ними, граница интеграции с MTProto и поведение системы, когда одна часть лежит.
Самое сложное
Долгоживущие соединения с состоянием не укладываются в модель сервисов без состояния. Решение о том, где состоянию разрешено жить и как пережить перезапуск любого сервиса, сформировало большую часть архитектуры.
Архитектурные решения
- Изоляция протокола. Всё специфичное для MTProto стоит за одной границей, поэтому остальная система говорит в доменных терминах и тестируется без Telegram вообще.
- Контракты, начинающиеся со схемы. Protocol Buffers между сервисами делают ломающее изменение заметным при сборке, а не в три часа ночи.
- Четыре сервиса, а не один. Разделение шло по доменам отказов и нуждам масштабирования, а не по опрятности, поэтому шумные части можно перезапускать, не утягивая тихие.
Текущее состояние
В проде, Red Sentra продолжает его сопровождать.