Всем привет! Сегодня хочу зажечь настоящий холивар — но с практическим уклоном. Речь пойдет о нашем большом рефакторинге, вернее, о почти полном переписывании ядра нашего API-гейтвея.
Немного контекста: У нас классический монолит на Java (Spring Boot), который неплохо служил нам лет 5. Но с ростом нагрузки до 100k+ RPS мы уперлись в лимиты:
Потребление памяти под 16-32 GB на инстанс
GC паузы по 200-300ms в пике
Стоимость облачной инфраструктуры стала сопоставима с зарплатой нескольких миддлов
И мы приняли решение — переписать самые горячие пути на что-то более эффективное. Кандидаты: Go, Rust и современный C++.
Go: модный и быстрый на старт
Плюсы:
Простота написания конкурентного кода (горутины — это действительно круто)
Быстрая компиляция
Отличная стандартная библиотека для сетевых задач
Минусы, с которыми столкнулись:
Сборка мусора всё ещё дает просадки, хоть и меньше чем в Java
Нет настоящей работы с памятью — в некоторых сценариях это критично
Вердикт: Идеально для быстрого старта, но не дает того контроля, который хочется в ядре системы.
Rust: хайп и реальность
Плюсы:
Нулевая стоимость абстракций — это не шутка
Гарантии безопасности памяти без GC
Невероятно умный компилятор
Минусы на практике:
Кривая обучения круче, чем кажется
Время компиляции в больших проектах измеряется минутами
Некоторые концепции (lifetimes) требуют переосмысления архитектуры
Вердикт: Мощно, но дорого в разработке и поддержке.
C++23: старый добрый друг с новыми трюками
Что удивило:
Модули наконец-то работают как надо
Coroutines в стандартной библиотеке
Концепты делают шаблоны читаемыми
Меньший оверхед по памяти чем у Go и Rust
Боль:
До сих пор нет нормальной системы пакетов (хотя vcpkg и Conan спасают)
Нужны очень опытные разработчики
Наш выбор и почему
После 3 месяцев прототипов и бенчмарков мы остановились на... Zig.
Шутка! Хотя Zig мы тоже смотрели — но для продакшена рано.
Реальный выбор — Rust. И вот почему:
Долгосрочная выгода: Да, первые 2 месяца скорость разработки была ниже. Но потом — стабильный рост без дебаггинга багов с памятью и data races.
Экосистема: Tokio + Hyper показали производительность лучше чем Go net/http и сравнимую с оптимизированным C++.
Компиляция в WASM: Это оказалось killer feature! Мы можем компилировать отдельные модули в WASM и запускать их в разных средах.
Что в сухом остатке через 6 месяцев:
Потребление памяти: упало в 4-5 раз
Производительность: выросла в 2-3 раза
Количество багов: критических — почти ноль
Стоимость инфраструктуры: уменьшилась на 60%
Вывод: Не существует идеального языка. Но есть идеальный язык для вашей команды и задачи. Для нас это оказался Rust — несмотря на все сложности, он дал тот уровень контроля и производительности, который нам был нужен.
А что выбираете вы для высоконагруженных сервисов в 2025? Делитесь в комментах!
P.S. Кто заинтересовался — в следующем посте распишу наш стек инструментов для Rust в продакшене: мониторинг, дебаггинг, деплой...
Комментарии (25)
gmtd
04.10.2025 05:56Автор зашел вчера на Хабр, запостил 4 сгенерённые LLM статьи, и... дальше что?
shlmzl
04.10.2025 05:56Если сгенерировал, то хотелось бы знать чем было сгенерировано вот это:
Вот алгоритм, который позволит вам спать спокойно, используя GPT-5:
Декомпозируйте задачу. Разбейте её на мелкие, атомарные части.
Пишите детальные промпты. Представьте, что пишете ТЗ для джуниора, который склонен делать именно то, что ему сказано, и не более.
Генерируйте код небольшими порциями. Не целый модуль, а одну функцию, один класс, один метод.
Проверяйте ВСЁ. Линтеры, тесты, внимательный код-ревью. Никаких исключений.
Рефакторите и интегрируйте. Вставьте проверенный код в свою кодобазу, приведите к своим стандартам.
Очень неплохо на мой взгляд. Сам(а) GPT-5 дает советы как строить ракботу с ней (ним)?
atomlib
04.10.2025 05:56Не согласен. На мой взгляд, плохо и низкокалорийно. Ну давайте по пунктам.
Редукционизм изобрели в пятом веке до нашей эры. Тоже мне откровение. Совет понятный, но очевидный. Куда полезнее очертить оптимальный объём работы для каждого промпта. Сколько оптимально токенов должно быть в вводе и выводе? Человек с опытом немедленно покажет примеры, большая языковая модель будет давать общие указания.
Писать детальный промпт — самый хороший совет. Я бы разве что рекомендовал представлять не младшего разработчика, а дьявола, который будет делать всё наоборот (вразрез с вашими ожиданиями), если вы не оговорили обратное. Для начала нужно задуматься, какие из ваших ожиданий остаются невысказанными и, собственно, высказать эти ожидания.
См. пункт 1.
Проверять вывод БЯМ — тоже неплохой совет. Обратите внимание, что он опять дан словами Капитана Очевидность, без примеров из практики.
См. пункт 4.
Итого пять советов, из которых в реальности будет три. И все даются максимально общими словами.
Именно так пишут дешёвые языковые модели: мало смысла, слов избыток. Модель не назову, но не думаю, что здесь бесплатный тариф. Думаю, БЯМ была без reasoning.
sunUnderShadow
04.10.2025 05:56Тут похоливарить можно только на тему осознанности выбора, потому что судя по приведенным плюсам и минусам она где-то не с нами
Dhwtj
04.10.2025 05:56Автор провокатор и выдумщик.
Вопросы:
Кто же вам дал старый священный код переписывать? Да ещё и время команды тратить.
"переписать самые горячие пути" - а интегрировать как? Есть много тонкостей.
Почему такое неправдоподобно большое преимущество по памяти и ЦП перед старой системой? Где именно?
Где цифры, Билли?!
З.Ы. Крутая кривая обучения Раст это преувеличение. Просто забудьте всё, чему вас учили раньше©
Smartor
04.10.2025 05:56Хотелось бы увидеть какие-нибудь картинки с тестами, что ли. А то написать сейчас так можно про что угодно:)
Rive
04.10.2025 05:56В топе бенчмарков techempower стабильно фреймворки на Rust, C и C++, иногда NodeJS.
Для разработки лучше может оказаться использовать не топ-3 фреймворки (поскольку они подгоняются под тесты соревнования), и в процессе вполне можно написать глубоко неоптимальный тормозной код, но некоторые языки просто удобнее для написания высокопроизводительного кода, чем другие (за счёт отказа от виртуальной машины, сборщика мусора и прочих вещей, которые облегчают жизнь разработчикам, но не потребителям).
На задачах компании ТСа рейтинг языков и фреймворков может быть другой, разумеется (на скриншоте - просто RPS статичной страницы).
Wicort
04.10.2025 05:56У нас в компании Java (SpringBoot) пока всё равно остается на первом месте просто потому что вся экосистема на это завязана - генераторы кода и прочее - ну и компетенции разработчиков тоже. Однако, самые высоконагруженные сервисы потихоньку переезжают на Go. Лично меня это пока не коснулось, но в планы аттестаций MSA разрабов Go уже залетел как обязательный пункт.
ALapinskas
04.10.2025 05:56Немного контекста: У нас классический монолит на Java (Spring Boot), который неплохо служил нам лет 5. Но с ростом нагрузки до 100k+ RPS мы уперлись в лимиты:
Поднять еще нод, не вариант?
denis_iii
04.10.2025 05:56Судя, по 200-300ms пауз в пике, сервис наоборот надо было разрезать на более мелкие кучи и запустить с нормальным современным GC.
NN1
04.10.2025 05:56А почему не рассматривался C# ?
Современный .NET позволяет даже работать напрямую с памятью с нулевым оверхедом.
HaxeZ
04.10.2025 05:56На самом деле хотелось бы увидеть примеров: контроллера, ORM и обращений в БД, легирования (желательно сквозного там c OTel и Jaeger), юнитов под это добро написанных и тд, DI особенно после Spring-экосистемы.
При том я к Rust’у отношусь крайней положительно, но ни разу не видел продовый код на нем, а очень хотелось бы.
UPD: дописал про DI
Gorthauer87
04.10.2025 05:56Вот кстати с логировагием и телеметрией есть tracing, он нас устраивал до определённого момента, но начал бесить своей не гибкостью и мы приняли решение на fastrace переезжать.
akod67
04.10.2025 05:56В нынешней реальности надо ещё анализировать качество перегонки кода туда сюда LLMками
Gorthauer87
04.10.2025 05:56Забавно, что мы со скалы на rust переписали сервис и примерно такие же порядки цифр по памяти и процессору получили. Ну и в результате там теперь 8 подов, а не 32.
azgnetov
04.10.2025 05:56Скорость работы это хорошо, а скорость стабильной работы сравнивали? А то вот убунтоводы тоже на ржавом переписали gnu coreutils и сразу начали огребать: https://www.phoronix.com/news/Ubuntu-25.10-Coreutils-Makeself
Fardeadok
04.10.2025 05:56Открою секрет: на си еще быстрее будет) просто надо его не напрямую через хттп использовать
user-book
04.10.2025 05:56херня какая-то
известны проблемы стандартного net/http в Го, именно потому если важна скорость или распределенность то есть куча других пакетов которые дышат в затылок найтивкам на си и раст
В Го есть встраиваение, сетевой уровень вы могли бы написать на Си и встроить, а уже на го работать с самими данными
За WASM просто смешно, на этот моменте я начал думать о том что это написано нейронкой. При чем тут вообще WASM? Единое что - сторонние модули которые подключаются на нем. Это удобно но это тонкое место для таких высоконагруженных систем, оптимальнее разбить на микросервисы если у вас там монолит с модулями.
UPD
к слову про тонкие моменты - есть абсолютно рабочий способ добиваться великого даже на net/http - шардирование.
на одном инстансе поднимаем сразу десяток одинаковых серверов которые написаны по принципу шарда и имеют общую память в том же редисе. настраиваем nginx как балансировщик (он может) что бы раскидывал запросы между этими 10 шардами и вуаля
sedyh
Почему третий пункт приписан, как killer-feature раста? Он, конечно, хорошо туда собирается, но плюсы и go тоже умеют в wasm. И у всех трех есть zerodep embedded рантаймы для запуска модулей по типу wasmi, wasm3, wazero.