同城系统统一后台：容器与云主机怎么选型

地级市客户部署同城统一后台时，常见分歧是：一套 ECS 跑全部模块，还是上 Kubernetes 拆服务？选错形态，要么首期运维门槛过高，要么后期扩模块只能整机升配，权限与发布窗口都失控。

本文从部署选型视角对比容器与云主机方案：统一后台场景下哪些组件适合容器化、哪些适合托管 RDS/Redis、何种团队规模选何种路径。面向技术负责人与运维，不涉及具体厂商促销配置，交付以当期方案为准。

一、业务背景：统一后台的部署特征

同城统一后台通常包含：

• 管理端 API 与静态前端
• 多模块业务 API（外卖、跑腿等）
• 统一身份与权限服务
• 订单、结算、导出等后台任务
• MySQL、Redis、对象存储、消息队列

负载特征：日常中等 QPS + 晚高峰写入 + 定时导出。不是纯静态站，也未必需要超大集群。选型目标是可独立扩模块、可回滚、权限与网络可隔离。

二、三种典型路径

路径 A：单机 / 少量 ECS（docker-compose）

适合： 首期单城、团队无 K8s 经验、预算敏感。

ECS-1: nginx + admin-ui + api-gateway + 核心模块
ECS-2（可选）: worker + 导出
RDS: MySQL 主从
Redis: 托管版
OSS: 附件与导出

优点：上手快、故障域清晰。缺点：模块增多后 ECS-1 容易变成「巨石」；滚动发布需自建脚本。

路径 B：K8s（ACK 或自建）

适合： 已规划多模块并行迭代、需 HPA、有多套环境（测试/预发/生产）。

Namespace: unified-admin
  Deployments: gateway, auth, takeout-api, errand-api, settle-worker
  HPA: takeout-api, settle-worker
  Ingress + cert-manager
  RDS / Redis 托管

优点：按模块扩缩、发布与回滚标准化。缺点：运维学习成本、集群基线组件要维护。

路径 C：混合（核心 API 容器 + 重任务 VM worker）

适合： 容器化已部分落地，但导出/批处理希望与在线 API 物理隔离。

在线 API 在 K8s；settle-export 跑在独立 ECS，通过 MQ 消费，避免导出 CPU 抢占。

三、选型对照表

同城统一后台若已明确半年内叠加跑腿、团购等模块，建议至少从路径 A 规划迁移到 B 的接口边界，避免权限与订单服务焊死在同一进程。

四、组件放置建议

无论 A/B/C，下列组件强烈建议托管：

1. MySQL（RDS）：主从、备份、监控；不要生产 MySQL 跑在应用 ECS 上。
2. Redis：会话、限流、分布式锁。
3. OSS：导出 CSV、商户图片、备份归档。
4. MQ（可选但推荐）：结算投影、异步通知。

应用层容器化收益最大；有状态组件用云托管，减少自建运维风险。

五、统一后台特有的拆分点

auth-service      身份、角色、审计（变更频率低，资源小）
admin-gateway     统一入口、路由、鉴权
module-apis       各业务模块（可按模块 Deployment）
settle-worker     导出与投影（与在线 API 分离）

权限变更不应与外卖促销发布绑在同一镜像里。容器化时auth 与 module-apis 分镜像，回滚半径更小。

六、安全与合规基线

• 生产 VPC 与测试 VPC 隔离；RDS 无公网。
• 镜像扫描 + 私有仓库；禁止 latest 漂移上线。
• 密钥走 KMS；CI/CD 用短期凭证。
• 管理后台强制 MFA 或 VPN；审计日志独立存储。

七、成本与容量粗算思路

1. 先压测单城晚高峰订单写入 + 一次全量导出叠加场景。
2. order-api 按 QPS 选最小副本；RDS 按 IOPS 而非仅 CPU 选规格。
3. worker 按 MQ 峰值深度选副本，平时可缩到 1。
4. 预留 30% 连接与 IOPS 余量，避免促销临时升配来不及。

八、验收清单

1. 模块 API 可独立发布，其他模块无感知重启。
2. 非超管账号权限与入口符合预期（403 越权测试通过）。
3. RDS 备份恢复演练成功。
4. 导出任务高峰不导致下单 P95 劣化（混合或 worker 分离时重点验）。
5. 回滚一次发布在约定时间内完成。
6. compose 路径下 ECS-2 worker 停掉后，在线下单仍成功，仅导出延迟。
7. K8s 路径下 auth 镜像回滚不影响 takeout-api 当前版本。
8. 混合路径下 export ECS CPU 打满时，Ingress 健康检查仍绿。
9. 三套环境配置 diff 无生产密钥泄露到 dev。
10. 模块开关关闭跑腿 Tab 后，API 返回 404 而非 500，且无残留菜单缓存。

