作者：一名阿里系 Java 开发工程师
背景：参与麦座国际（大麦海外业务）从大麦整体架构中独立拆分的技术迁移项目
关键词：业务拆分、应用迁移、资源隔离、Aone Copilot、AI 自动化重构、Java、阿里中间件

---

一、项目背景：为什么要做这次迁移？

阿里巴巴启动“1+6+N”组织变革战略，推动各业务单元独立运营。在此背景下，大麦娱乐旗下的海外业务——麦座国际（MAISEAT）正式独立，需从原有的大麦统一技术体系中完全剥离。

作为服务端开发工程师，我所在的团队承担了核心后端应用的代码与资源配置迁移任务。目标是：

• ✅ 代码隔离：将原共享代码库 Fork 出全新独立应用；
• ✅ 资源解耦：所有依赖的中间件、存储、配置中心等资源全部新建，杜绝与国内业务交叉；
• ✅ 架构优化：借机整合低流量/无流量应用，降低运维复杂度；
• ✅ 流程提效：通过 AI 工具实现标准化、可复用的迁移流程，为后续类似项目打样。

---

二、迁移范围：涉及哪些核心资源？

在阿里技术栈下，一个典型 Java 应用依赖的资源非常丰富。本次迁移需全面覆盖以下类别（并持续扩展）：

表格

资源类型	具体产品	迁移要点
对象存储	OSS	新建 Bucket，更新 endpoint、AK/SK
数据库	TDDL（DRDS）	申请新实例，重建分库分表或简化为单库
分析型数据库	ADS（AnalyticDB）	重新建模，数据同步策略调整
缓存	Redis / Tair	申请新集群，评估内存规格，部分低频缓存可合并
分布式 KV 存储	Tair（持久内存版）	用于高可靠配置/状态存储
搜索引擎	OpenSearch	重建索引模板，更新 client 配置
配置中心	Diamond / Switch	申请新命名空间，复制并重命名开关
消息队列	MetaQ / RocketMQ	新建 Topic 和 Group
服务注册发现	ConfigServer / Nacos	新建服务分组
日志监控	SLS / ARMS	重新接入日志采集与 APM

💡 关键策略：对每个应用进行流量画像分析，将无流量或极低流量的应用所用资源合并到共享资源池，大幅降低资源成本和管理开销。

---

三、核心挑战：传统迁移 vs AI 辅助迁移

传统方式痛点：

• 人工易错：配置项成百上千，漏改一处即导致启动失败；
• 重复劳动：几十个应用，每个都要手动改代码、配资源；
• 知识断层：老系统文档缺失，新人上手难；
• 验证成本高：部署后才发现问题，回滚耗时。

我们的破局点：Aone Copilot + Skills 模型

我们没有选择 GitHub Copilot，而是基于阿里内部 Aone Copilot 平台，构建了一套领域专用的 AI 迁移技能（Skills）。

---

四、解决方案：基于 “文档驱动 + AI 执行” 的迁移框架

4.1 整体架构设计

4.2 核心组件说明

（1）资源清单文档（Document-Driven）

• 按应用维度建立 Markdown/JSON 文档；
• 记录：旧资源 → 新资源 映射关系（如 oss-old-bucket → maiseat-prod-user-avatar）；
• 包含：OSS、TDDL、Redis、Switch 开关等所有需变更项；
• 优势：内容与执行逻辑解耦，AI 通过 Skills 读取文档即可操作，无需硬编码。

（2）Aone Copilot Skills 定义

我们开发了多个 Skills，核心包括：

• ResourceReplacerSkill

  • 功能：扫描代码/配置文件，替换所有旧资源标识为新资源；
  • 输入：资源映射文档；
  • 输出：修改后的代码文件。

• DiamondSwitchCreatorSkill

  • 功能：自动在 Diamond 中申请新开关，命名规则为 maiseat.{original_name}；
  • 支持灰度、ABTest 等场景。

• ConfigExporterSkill

  • 功能：导出原应用所有环境（预发/线上）的配置项，作为新配置基线。

• XmlRefactorSkill

  • 功能：针对 MyBatis/Hibernate XML 文件，根据数据量判断是否保留分库分表逻辑，低流量应用自动降级为单库配置。

