King's 技术博客：技术分享与创新解读

"用 Rust 写微服务？为什么不用 Go？"

每次在技术群里提这个话题，总有人问这句话。

Go 确实更简单，生态更成熟，学习曲线更平缓。但 Rust 有 Go 给不了的东西：零成本抽象、内存安全、以及"编译通过就能上线"的信心。

这篇文章不教你从零搭框架——那些教程网上一大把。我想分享的是真正踩过的坑、做过的选择、以及回头来看哪些决定是对的。

什么时候该用 Rust 写微服务？

先说结论，别浪费时间。

适合的场景：

高性能网关、代理（替代 Nginx/OpenResty）
实时数据处理（游戏服务器、交易系统、流式计算）
资源敏感环境（边缘计算、IoT 网关、嵌入式服务）
需要和 C/C++/Python 做 FFI 集成的系统

不适合的场景：

快速迭代的业务系统（开发效率真的低）
团队没有 Rust 经验（至少需要一个老手带）
CRUD 密集型应用（Go/Java 更合适）

选 Rust 之前，你要接受这几件事：

编译时间很长——大项目增量编译 30 秒起步，全量编译可能要几分钟
异步生态碎片化——tokio 和 async-std 至今没有统一
错误处理的样板代码很多——没有 ? 的语言都不理解你的痛
中间件生态不如 Go/Java 丰富——很多东西要自己造轮子

框架选型：为什么选了 axum

Rust Web 框架主要三个选择：axum、actix-web、poem。

我选 axum 的原因很简单：它是 Tokio 团队维护的。

不是说 actix-web 和 poem 不好，而是在微服务这种需要长期维护的场景里，维护者的持续投入比性能指标更重要。 actix-web 之前经历过核心维护者交接的动荡期，这让我有点担心。

axum 的设计思路和 actix-web 也不同。actix-web 用 extractor 做参数提取，类型安全但写起来啰嗦。axum 的 extractor 模式更简洁，编译期检查更严格，运行时错误更少。

一个真实的对比感受： 写一个接收 JSON body 的 handler，actix-web 需要 #[post("/users")] 加上手动标注 Json<CreateUserRequest>，axum 直在函数签名里用 extractor，编译器就能帮你检查类型是否匹配。

错误处理：最大的坑

这是 Rust 微服务里最容易踩坑的地方，没有之一。

刚开始写的时候，我的错误处理很随意——随便定义一个 Box<dyn Error> 然后到处 .unwrap()。结果上线后第一个问题就是：某个接口偶尔返回 500，但日志里什么都没有。

原因是 unwrap() 在 panic 之前没有记录任何上下文信息，而生产环境的 panic 默认不会直接打到 stderr。

后来我学乖了，做了几件事：

1. 定义统一的错误类型

每个微服务都定义自己的 AppError 枚举，包含所有可能的错误情况。不要用 Box<dyn Error>，编译器帮不了你。

2. 实现 `IntoResponse`

让每个错误类型自动映射到 HTTP 状态码。这样 handler 函数的返回类型就是 Result<Json<T>, AppError>，清晰明了。

3. 错误转换要分层

数据库错误、业务逻辑错误、外部服务错误，它们的 HTTP 语义完全不同。数据库挂了应该返回 503，参数校验失败返回 400，资源不存在返回 404。不要把所有错误都返回 500。

4. 记录详细日志，返回友好消息

内部错误要记录完整的 error chain 和 stack trace，但返回给客户端的应该是简洁的错误描述。别把数据库连接字符串泄露出去。

数据库连接池：参数不是越多越好

sqlx 的连接池配置看起来很简单，但参数调优是门学问。

刚开始我把 max_connections 设成 100，觉得"越大越好"。结果在压测时发现 QPS 反而下降了。原因是 PostgreSQL 的连接数有上限，而且每个连接都有内存开销。过多的连接反而增加了锁竞争。

我的经验公式： max_connections = CPU 核心数 × 2 + 磁盘数。一般微服务设 20-50 就够了。

另外几个容易忽略的参数：

acquire_timeout：获取连接的超时时间，建议 3-5 秒。太短会频繁失败，太长会让请求卡住。
idle_timeout：空闲连接的存活时间，建议 5-10 分钟。太长浪费资源，太短频繁创建销毁。
max_lifetime：连接的最大生命周期，建议 30 分钟。防止数据库端的连接泄漏。

