用 Rust 与太空对话：KSAT 的工程实践

本文来自 corrode.dev/podcast/s04...

大家好，今天想和你聊一个既浪漫又硬核的技术话题：

"Rust 语言，在全球卫星通信系统中的真实应用。"

这不是实验项目，也不是业余爱好，而是实打实的------每天有成百上千颗卫星，靠它在地球和太空之间传输数据、发送指令。

听上去像是太空歌剧？其实就是现实的 KSAT 公司正在干的事。

KSAT 是谁？他们到底在干嘛？

KSAT，全称是 Kongsberg Satellite Services，总部在挪威。他们的主业是做全球卫星地面站网络，简单讲就是：

卫星上有数据？他们来接。
要给卫星发指令？他们来发。
卫星什么时候从头顶飞过？他们来算。
哪颗卫星数据卡住了？他们来查。

他们的客户是谁？

NASA、ESA（欧洲航天局）、NOAA、SpaceX、Planet Labs、OneWeb、ICEYE......你听说过的和没听说的航天公司，很多都跟 KSAT 合作。

这行的技术难度到底有多高？

你可能会想：地面站嘛，不就是"收发数据"吗？看上去不复杂啊？

但真相是：超级复杂，超级容易出问题，比你想象中要难十倍。

我们来举几个真实的挑战：

1. 卫星不是随时在线的！

很多低轨道卫星（LEO）每次只在你头顶飞几分钟，你必须在窗口期内完成所有通信。

错过一次，就要等下一个轨道周期（可能 90 分钟以后）。

所以系统必须：

准时唤醒
快速同步
毫不延迟地发指令 / 接数据

容不得一秒钟的耽误。

2. 每天同时服务上百颗卫星

KSAT 全球有 20+ 地面站，每天要和几百颗卫星通信，这意味着：

多线程并发调度是常态
网络带宽压力极大（下行数据可能是高清视频、雷达图像）
系统必须"脑子清楚"，不能搞混哪颗卫星传了什么数据

3. 环境恶劣，设备多样

很多地面站建在极地、沙漠、荒岛，硬件系统老旧但仍在运行中，有的设备是 90 年代留下来的，甚至不支持 HTTPS......

这些设备要：

保证互联
和新系统对接
还能被远程运维

所以代码得非常"能适应环境"。

为什么选择 Rust？

Vegard Sandengen 是 KSAT 的一位资深工程师，负责他们使用 Rust 构建关键通信服务。他在播客里直接讲：

"我们一开始是出于兴趣试试 Rust，结果越用越香，最后干脆整个模块都换成 Rust 了。"

总结一下，他们选 Rust 的真实理由，其实就是 6 个字：

快、稳、不出错。

具体来说是：

Rust 特性	实际价值
没有 GC，延迟低	发数据必须准时，不能卡一下就掉链子
编译器非常"严格"	上线前能帮你发现逻辑错误，防呆能力一流
所有权系统	保证数据不会乱窜、不会出现悬空指针
零成本抽象	可以放心写泛型、写 trait，不用担心性能损耗
async/await + tokio	多个任务一起跑，CPU 不用闲着
和 C/C++/Python 都能集成	不必重写老系统，Rust 可以慢慢"渗透"进去

KSAT 用 Rust 干了什么活？

以下是他们系统里已经跑 Rust 的部分内容：

一、卫星协议解析器

从卫星收到的不是"正常数据"，而是一堆非常底层的比特流，还会用各种协议格式，比如：

CCSDS（国际卫星通用格式）
自定义打包格式
压缩过的图像 / 遥感 / 科学实验数据

这些数据要：

按位解析
检验帧头帧尾
错误纠错
丢弃冗余
解包成结构化数据

Rust 的 nom、bitvec、serde 等库，在这方面表现非常棒。而且一出 bug，编译器基本就会告诉你："嘿，你这个 slice 越界了！"

二、地面站任务调度器

他们会预先安排"哪颗卫星几点几分从哪座地面站通信"。

这套调度系统跑在异步架构上，用了：

tokio 做 async
tower 管理请求流程
tracing 记录任务状态

举个例子：

系统发现卫星将在 15:03:22 飞过挪威站点
提前 30 秒准备设备（天线对准、信号预热）
接收窗口是 3 分 11 秒
每个异步任务是一个 tokio task
数据流入后立即解析、写入数据库

三、遥测数据转发服务

卫星遥测数据（比如电池电压、姿态状态）需要快速转发给客户。

他们用 Rust 写了 HTTP/gRPC 服务，负责：

认证用户
校验数据完整性
以 JSON 或 protobuf 返回实时数据

这样客户就可以通过浏览器、仪表盘、API 实时接入。

遇到的问题和坑有哪些？

Rust 虽然很棒，但也不是"没有学习成本"的。Vegard 分享了他们踩过的一些坑：

1. 调试异步任务非常痛苦

异步系统最难的不是"写"，而是"查问题"。

有时候系统跑慢了，他们不知道是哪一步卡了。后来他们引入 tracing 和 tokio-console，每个任务加 #[instrument]，再通过 trace_id 追踪完整链路。

后来他们还用 Prometheus + Grafana 做了一个"任务热力图"，一目了然看哪里拥堵。

2. 编译时间有点夸张

每次改点泛型、宏或者引入新的库，可能等 30 秒以上才编完。

"但我们已经习惯了，大家会在编译时起来倒杯水。"

他们优化的方法是：

用 cargo check 快速预检
用 sccache 做构建缓存
模块化代码，减少全量重编

3. 某些库生态没那么成熟

比如早期他们用 tonic 做 gRPC 服务时，遇到了一些互操作性问题，需要手动 patch 或提交 PR 修复。

这不只是代码，而是跟宇宙通信

Rust 在 KSAT 不是做一个"工具链的小轮子"，它是真正在：

接收来自 500km 以上的卫星数据
保障几千万美元项目的通信安全
支撑全球关键任务的实时链路

Vegard 的一句话特别打动人：

"我们不是在写代码，而是在帮人类跟宇宙对话。"

想象一下，一行 Rust 代码，可能正在控制天上的一颗卫星。是不是有点浪漫？

想开始用 Rust 干这些酷事？给你几点建议：

入门路线：

学好 Rust 的基本语法，特别是 ownership、lifetimes
学 async 编程：tokio + async/await
学 tracing、metrics、监控工具
学怎么和 C 接口打交道：FFI、bindgen
看实际项目案例（比如 KSAT、Redox OS、Embassy 等）

结语：Rust，不只是写游戏，它能上天

我们常听说 Rust 拿下了 Web 开发、安全工具、嵌入式领域，但现在，它也站在了离地几百公里的地方。

它不是万能，但它在：

不允许出错的系统中
性能和安全都要的场景下
和 legacy 系统要协同的复杂环境里

真的越来越吃香。

如果你也在做关键系统、异步服务、多线程任务，或老旧系统重构，那 KSAT 的故事可以带给你很多启发。