Инициатива: "Давайте перепишем это на gRPC"

Я не ждал поручения. Я собрал данные: •  Рост числа устройств — +300% за год •  Задержки в обработке — до 40 минут •  Ошибки десериализации — 5% сообщений

И предложил: полностью заменить байтовый протокол на gRPC.

Команда сомневалась. «А если медленнее будет?» «Мы же уже потратили столько времени на старый протокол!» Но я знал: технология должна служить бизнесу, а не наоборот.

🔧 Как я это сделал 1. gRPC вместо ручного фрейминга Теперь клиент подключается один раз — и получает команды в реальном времени. В gRPC есть встроенный механизм фрейминга — он основан на формате HTTP/2. Преимущества: Упрощение кода: больше не нужно управлять буферами, offset’ами и partial reads. Чёткие контракты: автоматическая генерация кода для всех языков. Надёжность: встроенные механизмы управления потоком, ошибками и статусами. Масштабируемость: поддержка server-side и bidirectional streaming.

2. Сохранение надёжности gRPC оказался не просто удобным — он гибким и контролируемым. 3. RabbitMQ — как брокер событий Чтобы не потерять ни одного пакета при нагрузке, я внедрил RabbitMQ: •  Gateway принимает gRPC → пушит в очередь. •  Воркеры потребляют параллельно. •  При сбое — сообщения не теряются. Система стала отказоустойчивой по design. 4. Redis для WebSocket-сессий в кластере Главная задача — уведомить пользователя, даже если он на другом сервере. Я реализовал: •  Хранение активных сессий в Redis. •  Механизм маршрутизации: user_id → node_id. •  Push через Pub/Sub в кластере. Теперь, когда устройство возвращается в сеть — пользователь узнаёт об этом мгновенно, независимо от того, где он подключён. 💡 Почему это важно? Потому что: •  Я не ждал, пока проблема взорвётся. •  Я взял ответственность — без ТЗ, без Тимлида. •  Я реализовал с нуля: от архитектуры до деплоя. •  И результат: o  Задержки ↓ на 90% o  Ошибки десериализации ↓ до 0% o  Время на добавление нового контракта ↓ с дней до минут ____ Что я понял •  Хороший инженер решает задачи. •  Выдающийся — предотвращает их. Иногда лучшее решение — не «починить», а создать заново, но правильно. ____ 🏁 Это мой проект Я его начал. Я его построил. Я им горжусь. И если завтра придёт следующая legacy-система — я снова скажу: «Давайте перепишем. Я знаю, как.»

🔗 Документация:

📄 Протокол: http://dev-abs.ru/proto 🧩 Кейс внедрения: http://dev-abs.ru/case

Подписаться | Канал в дзене | Наш сайт | ВК | YouTube

Инициатива: "Давайте перепишем это на gRPC" | Сетка — социальная сеть от hh.ru Инициатива: "Давайте перепишем это на gRPC" | Сетка — социальная сеть от hh.ru Инициатива: "Давайте перепишем это на gRPC" | Сетка — социальная сеть от hh.ru Инициатива: "Давайте перепишем это на gRPC" | Сетка — социальная сеть от hh.ru