Всем привет! Сегодня хочу зажечь настоящий холивар — но с практическим уклоном. Речь пойдет о нашем большом рефакторинге, вернее, о почти полном переписывании ядра нашего 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 в продакшене: мониторинг, дебаггинг, деплой...
Комментарии (64)
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.
shlmzl
04.10.2025 05:56С удовольствием поспорил бы с замглавреда, но здесь изначально с моей стороны было обозначено, что это просто мое мнение.
sunUnderShadow
04.10.2025 05:56Тут похоливарить можно только на тему осознанности выбора, потому что судя по приведенным плюсам и минусам она где-то не с нами
Dhwtj
04.10.2025 05:56Автор провокатор и выдумщик.
Вопросы:
Кто же вам дал старый священный код переписывать? Да ещё и время команды тратить.
"переписать самые горячие пути" - а интегрировать как? Есть много тонкостей.
Почему такое неправдоподобно большое преимущество по памяти и ЦП перед старой системой? Где именно?
Где цифры, Билли?!
З.Ы. Крутая кривая обучения Раст это преувеличение. Просто забудьте всё, чему вас учили раньше©
ruslan_sverchkov
04.10.2025 05:56Почему такое неправдоподобно большое преимущество по памяти и ЦП перед старой системой?
в старой системе из коробки Map<Long, Long> а в новой open addressing на примитивах)
Anarchist
04.10.2025 05:56То есть, переписать всё оказалось проще, чем оптимизировать Map[Long, Long]?
ruslan_sverchkov
04.10.2025 05:56Ключевое слово тут «переписать», переписывание с джавы на джаву даст тот же эффект) при условии конечно что разрабы не совсем валенки и хотя бы примерно представляют во что компиляется и как исполняется их поделие. Исключение - ультралоулатенси которое на гц физически невозможно сделать, но судя по паузам в 300мс тут был не тот случай (если он вообще был)
Maverik
04.10.2025 05:56Кто же вам дал старый священный код переписывать? Да ещё и время команды тратить.
Когда затраты на инфраструктуру превышают зарплату нескольких мидлов, то могли и разрешить.
Крутая кривая обучения Раст это преувеличение. Просто забудьте всё, чему вас учили раньше©
Раст очень гибок в плане представления. Я до сих пор натыкаюсь на свой собственный код 1-2 летней давности с mut и match на Optional, хотя через полгода интенсивного литкода освоил кучу идиом, которые приближают код к идеалу на хаскеле.
Anarchist
04.10.2025 05:56Затраты на инфраструктуру в месяц сопоставимые с годовыми зарплатами нескольких сеньоров - суровая правда жизни.
Smartor
04.10.2025 05:56Хотелось бы увидеть какие-нибудь картинки с тестами, что ли. А то написать сейчас так можно про что угодно:)
Rive
04.10.2025 05:56В топе бенчмарков techempower стабильно фреймворки на Rust, C и C++, иногда NodeJS.
Для разработки лучше может оказаться использовать не топ-3 фреймворки (поскольку они подгоняются под тесты соревнования), и в процессе вполне можно написать глубоко неоптимальный тормозной код, но некоторые языки просто удобнее для написания высокопроизводительного кода, чем другие (за счёт отказа от виртуальной машины, сборщика мусора и прочих вещей, которые облегчают жизнь разработчикам, но не потребителям).
На задачах компании ТСа рейтинг языков и фреймворков может быть другой, разумеется (на скриншоте - просто RPS статичной страницы).
ruslan_sverchkov
04.10.2025 05:56Покликал по разным вкладкам на страничке этого проекта, там худший результат у джавы 80% от топа (в каких то тестах при этом 99,9)
yrub
04.10.2025 05:56эти тесты не имеют никакого отношения к реальной жизни - вы хоть раз видели чтобы кто-то использовал эти макетные http сервера? по сути они тестируют качество реализации socket api и не более тк внутри примитивный парсинг http 1.1 (уверен что http2 или 3 никто из первой сотни не поддерживает) - и не полный, а только того, что нужно для этих простых тестов. в принципе проскакивала инфа, что в java под линукс все еще нет нормального асинхронного IO апи, раньше в нем просто не было необходимости пока не появились виртуальные потоки, наверно этим объясняется разница этого теста, на сколько помню они ж засыпают сервак конкурентными запросами и по сути больше ничего не тестируют.
ruslan_sverchkov
04.10.2025 05:56в java под линукс все еще нет нормального асинхронного IO апи
раньше те кому это было нужно просто делали такой апи, в томкетике например есть реализация, в одноклассниках есть one-nio, так что это не блокер)
aiscy
04.10.2025 05:56С одной стороны, хочется с вами согласиться. С другой стороны, на скриншоте выше, на седьмой позиции, стоит axum, который и h2 поддерживает, и в проде встречается. Чтобы далеко не ходить: https://github.com/rust-lang/crates.io
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.
CrazyHackGUT
04.10.2025 05:56Если там уже затраты на инфру исчислялись зарплатами мидлов, то ответ очевиден.
yrub
04.10.2025 05:56очень наивно, т.е. нужно потратить условно не один человеко год сеньоров, менеджера, еще неопределенное время qa не реализовав ни одной новой фичи при этом, никакой новой ценности для клиентов чтоб сэкономить сколько? тысячу уе в месяц тратя при этом минимум 6 (это если мы захантим еще самых скромных, фактически мидлов, и это без налогов и прочих расходов) на протяжении нескольких лет? Плюс java еще в том, что ее очень легко профилировать и мониторить, лично я уверен что можно малыми силами в любом проекте закрыть главные проблемы в производительности на уровне вашего приложения. Все остальное не про джаву это или желание моментального старта без лишних усилий или потребление памяти на уровне 20 мб, а не 200 + 20*3 мб, при этом получая 20 мб и быстрый старт вы лишаетесь абсолютно всех фичей java и spring, ибо им нет нормальных аналогов в go-rust-c++. а go кстати еще и довольно странный, как только дело доходит до числодробилок, то он пригрывает java, и еще интересно будет посмотреть расклады через пару лет когда в java завезут value типы - виртуальная машина конечно останется, но памяти станет кушаться наверно в пару раз меньше.
CrazyHackGUT
04.10.2025 05:56Разрабатывать фичи можно и параллельно, или и вовсе сразу в новом сервисе, а в старом просто прокладки рисовать, делающие обращения в новый.
Да, мы живём к сожалению в реальности, когда прям заниматься переписыванием и ничем больше никто не даст, но совмещать полезное с нужным никто не запретит.
NN1
04.10.2025 05:56А почему не рассматривался C# ?
Современный .NET позволяет даже работать напрямую с памятью с нулевым оверхедом.
yrub
04.10.2025 05:56нам джавистам не очень понятно о чем вы, если что в java сто лет как можно работать с памятью без оверхеда, это и так называемый off heap которым балуются кэши, базы на java типа кассандры. На мелком уровне есть библиотеки где коллекции реализованы уже под конкретные типы. Ну а терпеливые ждут value типы когда Map<Long, Long> наконец станет работать как на примитивах - пилят 10 лет, 8 прототипов, но наконец появился свет в конце туннеля.
HaxeZ
04.10.2025 05:56На самом деле хотелось бы увидеть примеров: контроллера, ORM и обращений в БД, легирования (желательно сквозного там c OTel и Jaeger), юнитов под это добро написанных и тд, DI особенно после Spring-экосистемы.
При том я к Rust’у отношусь крайней положительно, но ни разу не видел продовый код на нем, а очень хотелось бы.
UPD: дописал про DI
Gorthauer87
04.10.2025 05:56Вот кстати с логировагием и телеметрией есть tracing, он нас устраивал до определённого момента, но начал бесить своей не гибкостью и мы приняли решение на fastrace переезжать.
Jijiki
04.10.2025 05:56да фаст штуки можно хоть на С++ написать и будет быстро, вот интересно если сравнивать 2 бвх дерева на раст и С++, кто быстрее кастует в обьект, я клоню к тому, что процесс может быть в дереве, и можно отсекать всё что не связано с запросом
я просто почитал про фаст трейс и подумал про бвх
тоесть если упростить вопрос чей рейтрейс быстрее раста или С или С++
Format-X22
04.10.2025 05:56У меня такой есть, не большой, но деньгами ворочает. Работает стабильно и эффективно по памяти. И главное - я могу ему доверять, компилятор и механизмы паттерн-метчинга гарантируют мне что неожиданностей не будет. Для финтеха очень важно.
akod67
04.10.2025 05:56В нынешней реальности надо ещё анализировать качество перегонки кода туда сюда LLMками
Gorthauer87
04.10.2025 05:56Забавно, что мы со скалы на rust переписали сервис и примерно такие же порядки цифр по памяти и процессору получили. Ну и в результате там теперь 8 подов, а не 32.
yrub
04.10.2025 05:56так скала не про перформанс ;) она ощутимо проигрывает java, на столько, что ее частенько решают гонять на graalvm (даже платный) ибо он хорошо умеет оптимизировать ее оверхед. ну и хотелось бы больше специфики что там у вас и во что был упор. ну и как я понимаю код на rust все равно не такой высокоуровневый по итогу...
azgnetov
04.10.2025 05:56Скорость работы это хорошо, а скорость стабильной работы сравнивали? А то вот убунтоводы тоже на ржавом переписали gnu coreutils и сразу начали огребать: https://www.phoronix.com/news/Ubuntu-25.10-Coreutils-Makeself
CrazyHackGUT
04.10.2025 05:56Убунтоводы не переписывали. Убунтоводы просто интегрировали по умолчанию.
Fardeadok
04.10.2025 05:56Открою секрет: на си еще быстрее будет) просто надо его не напрямую через хттп использовать
budnikovsergey
04.10.2025 05:56у вашего решения фактор автобуса чудовищен
Tuxman
04.10.2025 05:56Фактор автобуса, только лишь на владении Растом, не канает. Если несколько человек знакомы с проектом, если есть какая-то документация, если есть какие-то автотесты, то автобуса тут нет.
user-book
04.10.2025 05:56херня какая-то
известны проблемы стандартного net/http в Го, именно потому если важна скорость или распределенность то есть куча других пакетов которые дышат в затылок найтивкам на си и раст
В Го есть встраиваение, сетевой уровень вы могли бы написать на Си и встроить, а уже на го работать с самими данными
За WASM просто смешно, на этот моменте я начал думать о том что это написано нейронкой. При чем тут вообще WASM? Единое что - сторонние модули которые подключаются на нем. Это удобно но это тонкое место для таких высоконагруженных систем, оптимальнее разбить на микросервисы если у вас там монолит с модулями.
UPD
к слову про тонкие моменты - есть абсолютно рабочий способ добиваться великого даже на net/http - шардирование.
на одном инстансе поднимаем сразу десяток одинаковых серверов которые написаны по принципу шарда и имеют общую память в том же редисе. настраиваем nginx как балансировщик (он может) что бы раскидывал запросы между этими 10 шардами и вуаля
Sanchous98
04.10.2025 05:56Или берем fiber у которого соответствующее решение уже сделано и решается флагом в конфиге. При чем nginx не нужен, под капотом используется сокет с опцией reuse port
MonkeyWatchingYou
04.10.2025 05:56Всем привет! Сегодня хочу зажечь настоящий холивар
Ок, не "куда переписываем", а "на что переписываем".
IlyaSlayer
04.10.2025 05:56Щас бы но сравнивать с раст или плюсами... Го такой же, как условный с# или джава. Только со своим обрыганным синтаксисом, меньшим количеством либами и хуже комьюнити. Быстроты в нем нет, если сравнивать с плюсами или растом. Да даже нет преимущества в быстроте с тем же с# или джава
vic_1
04.10.2025 05:56Может надо было распилить монолит для начала? И на самом деле интересно какая предметная область? Если телеком, ну может быть в каких то случаях rust, но для обычного энтерпрайза мне кажется перебор
feelamee
04.10.2025 05:56Компиляция в WASM: Это оказалось killer feature! Мы можем компилировать отдельные модули в WASM и запускать их в разных средах.
Не особо в теме, но разве go/cpp не может?
Предположу что любой компилируемый язык использующий llvm как бекенд имеет тулчейн для компиляции в wasm
SilverTrouse
04.10.2025 05:56Компиляция в WASM: Это оказалось killer feature! Мы можем компилировать отдельные модули в WASM и запускать их в разных средах.
Эммм и с++ и go также умеют в wasm, каким образом это стало киллер фичей?
tuxi
04.10.2025 05:56Автор, ну Вы бы хоть указали сколько строк кода в старом монолите, больше/меньше 1млн ?
Aleus1249355
04.10.2025 05:56Меня тоже интересует.
Предположил что проект большой и первая мысль была, что на переписывание "классического монолита на Spring Boot" уйдут человеко-годы. Ещё и на малоизвестный язык.
Tuxman
04.10.2025 05:56C++23: старый добрый друг с новыми трюками
Модули наконец-то работают как надоПодключить библиотеку std можно только в MSVC. Модули только для своего проекта - так себе.
Coroutines в стандартной библиотеке
std::generator только если. Корутины есть в языке в виде co_await/co_yield/co_return, а дальше надо брать какую-то стороннюю библиотеку, типа cppcoro или Boost::ASIO.
До сих пор нет нормальной системы пакетов (хотя vcpkg и Conan спасают)
cmake с FetchContent или сразу CPM.cmake.
Нужны очень опытные разработчики
На Rust тоже нужны, и их чаще всего не завезли, и кто-то будет переучиваться с плюсов или джавы.
SilverTrouse
04.10.2025 05:56Подключить библиотеку std можно только в MSVC. Модули только для своего проекта - так себе.
Эммм libc++ c 17 версии llvm поддерживает import std , а libstdc++ с 15 версии gcc ( 15 версия вышла весной этого года)
Tuxman
04.10.2025 05:56По факту не готово.
C++ compiler support Standard Library Modules (FTM)* P2465R3GCC libstdc++ 15*
Clang libc++ 17 (partial)*
MSVC STL 19.35* (partial)*
Apple Clang* 19.36*
nomorewar
04.10.2025 05:56Хаха, через полгода вынесли функционал из монолита и уже увидели профит. Хз как так, обычно полгода идет анализ монолита (если это реально что-то серьезное, как говорит автор, судя по стоимости инфры) , сбор бизнес требований, обсуждение выносимого функционала, описание интеграции этого функционала, всевозможные репликации для поддержки работы старого монолита в параллель с обновленным. Потом еще пишется и согласовывается вязанка ТЗ, происходит аудит всего и вся, типа архитектуры, безопасности и т. д. Потом выделяется инфра для всех окружений (не забыв согласовать бюджет). И вот, через полгода-год, можно начинать что-то писать.
AlanDeLoske
04.10.2025 05:56ИМХО. Думаю джаву все же можно было затюнить, что бы она держала нормально трафик на себе. Тк свежая джава довольно производительна. В основном я склоняюсь к тому, что просто появился шанс зауюзать раст. Надеюсь ребята внедряли его с оглядкой на то, что если вся команда со временем разбежится из конторы, то будет довольно трудно искать людей на поддержку этого проекта.
sedyh
Почему третий пункт приписан, как killer-feature раста? Он, конечно, хорошо туда собирается, но плюсы и go тоже умеют в wasm. И у всех трех есть zerodep embedded рантаймы для запуска модулей по типу wasmi, wasm3, wazero.