09 Linux 现状与运维

先说结论

截至 2026-06-05，官方 Compute 指南已经包含 Linux Server 入门文档，但该页面明确标注 RhinoCompute on Linux 属于 Rhino WIP，不建议用于生产工作。

因此教学中建议这样定位：

Windows/IIS：生产主线。
Linux：实验、评估、未来兼容性验证。
Docker/容器：适合快速体验，不建议作为生产运行方式。

Linux 支持范围

官方 Linux 入门文档提到的系统包括：

Ubuntu Server 24.04。
AmazonLinux 2023。
Debian 13 的步骤可能适用，但不应默认视为完整支持。

官方也说明仍在处理的事项包括：

Grasshopper 中 RhinoCode 相关脚本组件。
3dm 以外文件导入导出。
第三方插件管理。
其他 WIP 问题。

Linux 安装概念流程

概念上分为：

安装 .NET 依赖。
添加 McNeel 软件源。
安装 rhino-compute 包。
配置 RHINO_TOKEN 和 RHINO_COMPUTE_KEY。
使用 systemd 启动服务。
用 Hops 或客户端调用 Linux Compute。

服务命令示例：

sudo systemctl start rhino-compute
sudo systemctl stop rhino-compute
sudo systemctl enable rhino-compute
sudo systemctl status rhino-compute
sudo journalctl -u rhino-compute -f

Linux 日志目录：

/var/log/rhino-compute

容器方式的限制

官方文档说明容器适合入门，但不建议生产使用。核心原因是容器通常缺少标准 systemd 服务管理，不适合作为需要随系统重启、受服务管理器托管的长期 Compute 服务。

容器适合：

快速验证 Linux 包安装流程。
测试 API Key、Hops 连接、基础 GH 定义。
CI 中做有限的 smoke test。

容器不适合：

直接承载生产用户请求。
运行复杂第三方插件。
依赖长期稳定授权、日志、重启恢复的场景。

运维指标

无论 Windows 还是 Linux，运维上都应关注：

指标	说明
请求量	每分钟请求数、峰值请求数。
成功率	2xx/4xx/5xx 比例。
延迟	平均、P95、P99，区分冷启动和热启动。
子进程数量	当前 active children、启动失败次数、异常退出次数。
内存	Rhino/Grasshopper/插件很容易成为内存瓶颈。
请求体大小	大 DataTree 或大几何会增加序列化和内存压力。
超时次数	区分客户端超时和服务端超时。
授权状态	RHINO_TOKEN 有效性、核心小时用量。

日志策略

建议为每个业务请求生成 request id，并在外层服务日志中记录：

用户或租户。
业务任务类型。
Compute URL。
请求体大小。
超时时间。
HTTP 状态码。
Compute 响应耗时。

Compute 自身日志通常记录进程、加载、异常和请求状态。外层业务日志和 Compute 日志结合，才能定位“是业务输入错了、网络错了、Compute 子进程错了、还是 Grasshopper 定义错了”。

容量规划

容量规划不要只看 CPU 核心数。还要测：

单个 compute.geometry 子进程启动后占用多少内存。
加载 Grasshopper 后增加多少内存。
加载第三方插件后增加多少内存。
单次典型请求峰值内存。
并发请求下 GC、序列化、网关超时表现。

经验做法：

从小 childcount 开始压测。
逐步增加并发，观察内存和 P95 延迟。
找到“再增加子进程反而变慢”的点。
以测试结果决定 VM 规格和 idlespan。

发布流程建议

在测试机安装同版本 Rhino、Compute、插件。
用代表性 GH 定义和自定义端点跑回归。
检查授权、日志、API Key、请求体限制、超时。
在维护窗口更新生产。
更新后先跑 smoke test。
观察日志和核心小时用量。

本章检查点

是否明确 Linux 当前是 WIP，不作为默认生产主线？
是否知道 Linux 日志在 /var/log/rhino-compute？
是否为请求链路设计了 request id？
是否通过压测确定 childcount，而不是凭 CPU 核心数猜？

目录