每秒 7000 万次请求、500PB 数据、每周 10 亿用户——这是 OpenAI 背后存储系统 Habitat 面对的规模。真正值得工程团队借鉴的，不只是数字，而是它处理技术债的方式：Habitat 最初只是一个连接数据库的小型 Python 库，OpenAI 很早就知道 Python 终究难以支撑这样的增长，却没有立刻推倒重来。
这是一种很成熟的工程判断：知道系统最终需要重写，不等于现在就应该重写。 更稳妥的路径，是先让旧系统继续产生业务价值，同时把边界、协议和瓶颈逐步固定下来，再把最值得优化的部分迁移到 Rust 等更适合高性能基础设施的语言中。
真正难的不是“换语言”，而是“换语言时不丢掉系统”
从 Python 迁移到 Rust，表面上是语法和运行时的变化，实际涉及至少四个层面：
- 调用协议：上层业务如何访问存储，参数和返回值是否稳定？
- 数据语义：超时、重试、空值、并发写入和错误码是否保持一致？
- 运维方式：新组件能否被现有监控、发布和回滚系统管理？
- 迁移节奏：能否只替换一个热点路径，而不是一次性替换整个系统？
如果这些问题没有答案，重写项目往往会从“提升性能”变成“同时维护两个不兼容的系统”。
因此，语言迁移的第一产物不应该是 Rust 代码，而应该是一个稳定的接口。例如，先把存储访问收敛成这样的契约：
get(namespace, key) -> value | not_found
put(namespace, key, value, ttl) -> success | error
具体实现可以继续是 Python，也可以逐步替换成 Rust。只要契约不变，上层调用方就不必跟着迁移。
为什么不应该一开始就重写
“Python 扛不住规模”可能是正确判断，但它仍然不是立刻重写的充分理由。原因很现实：
- 瓶颈可能不在语言本身。网络往返、数据库锁、序列化、磁盘和连接池都可能比解释器更慢。
- 完整重写会放大未知风险。旧系统中可能存在没有文档记录的兼容行为。
- 业务需求会持续变化。如果接口还没有稳定，Rust 版本很可能只是把不稳定需求重新实现一遍。
- 一次性切流难以回滚。基础设施系统出现数据一致性问题，代价远高于一次请求变慢。
更好的做法是先测量，再决定迁移范围。可以按下面的顺序拆解问题：
- 统计请求量、延迟分位数、错误率和资源消耗；
- 找出 CPU 密集、锁竞争或内存占用最高的路径；
- 为该路径建立输入、输出和错误行为的契约测试；
- 保留 Python 实现作为对照或回退路径；
- 只迁移一个可独立验证的模块；
- 通过灰度流量比较两套实现，再逐渐扩大范围。
这比“把整个仓库翻译成 Rust”更像是工程，而不是一次语言迁移竞赛。
一个可落地的渐进式迁移骨架
下面是一个简化示例。假设旧系统有一个 Python 存储客户端，现在希望在不修改业务调用方式的前提下，逐步接入新的 Rust 实现。
示例使用 Python 标准库，因此不需要额外安装依赖。将内容保存为 migration_demo.py 后直接运行即可：
import os
from dataclasses import dataclass
from typing import Dict, Optional
@dataclass
class Record:
value: str
version: int
class PythonStore:
"""旧实现：用于开发、回退和对照测试。"""
def __init__(self) -> None:
self.data: Dict[str, Record] = {}
def get(self, key: str) -> Optional[Record]:
return self.data.get(key)
def put(self, key: str, value: str) -> Record:
old = self.data.get(key)
record = Record(value=value, version=(old.version + 1 if old else 1))
self.data[key] = record
return record
class RustStoreAdapter:
"""新实现的适配器示意。
真实项目中，这里可以调用 Rust 动态库、HTTP 服务或 gRPC 服务。
本示例先用同样的语义模拟远端 Rust 服务，方便直接运行。
"""
def __init__(self) -> None:
self.data: Dict[str, Record] = {}
def get(self, key: str) -> Optional[Record]:
return self.data.get(key)
def put(self, key: str, value: str) -> Record:
old = self.data.get(key)
record = Record(value=value, version=(old.version + 1 if old else 1))
self.data[key] = record
return record
def build_store():
# 先通过环境变量切换实现，便于灰度、回滚和本地对照。
backend = os.getenv("STORE_BACKEND", "python")
if backend == "rust":
return RustStoreAdapter()
return PythonStore()
def main() -> None:
store = build_store()
first = store.put("user:42", "active")
second = store.get("user:42")
print(f"backend={store.__class__.__name__}")
print(f"written={first}")
print(f"read={second}")
if __name__ == "__main__":
main()
运行旧实现：
python migration_demo.py
切换到新实现的适配器：
STORE_BACKEND=rust python migration_demo.py
这个例子没有声称模拟 Habitat 的内部实现，它展示的是迁移时应保留的结构：业务代码依赖接口，不直接依赖具体语言；实现通过配置切换；旧实现始终保留为回退路径。
在真实系统中，RustStoreAdapter 可以进一步变成一个 HTTP 客户端。例如，先让 Rust 服务提供稳定的 GET /records/{key} 和 PUT /records/{key} 接口，再让 Python 逐步把流量转发过去。这样做的代价是增加一次网络跳转，但换来的好处是进程隔离、独立发布和更清晰的回滚边界。
Rust 应该优先接管哪些部分
并不是所有 Python 代码都值得迁移。更合适的目标通常具备以下特征：
- 每个请求都会执行，累计 CPU 消耗很高；
- 需要高并发、低延迟和稳定的尾部延迟；
- 包含序列化、压缩、协议解析或内存管理等热点操作；
- 接口相对稳定，能够通过契约测试验证行为；
- 可以与业务编排、控制面和实验性逻辑隔离。
相反，变化频繁的业务规则、一次性脚本、低流量管理接口，通常没有必要为了“统一语言”而迁移。Rust 的编译约束和内存安全能降低一类运行时风险，但也会提高开发门槛、编译复杂度和团队维护成本。
一个实用的决策表可以是：
| 模块类型 | 迁移优先级 | 主要原因 |
|---|---|---|
| 高频数据路径 | 高 | 性能收益可能直接影响容量和延迟 |
| 序列化、压缩、协议解析 | 高 | 边界清晰，容易做基准测试 |
| 稳定的连接池或调度核心 | 中高 | 可长期复用，但需要严格验证并发语义 |
| 快速变化的业务规则 | 低 | 重写后很快还会继续变化 |
| 低频运维脚本 | 低 | 迁移收益通常不足以覆盖成本 |
关键不是证明 Rust 更快，而是证明某个具体模块值得用 Rust 重新实现，并且收益能够覆盖迁移和运维成本。
把迁移当成长期架构能力
Habitat 的案例给出的启发，可以浓缩成一条路线：先用更快的方式验证产品和接口，再用数据找出真正的系统瓶颈，最后把稳定且高价值的核心路径迁移到更合适的实现上。
落地时可以检查以下事项：
- 是否有明确的接口和错误语义，而不是只有函数调用习惯？
- 是否有覆盖读写、超时、重试、并发和故障场景的契约测试？
- 是否能按租户、分片、机房或请求比例逐步灰度？
- 是否保留旧实现，并且能在分钟级完成回滚？
- 是否同时比较平均延迟、P95/P99、CPU、内存、网络和错误率？
- 是否明确谁负责 Rust 组件的发布、值班和安全更新？
从 Python 到 Rust 的价值，不在于把代码换成另一种语法，而在于让系统获得更清晰的边界、更可控的性能和更低风险的演进路径。面对超大规模基础设施，最有效的重写往往不是一次完成的重写，而是一连串可以测量、验证和撤回的小步替换。