阿里云SLB-ECS-OSS-RDS迁移实战：从单机到云端架构的完整指南

简介：这份文档面向云计算运维、后端开发及系统迁移实施人员，围绕阿里云SLB、ECS、OSS、RDS四大核心服务，梳理其在系统数据迁移场景中的定位与配合方式，适合需要从零理解阿里云产品体系或准备上云迁移方案的技术人员参考。资源包内共1个docx文件，约1.78MB，内容以图文与目录结构组织，涵盖OSS对象存储的桶、对象、存储类型等概念及上传下载与管理方式，RDS的实例、数据库、账户模型与备份恢复、迁移服务，SLB的监听器、后端服务器、会话保持、健康检查、证书管理与高可用架构，并延伸至ECS与整体迁移思路。目录层级清晰，从服务概述、基本概念到应用说明逐层展开，便于按模块查阅与整理笔记。目前已有777人学习下载，可作为上云迁移前的知识梳理材料，帮助读者建立对阿里云基础服务组合的整体认知，为后续实操与方案设计打下基础。

1. 从一台快撑爆的 ECS 说起：这套 SLB-ECS-OSS-RDS 迁移方案到底解决什么

去年帮一个朋友处理他们的电商后台，单台 ECS 上跑着 Nginx、Java 应用、MySQL，图片全堆在服务器本地磁盘。大促前一天磁盘告警，图片目录 40 多个 G，数据库和 Web 服务抢 IO，页面加载肉眼可见地变慢。这种"一台机器扛所有"的架构，在业务量上来之后基本都会翻车。这份《阿里云 SLB-ECS-OSS-RDS 与系统数据迁移》文档，讲的正是把这种单机架构拆成阿里云标准四件套的完整过程：OSS 承接图片等非结构化资源，RDS 接管 MySQL，ECS 承载应用服务，SLB 做流量分发。文档覆盖了从服务概念、迁移准备到具体实施步骤的全流程，适合正在做上云迁移或架构拆分的一线开发和运维。下面我按实际落地顺序，把这份资料里能直接抄作业的部分拆开讲。

2. OSS 对象存储：图片资源从本地磁盘搬到 Bucket 的完整路径

2.1 为什么图片不该继续放在 ECS 本地盘

文档里对 OSS 的定位说得很清楚：对象存储是 Key-Value 形式的分布式存储，和文件系统的树状索引结构有本质区别。很多人第一次接触 OSS 会不自觉地把它当网盘用，建一堆"目录"，这其实是个误区。在 OSS 里，test1/test.jpg只是一个字符串 Key，和a.jpg没有本质区别，不存在真正的目录层级。理解这一点很关键，因为它直接决定了迁移时文件路径怎么映射。

从成本角度看，ECS 的系统盘和数据盘都是有容量上限的，图片、视频这类非结构化数据增长速度快，放在 ECS 上意味着要么不断扩容磁盘（成本高且操作麻烦），要么定期清理（业务不允许）。OSS 的容量弹性扩展，标准存储适合频繁访问的热数据，低频访问存储适合每月访问 1-2 次的数据，归档存储适合半年以上不访问的冷数据。迁移时可以根据图片的实际访问频率选择存储类型，不必一刀切用标准存储。

从性能角度看，图片请求走 OSS 后，ECS 的磁盘 IO 和带宽压力会明显下降，数据库和应用服务的响应也会更稳定。文档中提到 OSS 的数据设计持久性不低于 99.9999999999%（12 个 9），服务可用性不低于 99.995%，这个可靠性级别是自建文件存储很难达到的。

2.2 迁移前的网络与权限准备

文档在"迁移准备"部分强调了网络访问的准备工作。实际操作中，这一步的核心是确认 ECS 到 OSS 的网络连通性。如果 ECS 和 OSS Bucket 在同一个地域，走内网 Endpoint 访问，不走公网流量，速度快且不产生公网流量费用。比如杭州地域的外网 Endpoint 是oss-cn-hangzhou.aliyuncs.com，内网 Endpoint 是oss-cn-hangzhou-internal.aliyuncs.com。迁移时务必用内网 Endpoint，否则大量图片走公网传输，流量费用会让人后悔。

权限方面，文档提到了 AccessKey 的概念。AccessKey 由 AccessKeyId 和 AccessKeySecret 组成，用于身份验证。实际迁移中，不建议直接用主账号的 AccessKey，而是通过 RAM 创建一个子账号，只授予目标 Bucket 的读写权限。这样即使密钥泄露，影响范围也可控。

