06

部署链路、运行形态与行业取舍

到最后一章，臣不想只告诉陛下“它现在怎么跑”，还要告诉陛下“为什么这么跑、何时该换、业界通常怎么选”。这才是架构视角真正有用的地方。

从脚本看，这套平台上线不是一键黑箱

`spug/aws` 目录把发布拆成了构建、升级、迁移、环境变量同步与版本校验几个环节。拆得越清楚，越容易审计，也越容易在某一步失败时止损。

1
构建镜像

Git tag 触发构建，把 `im-app-server` 与 `im-admin-server` 分别打成 `.server` / `.admin` 两个镜像标签。

2
推送 ECR 与更新 ECS

镜像先入 ECR，再由升级脚本注册新任务定义并更新服务。

3
跑迁移

PostgreSQL 与 DynamoDB 迁移被单独包装成 ECS 一次性任务，而不是混进应用启动里赌运气。

4
同步环境与 Secret

脚本会把配置中心数据同步进 ECS 与 Secrets Manager，并区分敏感项。

5
验证版本与通知

发布脚本还会检查版本接口、回报构建状态，并把关键信息发到飞书。

真实代码：一条 Git tag 会产出两张镜像

这段来自构建工作流。它清楚说明：虽然仓库是一个 monorepo，但运行产物是两套独立镜像。

代码 

      - name: Build and push im-app-server image
        uses: docker/build-push-action@v5
        with:
          context: ./im-app-server
          file: ./im-app-server/Dockerfile
          push: true
          tags: |
            ${{ steps.login-ecr.outputs.registry }}/${{ env.ECR_REPOSITORY }}:${{ steps.metadata.outputs.TAG }}.server
            ${{ steps.login-ecr.outputs.registry }}/${{ env.ECR_REPOSITORY }}:latest.server

      - name: Build and push im-admin-server image
        uses: docker/build-push-action@v5
        with:
          context: ./im-admin-server
          file: ./im-admin-server/Dockerfile
          push: true
          tags: |
            ${{ steps.login-ecr.outputs.registry }}/${{ env.ECR_REPOSITORY }}:${{ steps.metadata.outputs.TAG }}.admin
            ${{ steps.login-ecr.outputs.registry }}/${{ env.ECR_REPOSITORY }}:latest.admin
白话

同一个仓库里，`im-app-server` 和 `im-admin-server` 分别按自己的 Dockerfile 构建。

镜像标签也故意拆成 `.server` 和 `.admin`，避免发布时把两者混淆。

这意味着它们可以一起发版，也可以在部署脚本里选择只升级其中一个组件。

那么，更好的选择有吗

更好的意思，永远要补一句“对谁、更在哪”。下面这些是业界常见替代路径。没有一条是普世答案，但你至少该知道什么时候值得认真评估。

🚢

ECS Fargate vs Kubernetes

若团队更重交付速度与较低运维，Fargate 很合适；若你要跨云、复杂调度、统一平台团队，业界常转 EKS/Kubernetes。

📡

Ably vs Pusher vs AppSync

Ably 偏全能托管实时总线；Pusher 更轻；AppSync 更适合 GraphQL 订阅一体化。团队已有技术重心，常决定答案。

🧵

SQS vs Kafka / RabbitMQ

SQS 简洁、云原生、够稳；若你要强回放、复杂流处理、长保留与多消费者分析，业界会考虑 Kafka。若你更重复杂路由，可看 RabbitMQ。

🗄️

Aurora + DynamoDB + Redis 是否过重

对小团队或早期产品，也许偏重；但对多租户 IM 来说，这是一条很典型的“按数据性格拆层”的行业路线。

⚠️
别把“能换”误听成“该换”

大多数架构事故，不是因为没选最潮的技术，而是因为在没有足够收益前提下，过早改底座。

小测：何时该守、何时该换

团队只有少数后端，当前最痛的是发版稳不稳，不是跨云调度。此时对运行平台更务实的态度是什么？

什么时候你更可能认真评估 Kafka，而不是继续沿 SQS 路线加码？

若有人问“Ably、SQS、DynamoDB 会不会太多了”，最成熟的回答起点是什么？