gRPC-микросервис на tonic

Привет, Хабр!

Сегодня мы рассмотрим, как поднять gRPC‑микросервис на tonic и обвязать его аутентификацией плюс метриками через Tower‑middleware.

Зачем gRPC в Rust-экосистеме микросервисов?

gRPC уверенно занимает свою нишу в Rust‑экосистеме микросервисов, потому что даёт то, чего не хватает REST — настоящую пропускную способность, строгую типизацию и стабильную двустороннюю коммуникацию. По бенчмаркам, при серьёзной параллельной нагрузке (500 клиентов и более) gRPC способен держать до 9× больше запросов, чем REST на JSON, а при использовании protobuf через HTTP — выигрывает около 30%.

Второй козырь — это зрелый сетевой стек: gRPC работает поверх HTTP/2 с полноценным мультиплексированием, без проблем head‑of‑line blocking и с поддержкой стриминга и bidirectional‑каналов сразу из коробки. Кодогенерация на основе .proto создаёт строгие SDK с полной типобезопасностью. А сам tonic — это стабильная обёртка на Tokio и Hyper, активно поддерживаемая и адаптированная под актуальные версии Hyper 1.0 и Prost 0.13. В общем, всё, что нужно для адекватного сервиса, тут уже есть.

Подготовка .proto и генерация кода

На первом этапе мы определяем gRPC‑контракт — для этого создаём отдельную директорию proto/, в ней описываем структуру и API нашего сервиса на языке Protocol Buffers. Получается базовая структура проекта:

my-svc/  ├─ Cargo.toml  ├─ build.rs  └─ proto/      └─ greeter.proto

Содержимое greeter.proto:

syntax = "proto3";  package helloworld;  service Greeter {   rpc SayHello (HelloRequest) returns (HelloReply); }  message HelloRequest { string name = 1; } message HelloReply  { string message = 1; }

Объявляем сервис Greeter с одним методом SayHello, который принимает HelloRequest с полем name и возвращает HelloReply с текстом ответа.

Теперь нужно сгенерировать код на Rust, который реализует этот контракт. Это делается с помощью tonic-build — плагина, который по .proto файлам генерирует клиентские и серверные трейты и структуры. Для этого юзаем build.rs:

fn main() -> Result<(), Box<dyn std::error::Error>> {     tonic_build::configure()                  // настройка генерации         .build_server(true)                   // генерируем серверную сторону         .build_client(true)                   // и клиентскую         .compile(&["proto/greeter.proto"], &["proto"])?; // путь к .proto и include-пути     Ok(()) }

configure() позволяет настроить, что именно мы хотим сгенерировать, указываем, что нужны и сервер, и клиент. compile() принимает список файлов .proto и include‑пути (их может быть несколько, если .proto‑файлы разбиты по модулям). Всё это интегрировано с системой сборки Cargo: при первом cargo build код будет сгенерирован автоматически и попадёт в папку OUT_DIR, откуда мы его позже подключим через tonic::include_proto!.

Фрагмент Cargo.toml, нужный для этого:

[dependencies] tokio   = { version = "1.38", features = ["rt-multi-thread", "macros"] } tonic   = { version = "0.13", features = ["transport", "tls"] } prost   = "0.13"  # для метрик и интерсепторов tower       = "0.5" tower-http  = { version = "0.5", features = ["trace"] } tracing     = "0.1" tracing-subscriber = "0.3"

На выходе получаем полностью типизированный код — трейты сервиса, структуры сообщений, клиентскую обёртку, серверный интерфейс и всё это совместимо с остальным Rust‑кодом.

Асинхронный сервер на tonic

Создаём gRPC‑сервер, который реализует интерфейс Greeter и отвечает на метод SayHello. Подключаем сгенерированный код и реализуем логику:

use tonic::{transport::Server, Request, Response, Status};  pub mod greeter {     tonic::include_proto!("helloworld"); }  #[derive(Default)] pub struct MyGreeter;  #[tonic::async_trait] impl greeter::greeter_server::Greeter for MyGreeter {     async fn say_hello(         &self,         request: Request<greeter::HelloRequest>,     ) -> Result<Response<greeter::HelloReply>, Status> {         let name = request.into_inner().name;         let reply = greeter::HelloReply { message: format!("Привет, {name}!") };         Ok(Response::new(reply))     } }

Главный main.rs:

#[tokio::main] async fn main() -> Result<(), Box<dyn std::error::Error>> {     tracing_subscriber::fmt::init();      let addr = "0.0.0.0:50051".parse()?;     let greeter = MyGreeter::default();      // Перехватчик для заголовочного токена     let auth_interceptor = tonic::service::Interceptor::new(|req: Request<()>| {         match req.metadata().get("authorization") {             Some(v) if v == "Bearer super-secret" => Ok(req),             _ => Err(Status::unauthenticated("missing or invalid token")),         }     });      Server::builder()         // Tower-слой для трассировки и метрик         .layer(             tower::ServiceBuilder::new()                 .layer(tower_http::trace::TraceLayer::new_for_grpc())                 .into_inner(),         )         .add_service(             greeter::greeter_server::GreeterServer::with_interceptor(greeter, auth_interceptor),         )         .serve(addr)         .await?;     Ok(()) }

Interceptor в tonic реализуется через замыкание FnMut(Request) -> Result. TraceLayer из tower‑http сразу умеет выводить tracing‑спаны для gRPC‑методов.

Немного про безопасность

Чтобы сервер шифровал трафик, включаем фичу tls или tls-ring и настраиваем Server::builder().tls_config(...). Если нужно mTLS (взаимная аутентификация), обязательно подключаем клиентские сертификаты и валидацию subjectAltName.

Ну и конечно не забываем про базовые защиты на уровне middleware: concurrency_limit, timeout, rate_limit, in_flight_requests из Tower — это обязательный слой при боевом деплое. Он защищает от внезапных всплесков, медленных клиентов и сетевых глюков.

Метрики и Prometheus

Если хотите интеграцию с Prometheus:

use tower_http::metrics::{InFlightRequestsLayer, PrometheusMetricLayer};

Подключаем:

.layer(InFlightRequestsLayer::new()) .layer(PrometheusMetricLayer::new())

Сами метрики можно затем отдавать через отдельный HTTP‑сервер (например, на axum, warp, hyper) — это уже зависит от общей архитектуры проекта.

Стуб-клиент

Для обращения к gRPC‑сервису используем автоматически сгенерированный клиент. Он типизирован, работает асинхронно и поддерживает те же механизмы Interceptor’ов, что и сервер.

Пример:

#[tokio::main] async fn main() -> Result<(), Box<dyn std::error::Error>> {     // Создаём канал к серверу     let channel = tonic::transport::Channel::from_static("http://localhost:50051")         .connect()         .await?;      // Оборачиваем канал в клиент с Interceptor'ом     let mut client = greeter::greeter_client::GreeterClient::with_interceptor(         channel,         |mut req: Request<()>| {             req.metadata_mut()                 .insert("authorization", "Bearer super-secret".parse().unwrap());             Ok(req)         },     );      // Отправляем gRPC-запрос     let reply = client         .say_hello(greeter::HelloRequest { name: "Habr".into() })         .await?         .into_inner();      println!("Server answered: {}", reply.message);     Ok(()) } 

СоздаемChannel, который является абстракцией над gRPC‑транспортом. Он может быть from_static, либо динамически через DNS / load balancing.

GreeterClient::with_interceptor позволяет внедрить middleware на клиентской стороне — удобно, чтобы централизованно добавлять токены, трейсинг, идентификаторы, tenant‑id и т. п.

say_hello(...) вызывается как обычная асинхронная функция — типизация, структура запроса и ответа полностью совпадают с тем, что было описано в .proto.

Клиентский Interceptor использует точно такой же API, как и серверный — это даёт единообразие в обработке метаданных. Один раз написали обёртку — используете и на входящих, и на исходящих вызовах.

А ну и еще, если бы мы не использовали Interceptor, можно было бы добавлять метаданные вручную к каждому отдельному запросу, но это не масштабируется. Лучше один раз обернуть — и забыть.

Если вы уже обкатывали gRPC в Rust или внедряли что‑то похожее с tonic, делитесь своим опытом в комментариях — какие подходы сработали, какие мидлвары зашли и как решали вопросы с безопасностью.

---

Когда разбираешься с gRPC, хочется верить, что это решает всё. Но настоящая боль начинается там, где нужно продумать бизнес-логику, распределить ответственность между сервисами, не утонуть в очередях сообщений и не превратить архитектуру в клубок. Если вы тоже на этом этапе — заглядывайте на открытые уроки:

• 28 июля, 20:00
  Основы проектирования бизнес-логики в микросервисной архитектуре
  Как не похоронить масштабируемость под слоем хаотичной логики. Разбор паттернов, ошибок и живых кейсов.

• 11 августа, 20:00
  RabbitMQ против Kafka — что выбрать для вашей структуры
  Что реально стоит за этими системами, когда вы работаете не с туториалами, а с продом. Честное сравнение, нюансы и рекомендации для вашей архитектуры.

Пройдите вступительный тест и получите скидку на курс «Microservice Architecture».