📌 Skills 编写方式：由同事通过自然语言描述目标（如“把所有 tddl datasource 名称加前缀 maiseat_”），Aone Copilot 自动生成 Python 执行脚本，并封装为可调用 Skill。

---

五、详细操作流程

步骤 1：代码 Fork 与分支管理

• 对每个原应用（如 taobao-user）创建新应用（如 maiseat-user）；
• 切换到 master-sg 分支（海外主干）；
• 创建新迁移分支 migrate_init，所有变更在此分支进行。

步骤 2：配置导出与文档生成

• 使用 ConfigExporterSkill 导出原应用所有 properties/yaml 配置；
• 人工审核后，生成《资源迁移对照表》文档；
• 示例片段：

  ## taobao-user → maiseat-user
  ### OSS
  - old: dama-oss-sg
  - new: maiseat-oss-prod
  ### TDDL
  - old: dama_user_db
  - new: maiseat_user_db (single db, no sharding)

步骤 3：AI 执行迁移（Plan + Exec）

• Plan 阶段：Skills 读取文档，生成《变更点清单》，列出所有待修改文件及行号；
• Exec 阶段：自动执行替换，生成新代码；
• 全程记录：输出详细的迁移日志，便于审计。

步骤 4：部署与问题修复

• 初期：调研使用阶段首个应用耗时约 1周（AI 不成熟，大量兼容性问题）；
• 后期：稳定后 2天/应用并且逐渐变快；
• 常见问题：
  • 分库分表逻辑残留 → 通过 XmlRefactorSkill 优化；
  • 开关未生效 → DiamondSwitchCreatorSkill 补充权限申请；
  • 依赖 jar 冲突 → 统一 parent pom 版本。

🔁 闭环优化：每次遇到新问题，立即更新 Skills 规则，确保下一个应用不再犯同样错误。

---

六、测试与验证策略

6.1 灰度切流

• 前端和后端结合的灰度切流等（前端也需要同步做的 当然我是服务端开发工程师不管这个 也看不了他们的开发计划，因为前段很早之前就具备这个能力了就是已经操作过实践了所以这次我参与的迁移也没介绍前端的开发计划）。

6.2 自测阶段

• 通过 HSF 直接调用 Service 接口，传入典型参数验证核心链路；
• 使用 “天星”流量监控工具，观察接口调用量、RT、错误率。

6.23测试团队介入

• 提供完整《接口变更清单》和《资源映射表》；
• 测试同学基于历史 Case 全量回归；
• 相信大部分公司还是人工测试比较多，但是我们老板说这样还是不保险和效率慢因为测试范围几乎就是从0到1的测试 也很浪费人力 需要测试同学也出相应的保障测试计划。现在还没有具体的计划出现，因为我们处于自测阶段我写的这个文档个人感觉大概率测试同学还是按众测case或者是他们的case集全量跑内容吧；
• 未来方向：推动测试团队建设 AI 自动生成测试用例能力，实现“迁移即测试”。

---

七、经验总结与最佳实践

✅ 成功关键

1. 文档先行：结构化文档是 AI 可靠执行的基础；
2. 小步快跑：先迁一个非核心应用试错，快速迭代 Skills；
3. 人机协同：AI 负责机械替换，人负责逻辑判断和异常处理；
4. 资源治理：借机清理僵尸应用，优化资源拓扑。

⚠️ 避坑指南

• 不要信任 AI 100%：所有生成代码必须 Code Review；
• 分支策略要清晰：避免污染主干；
• Diamond 开关需提前申请：权限审批可能耗时；
• 前端切流不在本次 scope：需提前对齐，避免联调阻塞。

---

八、未来展望

本次迁移不仅是业务拆分的技术落地，更是 “AI for DevOps” 的一次成功实践。后续我们将：

• 将整套 Skills 沉淀为公司级迁移工具包；
• 探索 AI 自动生成测试用例 + 自动化回归；
• 推动 “文档即契约” 模式在更多工程场景落地。

结语：在 AI 时代，开发者的核心竞争力不再是“写代码”，而是“定义问题 + 设计自动化流程”。这次迁移，让我们真正体会到了“让 AI 干活，让人思考”的高效协作模式。

---

欢迎交流讨论！如果你也在做类似迁移，欢迎留言分享你的经验～