九、常见坑

1. 把所有模块打成一个 jar 包部署 —— 扩外卖连带重启团购。
2. K8s 集群过小的同时跑太多 DaemonSet —— 业务 Pod 被挤。
3. 容器化但未托管数据库 —— 容器化了应用，数据仍单点。
4. 测试与生产共 RDS —— 压测拖垮生产。

十一、发布流水线：GitOps 与镜像策略

建议 trunk-based 或 release 分支 + 自动构建镜像，tag 用 git sha 而非 latest。K8s 滚动更新 maxUnavailable: 0，保证发布期间下单不中断。数据库 migration 与代码发布分离：先跑兼容 migration，再发代码，最后清理旧字段。

十二、多环境配置管理

统一后台模块多，配置项易漂移。使用分环境 values 文件（dev/staging/prod），敏感项进密钥服务。模块开关（如是否启用跑腿 Tab）用配置中心或 ConfigMap，避免为关 Tab 而改代码发版。

【1】三条路径的部署实操对照

路径 A（compose）落地顺序： 先起 RDS + Redis + OSS；ECS-1 用 compose 拉 gateway、auth、takeout-api；ECS-2 只跑 settle-worker 与定时导出。nginx 反代统一 HTTPS，证书自动续期。发布时先更 worker 镜像再更 API，避免新 API 调旧 worker 字段不一致。

路径 B（K8s）落地顺序： 集群基线（Ingress、cert-manager、监控 agent）→ Namespace unified-admin → 先 auth 与 gateway → 各 module-api Deployment → settle-worker HPA 绑 MQ 深度。数据库 migration Job 独立执行，失败则阻断后续 Helm upgrade。

路径 C（混合）落地顺序： K8s 内跑在线 API；单独 ECS 装 worker，通过内网 MQ 地址消费；安全组只允许 ECS worker 访问 MQ 与 settle 库，缩小 blast radius。

无论哪条路径，有状态组件不上容器裸跑：MySQL、Redis、OSS 一律托管，避免「容器化了应用，数据还在单盘 ECS」。

【2】数据层边界（统一后台多模块）

统一后台的价值是「一个入口管多模块」，不是「所有表塞进一个库」。模块增多时，按上表扩库或扩 schema，导出与报表仍走 worker + replica，避免晚高峰互相拖死。

【3】故障排查（人话版）

现象：发版外卖后跑腿也挂了。 多半共用一个 jar 或同一 Deployment；应拆镜像与 Deployment，回滚只影响变更模块。

现象：K8s 节点 NotReady，业务间歇 502。 查是否 DaemonSet 过多挤占业务 Pod；或镜像拉取失败；先 cordon 节点再迁移 Pod。

现象：导出卡死，下单正常。 混合路径下看 ECS worker 磁盘与 CPU；compose 路径看 ECS-2 是否被 OOM；确认导出 SQL 走 replica。

现象：权限改了不生效。 查 auth 缓存 TTL 与各 API 本地权限缓存；统一后台应支持短 TTL 或主动失效，而不是让用户重新登录才生效。

现象：测试压测拖慢生产。 VPC 或 RDS 未隔离；立即拆测试实例，禁止共用 max_connections。

【4】上线前一周运维日程（统一后台）

周一： 核对 compose / K8s 清单与镜像 tag，禁止 latest 上生产。周二： 跑权限越权用例与非超管菜单可见性。周三： RDS 备份恢复演练，含 OSS 附件抽测。周四： 晚高峰模拟：下单 + 全量导出叠加，记录 P95。周五： 回滚演练：只回滚 takeout-api，auth 与 gateway 保持不动，验证其他模块无感知。日程结束输出一页「选型路径 + 规格余量 + 值班联系人」，交给客户运维签字存档，作为后续扩模块的基线文档。

总结

同城统一后台容器与云主机怎么选，取决于团队运维能力、模块路线图与高峰特征：首期可 compose，多模块并行建议 K8s；重导出建议 worker 分离。托管 RDS/Redis/OSS 比「全放 ECS」更稳；发布与 migration 分离、镜像可回溯，是多模块长期迭代的底座。光合同城支持私有化源码交付与统一后台多模块部署，具体选型与规格以项目当期方案为准。