告别服务孤岛：用Axum+Tonic构建多服务gRPC应用的实战指南-优快云博客

告别服务孤岛：用Axum+Tonic构建多服务gRPC应用的实战指南

【免费下载链接】tonic A native gRPC client & server implementation with async/await support. 项目地址: https://gitcode.com/GitHub_Trending/to/tonic

你是否在开发微服务时遇到过这些痛点？多个gRPC服务分散部署导致运维复杂度飙升，服务间通信延迟增加，资源利用率低下？本文将带你一步一步实现用Axum构建复合gRPC应用，通过多服务路由功能将多个gRPC服务整合到单一入口，大幅简化架构并提升性能。读完本文后，你将掌握：Axum与Tonic的无缝集成、多服务注册与路由分发、请求处理流程优化以及完整的部署测试方案。

技术架构概览

在开始编码前，让我们先了解复合gRPC应用的整体架构。下图展示了使用Axum作为入口网关，如何将不同的gRPC服务请求路由到对应的服务实现：

mermaid

这种架构的核心优势在于：

单一入口点，简化客户端配置
集中式的认证、日志和监控
服务间共享资源，提高利用率
简化的部署和扩展策略

环境准备与依赖配置

首先确保你的开发环境中已安装Rust和Cargo。然后创建新项目并添加必要依赖：

[package]
name = "tonic-axum-multi-service"
version = "0.1.0"
edition = "2021"

[dependencies]
axum = "0.6"
tonic = "0.9"
prost = "0.12"
tokio = { version = "1.0", features = ["full"] }
tokio-stream = "0.1"
bytes = "1.0"
futures = "0.3"

项目结构建议参考官方示例的组织方式，主要分为协议定义、服务实现和主程序入口三部分：

tonic-axum-multi-service/
├── proto/                 # 协议定义目录
│   ├── test.proto         # Test服务定义
│   └── test1.proto        # Test1服务定义
├── src/
│   ├── main.rs            # 主程序入口，Axum服务器配置
│   ├── services/          # 服务实现目录
│   │   ├── test.rs        # Test服务实现
│   │   └── test1.rs       # Test1服务实现
│   └── generated/         # 生成的代码目录(自动生成)
└── build.rs               # 构建脚本，用于协议编译

定义gRPC服务协议

创建两个示例服务的proto文件，分别定义不同的gRPC方法。首先是Test服务：

proto/test.proto

syntax = "proto3";

package test;

service Test {
  rpc UnaryCall(Input) returns (Output);
}

message Input {
  string message = 1;
}

message Output {
  string reply = 1;
}

然后是Test1服务，包含简单调用和流式调用：

proto/test1.proto

syntax = "proto3";

package test1;

service Test1 {
  rpc UnaryCall(Input1) returns (Output1);
  rpc StreamCall(Input1) returns (stream Output1);
}

message Input1 {
  bytes buf = 1;
}

message Output1 {
  bytes buf = 1;
}

创建build.rs文件来配置代码生成：

build.rs

fn main() -> Result<(), Box<dyn std::error::Error>> {
    tonic_build::compile_protos("proto/test.proto")?;
    tonic_build::compile_protos("proto/test1.proto")?;
    Ok(())
}

运行cargo build后，Tonic会自动生成Rust代码，你可以在target/debug/build/目录下找到生成的文件。这些生成的代码包含了服务trait和客户端结构体，我们将在后续步骤中实现和使用它们。

实现gRPC服务逻辑

现在我们来实现这两个服务的业务逻辑。首先是Test服务的实现：

src/services/test.rs

use tonic::async_trait;
use generated::test::test_server::{Test, TestServer};
use generated::test::{Input, Output};

pub mod generated {
    tonic::include_proto("test");
}

#[derive(Debug, Default)]
pub struct TestService;

#[async_trait]
impl Test for TestService {
    async fn unary_call(
        &self,
        request: tonic::Request<Input>,
    ) -> Result<tonic::Response<Output>, tonic::Status> {
        let input = request.into_inner();
        Ok(tonic::Response::new(Output {
            reply: format!("Test service received: {}", input.message),
        }))
    }
}

pub fn create_test_service() -> TestServer<TestService> {
    TestServer::new(TestService::default())
}

接下来是Test1服务的实现，包含一个简单调用和一个服务器流式调用：

