简介这是一份面向云计算运维与系统迁移人员的阿里云服务实战文档聚焦SLB、ECS、OSS、RDS四大核心组件及其在系统数据迁移中的协同用法。文档从OSS对象存储的Bucket、存储类型与管理方式到RDS实例、数据库账户及备份恢复再到SLB监听器、后端服务器、会话保持与健康检查并延伸至产品架构、证书管理与应用场景层层拆解帮助读者建立从存储、数据库到流量分发的完整迁移认知同时能理解各服务在跨系统迁移中的配置与选型思路。资源为单个docx文件约1.78MB内容结构清晰、目录完整适合作为方案设计和技术笔记查阅。当前已有778人学习下载可用于日常运维参考或迁移项目前期调研。1. 云上迁移的本质不是在搬机器而是在重新划分职责边界一套跑在线下机房的业务系统里面有图片、附件这类二进制文件有 MySQL 里的结构化数据有处理请求的应用服务还有入口处的 Nginx。迁移上云最容易理解的方案是「照原样搬」——找几台云服务器装同样的环境把文件和数据库导过去再把域名指过来。看起来只是换了台机器但云上真正的价值恰恰在于不照原样搬。这套阿里云 SLB-ECS-OSS-RDS 的资料里迁移的落点不是四台机器而是四种不同职责的基础设施。OSS 承接静态文件RDS 承接数据库ECS 只跑应用逻辑SLB 在最前面挡流量。它们各自的存储模型、高可用方式、运维手段完全不同。理解这次迁移关键是先理解一个问题为什么同一个系统里的数据要拆给存储、数据库、计算、负载均衡四个不同的服务去管这个拆分逻辑搞清楚了迁移就不是「把文件拷过去」而是「让每份数据落到正确的机制里」。后文将按照「静态文件 → 数据库 → 应用服务 → 流量入口」的迁移顺序展开每一站都会追问同一个问题这个服务底层是怎么设计的为什么迁移时必须要按它的规则来。2. OSS对象存储为什么不能被当成「网盘挂载点」OSS 是这次迁移里第一个要处理的对象因为静态资源图片、附件、音视频往往占体积最大、访问最频繁。大部分人第一次接触 OSS是按「文件系统迁移」的思路来理解的建一个 Bucket然后把本地的目录结构原样传上去。这个思路会在后续使用中带来一串麻烦。2.1 数据模型Key-Value 扁平空间与「假目录」OSS 最核心的设计是存储空间内部是扁平的。对象Object由元信息、数据和文件名Key组成所有对象直接隶属于 Bucket没有多级目录的概念。你在控制台看到类似test1/test.jpg这样的路径那只是一个字符串 Key和a.jpg没有本质区别——OSS 并不会去建立test1这个目录节点也不存在「进入目录再查找文件」的寻址过程。这个设计和文件系统的树状索引结构有本质差异。文件系统里访问test1/test.jpg要先找到test1目录再在目录项里找到test.jpg而 OSS 里一次GetObject请求直接用 Key 定位对象。两者访问资源的消耗逻辑完全不同OSS 的对象数量可以扩展到海量规模而文件系统一旦目录层级变深、文件数量变大元数据操作就会成为瓶颈。所以迁移图片资源时原目录结构可以直接拼到 Key 里但心里要清楚/2019/08/08/foo.jpg只是一个便于人识别的命名约定不是存储结构。OSS 的命名规范也暗示了这一点——Key 不能以/或\开头长度 1 到 1023 字节大小写敏感。这些约束在文件系统里是不存在的。2.2 强一致性与冗余机制read-after-write 的保证资料里用了一个很重的词强一致性。用户收到上传成功的响应后该对象立刻可读而且冗余数据已经写入多个设备。不存在上传成功却读不到、或者读到半个文件的中间状态。删除操作同理返回成功即对象立即消失。这个机制对迁移来说意义重大。如果你用脚本批量迁移不需要担心「传完就校验」的竞态——只要 HTTP 200 返回了数据就真的在 OSS 上了。对比自建文件服务器 异步同步的方案OSS 把「成功」的语义定义得非常干净。数据冗余层面OSS 将对象的不同冗余副本存储在同一个区域内多个设施的多台设备上支持两个存储设施并发损坏时数据不丢失并周期性地做数据完整性校验发现损坏就用冗余数据重建。这些机制对用户完全透明你不需要像以前维护 RAID 那样关心磁盘健康状态。2.3 迁移时一定要用内网 Endpoint这里有一个迁移时最容易犯的操作错误。OSS 的访问域名Endpoint)分内网和外网同一个 Region 的 ECS 访问 OSS应该用oss-cn-{region}-internal.aliyuncs.com这样的内网地址。用外网地址访问也能通但流量会绕出数据中心再回来产生流量费用而且带宽和延迟都比内网差一个量级。用 Python 的 SDKoss2或boto3迁移时关键就在 Endpoint 和 Bucket 的地域必须匹配import oss2 # 注意auth 里的 AccessKey 只是身份凭证不决定地域 auth oss2.Auth(AccessKeyId, AccessKeySecret) # 关键点这里必须用内网 Endpoint才能走内网流量 endpoint https://oss-cn-{region}-internal.aliyuncs.com bucket oss2.Bucket(auth, endpoint, your-bucket-name) # 遍历本地目录把文件写入 OSS import os for root, dirs, files in os.walk(/data/static): for name in files: local_path os.path.join(root, name) # 去掉本地前缀保留相对路径作为 Key key os.path.relpath(local_path, /data/static) # put_object_from_file 是流式上传不会把整个文件读进内存 bucket.put_object_from_file(key, local_path)这段逻辑里有几个值得说明的机制点。put_object_from_file是流式上传适合大文件不会因文件过大撑爆内存Key 由relpath生成保留了原有的目录层次方便后续 URL 规则兼容。迁移脚本跑完后用GetObject随机抽查几个文件能直接验证强一致性——上传成功的对象立即可读。2.4 对象不可变与模拟目录的代价OSS 的对象生命周期里除了通过追加上传接口写入的对象外普通对象内容不可修改。想改一个字节只能重新上传整个对象。想「重命名目录」OSS 的实际操作是所有以旧前缀开头的 Object 全部复制成新前缀这是一个非常消耗资源的动作。这意味着如果你的应用代码里有「动态改名文件」「修改文件部分内容」的逻辑迁到 OSS 上必须先改应用。常见做法是文件名用 UUID 这类不可变标识内容更新时写入新 Key再删旧 Key需要覆盖时用同名上传但不推荐频繁这么做。资料里的对比表说得很直白把 OSS 映射为文件系统是低效的建议尽量只做写新文件、删除文件、读取文件这三种操作。3. RDSMySQL 迁移的增量追赶是怎么做到「不掉数据」的静态文件迁完接着是数据库。相比把图片传上去就完事数据库迁移要复杂得多——业务不会停下来等你。迁移期间源库还在持续写入怎么保证切到 RDS 时不丢数据这就是全量 增量迁移机制要解决的问题。3.1 全量 增量的时序配合迁移的时序可以拆成三个阶段。第一阶段做全量迁移把源库当前时刻的数据快照倒进 RDS。第二阶段做增量迁移持续把源库新产生的数据变更同步到 RDS让两边数据不断逼近。第三阶段是追平当增量延迟降到几秒甚至更小选择一个窗口把应用停掉或切到只读等最后一次增量追平然后切换连接串。这里最值得追问的是增量同步的实现基础。MySQL 主从同步依赖 binlog二进制日志DTS 这类数据迁移服务本质上是模拟了一个「从库」——它连接到源库拉取 binlog解析其中的事务和行变更再在目标库重放。所以源库必须先开启 binlog并且迁移账号要有REPLICATION SLAVE, REPLICATION CLIENT权限否则服务端连 binlog 都读不到。3.2 增量同步支持的 SQL 操作与类型限制不是所有 SQL 都能被增量同步。常见可支持的包括INSERT、UPDATE、DELETE、REPLACE这些 DMLDDL 里的CREATE TABLE、ALTER TABLE一类表单结构变更通常也能随 binlog 同步。但要注意binlog 里记录的是变更后的数据行或变更语句而不是应用逻辑。存储过程、触发器这类在数据库内部执行逻辑同步机制往往不做复制建议迁移前就把这部分从库里挪到应用层。binlog 的格式也直接决定增量同步能不能精确重放。如果源库 binlog 格式是STATEMENT基于 SQL 语句带非确定性函数比如NOW()、UUID()的语句在目标库重放时可能产生不同的值而ROW格式记录的是每一行的变更前后镜像可以精确重放。所以很多迁移要求源库 binlog 格式为ROW这不是偏好是正确性需要。可以通过一条 SQL 确认源库的 binlog 配置-- 检查当前 binlog 格式和是否开启 SHOW VARIABLES LIKE log_bin; SHOW VARIABLES LIKE binlog_format; -- 迁移任务完成后对比两边的数据量 SELECT COUNT(*) FROM your_schema.your_table;第一次做增量同步的人常遇到的困惑是明明全量都导完了为什么任务一直显示「增量延迟」原因大概率是源库写入压力大binlog 积压的变更还没追完。这符合设计预期——增量同步的目的就是尽量缩短切换窗口而不是让两边永远零延迟。3.3 迁移账号的权限边界与费用关注点资料里把「数据库账号的权限要求」单独列了一节这不是走形式。全量迁移和增量迁移对账号权限的要求不同全量至少需要读取目标表结构和数据的权限SELECT增量则叠加REPLICATION SLAVE等复制权限。如果权限给少了任务到增量阶段会报「无权限读取 binlog」之类的错误给大了主账号泄露的风险也随之变大。常见做法是单独创建一个迁移专用账号只授权待迁移的库不拿主账号跑迁移。费用方面增量迁移通常按迁移任务的规格和运行时长计费任务挂得越久费用越高。所以合理预期是增量任务不是让你一直挂在那边做长期同步的而是要在追平后尽快切换、结束任务。3.4 为什么数据结构也要迁移数据迁移不止是行数据还包括表结构索引、约束、分区、视图、函数等元数据。增量同步能同步后续的结构变更但初始的表结构要靠全量迁移或者单独的结构迁移完成。一个容易漏的坑是自增主键的起点。全量导完后如果自增列没有设置好AUTO_INCREMENT的下一个值新插入的数据可能触发主键冲突。用mysqldump --set-gtid-purgedOFF这类逻辑备份工具长期用惯了的人切到 RDS 后要习惯「DTS 任务 事后校验」的流程。4. SLB健康检查、会话保持与流量转发是怎么配合的数据库迁完应用部署到 ECS 上这时流量入口还是单台 Nginx。接下来要做的是把入口从「一台机器」升级成「一个负载均衡实例」。SLB 不是一个简单的前置代理它由监听器、后端服务器组、健康检查、会话保持等机制组成理解这些机制才能配出一套不会在下一次发布时翻车的负载均衡。4.1 四层监听与七层监听的转发差异SLB 的监听器支持四层TCP/UDP和七层HTTP/HTTPS。四层监听工作在传输层SLB 只做 IP 和端口的转发不解析 HTTP 内容——后端拿到的请求源 IP 会被替换成 SLB 的地址所以后端 ECS 上如果配了基于来源 IP 的访问控制会发现「所有请求都来自负载均衡」这个现象。七层监听则工作在应用层SLB 会解析 HTTP 头部可以做域名和路径转发、改写、超时控制等更细粒度的操作。选择哪个层级的监听取决于你的应用关心不关心 HTTP 头部内容。纯 TCP 协议比如自研的长连接服务、Redis 代理必须走四层HTTP 服务建议走七层可以把证书卸载和 HTTP 层面的控制都交给 SLB。4.2 健康检查后端不可用时的自动摘除与恢复健康检查是一个容易被轻视但决定可用性的机制。SLB 按照你配置的检查间隔比如每 2 秒一次向后端服务器发送请求或 TCP 探测如果连续 N 次失败就把这台 ECS 从转发池里摘掉不再给它分流量恢复健康后再加回池子。这里面有一个需要仔细配合的细节健康检查的类型要和你的服务匹配。如果你的 ECS 跑的是 Nginx PHP-FPM健康检查用 HTTP 方式探测一个轻量的路径比如/healthz是合理的如果探测的是一个重接口每次检查都会产生实际业务压力高峰期可能打满后端。更隐蔽的是如果后端配置了防火墙或白名单只接受来自 SLB IP 段的流量健康检查的探测包一样会被拦截导致健康的机器被误判为不健康。解决方法是健康检查本身也放在 SLB 的白名单范围内。4.3 会话保持无状态应用不需要有状态应用不能省会话保持解决的是这样一个问题同一个用户的多次请求如果被分到不同的后端 ECS而这个应用把 Session 存在了本机内存里用户就会「掉登录」。会话保持的作用是让同一来源的请求始终分发到同一台后端。但会话保持其实是在「容忍有状态」而不解决问题——它只是把同一个会话钉在一台机器上一旦这台机器挂了会话一样丢失。云上推荐的做法是让应用层把 Session 迁移到共享存储比如 Redis让负载均衡无需做会话保持也能正确处理所有请求。这样既简化了 SLB 的配置也让水平扩展真正成为可能新加一台 ECS不需要拷贝任何会话数据。配置层面SLB 既支持基于 Cookie 的会话保持插入你自己的 Cookie 或由 SLB 植入也支持四层监听的源 IP 会话保持。后者实现最简单但同一个 NAT 出口的用户会被固定到同一台后端可能造成后端负载不均。4.4 高可用架构控制面与数据面是怎么设计的SLB 本身的可用性不是靠单台设备而是靠集群。流量先到达一组 LVS四层节点再做分发七层由 Tengine 集群承接再转发给后端的 ECS。任何一个节点出现故障调度系统会把流量引导到其他健康节点这个过程对用户无感知。这也解释了为什么 SLB 实例的规格选择和后端 ECS 一样需要留有余量——集群本身高可用不代表你的账号配额和带宽规格不需要规划。一个常见的配置错误是只在 SLB 上做了健康检查但没有给后端的 ECS 开放足够的带宽或并发连接数。健康检查摘除了故障节点但某个节点如果只是「活着但不健康」比如连接池耗尽健康检查如果只探测 TCP 连通性而不检测应用层状态它依然会被判定为健康请求继续打过去表现为偶发超时。5. 迁移中常见的坑与排查记录这一章把迁移实践中高频出现的问题按「现象 → 原因 → 解决」梳理一遍。每一条都是真实踩过的值得在动手前过一遍。5.1 图片迁移后用外网 URL 访问奇慢流量费用异常现象资源传到 OSS 后线上页面加载图片速度比原来自建的文件服务器还慢月底账单流量费爆表。原因ECS 上的应用通过外网 Endpoint 访问 OSS每一个 Get 请求都从数据中心绕了一圈公网再回来。控制台复制 URL 默认是外网地址应用代码如果直接拼接这个地址就是主动走公网。解决同一 Region 的 ECS 访问 OSS一律改用oss-cn-{region}-internal.aliyuncs.com内网 Endpoint。切换后延迟和流量费用同时下降。判断方式是登录 ECSping一下 OSS 的内网域名能通就走内网不通则检查是否跨 Region。5.2 增量迁移一直追平不了任务延迟几十分钟现象全量迁移完成增量迁移显示有延迟并且延迟时间持续不减甚至增大。原因增量同步的速度取决于源库 binlog 的产生速度、迁移任务的规格和源库与目标库之间的网络带宽。如果源库有大量耗时的批量 UPDATE/DELETEbinlog 会产生大量行变更记录迁移任务规格过小或者源库、目标库跨地域延迟就会积累。解决把迁移任务换成更高规格尽量让源库和目标库在同一个地域如果延迟是大事务导致的可以在业务低峰期拆分大批量操作减小单个 binlog 事务的体积让增量同步可以更均匀地消费。5.3 配置了健康检查某台 ECS 还是被打到接口报 502现象SLB 健康检查显示后端全部正常但仍有部分请求返回 502且集中在某一台 ECS 上。原因健康检查只探测了 TCP 端口连通而服务本身已经无法正常处理请求比如线程池占满、Nginx worker 异常。TCP 探测返回成功不代表应用层可用。解决七层监听的健康检查改用 HTTP 方式路径指向一个专门的状态接口比如/healthz该接口检测依赖组件DB、Redis的状态对 TCP 监听可在 ECS 上部署一个最小 HTTP 服务专门响应健康检查把端口探测提升到应用层校验。5.4 应用连 RDS 报连接数超限现象切换数据库连接串后运行一段时间应用开始报Too many connections。原因RDS 实例规格默认有最大连接数限制。应用原来的连接池配置比如连接池上限 200在自建 MySQL 上没问题但超出了 RDS 小规格实例的连接数上限。解决调整应用的连接池上限把它控制在 RDS 实例规格的合理比例内比如最大连接的 80%同时检查是否存在连接泄漏——应用代码里有没有 finally 或 defer 释放连接。不要一上来就升 RDS 规格先看连接池配置和慢查询可能要解决的是哪个环节没释放连接。5.5 迁移后出现过期面包屑老 URL 带端口被 SLB 转发失败现象老系统里的资源 URL 是http://ip:8080/images/foo.jpg迁移后通过 SLB 域名访问时端口对不上。原因源站域名和端口写死在应用配置里。SLB 七层监听用 80 端口接收请求转发给后端的 8080 端口应用生成 HTML 时却回写了带 8080 的绝对地址浏览器直接访问该地址绕过了 SLB。解决应用代码所有生成 URL 的地方改为相对路径或者统一读取环境变量中的对外域名Nginx 侧加一层proxy_redirect配合改写 Location 头。这属于应用「出口」和「入口」没解耦导致的迁移问题改动代码而不是改 SLB 配置。5.6 ECS 上的日志与监控在新环境没有接上现象迁移后系统出问题想查 Nginx 访问日志和 SLB 转发日志发现控制台没有日志ECS 上也没有采集。排查无从下手。原因原环境里日志是直接写在本地磁盘靠人肉登录看云上新环境没有部署日志采集SLB 的日志管理功能也未开启。排障时才发现没有任何历史数据。解决SLB 控制台开通日志管理功能把转发日志投递到日志服务ECS 上部署日志采集 agent把应用日志和 Nginx 日志都收上来。这一步应该在迁移之前做成本低、收益高否则上线前一周的排障效率会非常低。6. 迁移顺序本身就是一种架构取舍回到开头的问题为什么数据要拆给四个服务迁移顺序 —— 静态文件先走、数据库次之、应用重新部署、流量最后切换 —— 不是随机的而是按「数据熵增程度」排列的。静态资源是熵最低的传上去就是完整的、不可变的OSS 的强一致性保证它「一次成功永远可用」数据库其次需要全量和增量的配合才能完成在线切换应用服务是中间态代码本身不变变的是运行环境和依赖流量入口排最后因为只有前面的数据层都稳定了才值得把正式流量切过来。这个取舍背后是云上架构的一个核心理念面向失败设计。OSS 的 12 个 9 持久性来自跨设备冗余RDS 的高可用来自主备切换机制SLB 的高可用来自控制面和数据面集群而 ECS 依然会宕机——但这没关系因为健康检查会把坏节点摘掉无状态应用可以被新节点无缝替换。每一层的可靠性机制不同你在每一层要做的配置也完全不同。从这套材料里可以提炼一个判断标准迁移能否成功的分水岭不是数据有没有搬完而是每一层有没有按它自己的机制去适配。OSS 层你能不能说清楚内网上传和外网上传的差别RDS 层你能不能回答增量同步依赖源库的哪个开关SLB 层你是不是把健康检查配到了应用层。这些细节的答案决定了你是在「搬服务器」还是在「做迁移」。我自己以前做过一次线下到云上的迁移当时按「搬完就跑」的思路半天把所有文件scp到 ECSMySQL 直接用mysqldump倒过去。上线后第一周就踩了三个坑图片外网流量超预算、数据库主键冲突、一台 ECS 被打挂后 SLB 还在往它转发请求。后来才明白云上每个服务都把「某个横切面的问题」解决到了极致——OSS 解决了存储的 Scale-outRDS 解决了数据库的运维SLB 解决了流量的可控性——而你真正要做的是让数据流和每一层的设计对齐。从那以后我每次迁移都强制自己把过程拆成「理解存储模型 → 核对同步机制 → 配置健康检查 → 切换流量」四步走一步一步验证之后再动正式环境。这份阿里云四件套的迁移材料最有价值的地方就是把这四步的标准答案都写了出来。希望帮到你——下次做同类迁移时能少走我用血泪换来的那些弯路。本文还有配套的精品资源点击获取