部署与运维架构
标准安装形态
标准部署包使用 Docker Compose 管理以下服务：
- Cloud Blox 应用；
- MySQL 8；
- Redis 7；
- ClickHouse 24.1。
应用镜像包含管理控制台和服务端程序。安装人员不需要从源码编译，推荐解压发布包后运行交互式安装脚本：
bash install.sh安装脚本负责环境检查、端口检查、秘密生成、配置生成、镜像拉取、服务启动和就绪探测。
默认网络拓扑
flowchart TB
Internet[公网或企业网络] --> Proxy[HTTPS 反向代理 / 负载均衡]
Proxy --> Admin[管理入口 38002]
Proxy --> S3[S3 入口 38003]
Proxy --> Access[资源入口 38004]
Proxy --> DAV[WebDAV 入口 38005]
Admin --> App[Cloud Blox 应用]
S3 --> App
Access --> App
DAV --> App
App --> MySQL[(MySQL)]
App --> Redis[(Redis)]
App --> ClickHouse[(ClickHouse)]
App --> Data[storage / storage_temp / cache / logs]
MySQL、Redis 和 ClickHouse 默认应只绑定本机或私有网络。应用只提供 HTTP，生产环境必须由 Nginx、Caddy、云负载均衡等组件统一终止 TLS。
端口与域名规划
默认应用端口为：
- 管理控制台与管理 API：
38002； - S3：
38003； - 资源访问：
38004； - WebDAV：
38005。
基础设施常用宿主机端口为：
- Redis：
38006； - MySQL：
38007； - ClickHouse HTTP：
38008； - ClickHouse Native：
38009。
基础设施端口默认不映射到宿主机；仅在区域节点需要跨机访问主节点数据库时按需映射，并限制来源地址。
生产环境建议：
- 为 Admin、S3、Access 和 WebDAV 使用不同域名；
- 由统一反向代理提供 HTTPS；
- 只向公网开放必要域名和端口；
- 管理入口优先限制到企业网络、VPN 或访问白名单；
- 基础设施端口不直接开放公网；
- 逐一验证共享端口下的域名分发。
按 Host 分发到四类入口的 Nginx map 完整示例见 Nginx 反向代理（默认端口 38002–38005）。
持久化目录
标准部署需要持久化：
- MySQL 数据；
- Redis 数据；
- ClickHouse 数据；
- 本地存储通道；
- 异步上传临时文件；
- 访问与媒体缓存；
- 应用日志；
- 配置和环境变量。
缓存通常可以重建，但临时上传目录、数据库和本地存储不能按缓存对待。备份策略应明确每个目录的业务含义。
容量规划
应用节点
应用节点主要消耗：
- 大文件上传和下载的网络带宽；
- 媒体处理的 CPU 和内存；
- 异步任务并发；
- 临时文件与缓存磁盘；
- 与外部存储通道的连接数。
不要只按数据库体量估算应用节点。媒体处理和并行传输通常是 CPU、内存和带宽峰值来源。
临时上传空间
临时目录容量至少需要覆盖：
- 同时上传文件的总大小；
- 分片合并过程的额外空间；
- 队列积压期间尚未同步到通道的文件；
- 上传失败后的保留和重试窗口。
建议为临时目录设置独立磁盘告警，并预留突发空间。磁盘达到警戒线后应停止接收新上传，而不是等待写满后被动失败。
缓存空间
通道缓存、回源缓存和媒体缓存应分别制定：
- 最大容量；
- 过期时间；
- 淘汰策略；
- 高低水位；
- 缓存命中率目标；
- 清理失败告警。
ClickHouse
ClickHouse 容量取决于访问量、日志保留期、计费事件和节点指标。调整日志保留天数前，应评估磁盘增长速度和查询窗口。
启动与健康
标准编排会等待 MySQL、Redis 和 ClickHouse 通过容器健康检查后再启动应用。应用提供：
/livez：只判断进程存活；/readyz：判断核心依赖是否可以接收流量；/health：返回更完整的依赖、队列、计划任务、媒体工具、节点和磁盘状态。
负载均衡应使用 /readyz 决定是否转发流量，进程管理器可使用 /livez 判断是否需要重启。完整健康信息可能需要内部认证，不应直接暴露到公网。
日常运维
发布包提供统一管理脚本，常用操作包括：
./manage.sh start./manage.sh stop./manage.sh restart./manage.sh logs./manage.sh status./manage.sh update./manage.sh backup每日应至少检查：
- 应用和基础设施健康；
- 各数据盘使用率；
- 队列积压和失败任务；
- 计划任务最近执行结果；
- 数据库备份结果；
- 计费事件与快照完整率；
- 存储通道和区域健康；
- 证书有效期和域名解析；
- 日志丢弃、缓存错误和外部服务失败。
备份与恢复
必须保护的数据
- MySQL：业务元数据、任务、用户、账单和配置；
- ClickHouse：日志、计费事件和历史指标；
- 本地存储：使用本地通道时的实际文件；
- 配置与秘密：环境变量、域名、端口和密钥；
- Redis：根据任务恢复设计决定持久化和恢复要求。
备份原则
- 数据库使用应用一致的备份方式，不把运行中的数据目录直接打包当作唯一方案；
- 备份文件应复制到独立故障域；
- 备份应加密并限制访问；
- 记录备份时间、大小、校验值和保留状态；
- 定期执行恢复演练；
- 多区域环境分别验证主节点、区域节点和外部存储恢复。
RPO 与 RTO
生产环境必须明确：
- RPO：最多允许丢失多长时间的数据；
- RTO：故障后多久恢复服务；
- 哪些功能可以降级；
- 哪些数据必须强一致恢复；
- 恢复后如何核对对象、物理引用、任务和账单。
升级策略
升级前：
- 查看当前版本和发行版；
- 阅读更新说明；
- 完成数据库和配置备份；
- 检查临时上传和运行中任务；
- 确认磁盘余量；
- 在预发布环境验证安装包。
升级时：
- 使用发布包提供的升级入口；
- 保留配置和持久数据目录；
- 避免在大量浏览器上传过程中重启；
- 多节点逐个退出流量、升级和重新加入；
- 通过
/readyz后再恢复流量。
升级后：
- 验证四类入口；
- 验证上传、下载、删除和回收站；
- 验证队列消费者和计划任务；
- 检查数据库版本、日志和告警；
- 验证桌面客户端兼容性。
高可用演进
默认 Compose 是单主机拓扑，不等同于高可用。关键生产环境的演进顺序建议为：
- HTTPS、备份和监控；
- MySQL 高可用；
- Redis 高可用和持久化；
- 应用多实例与滚动升级；
- 上传会话持久化和临时存储共享策略；
- ClickHouse 高可用；
- 主节点故障切换；
- 多区域容灾演练。