src/services/test1.rs

use tonic::async_trait;
use generated::test1::test1_server::{Test1, Test1Server};
use generated::test1::{Input1, Output1};
use tokio_stream::{Stream, StreamExt};
use std::pin::Pin;

pub mod generated {
    tonic::include_proto("test1");
}

#[derive(Debug, Default)]
pub struct Test1Service;

#[async_trait]
impl Test1 for Test1Service {
    async fn unary_call(
        &self,
        request: tonic::Request<Input1>,
    ) -> Result<tonic::Response<Output1>, tonic::Status> {
        let input = request.into_inner();
        Ok(tonic::Response::new(Output1 { buf: input.buf }))
    }

    type StreamCallStream = Pin<Box<dyn Stream<Item = Result<Output1, tonic::Status>> + Send>>;

    async fn stream_call(
        &self,
        request: tonic::Request<Input1>,
    ) -> Result<tonic::Response<Self::StreamCallStream>, tonic::Status> {
        let input = request.into_inner();
        let data = input.buf;
        
        // 创建一个流，将输入数据分块返回
        let stream = tokio_stream::iter(
            vec![
                Ok(Output1 { buf: data.clone() }),
                Ok(Output1 { buf: data.clone() }),
                Ok(Output1 { buf: data }),
            ]
        );
        
        Ok(tonic::Response::new(Box::pin(stream) as Self::StreamCallStream))
    }
}

pub fn create_test1_service() -> Test1Server<Test1Service> {
    Test1Server::new(Test1Service::default())
}

这两个服务实现了基本的功能：Test服务接收字符串并返回处理后的消息，Test1服务接收字节数据并返回相同的数据，其中流调用会将数据分三次返回。

使用Axum构建路由网关

现在到了本文的核心部分：使用Axum将多个gRPC服务组合成一个复合应用。Axum是一个基于Tokio和Hyper的Web框架，它的路由系统非常灵活，可以轻松集成Tonic的gRPC服务。

src/main.rs

use axum::{
    routing::get,
    Router, Server,
};
use std::net::SocketAddr;
use tonic::transport::Server as TonicServer;
use axum::body::Body;
use axum::http::{Request, Response};
use services::test::create_test_service;
use services::test1::create_test1_service;
use tonic::codegen::Service;
use futures::future::FutureExt;

mod services {
    pub mod test;
    pub mod test1;
}

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    // 创建gRPC服务
    let test_service = create_test_service();
    let test1_service = create_test1_service();
    
    // 创建Axum路由
    let app = Router::new()
        // 添加健康检查端点
        .route("/health", get(health_check))
        // 嵌套gRPC服务
        .nest_service("/test.Test/", test_service)
        .nest_service("/test1.Test1/", test1_service);
    
    // 配置服务器地址
    let addr = SocketAddr::from(([127, 0, 0, 1], 50051));
    println!("Server running on {}", addr);
    
    // 启动Axum服务器
    axum::Server::bind(&addr)
        .serve(app.into_make_service())
        .await?;
    
    Ok(())
}

async fn health_check() -> &'static str {
    "OK"
}

在这段代码中，我们使用nest_service方法将Tonic的gRPC服务嵌套到Axum的路由中。Axum会根据请求的gRPC服务名和方法名，自动将请求路由到对应的服务实例。注意路由路径的格式：/package_name.ServiceName/，这需要与proto文件中定义的包名和服务名保持一致。

请求处理流程解析

Axum处理gRPC请求的流程可以分为以下几个步骤：

客户端发送HTTP/2请求，包含gRPC特定的头信息
Axum根据请求路径匹配到对应的gRPC服务
请求被转换为Tonic能够处理的格式
Tonic调用我们实现的服务方法处理请求
处理结果被转换回HTTP/2响应并返回给客户端

下面是一个完整的请求处理流程图：

mermaid

这种架构的优势在于：

单一的HTTP/2连接可以复用，减少连接建立开销
集中式的错误处理和日志记录
简化的服务发现和负载均衡
易于添加认证、限流等横切关注点

测试与验证

为了验证我们的复合gRPC应用，我们需要编写客户端代码来测试这两个服务。创建一个测试客户端：

src/client.rs

use services::test::generated::test::test_client::TestClient;
use services::test::generated::test::Input;
use services::test1::generated::test1::test1_client::Test1Client;
use services::test1::generated::test1::Input1;
use tokio_stream::StreamExt;