# 安装 ossutil 命令行工具（Linux x86_64） wget https://gosspublic.alicdn.com/ossutil/1.7.19/ossutil64 chmod 755 ossutil64 mv ossutil64 /usr/local/bin/ossutil # 配置 AccessKey（按提示输入 RAM 子账号的 AK） ossutil config # 配置文件默认路径 ~/.ossutilconfig # 需要填写：endpoint、accessKeyId、accessKeySecret

上面这段是 ossutil 的安装和配置流程。ossutil 是阿里云官方提供的 OSS 命令行管理工具，比控制台适合批量操作。ossutil config会交互式地让你输入 Endpoint、AccessKeyId、AccessKeySecret，配置信息写入~/.ossutilconfig。Endpoint 填内网地址，比如oss-cn-hangzhou-internal.aliyuncs.com。如果 ECS 和 Bucket 不在同一地域，内网不通，只能走公网 Endpoint，这时候要评估流量成本。

2.3 用 ossutil 批量迁移图片资源

准备工作做完之后，迁移本身其实不复杂。文档中"迁移实施"部分的核心思路是把本地文件资源通过 HTTP 或工具上传到 OSS。我一般用 ossutil 的cp命令做批量上传，支持递归目录、断点续传和增量同步。

# 创建 Bucket（如果还没有的话） ossutil mb oss://your-bucket-name --acl private # 批量上传本地图片目录到 OSS，-r 表示递归，-u 表示增量（跳过已存在且未修改的文件） ossutil cp -r /data/www/uploads/ oss://your-bucket-name/uploads/ -u --jobs 10 # 上传完成后验证文件数量 ossutil ls oss://your-bucket-name/uploads/ -s | tail -1

-r参数表示递归处理子目录，-u表示增量上传，只上传本地比 OSS 上更新的文件，重复执行不会重复上传。--jobs 10表示并发 10 个上传任务，根据 ECS 的带宽和 CPU 情况调整，一般 5-20 之间比较合适。上传完成后用ossutil ls -s查看统计信息，对比本地文件数量和 OSS 上的对象数量是否一致。

迁移完成后，应用代码里的图片访问路径需要从本地路径改成 OSS 的 URL 或 CDN 加速域名。文档在"后续操作"部分提到了这一步。常见做法是把图片域名切到 CDN，CDN 回源到 OSS，这样用户访问图片走 CDN 边缘节点，速度更快，OSS 的回源压力也更小。

注意：迁移完成后不要急着删除本地图片，至少保留一周作为回滚备份。确认线上图片访问全部正常后再清理。

3. MySQL 迁移 RDS：增量同步与割接窗口怎么控制

3.1 迁移类型的选择逻辑

文档在"迁移类型说明"部分区分了全量迁移和增量迁移。全量迁移是把源库的所有数据一次性搬到目标库，适合停机时间充裕的场景。增量迁移是在全量迁移的基础上，持续同步源库的 binlog 到目标库，适合不能长时间停机的业务。实际生产环境中，大多数业务都要求最小化停机时间，所以增量迁移是更常见的选择。

文档提到增量数据迁移支持同步的 SQL 操作，包括 INSERT、UPDATE、DELETE 等。这意味着在迁移过程中，源库的业务写入会实时同步到 RDS，等到割接时只需要短暂停写，确认增量同步追平后切换连接地址即可。整个割接窗口可以控制在几分钟以内，而不是几小时。

数据库账号的权限要求也需要提前确认。源库账号需要有 REPLICATION SLAVE 和 REPLICATION CLIENT 权限，否则无法读取 binlog。目标 RDS 账号需要有读写权限。这些权限在迁移前就要配好，不要等到迁移时才发现权限不够。

3.2 迁移任务的创建与参数配置

文档"操作步骤"部分描述了迁移任务的创建流程。在阿里云 DTS（数据传输服务）控制台创建迁移任务时，需要填写源库和目标库的连接信息，选择迁移类型（结构迁移、全量迁移、增量迁移），以及选择要迁移的库表。

-- 在源库上确认 binlog 是否开启 SHOW VARIABLES LIKE 'log_bin'; -- 如果返回 ON，说明 binlog 已开启 -- 查看 binlog 格式，必须是 ROW 模式 SHOW VARIABLES LIKE 'binlog_format'; -- 返回 ROW 才能支持增量迁移 -- 确认源库账号权限 SHOW GRANTS FOR 'migration_user'@'%'; -- 需要包含 REPLICATION SLAVE 和 REPLICATION CLIENT

上面这几条 SQL 是迁移前在源库上执行的检查。log_bin必须是 ON，binlog_format必须是 ROW，这两个条件不满足的话增量迁移无法工作。binlog_format如果是 STATEMENT 或 MIXED，需要在 my.cnf 里改成 ROW 并重启 MySQL，这个操作本身就需要一次停机，所以要提前规划。SHOW GRANTS确认迁移账号的权限，缺少 REPLICATION 权限的话需要用 root 账号补授。

