Go 1.24 vs Rust для микросервисов — когда Go уже не достаточно?

[roero]

Команда у нас пишет бэкенд на Go уже 4 года, всё устраивает. Но появилась задача — обработка потока событий с очень низкими требованиями по латентности (p99 < 2ms при 50к RPS). На Go получаем p99 около 8-12ms из-за GC пауз. Коллега предлагает переписать этот конкретный сервис на Rust. Архитектор против — говорит что команда Rust не знает и это риск. Как правильно оценить трейдофф?

[navspy]

8-12ms p99 на Go при 50к RPS это решаемо без Rust. Сначала попробуйте GOGC=off + runtime.GC() вручную в периоды низкой нагрузки, или GOMEMLIMIT для ограничения хипа чтобы GC срабатывал предсказуемее. Ещё посмотрите на GOMAXPROCS — иногда помогает выставить меньше чем число ядер чтобы снизить contention. Go 1.24 улучшил GC, Swiss Tables дали 2-3% на throughput. Но если у вас реально 2ms требование — это серьёзно, и Rust там действительно выигрывает.

[depechie]

Вопрос не только в производительности но и в TCO. Rust разработчик в СНГ стоит заметно дороже Go разработчика — рынок меньше, спрос со стороны иностранных заказчиков высокий. Если у вас небольшая команда и нет бюджета на найм Rust-разраба, то полгода на переписывание одного сервиса могут обойтись дороже чем просто взять более мощное железо. Конкретно — взять инстанс с меньшими паузами GC через выделение памяти и профиль нагрузки.

[penalty]

@roero, Реальный кейс из практики: у нас был похожий сервис на Go, p99 15ms. Оптимизировали структуры данных, убрали лишние аллокации (pprof показал где), использовали sync.Pool для частых аллокаций — опустили до 4ms p99. Это заняло 2 недели против потенциальных 3-6 месяцев на Rust. Rust не панацея, сначала профилируй что именно тормозит.

[rburr]

@depechie, Если решение всё же за Rust — рассмотрите гибридный подход: Go остаётся основным языком инфраструктуры, один критичный сервис пишется на Rust, коммуникация через gRPC. Это позволяет команде начать осваивать Rust на реальном проекте без риска для всей системы. Главное — сразу договориться об ответственности за сервис: кто онкол, кто деплоит.

[lunarod]

Benchmarks говорят что Rust быстрее Go в 10-12 раз на memory-intensive задачах. Но это синтетика. В реальном сетевом сервисе с IO разница обычно 20-40% по латентности, и это часто не стоит усложнения. Порог когда Rust оправдан по моему опыту — когда Go уже оптимизирован и всё равно не хватает, или когда пишешь что-то типа базы данных / очереди сообщений где латентность p99.9 важна.

[mystiga]

@navspy, подтверждаю путь через pprof + sync.Pool. У нас на highload-роутере Go 1.22 был p99 около 18ms, pprof heap показал что в горячем пути каждый запрос создаёт по 4-6 мелких struct для парсинга хедеров — всё это шло в GC. Заменили на pool, подрезали аллокации ещё в encode/decode — вышли на 3.2ms p99 при 60к RPS. Два спринта работы, никакого Rust.

[cohenst1]

Важный момент которого в треде не касались: если требование p99 < 2ms это не просто желание, а контрактное SLA — сначала изолируйте где именно тратится время. На 50к RPS при Go с стандартным net/http сеть и сериализация часто едят больше чем GC. Попробуйте fasthttp или gnet как транспорт — они вообще обходят стандартный аллокатор на горячем пути. У нас на gnet p99 упал на 40% без каких-либо изменений бизнес-логики.

[qcdeed]

@mystiga, про 20-40% в реальном сетевом сервисе — точно, синтетика врёт сильно. Добавлю к этому: в микросервисной архитектуре с gRPC разница между Go и Rust на уровне одного сервиса в итоге убивается сетевым хопом между сервисами. Если у вас latency-чувствительная цепочка из трёх сервисов — сначала смотрите на количество сетевых переходов и батчинг вызовов, а не на язык внутри отдельного сервиса.