====== 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。

服务命令示例：

<code bash>
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
</code>

Linux 日志目录：

<code>
/var/log/rhino-compute
</code>

===== 容器方式的限制 =====

官方文档说明容器适合入门，但不建议生产使用。核心原因是容器通常缺少标准 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 核心数猜？

===== 参考资料 =====

  * [[https://developer.rhino3d.com/guides/compute/compute-linux-getting-started/|Getting Started with Rhino.Compute on Linux]]
  * [[https://developer.rhino3d.com/guides/compute/deploy-to-iis/|Deployment to Production Servers]]
  * [[https://developer.rhino3d.com/guides/compute/compute-faq/|Compute FAQ]]