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 продовжує його супроводжувати.