AI Agent 辅助企业上云：CRM 三层架构迁移全流程解析
## 引子
最近接了个活：把 IDC 机房里一套 CRM 系统迁到亚马逊云科技。
这套系统很典型——Nginx 反向代理、Spring Boot 后端、MySQL 8.0 数据库，容器化跑在虚拟机上，文件存 NFS。不复杂，但迁移步骤多、配置细节杂。
先试了手工迁移，在控制台点了 218 分钟。然后换 Kiro（亚马逊云科技的 AI 命令行助手）辅助，55 分钟完事。这篇文章把全过程拆开讲。
## 一、IDC 侧架构
```
客户端
↓
Nginx（反向代理 + 负载均衡）
↓
┌──────────────┬──────────────┐
│ 前端容器 │ 后端容器 │
│ (静态资源) │ (Spring Boot) │
└──────────────┴──────┬───────┘
↓
MySQL 8.0（独立 VM）
NFS/SAN（共享存储）
```
数据规模：约 10000 客户记录、12000 订单。Spring Boot 提供 REST API，Nginx 做前端静态资源托管和 API 请求转发。
容器镜像统一从内部 Docker Hub 拉取。服务发现靠 Docker Compose 内部 DNS。
## 二、目标架构设计
迁移不是简单搬家。每一层都有对应的云原生替代方案：
| 层级 | IDC 方案 | 亚马逊云科技方案 | 核心变化 |
|------|---------|----------------|---------|
| 流量入口 | Nginx 单点 | ALB 跨可用区 | 高可用 + 自动扩缩 |
| 应用服务 | Docker Compose | ECS Fargate | 全托管，无需管节点 |
| 镜像仓库 | 内部 Docker Hub | Amazon ECR | 私有仓库 + 漏洞扫描 |
| 服务发现 | Docker 内部 DNS | AWS Cloud Map | 跨 AZ 服务注册 |
| 数据库 | 裸 MySQL VM | Amazon RDS | 自动备份 + 故障切换 |
| 文件存储 | NFS/SAN | Amazon S3 | 无限容量 + 11 个 9 持久性 |
| 日志 | 手动搭建 | CloudWatch Logs | 集中化 + 告警 |
## 三、手工迁移全流程（218 分钟）
### 步骤 1：网络与安全组（45 min）
4 个安全组：ALB、ECS 前端、ECS 后端、RDS。彼此有引用关系。
难点在于引用顺序。你不能在创建 ECS 安全组时引用一个还不存在的 ALB 安全组。正确做法：
```bash
# 1. 先全部创建（不加规则）
for name in sg-alb sg-ecs-frontend sg-ecs-backend sg-rds; do
aws ec2 create-security-group --group-name $name --description "$name" --vpc-id vpc-xxx
done
# 2. 再逐个添加互引规则
aws ec2 authorize-security-group-ingress \
--group-id sg-alb --protocol tcp --port 80 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress \
--group-id sg-ecs-backend --protocol tcp --port 8080 --source-group sg-alb
aws ec2 authorize-security-group-ingress \
--group-id sg-rds --protocol tcp --port 3306 --source-group sg-ecs-backend
```
### 步骤 2：镜像迁移（20 min）
从内部 Registry 拉镜像，重新打标签推到 ECR：
```bash
# 登录 ECR
aws ecr get-login-password --region us-east-1 | \
docker login --username AWS --password-stdin 123456789.dkr.ecr.us-east-1.amazonaws.com
# 拉取、标签、推送
docker pull internal-registry/crm-backend:v2.1
docker tag internal-registry/crm-backend:v2.1 \
123456789.dkr.ecr.us-east-1.amazonaws.com/crm-backend:v2.1
docker push 123456789.dkr.ecr.us-east-1.amazonaws.com/crm-backend:v2.1
```
### 步骤 3-4：存储与数据库（50 min）
```bash
# S3 文件同步
aws s3 sync /nfs/crm-files/ s3://crm-production-files/
# RDS 数据导入
mysqldump -h old-mysql -u root -p crm_production | \
mysql -h crm-db.cluster-xxx.us-east-1.rds.amazonaws.com -u admin -p crm_production
```
这里踩了一个坑：RDS 默认参数组的 `collation_server` 是 `utf8mb4_0900_ai_ci`，和 IDC 的 `utf8mb4_unicode_ci` 不同。中文排序结果会不一样。需要提前创建自定义参数组。
### 步骤 5-7：服务发现 + ECS + ALB（75 min）
这是耗时的大头。ECS Task Definition 的 JSON 很长：
```json
{
"family": "crm-backend",
"networkMode": "awsvpc",
"requiresCompatibilities": ["FARGATE"],
"cpu": "512",
"memory": "1024",
"containerDefinitions": [{
"name": "backend",
"image": "123456789.dkr.ecr.us-east-1.amazonaws.com/crm-backend:v2.1",
"portMappings": [{"containerPort": 8080, "protocol": "tcp"}],
"environment": [
{"name": "DB_HOST", "value": "crm-db.cluster-xxx.us-east-1.rds.amazonaws.com"},
{"name": "DB_PORT", "value": "3306"},
{"name": "DB_NAME", "value": "crm_production"},
{"name": "S3_BUCKET", "value": "crm-production-files"}
],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/crm-backend",
"awslogs-region": "us-east-1",
"awslogs-stream-prefix": "ecs"
}
}
}]
}
```
还要配 Cloud Map 命名空间、创建 ALB Target Group、Listener 规则。手工在控制台配这些，光是页面切换就够累的。
### 步骤 8-10：验证 + DNS + 清理（28 min）
逐项检查：ALB 健康状态、ECS 任务运行状态、数据库连通性、前端页面功能。确认没问题后切 DNS、关 IDC 服务。
## 四、Kiro 辅助迁移（55 分钟）
Kiro 的工作方式是**对话→规划→执行→验证**闭环。
```bash
kiro chat
> 把 IDC 的三层 CRM 迁到 AWS。
> 源：Nginx + Spring Boot + MySQL + NFS
> 目标：ALB + ECS Fargate + RDS + S3
> 帮我搞定全部步骤。
```
Kiro 做了什么：
- 自动分析架构差异（2 min）
- 按依赖顺序创建安全组（8 min）
- 构建推送镜像（5 min）
- 同步文件到 S3（4 min）
- 创建 RDS + 导入数据 + 自定义参数组（10 min）
- 配置 Cloud Map + ECS + ALB（21 min）
- 端到端验证（5 min）
中间遇到 ECS 任务启动失败，Kiro 自动查 CloudWatch 日志，发现环境变量还在用 IDC 的数据库地址。改成 RDS Endpoint 后重新部署，通过。
## 五、时间对比汇总
| 阶段 | 手工 | Kiro | 省时 |
|------|------|------|------|
| 网络安全组 | 45 min | 8 min | 82% |
| 镜像迁移 | 20 min | 5 min | 75% |
| 存储+数据库 | 50 min | 14 min | 72% |
| ECS+ALB | 75 min | 21 min | 72% |
| 验证+切换 | 28 min | 7 min | 75% |
| **合计** | **218 min** | **55 min** | **75%** |
## 六、技术决策：为什么选 Fargate
选 ECS Fargate 而不是 EKS，考虑了三点：
1. **容器少**——才 3-5 个容器，EKS 的集群管理太重
2. **全托管**——不用管底层 EC2 节点，按容器计费
3. **学习成本**——团队没 K8s 经验，ECS 概念简单很多
如果你的场景是几十上百个微服务、需要复杂调度，EKS 更合适。CRM 这种规模，Fargate 刚好。
## 七、适用范围
- ✅ 标准 Web/App/DB 三层架构
- ✅ 组件依赖关系清晰
- ✅ 数据量中等（GB 级）
- ❌ 有状态中间件集群（Redis Cluster、Kafka）
- ❌ 零停机要求的核心交易系统
- ❌ 商业软件许可证迁移
## 写在最后
AI Agent 辅助上云的本质是：**把 80% 的配置搬砖活自动化，让工程师做那 20% 的判断题**。
218 分钟里，真正需要人脑的决策可能就 15 分钟。剩下的全是在控制台填参数、查文档、回退重试。Kiro 恰好解决了这部分。
建议先拿测试环境跑一遍，摸清能力边界。
---
**参考：**
- [AI Agent CRM 迁移实战](https://aws.amazon.com/cn/blogs/china/ai-agent-how-to-enterprise-crm-system-migration/)
- [Amazon ECS 文档](https://docs.aws.amazon.com/ecs/)
- [Kiro 官网](https://kiro.dev/)
浙公网安备 33010602011771号