异步编程的陷阱

Rust 的异步编程和 Go 的 goroutine 完全不同。Go 的调度器帮你处理一切，Rust 的 tokio 需要你自己考虑 Send、Sync、以及 Pin。

最常见的坑：在异步上下文中持有 MutexGuard

// 千万不要这样写
async fn bad_example(data: Arc<Mutex<HashMap<String, String>>>) {
    let lock = data.lock().await;  // 持有锁
    // 如果这里 await 了另一个异步操作，锁可能永远不会释放
    some_async_operation().await;
}  // 锁在这里释放

用 tokio::sync::RwLock 代替 std::sync::Mutex，它支持异步等待。

另一个坑：block_on 在异步上下文中

不要在 async fn 里调用 tokio::runtime::Handle::block_on()。这会阻塞当前的 tokio worker thread，可能导致整个 runtime 停滞。

服务间通信：HTTP 够用就别上 gRPC

微服务之间的通信，很多人第一反应是上 gRPC。但我的经验是：先用 HTTP + JSON，等真正遇到性能瓶颈再考虑 gRPC。

原因：

HTTP + JSON 调试方便——curl 就能测，Postman 就能调
gRPC 的 Rust 生态（tonic）虽然成熟，但学习成本不低
服务间调用的延迟瓶颈通常在序列化和网络传输，不在协议本身

什么时候真的需要 gRPC？

服务间需要双向流式通信
对序列化性能有极端要求（每秒百万级消息）
需要强类型的跨语言接口定义

Docker 部署的教训

Rust 项目的 Docker 镜像构建是个老大难问题。

教训一：一定要用多阶段构建。 编译阶段的镜像可能几个 GB，运行时镜像只要几十 MB。

教训二：利用 cargo chef 缓存依赖。 不然每次修改一行代码，Docker 都要重新编译所有依赖，等十几分钟是常态。

教训三：不要在镜像里装多余的包。 用 debian:bookworm-slim 或者 alpine 作为基础镜像，只安装必要的运行时依赖（通常是 ca-certificates 和 libssl）。

教训四：用非 root 用户运行。 这是安全最佳实践，但很多教程都忽略了。

监控：别等出了问题才加

微服务上线之前，至少要有这些：

请求日志：记录 method、URI、状态码、耗时。用 tracing crate，不要用 log。
健康检查：提供 /health 和 /readiness 端点。Kubernetes 需要这些。
关键指标：QPS、P99 延迟、错误率。用 prometheus crate 暴露指标。
分布式追踪：用 OpenTelemetry 记录请求在各个服务间的调用链。

一个真实的故事： 某个接口偶尔超时，但监控显示 P99 只有 200ms。后来加了 P999 才发现，0.1% 的请求延迟超过 5 秒——原因是某个数据库查询偶尔触发全表扫描。

性能优化：什么时候值得做

过早优化是万恶之源——这句话在 Rust 项目里尤其重要。

Rust 本身已经很快了。大多数微服务的性能瓶颈在 IO（网络、数据库、磁盘），不在 CPU。在你优化业务逻辑之前，先检查：

数据库查询有没有走索引？
连接池参数是否合理？
是不是频繁序列化/反序列化大对象？
日志级别设对了吗？debug 日志在生产环境会严重影响性能。

真正值得优化的场景：

热点路径上的大量小对象分配（用对象池）
频繁的字符串拼接（用 StringBuilder 或 bytes::Bytes）
大批量数据处理（用流式处理，不要一次性加载到内存）

结论

如果你决定用 Rust 写微服务，记住这几点：

先跑起来再优化。 不要一开始就追求极致性能。
错误处理不能偷懒。 这是 Rust 微服务的命门。
善用 cargo clippy。 它能发现很多你想不到的问题。
写测试。 Rust 的测试框架很好用，不要浪费。
文档化 API。 用 OpenAPI（swagger），前端和测试都感谢你。
团队里至少有一个 Rust 老手。 学习曲线确实陡。

最后，什么时候选 Go 而不是 Rust？

如果你的团队更熟悉 Go，如果你的业务变化很快需要快速迭代，如果你的需求就是简单的 CRUD——选 Go。Go 的开发效率确实比 Rust 高很多。

Rust 微服务适合那些需要长期运行、性能敏感、可靠性要求高的系统。选 Rust，意味着选择"一次写好，长期运行"的思路。