其他部署方式

启动与验证 描述的是 Docker Compose 单机部署，也是推荐方式。本组文档覆盖其他场景。

方式对比

方式	适用场景	复杂度	参考
单机 Compose（推荐）	试用、中小规模生产	低	启动与验证
二进制部署	不能装 Docker，或需纳入 systemd 体系	中	二进制部署
自建镜像	需改代码、加依赖、适配私有基础镜像	中	自建镜像
分离部署	数据库走云托管，或中间件已有独立集群	中	分离部署
离线部署	服务器无法访问镜像仓库	中	离线部署

服务依赖关系

选择部署方式前需了解各服务依赖哪些组件：

服务	依赖
admin-svr	MySQL、Redis、RabbitMQ
openapi	MySQL、Redis、RabbitMQ
worker-svr	MySQL、Redis、RabbitMQ
app-server	MySQL、Redis
upstream-chan	MySQL、Redis、Consul
upstream-proxy	MySQL、Redis、Consul
admin-ui	admin-svr（反向代理）
nginx	admin-ui、openapi、app-web、docs
sms	无
docs	无
onelink-mock	无

通用前提

无论哪种方式，这三项不变：

1. 配置文件必须能被服务读到——容器部署时挂载到 /app/config，二进制部署时放在工作目录的 config/
2. JWT_SIGNING_KEY 在 admin-svr、openapi、app-server 三处必须一致
3. 数据库需先完成初始化——schema/ 脚本按顺序执行一次

服务间通信方式

配置文件里通过服务名互访，例如：

database:
  default:
    link: "mysql:u_iotlcm:...@tcp(mysql:3306)/db_iotlcm"
upstream:
  proxy:
    address: "upstream-proxy:8510"

这些名称在单机 Compose 中由 Docker 网络解析。切换到二进制部署或分离部署时必须改为实际地址（127.0.0.1 或内网 IP），这是最容易遗漏的一步。

最常见的部署失败原因

只改了数据库地址，忘了改 upstream-proxy:8510、upstream-chan:8110 这类服务名。症状是服务能启动、数据库也通，但批次执行、智能诊断全部超时。