
用 Rust 写的 Python Web 框架 Robyn:Python 的皮,Rust 的心
开篇:Python 后端框架的"性能之痛"
如果你写过 Python 后端,大概率经历过这种纠结:
Flask 简单优雅,但同步模型扛不住高并发;FastAPI 很现代,但吞吐量总差那么一口气。根本原因就一个——CPython 的 GIL(全局解释器锁),它让 Python 进程在任意时刻只能执行一个线程,CPU 密集型任务永远快不起来。
网上有个很形象的比喻:普通 Python 框架像骑自行车送快递——你能到处跑,但腿(单线程 GIL)就那么快。
那如果换个思路呢?把"腿"换成 Rust,把"大脑"留给 Python。
这就是 Robyn 的答案——一个用 Rust 写引擎、用 Python 写业务的异步 Web 框架。你写的代码和 Flask / FastAPI 几乎一样简单,但真正处理请求的,是一个 Rust 编译的高性能运行时。
Robyn 是 GitHub 上 sparckles/robyn 开源项目,作者 Sanskar Jethi 是 Bloomberg 的软件工程师。项目创建于 2021 年,目前 7.3k+ stars、335 forks,最新版本 0.88.0,累计下载量超过 50 万次,支持 Python 3.10 及以上版本。
7 行代码,跑起第一个服务
先别急着谈原理,直接感受一下 Robyn 的 API 有多"Python":
[python]
# app.py from robyn import Robyn app = Robyn(__file__) @app.get("/") async def h(request): return "Hello, world!" app.start(port=8080)
运行:
[bash]
pip install robyn python app.py
然后打开 http://localhost:8080,就能看到 "Hello, world!"。整个体验跟 Flask 几乎一样——装饰器定义路由、直接返回字符串、指定端口启动。新手没有任何学习门槛。
但注意 app.start(port=8080) 这行:这个 start 不是普通的 Python 启动逻辑,它把服务器控制权交给了 Rust 运行时。从这一刻起,你的 HTTP 请求就不再走 CPython 那条慢车道了。

核心原理:Python 与 Rust 的三层协奏
Robyn 的架构可以拆成三层,职责分得非常清楚:
第一层:Python 层(开发者接口)
这是你写代码的地方,负责:
·路由定义与装饰器
·请求参数注入
·中间件配置
·业务逻辑执行
·响应格式化
[python]
from robyn import Robyn, Request app = Robyn(__file__) @app.get("/users/:id") async def get_user(request: Request, user_id: str): # 业务逻辑跑在 Python 里 user = await fetch_user_from_db(user_id) return {"user": user.to_dict()}
第二层:PyO3 桥接层(通信管道)
Python 和 Rust 之间靠 PyO3 这座桥通信。当你在 Python 里用 @app.get() 注册路由时,Robyn 会把这个处理函数打包成一个 FunctionInfo 对象,通过 PyO3 注册进 Rust 运行时。之后每次请求到达,Rust 层负责路由分发,再回调到 Python 执行你的业务函数。
第三层:Rust 层(性能引擎)
所有与性能密切相关的工作都交给 Rust:
·HTTP 请求解析(基于 actix-web)
·URL 路由匹配(基于 matchit 路由库)
·WebSocket 连接管理
·静态文件服务
·响应序列化
·异步 I/O(基于 tokio 运行时)
HTTP Request arrives → Rust HTTP parser (actix-web) Route matching → Rust router (matchit) Parameter extraction → Rust Handler execution → Python (via PyO3) Response processing → Rust HTTP Response → Client

这套设计的精妙之处在于:GIL 只在你执行 Python 业务代码时短暂持有,而耗时最长的 I/O、解析、路由都在 Rust 侧并发完成,绕开了 Python 并发能力的瓶颈。
性能秘籍:Robyn 是怎么"快"起来的
光有架构还不够,Robyn 在性能优化上做了几件很"卷"的事:
1. const 路由:直接绕过 Python
对于健康检查这类返回静态内容的接口,可以标记为 const:
[python]
@app.get("/health", const=True) def health_check(): return {"status": "healthy"}
标记后,响应会被缓存在 Rust 内存中。如果没有注册中间件,这个请求完全不进入 Python,由 Rust 层直接返回——快到不可思议。
2. 零拷贝请求处理
Rust 层尽量采用零拷贝技术:请求体只解析一次并在层间共享,字符串以引用而非复制方式传递,响应缓冲区在请求间复用。每一毫秒的拷贝都被省掉了。
3. 同步/异步函数分而治之
Robyn 支持同步和异步两种处理函数,并分别优化:
[python]
# 同步函数:在线程池中执行,避免阻塞异步运行时 @app.get("/sync") def sync_handler(request): time.sleep(1)# 不会阻塞其他请求 return "Done" # 异步函数:直接在主异步运行时中执行 @app.get("/async") async def async_handler(request): await asyncio.sleep(1) return "Done"
4. 多进程 + 多线程横向扩展
Robyn 通过 SO_REUSEPORT 实现多进程共享同一个监听端口,每个进程内部再开多个 worker 线程:
[bash]
# 4 个进程,每个进程 2 个 worker python app.py --processes 4 --workers 2 # 或者一键开启生产优化模式 python app.py --fast
在 TechEmpower 的权威基准测试中(Round 22),Robyn 长期位列 Python Web 框架性能榜前列,被认为是当前最快的 Python Web 框架之一。
特性巡礼:不只是"快"
如果 Robyn 只有快,那还不值得大书特书。关键是它把现代 Web 框架该有的能力基本配齐了:
·WebSocket:连接管理在 Rust 层完成,高吞吐消息广播
·中间件:before_request / after_request 请求前后钩子
·动态路由 + 参数注入:路径参数、查询参数、请求头、请求体按需注入
·依赖注入:内置 DI 容器
·自动 OpenAPI 文档:路由自动生成 API 文档
·热重载:--dev 模式下改代码自动重启
·Jinja2 模板:服务端渲染
·静态文件服务
·Streaming / Server-Sent Events:流式响应
WebSocket 示例
[python]
from robyn import WebSocketDisconnect @app.websocket("/chat") async def websocket_handler(websocket): try: while True: message = await websocket.receive_text() response = process_chat_message(message) await websocket.send_text(response) except WebSocketDisconnect: pass
最酷的一点:直接写 Rust 扩展
Robyn 允许你直接编译 Rust 代码到应用中,把热路径逐步迁移到 Rust。也就是说,性能瓶颈可以渐进式优化——先用 Python 快速开发,再慢慢把关键逻辑换成语速之王的 Rust,完美践行"先跑起来,再优化"。

