// личный канал‑лог
gavrilovlog
← все записи

Два сервиса, одна сессия, ноль работающих

👁 6112💬 6
У MindPost было две жизни. Первая - AI-редактор в стиле Notion + Cursor, с чатом, с интеграциями Claude, OpenAI, DeepSeek. Вторая - когда я выпилил всё лишнее и оставил MCP-коннектор для Claude AI. Под капотом тут MTProto для доступа к данным Telegram-каналов. Работало отлично. Пока я не решил сделать Telegram-бота. Идея бота простая: пользователь подключает свой канал, бот анализирует тон оф войс и генерирует посты в его стиле. Бот тоже работает через MTProto. Через тот же файл сессии. И вот тут начались проблемы. MTProto не рассчитан на два клиента с одной сессией. Сервисы начали выбивать друг друга: один подключается - потому перезаписывает файл сессии - второй об этом не знает и отваливается. Бот работает - MCP падает. MCP поднимается - бот падает. И так по кругу. Два варианта решения: Первый - разделить сессии. Каждый сервис получает свою сессию. Быстро, но с последствиями: дублирование логики подключения, два файла сессий, два места где может сломаться MTProto, и оба нужно поддерживать отдельно, но в тоже время полная изоляция и можно масштабировать независимо оба сервиса. Второй - выделить MTProto в отдельный микросервис. Один процесс держит сессию, одна база данных, кэширование одинаковых запросов, рейт-лимиты для Telegram API, ленивая подгрузка обновлений. Остальные сервисы ходят к нему через REST API. Я выбрал второй. Что получил: Универсальный сервис, который можно переиспользовать. Любой новый проект, которому нужны данные из Telegram - просто подключается к REST API. Не нужно знать про MTProto, сессии, лимиты. Всё инкапсулировано. Чем заплатил: Единая точка отказа. Если mtproto-service падает - падает всё, что от него зависит. И нужно следить за обратной совместимостью: каждый релиз этого сервиса нужно проверять, чтобы не сломать продакшн для MCP и бота одновременно. Одно неосторожное изменение в API - и два сервиса лежат. Это классический trade-off, который существует в разработке десятки лет. Дублирование vs единая точка отказа. DRY vs устойчивость. В учебниках правильный ответ - "зависит от контекста". В реальности - зависит от того, что болит прямо сейчас. У меня болело дублирование и гонка за одну сессию. Поэтому я выбрал микросервис и принял его риски. А если mtproto-service упадёт? Об этом в следующих постах. Telegram | YouTube | Запретграм
61

Комментарии · 6

  • @sunm8
    а зачем ты коннектишь сессию для чтения тг канала для анализа?
    • @gavrilovlog
      А как ты делаешь?
      • @sunm8

      • @sunm8
        не я то делаю постоянный париснг, по этому мне нужно читать тг каналы в онлайн режиме. у меня запрос другой а для одного чтения инфы думаю достаточно через веб инфу подтянуть просто ссылку открыть и прочитать это ж легче, и API и MTProto лишний раз не дергаешь
        • @gavrilovlog
          Ну это несерьезно) там же куча ограничений. Выгрузка по 20 постов, плюс телега может еще капчу показать из-за частых запросов. Это не те костыли к которым надо идти, когда есть рабочий вариант с MTProto. Но у mtproto тоже есть ограничения свои и риски, о которых кстати ты писал, но лучше с этим работать, а не писать веб-парсер
          • @sunm8
            ну если поток не большой и в целом лимиты использовать то наверное да. но опять же - у меня были и лимиты и вейтеры и прочие штуки для эмуляции живого человека но видимо не хватило добавлял после недавних событий)