# Standalone CVM Deployment Templates

本目录提供不依赖 Kubernetes 的生产部署模板。目标形态是 systemd 托管 Docker 容器，公网 CLB 只接 gateway，内部服务通过内网 CLB/DNS 或固定私网地址访问。

## Layout

- `systemd/*.service`: 每个后端服务一份 systemd unit，负责启动、停止和故障重启 Docker 容器。
- `docker/*.env.example`: 每个服务一份 Docker 运行参数示例，只保存镜像名、容器名、配置路径和停止等待时间。
- 服务业务配置仍使用 `services/<service>/configs/config.tencent.example.yaml` 作为线上模板，渲染后放到 `/etc/hyapp/<service>/config.yaml`。

## Install One Service

以 `gateway-service` 为例：

```bash
sudo mkdir -p /etc/hyapp/gateway-service
sudo cp deploy/standalone/docker/gateway-service.env.example /etc/hyapp/gateway-service/docker.env
sudo cp services/gateway-service/configs/config.tencent.example.yaml /etc/hyapp/gateway-service/config.yaml
sudo vi /etc/hyapp/gateway-service/docker.env
sudo vi /etc/hyapp/gateway-service/config.yaml

sudo cp deploy/standalone/systemd/hyapp-gateway-service.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable --now hyapp-gateway-service
sudo systemctl status hyapp-gateway-service
sudo docker inspect --format '{{json .State.Health}}' hyapp-gateway-service
```

`docker.env` 不承载业务密钥；密钥仍在最终 `config.yaml` 中，或者由发布系统先从密钥系统渲染到 `config.yaml`。当前代码只读取单个 YAML，不会自动展开 `${VAR}`。

## Network

模板默认使用 `--network=host`，让容器直接监听项目约定的 `13xxx` 端口。这样 CLB、安全组和本机排障都以同一个端口工作：

- `13000`: gateway HTTP
- `13001`: room gRPC
- `13004`: wallet gRPC
- `13005`: user gRPC
- `13006`: activity gRPC
- `13007`: cron gRPC
- `13008`: game gRPC

同一台 CVM 上不要启动两个相同端口的同服务实例。做蓝绿发布时优先使用新 CVM 或新容器节点，健康通过后再挂载到 CLB。

## Rolling Update

普通服务的无感更新流程：

1. 在新 CVM 上准备 `/etc/hyapp/<service>/docker.env` 和 `/etc/hyapp/<service>/config.yaml`。
2. `systemctl start hyapp-<service>`，等待 Docker health 进入 `healthy`。
3. 将新实例加入对应 CLB 或内部服务入口。
4. 观察错误率、延迟和服务日志。
5. 从 CLB 摘除旧实例，等待连接保护或业务 drain 窗口结束。
6. `systemctl stop hyapp-<service>`，Docker 会先发送 SIGTERM，服务内的 graceful shutdown 会进入 draining 并等待已进入请求结束。

`room-service` 当前还没有 gateway owner-routing 或非 owner 自动转发能力。没有补完该能力前，不要把多个 `room-service` active 实例直接放到普通负载均衡后面承接同一批房间命令；生产先保持单 active，或者只把备用实例作为故障接管目标。

## Service Discovery

不使用 Kubernetes 时，第一阶段推荐用内网 CLB/DNS 提供稳定入口，例如：

```yaml
user_service_addr: "user.service.internal:13005"
wallet_service_addr: "wallet.service.internal:13004"
activity_service_addr: "activity.service.internal:13006"
room_service_addr: "room.service.internal:13001"
game_service_addr: "game.service.internal:13008"
```

如果后续引入 Consul/Nacos，仍建议让业务配置只保存稳定服务名，不把实例 IP 写进每个服务配置。