实战:一个完整的 REST API
把前面的知识点串起来,写一个带参数注入、中间件和文件上传的完整示例:
[python]
from robyn import Robyn, Request from robyn.types import PathParams, QueryParams, Headers, RequestBody app = Robyn(__file__) @app.before_request("/protected") def auth_middleware(request: Request): if request.headers.get("authorization") != "secret-token": return {"error": "unauthorized"}# 返回非 None 则中断请求 @app.get("/users/:id") async def get_user( request: Request, path_params: PathParams,# :id 参数 query_params: QueryParams,# ?page=1&limit=5 headers: Headers,# 请求头 ): return { "id": path_params["id"], "page": query_params.get("page", "1"), "user_agent": headers.get("user-agent"), } @app.post("/users") async def create_user(request: Request, body: RequestBody): # body 是解析后的请求体 return {"created": True, "received": body.to_dict()} if __name__ == "__main__": app.start(port=8080, workers=4)
启动开发模式:
[bash]
python app.py --dev
Robyn 会自动打开浏览器、生成 OpenAPI 文档,并且文件变更后自动重启。开发体验相当丝滑。
Robyn vs FastAPI:怎么选?
很多人的第一反应是:那我可以抛弃 FastAPI 了吗?别急,看下对比:

维度 | Robyn | FastAPI |
底层运行时 | Rust(actix-web + tokio) | Python(Starlette + Uvicorn) |
峰值吞吐量 | 更高,接近 Rust 原生 | 在纯 Python 框架中优秀 |
学习成本 | 很低,语法像 Flask | 低,但需了解 Pydantic |
生态成熟度 | 年轻,插件较少 | 非常成熟,第三方库丰富 |
数据校验 | 可选 Pydantic 支持 | 内置,基于类型注解 |
适用场景 | 高并发 API、实时应用、微服务 | 大多数 API 项目、快速原型 |
我的建议:
·如果追求极致性能、要处理高并发实时场景,或者团队想渐进式引入 Rust → 试试 Robyn
·如果项目依赖成熟生态(Pydantic 模型、大量第三方集成),或者团队求稳 → FastAPI 依然是更稳妥的选择
这两个不是谁取代谁的关系,Robyn 代表的是 Python Web 框架的新方向——用系统级语言的性能,补齐 Python 的最后一块短板。
常见问题与避坑指南
Q1:Robyn 稳定吗?适合生产吗?
项目仍在活跃开发中(PyPI 上标注 Alpha),核心功能稳定可用,但生态和插件相对薄弱。生产环境建议先在非关键服务上验证,同时关注版本更新。
Q2:安装时要编译 Rust 吗?
不需要。pip install robyn 直接安装预编译的 wheel,日常使用完全不用碰 Rust。只有你想自己写 Rust 扩展时才需要 Rust 工具链。
Q3:Robyn 和 FastAPI 能混用吗?
不能直接混用。它们是两套独立的框架,路由、中间件机制都不兼容。但可以把 Robyn 只用于性能敏感的服务,与 FastAPI 服务共存于一个微服务架构里。
Q4:同步函数会被"卡死"吗?
不会。Robyn 会把同步函数放到线程池执行,避免阻塞异步事件循环。但注意线程池有大小上限,长时间运行的 CPU 密集型任务建议还是写成异步或用专门方案。
写在最后
Robyn 让我想到 Python 生态近几年的一个趋势:打不过,就"融合"。
从 PyPy、GraalPy 试图优化解释器,到 Granian 用 Rust 重写 ASGI 服务器,再到 Robyn 用 Rust 写整个运行时——Python 社区不再死磕 GIL,而是选择把性能敏感的底层交给系统级语言,让 Python 继续做它最擅长的事:快速、优雅地表达业务逻辑。
Robyn 的定位从来不是"取代 FastAPI",而是给 Python 开发者多一个选择:当你需要逼近 Rust 的性能,又不愿意放弃 Python 的开发效率时,它就在那里。
如果你对高性能 Python Web 开发感兴趣,非常值得花一下午跑一遍 Robyn 的文档和示例。毕竟,"Python 的皮 + Rust 的心"这种组合,在 Web 框架领域还是头一回这么彻底。
主要参考来源:
·Robyn 官方文档:https://robyn.tech/documentation
·Robyn GitHub 仓库:https://github.com/sparckles/robyn
·Robyn 架构深度解析:https://robyn.tech/documentation/zh/apireference/architecturedeep_dive
·PyPI 项目页:https://pypi.org/project/robyn/