Go и gRPC для среднего бизнеса: когда пора уходить с PHP, а когда Symfony достаточно

Сразу зафиксируем позицию: мы не фанаты ни одного языка. PHP/Symfony — отличный инструмент для бизнес-логики, и 80% корпоративных сервисов среднего бизнеса правильно писать именно на нём. Go — отличный инструмент для узкого класса задач: высокая нагрузка, строгие SLA по задержкам, стриминг и интенсивное межсервисное взаимодействие. Проблема начинается, когда язык выбирают по моде, а не по задаче: либо переписывают на Go CRUD-бэк-офис и платят за это двойную цену разработки, либо держат на PHP-FPM сервис, который давно должен был стать Go-воркером.

Коротко о Go и gRPC: почему о них все говорят

Go (Golang) — компилируемый язык, созданный в Google как ответ на боли больших распределённых систем. Его ключевая особенность — горутины: легковесные потоки исполнения со стеком 2–8 КБ, которых на одном ядре можно держать десятки тысяч. Для сравнения: поток в классической модели «процесс на запрос» (PHP-FPM) — это десятки мегабайт памяти. Отсюда главная суперспособность Go — дешёвая конкурентность: сервер на Go держит тысячи одновременных соединений без пула процессов и очередей на вход.

gRPC — RPC-фреймворк от Google поверх HTTP/2 с контрактами на Protobuf. Вместо «договоримся о JSON на словах» у вас есть .proto-файл — единый источник правды, из которого генерируются типизированные клиенты и серверы для Go, PHP, Python и чего угодно. Бинарный протокол даёт полезную нагрузку в 2–10 раз меньше JSON, HTTP/2 — мультиплексирование и стриминг (серверный, клиентский, двунаправленный). Для связи «сервис с сервисом» внутри периметра это заметно эффективнее REST.

В чём Go реально выигрывает у PHP

В чём PHP и Symfony по-прежнему сильнее

6 сценариев, где Go + gRPC имеет смысл в среднем бизнесе

1. Высоконагруженный инджест данных маркетплейсов. Ozon и WB присылают тысячи событий цен, остатков и статусов в минуту. Go-сервис с воркерами и очередью переваривает такой поток на 2 vCPU, тогда как PHP-обработчики требуют горизонтального пула воркеров и всё равно упираются в задержки.
2. Телеметрия и IoT с производства. Датчики, станки, контроллеры шлют данные непрерывно. Длинные соединения, стриминг, агрегация на лету — это профиль Go.
3. Интенсивное межсервисное взаимодействие (east-west трафик). Когда у вас 5+ сервисов постоянно ходят друг к другу, gRPC с его бинарным протоколом и строгими контрактами снижает и задержки, и количество ошибок интеграции.
4. API-шлюз / BFF с жёстким SLA. Агрегатор, который собирает ответ из пяти бэкендов и обязан уложиться в 100 мс, — классика для Go.
5. Тяжёлые ETL-воркеры. Пакетная обработка сотен тысяч строк: сверка каталогов, пересчёт цен, разбор выгрузок. Go с его конкурентностью делает это в разы быстрее и дешевле по памяти.
6. Стриминг и push в терминалы. WebSocket-хабы, push-уведомления на планшеты цеха, live-дашборды директора — тысячи одновременных соединений на одном сервере.

И честная оговорка: если ваша интеграция делает 500 запросов в час к 1С по OData — Go не даст ничего, кроме модного стек-трейса. Узкое место там — сама 1С и частота опроса, а не язык обработчика. Такие задачи правильно остаются на PHP.

Гибридная архитектура: PHP для бизнеса, Go для нагрузки

Подход, который мы используем в своих проектах и рекомендуем среднему бизнесу: не «переписывать всё на Go», а выносить в Go только те компоненты, где это окупается.

┌──────────────────┐  стриминг/gRPC  ┌─────────────────────┐
│ Ozon / WB / IoT  │ ──────────────▶ │  Go-сервисы:         │
│ датчики, события │                 │  инджест, шлюз, ETL  │
└──────────────────┘                 ──────────┬──────────┘
                                                │ NATS / gRPC
┌──────────────────┐   OData / HTTP  ┌──────────▼──────────┐
│ 1С / ELMA365     │ ◀────────────── │  Symfony: бизнес-    │ ──▶ PostgreSQL
│ СБИС, банк       │ ──────────────▶ │  ядро, бэк-офис, API │ ──▶ Redis / Qdrant
└──────────────────┘                 └─────────────────────┘

Symfony остаётся сердцем: бизнес-правила, права доступа, документооборот, интеграции с 1С и BPM, админки. Go забирает то, что «горячее»: потоки событий, стриминг, агрегацию. Общаются они через NATS или gRPC. В результате бизнес-логика пишется на языке, где она дешевле, а нагрузка живёт там, где она дешевле по железу.

Какая база данных нужна Go-сервису

PostgreSQL — выбор по умолчанию. Драйвер pgx — один из лучших в экосистеме Go, а для типобезопасных запросов мы рекомендуем sqlc: вы пишете обычный SQL, на выходе получаете типизированный Go-код без рантайм-магии ORM. JSONB закрывает полуструктурированные данные (события, атрибуты товаров), партиционирование — большие таблицы.

Redis — кэш, rate limiting, короткие очереди, сессии стриминговых клиентов. ClickHouse — аналитика и журналы событий: телеметрия с производства и логи инджеста сжимаются в 10–20 раз и считаются агрегатами на лету; хранить это в Postgres — дорого и медленно. NATS — лёгкая событийная шина для Go-мира (если потоки огромные — Kafka, но это уже другая цена эксплуатации). MongoDB — только если у вас действительно документная модель данных, что в бизнес-системах редкость. etcd/Consul — service discovery для gRPC, если вы ещё не в Kubernetes.