mod services {
    pub mod test;
    pub mod test1;
}

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    // 连接到gRPC服务器
    let mut test_client = TestClient::connect("http://[::1]:50051").await?;
    let mut test1_client = Test1Client::connect("http://[::1]:50051").await?;
    
    // 测试Test服务
    let test_response = test_client
        .unary_call(Input {
            message: "Hello from test client".to_string(),
        })
        .await?;
    println!("Test service response: {:?}", test_response.into_inner().reply);
    
    // 测试Test1服务的UnaryCall
    let test1_unary_response = test1_client
        .unary_call(Input1 {
            buf: b"Unary call test data".to_vec(),
        })
        .await?;
    println!(
        "Test1 unary response: {:?}",
        String::from_utf8_lossy(&test1_unary_response.into_inner().buf)
    );
    
    // 测试Test1服务的StreamCall
    let mut test1_stream_response = test1_client
        .stream_call(Input1 {
            buf: b"Stream call test data".to_vec(),
        })
        .await?
        .into_inner();
    
    println!("Test1 stream response:");
    while let Some(item) = test1_stream_response.next().await {
        match item {
            Ok(output) => println!("  - {}", String::from_utf8_lossy(&output.buf)),
            Err(e) => eprintln!("Stream error: {}", e),
        }
    }
    
    Ok(())
}

修改Cargo.toml，添加客户端二进制目标：

Cargo.toml

[[bin]]
name = "server"
path = "src/main.rs"

[[bin]]
name = "client"
path = "src/client.rs"

现在你可以打开两个终端，分别运行服务器和客户端：

# 终端1: 启动服务器
cargo run --bin server

# 终端2: 运行客户端测试
cargo run --bin client

客户端应该会输出类似以下内容：

Test service response: "Test service received: Hello from test client"
Test1 unary response: "Unary call test data"
Test1 stream response:
  - Stream call test data
  - Stream call test data
  - Stream call test data

性能优化与最佳实践

在实际生产环境中，我们还需要考虑一些性能优化和最佳实践：

连接复用：确保客户端和服务器都启用HTTP/2连接复用，减少连接建立开销。Axum默认启用了这一特性。
服务端配置调优：

// 在main.rs中优化服务器配置
let mut http = hyper::server::conn::Http::new();
http.http2_max_concurrent_streams(1000);
http.http2_initial_stream_window_size(1024 * 1024);
http.http2_initial_connection_window_size(4 * 1024 * 1024);

日志与监控：集成tracing和metrics库来监控服务性能：

// 添加依赖
tracing = "0.1"
tracing-subscriber = { version = "0.3", features = ["env-filter"] }

// 在main.rs中初始化
tracing_subscriber::fmt()
    .with_env_filter(tracing_subscriber::EnvFilter::from_default_env())
    .init();

错误处理：实现统一的错误处理机制，将业务错误转换为适当的gRPC状态码。
服务发现：在微服务环境中，可以结合Consul或etcd实现动态服务发现。

总结与未来展望

通过本文的学习，你已经掌握了如何使用Axum和Tonic构建多服务gRPC应用。我们从定义服务协议开始，实现了业务逻辑，然后使用Axum构建了一个复合服务网关，最后测试验证了整个系统。

这种架构特别适合以下场景：

需要将多个相关的gRPC服务组合在一起的微服务架构
需要为前端应用提供单一API入口的BFF(Backend For Frontend)模式
需要在边缘设备上部署多个轻量级gRPC服务的物联网应用

未来你还可以进一步探索：

实现基于gRPC反射的动态路由
添加服务健康检查和自动恢复机制
集成分布式追踪(如Jaeger或Zipkin)
实现服务间的分布式事务

希望本文能帮助你构建更高效、更易于维护的gRPC应用。如果你有任何问题或建议，欢迎在项目的GitHub仓库提交issue或PR。

官方文档和更多示例可以在以下路径找到：

Tonic官方文档：README.md
路由测试示例：tests/integration_tests/tests/routes_builder.rs
RouteGuide完整示例：examples/routeguide-tutorial.md

【免费下载链接】tonic A native gRPC client & server implementation with async/await support. 项目地址: https://gitcode.com/GitHub_Trending/to/tonic

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考