迁移任务创建后，DTS 会先做结构迁移（建表），再做全量迁移（搬数据），最后进入增量同步阶段。增量同步阶段会持续运行，直到你手动结束任务。这期间源库的正常读写不受影响。

3.3 割接窗口的操作清单

增量同步追平后，就可以做割接了。文档"结束迁移任务"和"后续操作"部分提到了收尾工作。割接的核心操作是：停止源库写入 → 确认增量同步延迟为 0 → 将应用连接地址切换到 RDS → 恢复业务写入。

# 割接前检查增量同步延迟（在 DTS 控制台查看） # 确认延迟为 0 秒或接近 0 秒 # 停止应用写入（以常见的 Java 应用为例，通过 Nginx 摘除后端） # 在 Nginx 配置中将要迁移的服务器标记为 down # 然后 nginx -s reload # 切换应用数据库连接地址 # 修改 application.properties 或环境变量中的数据库连接串 # 从源库地址改为 RDS 的内网地址 # 重启应用，验证数据库连接 # 观察日志中是否有连接异常

割接窗口内，先通过 Nginx 或 SLB 把流量从旧服务器摘除，确保没有新的写入。然后观察 DTS 的增量同步延迟，等延迟归零后，修改应用的数据库连接配置，重启应用。验证读写正常后，结束 DTS 迁移任务。整个过程如果顺利，5-10 分钟可以完成。

注意：割接前一定要在测试环境完整演练一遍，包括连接切换、应用重启、回滚操作。生产环境的割接不要第一次就上。

4. ECS 应用部署与 SLB 负载均衡：从单机到集群的最后一公里

4.1 应用服务的安装顺序与依赖关系

文档在"系统应用服务迁移 ECS"部分列出了需要安装的组件：JDK、Nginx、Redis、webp 依赖环境、Apache 服务、MapzoneServer 服务、系统 web 后台服务、系统 APP 移动端服务。这个安装顺序不是随意的，有依赖关系在里面。

JDK 是 Java 应用的基础运行环境，必须最先装。Nginx 作为反向代理和静态资源服务，通常第二个装。Redis 作为缓存服务，如果应用依赖它做 session 共享或数据缓存，需要在应用启动前就绪。webp 依赖环境是图片处理相关的库，如果应用有图片格式转换功能，需要提前安装。Apache 服务和 MapzoneServer 服务是特定业务组件，按文档顺序安装即可。

# 安装 JDK 8（以 CentOS 为例） yum install -y java-1.8.0-openjdk-devel java -version # 确认输出 1.8.x # 安装 Nginx yum install -y nginx systemctl enable nginx systemctl start nginx # 安装 Redis yum install -y redis systemctl enable redis systemctl start redis redis-cli ping # 返回 PONG 说明正常 # 安装 webp 依赖 yum install -y libwebp-devel libjpeg-devel libpng-devel

上面这段是基础环境的安装命令。java -version确认 JDK 版本，redis-cli ping确认 Redis 可用。webp 依赖的三个库是图片处理的基础，缺少的话应用启动时可能报UnsatisfiedLinkError或类似的本地库加载错误。这些依赖装完后，再按文档顺序部署业务应用。

4.2 SLB 实例的创建与监听配置

文档"创建负载均衡实例"和"配置负载均衡实例"部分描述了 SLB 的配置流程。SLB 的核心概念包括监听器（Listener）、后端服务器（Backend Server）和健康检查。监听器负责接收客户端请求并转发给后端服务器，健康检查负责探测后端服务器的可用状态。

创建 SLB 实例时，需要选择地域、实例类型（公网或私网）、计费方式。公网 SLB 有公网 IP，直接对外提供服务；私网 SLB 只有内网 IP，通常配合 EIP 或 NAT 网关使用。对于大多数 Web 应用，公网 SLB 是更直接的选择。

# SLB 配置的核心参数（在控制台或通过 API 设置） # 监听协议：HTTP 或 HTTPS # 监听端口：80 或 443 # 后端端口：应用实际监听的端口，如 8080 # 健康检查路径：如 /health 或 /api/status # 健康检查间隔：默认 5 秒 # 不健康阈值：默认 3 次 # 健康阈值：默认 3 次 # 后端服务器权重：根据 ECS 配置设置，配置高的权重高 # 例如：ecs-1 权重 100，ecs-2 权重 50

健康检查的配置直接影响故障切换的速度。间隔 5 秒、不健康阈值 3 次，意味着最坏情况下 15 秒后 SLB 会把故障节点摘除。如果应用启动较慢，健康检查路径要选一个能快速响应的接口，不要选依赖数据库的复杂接口，否则应用刚启动时健康检查可能误判。

