为什么不能所有事都塞在一个服务里

业务接口要处理用户、套餐、订单、配置、后台管理，这些请求节奏和调用模型接口的实时流量完全不是一个量级。

如果把模型转发、并发控制、流式返回也一起塞进主业务服务，排查问题会越来越痛苦，扩容策略也会被绑死。

  • 业务服务更适合承载规则、管理和配置。
  • 网关层更适合专注并发、超时、流式响应和协议兼容。

Go 和 Rust 在这里分别扮演什么角色

Go API 层更像大脑，负责让后台配置、站点页面和控制台功能都围绕统一的数据模型运转。

Rust Gateway 更像高压水管，重点是稳定、快、可控，尤其适合顶住模型调用这类长连接和高并发场景。

  • Go 负责业务速度和维护效率。
  • Rust 负责性能边界和协议处理稳定性。

对前台页面有什么帮助

当前台要展示模型列表、价格版本、能力标签时，最怕的是后端接口含糊不清。分层后，页面能更稳定地拿到结构化数据。

这也是为什么文档和博客页现在值得做得更像正式产品资料，因为它们背后终于有更稳定的系统边界在支撑。