Правило простое: не начинайте с NoSQL. PostgreSQL + Redis + (ClickHouse при появлении аналитики) закрывают 90% потребностей Go-сервисов среднего бизнеса.

Какой сервер нужен: инфраструктура в цифрах

Обратите внимание на асимметрию: Go-компонент, который съедает поток в десятки тысяч событий в минуту, живёт на 2 vCPU и паре гигабайт памяти. Эквивалент на PHP-FPM — это пул воркеров на 8–16 GB. Именно здесь Go экономит деньги на железе.

По оркестрации: среднему бизнесу до 8–10 сервисов Kubernetes не нужен — достаточно Docker Compose с healthcheck и restart-политиками. K8s оправдан, когда появляются требования автоскейлинга, канареечных деплоев и мультирегиональности. Балансировщик — Traefik или nginx с включённым HTTP/2 (для gRPC это обязательное условие). Мониторинг — Prometheus + Grafana, для профилирования Go — встроенный pprof: он позволяет найти узкое место по CPU и памяти за минуты, а не гадать.

Экономика: сколько стоит команда

Сервера — меньшая из статей расходов. Главная цена Go — люди. Middle Go в РФ в 2026 году — 250–320 тыс. ₽ против 190–250 тыс. у PHP, senior-разрыв ещё шире. Плюс стартовая скорость: Go строже, меньше «магии», и первые месяцы новая команда пишет медленнее, чем привычная PHP-команда. Зато поддержку Go-кода через год дешевле: меньше скрытого состояния, меньше сюрпризов от рантайма.

Практическое правило: Go окупается, когда экономия на серверах и цена сорванного SLA (простой инджеста, потерянные события, медленные дашборды) превышают надбавку к фонду оплаты труда. Для бизнеса с оборотом 300 млн – 2 млрд ₽ это почти всегда верно в высоконагруженных компонентах и почти никогда — в бэк-офисе.

Чек-лист: 5 вопросов перед переходом на Go

1. Есть ли реальная нагрузка? От 1 000 RPS или SLA p99 < 50 мс — да, смотрим на Go. Сотни запросов в час — нет.
2. Есть ли стриминг и длинные соединения? IoT, WebSocket, тысячи одновременных клиентов — профиль Go.
3. Сервисы интенсивно ходят друг к другу? East-west трафик — аргумент за gRPC.
4. Кто будет поддерживать? Нет Go-компетенции и бюджета на найм — остаёмся на PHP, это честнее.
5. Можно ли выделить компонент? Go даёт эффект, когда высоконагруженный кусок изолируется как отдельный сервис, а не когда переписывается монолит целиком.

Если «да» хотя бы на два первых вопроса и на пятый — Go + gRPC оправданы. Во всех остальных случаях правильнее инвестировать в архитектуру PHP-стека: RoadRunner/FrankenPHP, очереди, кэш и нормальные индексы в PostgreSQL дадут больше, чем смена языка.

Часто задаваемые вопросы

Правда, что Go всегда быстрее PHP?

Нет. В CRUD-задачах, где 90% времени уходит на запросы к базе и внешние API, разница между языками растворяется. Go выигрывает там, где много конкурентности, потоков данных и требований к задержкам, — и почти не даёт преимуществ в типовой бизнес-логике.

Может ли gRPC заменить REST в интеграциях с 1С и маркетплейсами?

Во внешнем контуре — нет: 1С и маркетплейсы говорят по HTTP/JSON, и это нормально. gRPC — это про внутреннюю связь ваших сервисов. Внешние интеграции оставляем в REST/HTTP, внутренний обмен переводим на gRPC или событийную шину.

У нас команда PHP. Страшно ли начинать с Go?

Начинайте с одного изолированного компонента — например, инджеста событий или ETL-воркера. Это снижает риск: бизнес-ядро остаётся на привычном стеке, а команда осваивает Go на задаче с понятными границами. Обычно первый Go-сервис пишется за 2–4 недели.

Что выбрать для старта: RoadRunner/FrankenPHP или сразу Go?

Сначала RoadRunner/FrankenPHP: это «почти бесплатно» даёт 2–5× к производительности PHP без смены команды и кода. Go подключаем, когда и этого мало или появляются стриминг и длинные соединения.

Когда переходить на Go точно не стоит?

Когда нагрузка мала, команда только PHP, а мотивация — «Go модный» или «PHP медленный» по ощущениям. В этом случае смена языка съест месяцы и не даст бизнес-эффекта: узкие места останутся в базе, интеграциях и процессах.

Итог

Go + gRPC — не «следующая ступень эволюции после PHP», а специализированный инструмент для конкретного класса задач: высокая конкурентность, стриминг, строгие SLA, интенсивный межсервисный обмен. PHP/Symfony — по-прежнему лучший выбор для бизнес-логики, бэк-офисов и интеграций с 1С и BPM. Зрелая архитектура среднего бизнеса — это гибрид: каждый язык работает там, где он дешевле и сильнее.

Если вы оцениваете, какие компоненты вашей системы стоит вынести в Go, — напишите нам. Проведём архитектурный аудит: замерим реальные нагрузки, найдём узкие места и предложим схему «PHP + Go» с расчётом инфраструктуры и стоимости владения. А про то, как мы выносим интеграции из 1С в отдельные сервисы, читайте в статье блога про интеграцию 1С и ELMA365 через Symfony и брокер сообщений.