[!info] 关联笔记

• 所属 MOC：系统与服务 · 学习路线
• 前置概念：async、Tokio、错误处理
• 后续概念：优雅关闭、可观测
• 容易混淆：同步 I/O

构建 Rust HTTP 服务

目标

理解 Rust 服务常见栈：tokio + hyper/axum（或 actix-web 等），完成健康检查与 JSON 接口心智，而不是绑死某一框架版本细节。

[!abstract] 一句话理解 异步运行时驱动服务；框架负责路由与提取器；业务状态用 Arc 共享；错误映射为 HTTP 状态。

最小可运行示例

场景：订单查询服务的健康检查形状

// 伪代码/形状说明——完整可运行需添加 axum/tokio 依赖。
// 业务意图：GET /health 返回 ok。
// 教学点：路由；async handler；状态共享入口。

/*
use axum::{routing::get, Router};
use std::net::SocketAddr;

async fn health() -> &'static str { "ok" }

#[tokio::main]
async fn main() {
    let app = Router::new().route("/health", get(health));
    let addr = SocketAddr::from(([0,0,0,0], 8080));
    let listener = tokio::net::TcpListener::bind(addr).await.unwrap();
    axum::serve(listener, app).await.unwrap();
}
*/

fn main() {
    println!("use tokio+axum (or similar) to run an HTTP server");
}

结合场景再看三个关注点

1. 框架选择可替换，异步模型相同
2. handler 保持瘦，业务进 service 层
3. 测试可用 tower 服务测试或起端口

核心骨架

层	职责
router	路径与方法
extractor	解析参数/JSON
app service	用例
domain	规则
infra	DB/HTTP 客户端

工程实践

1. 超时与限制默认开启
2. 统一错误类型 → 状态码
3. 优雅关闭
4. 指标与 tracing
5. 配置十二因子

本节总结

• HTTP 服务 = async 运行时 + 框架 + 分层
• 健康检查先通
• 与运维能力同步建设

自测题

1. 为什么 handler 不该塞 SQL？
2. 健康检查应检查什么边界？

参考答案

1. 难测、难替换、违反分层。
2. 进程存活 vs 依赖就绪要分开（liveness/readiness）。

延伸阅读与资料来源

资料	类型	支撑内容
axum	生态	常用框架
hyper	生态	HTTP 库
Tokio	生态	运行时