4.3 域名解析与流量切换

文档"域名解析"部分提到了将域名指向 SLB 的公网 IP。这一步在 DNS 服务商处操作，添加一条 A 记录，将业务域名解析到 SLB 的 IP 地址。如果原来域名直接解析到 ECS，切换时把 A 记录改成 SLB 的 IP 即可。

DNS 切换有缓存问题，各地 DNS 服务器的缓存时间从几分钟到几小时不等。为了平滑切换，可以提前把 TTL（Time To Live）调小，比如从 3600 秒改成 60 秒，这样切换后几分钟内就能全网生效。切换完成后观察 SLB 的监控指标，确认流量正常分发到后端 ECS。

注意：SLB 实例创建后不要急着删除旧的 ECS 或释放资源，确认业务稳定运行至少 24 小时后再做清理。

5. 迁移过程中最容易翻车的几个地方

5.1 现象：ossutil 上传大量小文件时速度极慢

原因：默认并发数较低，且小文件上传时每个请求的建立连接开销占比高。另外如果走了公网 Endpoint，带宽瓶颈也会导致速度慢。

解决：确认使用内网 Endpoint，将--jobs参数调大（建议 10-20），如果文件数量特别多（几十万以上），考虑先打包成 tar 再上传，到 OSS 后再解压，或者使用 OSS 的批量操作工具。

5.2 现象：DTS 增量迁移延迟持续增大，追不上源库写入

原因：源库写入量太大，DTS 的同步速度跟不上；或者源库有大事务（如批量 DELETE、ALTER TABLE），导致 binlog 事件积压。

解决：检查源库是否有大事务在执行，尽量拆分成小批次。如果是写入量本身太大，考虑升级 DTS 实例规格。另外确认源库和目标库的网络延迟是否正常，跨地域迁移时网络延迟会明显影响同步速度。

5.3 现象：SLB 健康检查显示后端 ECS 异常，但应用实际正常运行

原因：健康检查路径配置错误，或者应用监听的端口和 SLB 后端端口不一致。也可能是 ECS 的安全组没有放行 SLB 的健康检查源 IP。

解决：确认健康检查路径返回 200 状态码，确认应用监听端口和 SLB 后端端口一致，确认 ECS 安全组放行了 SLB 的健康检查 IP 段（阿里云 SLB 的健康检查 IP 段是 100.64.0.0/10）。

5.4 现象：迁移后图片访问 403 Forbidden

原因：OSS Bucket 的 ACL 设置为 private，但应用直接拼接了 OSS 的公网 URL 访问，没有签名。或者 CDN 回源时没有正确配置 OSS 的访问权限。

解决：如果图片是公开访问的，Bucket ACL 设为 public-read；如果是私有访问，应用需要通过 SDK 生成带签名的 URL，或者配置 CDN 回源时带上鉴权参数。不要为了省事直接把 Bucket 设为 public-read-write，这会导致任何人都能上传文件。

5.5 现象：割接后应用连接 RDS 报连接数超限

原因：RDS 的最大连接数默认值比自建 MySQL 低，应用连接池配置没有调整，导致连接数打满。

解决：在 RDS 控制台查看当前连接数和最大连接数，调整应用的连接池最大连接数（如 HikariCP 的 maximumPoolSize），确保不超过 RDS 的限制。如果确实需要更多连接，可以升级 RDS 规格。

6. 迁移完成后的验证清单与一个实用技巧

迁移做完不等于结束，验证才是保证不出问题的关键。我一般会按下面这个清单逐项确认：

这个清单看起来简单，但每一条都对应着实际踩过的坑。比如 OSS 文件完整性检查，曾经有一次迁移后发现少了几个文件，原因是文件名里有特殊字符，ossutil 默认跳过了。后来加了--include参数指定所有文件类型才解决。

最后分享一个实用技巧：迁移完成后，在 OSS 上开启版本控制功能。文档在"功能概览"里提到了版本控制，开启后针对数据的覆盖和删除操作会以历史版本保存下来。有一次应用代码 bug 导致批量覆盖了 OSS 上的图片，因为开了版本控制，直接回滚到之前的版本，几分钟就恢复了。如果没有这个功能，那些被覆盖的图片就真的找不回来了。

从那以后我每次做 OSS 迁移，都会在迁移完成后第一时间开启版本控制，并且给 Bucket 配置生命周期规则，把超过 90 天的历史版本自动转成低频存储，既保留了后悔药，又不会让存储成本失控。希望帮到你。

本文还有配套的精品资源，点击获取