gRPC-сервис на собственном VPS

gRPC даёт быстрый бинарный протокол поверх HTTP/2 — идеально для микросервисов и мобильных бэкендов. Разберём, как развернуть gRPC-сервис на VPS, закрыть его TLS и пробросить через nginx.

Почему gRPC требует нормального сервера

gRPC работает поверх HTTP/2 с постоянными мультиплексированными соединениями. Это значит, что каждый долгоживущий стрим держит ресурсы, а сериализация protobuf нагружает CPU. На дешёвом shared-хостинге такое просто не запустить — нужен root и полноценное ядро.

Для gRPC критична производительность на ядро: сериализация/десериализация protobuf и TLS-хендшейки любят быстрый одноядерный throughput. На тарифах MAATRIX стоят AMD EPYC + NVMe, поэтому даже базовый план тянет тысячи RPS без просадок по latency.

Ещё одна причина брать VPS, а не облачную функцию: gRPC-стримы бывают двунаправленными и живут минутами. Serverless-платформы режут время выполнения и рвут долгие соединения, а на своём сервере вы сами задаёте таймауты, keepalive и лимиты дескрипторов. Для аудитории из России добавляется практичный плюс — зарубежный сервер в UK или США с оплатой картой РФ, СБП или криптой, когда обычные иностранные провайдеры карту просто не принимают.

• Root-доступ — нужен для systemd, портов и TLS-сертификатов.
• HTTP/2 end-to-end — прокси обязан уметь grpc_pass.
• Статический IP — чтобы повесить домен и Let's Encrypt.

Готовим окружение

Возьмём Ubuntu 22.04/24.04. Обновляемся и ставим базовые пакеты:

apt update && apt upgrade -y
apt install -y build-essential curl git nginx

Поставим Go как пример рантайма для gRPC-сервера (аналогично можно взять Python/Node):

curl -LO https://go.dev/dl/go1.22.5.linux-amd64.tar.gz
rm -rf /usr/local/go && tar -C /usr/local -xzf go1.22.5.linux-amd64.tar.gz
echo 'export PATH=$PATH:/usr/local/go/bin' >> /etc/profile
source /etc/profile
go version

Для генерации кода из .proto понадобится protoc и плагины:

apt install -y protobuf-compiler
go install google.golang.org/protobuf/cmd/protoc-gen-go@latest
go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest

Запуск сервиса через systemd

Собираем бинарник и кладём его в /opt/grpcapp/server. Демонизируем через systemd, чтобы сервис поднимался после ребута:

cat > /etc/systemd/system/grpcapp.service <<'EOF'
[Unit]
Description=gRPC service
After=network.target

[Service]
ExecStart=/opt/grpcapp/server
Restart=always
User=www-data
Environment=GRPC_PORT=50051

[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl enable --now grpcapp
systemctl status grpcapp

Сервис слушает на 127.0.0.1:50051 — наружу его выпустит nginx с TLS, а сам порт закрыт файрволом. Директива Restart=always поднимет процесс после падения или ребута сервера, а запуск от пользователя www-data ограничивает права на случай компрометации. Логи смотрите через journalctl -u grpcapp -f — systemd собирает stdout/stderr автоматически, отдельный логгер не нужен.

Проксируем через nginx с TLS

gRPC требует HTTP/2 и специального модуля grpc_pass. Сначала выпустим сертификат:

apt install -y certbot
certbot certonly --standalone -d grpc.example.com

Конфиг nginx для gRPC-проксирования:

server {
    listen 443 ssl http2;
    server_name grpc.example.com;

    ssl_certificate     /etc/letsencrypt/live/grpc.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/grpc.example.com/privkey.pem;

    location / {
        grpc_pass grpc://127.0.0.1:50051;
        grpc_read_timeout 300s;
        grpc_send_timeout 300s;
    }
}

Проверяем и перезагружаем:

nginx -t && systemctl reload nginx

Проверка и частые ошибки

Тестируем сервис извне через grpcurl:

grpcurl grpc.example.com:443 list
grpcurl -d '{"name":"world"}' grpc.example.com:443 helloworld.Greeter/SayHello

• Ошибка «Received RST_STREAM» — nginx собран без http2 или в location нет grpc_pass.
• upstream unavailable — сервис не слушает 50051; проверьте ss -tlnp | grep 50051.
• TLS handshake fail — клиент коннектится по plaintext; используйте -plaintext только для локальных тестов.

Держите gRPC-сервис на отдельном VPS в UK или США: низкий пинг до Европы, root-доступ и ежедневные бэкапы на MAATRIX закрывают вопрос надёжности.

Частые вопросы