SLB、ECS、OSS、RDS四件套云上迁移实战笔记

简介文档围绕阿里云SLB、ECS、OSS、RDS四大核心服务及系统数据迁移展开适合云运维、开发人员及准备上云的项目团队阅读。内容以目录方式系统梳理先介绍OSS对象存储的Bucket、对象、存储类型与管理方式再讲RDS关系型数据库的实例、数据库、账户及备份恢复后重点展开SLB负载均衡的监听器、后端服务器、会话保持、健康检查、产品架构与应用场景并串联系统迁移中多个服务的配合方法。除概念外还涉及管理工具使用、常见操作与架构设计并补充证书管理、健康检查等实用细节覆盖从入门到落地的完整链路。全包为1个docx文件大小约1.78MB结构紧凑便于按章查阅。目前已有778人学习下载适合需要快速上手阿里云核心服务的中高级云运维与开发人员。1. 拆一份把SLB、ECS、OSS、RDS串起来的迁移笔记它能解决什么搞云上迁移的工程师最怕的不是单个组件不会配而是四个服务全都熟却不知道先迁什么、后迁什么、哪个环节会卡住。这份笔记正好踩中了这个痛点——它不是官方文档的复制粘贴而是一套带完整顺序的迁移实操先把系统里的静态资源从HTTP目录挪到OSS再把MySQL数据迁进RDS接着把应用服务部署到ECS最后用SLB把流量收口。整个过程有服务规划、有参数配置、有迁移后的验证和清理适合正在做自建机房上云、或者打算把业务整体搬到云上的人直接照着走。后面几章会把每一步的命令、参数和踩过的坑按实际执行顺序拆开讲。2. 云上四件套怎么选型与排序先把资源和迁移顺序理清2.1 四个服务在系统里分别扮演什么角色OSS、RDS、ECS和SLB这四个服务看名字都认识但在一次完整迁移里各自承担的任务是完全不同层面的。OSS是对象存储负责存放图片、音视频、附件这类非结构化数据它的核心价值是海量、低成本、不占应用服务器磁盘RDS是关系型数据库负责MySQL这类结构化数据的存储和查询迁移后不用再自己管主从、备份和监控ECS是计算资源跑应用代码和中间件相当于原来那台物理服务器的替代品SLB则是流量入口把用户请求按策略分发到多台ECS上顺带完成健康检查和故障摘除。这套划分看起来简单但迁移时必须先想清楚一件事数据永远比代码难搬。代码错了可以重新部署数据丢了没法重来。所以我的做法是先把OSS和RDS这两条数据链路打通再谈ECS上的应用部署最后用SLB把入口接上。2.2 规格选择这套系统适合什么配置原文里没有给出具体的机器规格数字但通过系统服务组成可以反推出来。这套系统包含了地图类服务模块、Web后台、APP移动端接口服务还依赖Nginx、Redis、Apache、JDK环境。这种组合意味着CPU和内存都有硬需求不能拿最低配的ECS硬扛。我的选型思路是ECS实例规格优先选通用型或计算型4核8G起步因为地图类服务模块通常有大量空间计算和坐标转换逻辑CPU容易先打满内存方面Redis缓存和JVM堆内存要提前预留2G内存的实例跑Java服务加Redis一定会频繁触发Swap这是最常见的翻车点。带宽方面如果文件资源已经迁到OSSECS的公网带宽只需要覆盖动态请求和应用API5Mbps起步就够用如果文件还留在ECS本地带宽就要按峰值流量重新估算。RDS的规格取决于MySQL的QPS和存储量。这套系统的数据量级如果以GB为单位4核8G的MySQL实例已经够用如果原库表数据量在百GB级别建议直接选8核16G给增量同步和后续业务高峰留出余量。存储类型选SSD云盘IOPS比高效云盘高出一截MySQL这类随机读写密集的引擎对IOPS非常敏感。OSS的存储类型选择反而是最不需要纠结的一步。原文档明确列了标准、低频访问、归档三种存储类型对应关系很直接系统当前正在展示和访问的图片、用户上传的附件走标准存储半年以上的历史日志、已经不再访问的归档数据走低频或归档存储。这里有一个经常被忽略的成本陷阱低频访问类型的单价虽然低但每次读取都要额外收数据取回费用如果资源明明每天都被访问却选了低频月底账单会比标准存储更贵。服务核心角色选型要点OSS静态资源存储热数据选标准冷数据选低频/归档RDS关系型数据库规格按QPS和存储量定8G起步稳妥ECS应用和中间件运行4核8G起步注意内存和带宽余量SLB流量入口和负载分发按业务域名和监听协议规划实例数2.3 迁移顺序为什么是OSS、RDS、ECS、SLB原文档的章节组织暗含了这套迁移顺序我在实操中验证过这个顺序是合理的。先迁OSS是因为静态资源迁移和应用逻辑无关文件上传完成后只需要把代码里的资源路径从本地地址换成OSS的访问域名即可风险最低。再迁RDS是因为数据库迁移有全量加增量的窗口期先把全量数据导入到RDS再通过增量同步追平源库的写入后面切应用时数据库已经是一条完整的新链路。接着迁ECS把应用代码和环境依赖部署到新机器上让应用直接连接RDS和OSS。最后配SLB把流量从旧入口切到负载均衡上。这个顺序保证每一步都有明确的完成标准不会出现在同一时间既要改代码又要导数据还要切流量的混乱局面。2.4 内网Endpoint与外网Endpoint一个低成本高收益的细节OSS和RDS都提供内网访问域名同一地域的ECS访问这些服务时走内网链路不消耗公网流量延迟也更低。原文档里明确提过OSS的内网Endpoint就是对应的地域内网域名RDS也提供内网连接地址。实际部署时ECS上的应用代码一定要配置成内网Endpoint否则一旦流量起来公网流量费用会成为一个持续流血的成本项。判断配置对不对很简单在ECS上ping一下配置的Endpoint域名解析到10.x.x.x或100.x.x.x这类私网地址段就是内网解析到公网IP就是配置错了。这里还有一个容易忽略的点Bucket创建时选了哪个地域内网Endpoint就是哪个地域的域名。如果Bucket在华东某地域ECS也在华东某地域内网访问走通没有问题但如果Bucket在A地域、ECS在B地域内网链路就不存在了只能走公网。所以创建Bucket之前一定要先确认ECS和RDS的所在地域尽量让所有服务落在同一个地域。3. 系统文件资源迁OSS批量上传、权限控制和回源兜底3.1 迁移前的文件清点与目录规划原文档在系统文件迁移这节提到了“迁移准备-准备网络访问图片资源”这句话背后要做的事比看上去多。准备网络访问图片资源第一步是把原来系统里通过HTTP对外提供访问的图片目录完整盘点出来确认总大小、文件数量和目录结构。这一步不要省因为OSS的Object Key设计直接决定后续代码改动量。我一般会先在源服务器上跑一条统计命令把文件总量和数量摸清楚du -sh /data/www/upload find /data/www/upload -type f | wc -ldu统计目录占用空间find统计文件数量。这两个数字决定上传方式几十GB以上就走命令行工具批量并发上传几十MB级别的零散文件直接图形化工具拖上去也能接受。文件数量多但单文件很小的情况要特别注意比如大量几十KB的头像图片这种场景的瓶颈不在总大小而在每秒钟能处理多少个文件并发参数要往上调。目录结构也要在这个阶段定好。OSS的Bucket是扁平结构本身没有目录概念data/upload/2024/只是一个带斜杠的字符串前缀但应用代码里的URL路径会直接映射到这个前缀。所以最好的做法是让Bucket里的Object Key和原服务器上的文件路径保持完全一致例如原路径是/data/www/upload/images/logo.png上传后Object Key就是upload/images/logo.png这样代码里替换资源地址时只改域名前缀不用改路径。3.2 用命令行工具做全量上传文件清点完成后进入正式迁移。这个步骤原文档命名为“迁移实施”核心工作就是把准备好的文件批量上传到OSS。标准做法是用官方的命令行工具支持递归上传、并发控制和增量同步。ossutil cp -r /data/www/upload oss://bucket-name/upload \ --parallel 8 \ --jobs 100 \ --update \ --delete参数说明-r表示递归上传整个目录--parallel 8控制并发上传的任务数8个并发是比较稳的起始值机器性能好可以往上加到16--jobs 100控制每个并发任务内部同时处理的文件数上限--update表示只上传本地有而OSS没有的文件以及大小不一致的文件相当于增量同步--delete会把OSS上存在但本地已经删掉的文件一并清理保证两端一致。这个命令第一次跑的时候是全量上传后面再跑就是增量同步。整个上传过程要留意两个指标一是上传速度是否稳定二是错误文件数量。命令执行完后用下面的统计命令确认结果ossutil ls oss://bucket-name/upload --stat--stat参数会输出这个前缀下的文件总数和总大小和第一步清点出来的数字做交叉比对数量、大小都对上了迁移才算完成。3.3 权限模型先私有后开白名单而不是一刀切公开上传完成后进入原文档所说的“后续操作”环节。很多人到这里就急着把Bucket权限设成公共读图省事实际上这是安全上最大的坑。Bucket一旦公共读所有Object都会暴露在公网任何人都可以通过拼接URL访问你的数据如果存在私有图片或用户上传的敏感文件等同于直接裸奔。我的习惯是Bucket ACL保持私有然后通过RAM用户授权或者STS临时凭证让应用服务器访问对于必须通过公网直接访问的图片资源单独设置Object级的读写权限而不是放宽整个Bucket。原文档里也专门提到了ACL的控制粒度Bucket和Object是两套独立的权限体系完全可以在Bucket私有的大前提下给指定Object开公共读。多提一句Bucket命名规则原文档写得清楚只能包含小写字母、数字和短横线必须以字母或数字开头结尾3到63字节。这个命名在创建后无法修改所以一旦定错只能删了重建再传一遍非常浪费时间。3.4 上传后的验证与回源兜底文件全部落到OSS后还要解决一个兼容性问题老的图片URL可能还被搜索引擎索引、被外部系统引用、或者被APP老版本的缓存记录。最稳妥的兜底方案是在ECS的Nginx里加一条回源规则如果请求的路径在OSS上返回404就回源到本地旧目录读取。这样即使有漏传的文件用户访问时也不会直接看到图片裂开。location /upload/ { proxy_pass https://bucket-name.oss-cn-xxxx-internal.aliyuncs.com/upload/; proxy_intercept_errors on; error_page 404 fallback; } location fallback { alias /data/www/upload/; }这段配置的含义是把/upload/路径的请求先转发给OSS内网Endpoint如果OSS上找不到对应Object、返回404就把请求转给本地旧目录兜底。proxy_intercept_errors on在这里是关键不加这一行Nginx会把404直接透传给客户端不会走回源逻辑。回源兜底在切换初期很有用可以等运行一段时间确认没有404后再关掉。4. MySQL数据迁RDS全量导入、增量同步与数据一致性校验4.1 源库前置检查binlog、字符集、账号权限数据库迁移是最不能拍脑袋的部分。原文档里把“前提条件”和“注意事项”放在最前面实操时确实如此。第一步是检查源MySQL的binlog配置因为增量迁移依赖binlog来捕获源库的实时写入。SHOW VARIABLES LIKE log_bin; SHOW VARIABLES LIKE binlog_format; SHOW VARIABLES LIKE binlog_row_image;log_bin必须是ONbinlog_format必须是ROWbinlog_row_image最好是FULL。如果binlog没开或者格式是默认的STATEMENT增量迁移阶段会漏数据或者没法精确同步。这一步检查结果不满足就先在源库把参数改掉并重启MySQL不要往下走。字符集也要提前对齐源库是utf8mb4RDS实例也必须建utf8mb4否则中文、emoji和一些生僻字在同步后会变成乱码。最后是账号权限迁移账号至少要具备源库的SELECT权限目标RDS账号要有目标库的读写权限。4.2 全量数据导出与导入前置检查通过后先做全量迁移。全量阶段最常用的是先通过mysqldump把源库逻辑导出再导入到RDS。导出时用--single-transaction对InnoDB表开启一致性快照不会锁表业务可以继续写入。mysqldump -h 源库地址 -u 迁移账号 -p \ --single-transaction \ --set-gtid-purgedOFF \ --routines \ --triggers \ --hex-blob \ db_name full_dump.sql参数说明--set-gtid-purgedOFF避免导出文件带上源库的GTID执行记录防止导入RDS时因GTID冲突报错--routines和--triggers分别导出存储过程、函数和触发器漏掉这两个参数导出的库结构就不完整--hex-blob把二进制字段按十六进制导出避免乱码。业务量大的时候mysqldump会占用源库一定IO资源我一般放在业务低峰期执行。导入到RDS用标准方式即可mysql -h RDS内网地址 -u 目标账号 -p db_name full_dump.sql导入后第一件事不是接着配增量而是先抽查几张关键表的行数和最大主键确认基础数据是对的再进入增量阶段。4.3 增量同步的配置与注意事项全量导入完成时源库的binlog已经推进了新的位点此时需要启动增量同步把这些新写入追平。常见的做法是使用云上提供的数据迁移服务原文档也单独列出了“增量数据迁移支持同步的SQL操作”和“数据库账号的权限要求”这两节说明增量链路是整个RDS迁移的核心环节。增量迁移链路启动后重点监控同步延迟和错误日志。延迟数字在几百毫秒内是正常的如果持续增长到几秒甚至几十秒说明源库写入压力太大或迁移账号权限不足。这里有一条血泪经验源库的binlog保留时间要提前调大。默认保留两天如果全量导入和增量链路衔接期间源库binlog过期清理了增量链路直接断开只能删掉重来。4.4 迁移完成后的校验方法增量链路追平、源库和目标库数据一致后先别急着切流量。我通常会做三层校验校验项方法通过标准行数一致性对每张业务表分别SELECT COUNT(*)对比源库RDS行数完全相等增量追平对比源库和目标库最新写入时间戳延迟低于可接受阈值字段完整性抽查核心表的MAX(id)和最近更新时间与源库一致行数和时间戳校验都通过后再把应用代码里的数据库连接地址从源库改成RDS内网地址。这里有一点要注意RDS的内网地址只能在VPC内访问ECS如果不在同一个VPC或者没有开通内网互通是连不上这个地址的。所以创建RDS时就要和ECS规划在同一个VPC跨VPC之后处理起来会非常麻烦。5. ECS应用部署与SLB负载均衡环境安装、监听配置与避坑记录5.1 ECS上按依赖顺序装好环境和应用服务原文档在“系统应用服务迁移ECS”一节列出了完整的服务安装清单JDK、Nginx、Redis、webp依赖环境、Apache、地图类服务模块、Web后台服务和APP移动端服务。这个安装顺序本身是有依赖关系的不能乱跳。我的执行顺序是先装JDK因为Java类服务模块和Web后台都依赖它装完确认java -version正常再继续然后装Nginx和Apache这两个都是Web服务层Nginx用来做入口转发和静态资源代理Apache跑地图类服务的旧逻辑接着装Redis因为Web后台和APP端的会话缓存依赖Redis再装webp图像处理依赖库这个影响图片格式转换和压缩漏了会导致后端处理webp图片时报错最后部署各业务服务模块并逐个确认端口监听了。java -version nginx -t redis-cli ping systemctl status apache2这套命令每执行一条就是一道检查关卡。nginx -t检查Nginx配置语法redis-cli ping通不通返回PONGApache用systemctl看运行状态。任何一步失败就停下来解决不要带着问题继续往下装。5.2 SLB实例创建、后端挂载与监听配置应用服务在ECS上跑通后就进入SLB负载均衡的配置阶段。原文档把SLB的创建和配置分成“准备工作”、“创建负载均衡实例”、“配置负载均衡实例”和“域名解析”四步实操时这四步的先后顺序不能乱。准备阶段要先把后端ECS的端口和服务状态确定下来。比如Web后台服务的端口是8080APP端API是8081健康检查的URL是/healthz这两个端口要在ECS的安全组里放行并且只允许SLB所在的安全组访问。控制台创建SLB实例时地域要和ECS在同一地域实例类型按业务选择公网私网组合型适合绝大多数Web业务。监听配置是整个SLB接入里最核心的一步参数要按业务协议填准确配置项推荐值说明监听协议HTTP / HTTPSWeb系统建议直接上HTTPS证书提前上传监听端口80 / 443对应用户访问入口后端端口8080 / 8081对应ECS上实际服务端口调度算法加权轮询后端两台ECS权重一致时轮询分发健康检查协议HTTP用TCP检查只能探端口存活探不到业务状态健康检查路径/healthz后端服务必须返回2xx或3xx会话保持按需开启需要登录态的Web应用建议开启超时时间对齐应用session这里要特别强调健康检查路径。很多人在SLB控制台图省事把健康检查设成TCP 80端口检查结果后端服务进程活着但业务逻辑卡死时SLB照样把流量打过来用户看到的就是页面无响应。用HTTP路径检查GET /healthz让后端服务自己报告健康状态才是真正有效的探活。后端服务器组配置时把两台ECS加进去权重先保持默认100。加完后去SLB的服务器组页面观察健康检查状态显示正常再继续。最后一步是做域名解析把原来指向ECS公网IP的A记录改成指向SLB实例的公网IP。DNS生效前先在本地电脑上改hosts做验证确认解析到SLB后访问正常再推广到现网。5.3 三个配置避坑健康检查误判、会话保持过期、权重分配失效这份资源里SLB部分的坑最值得单独写出来。第一个坑是健康检查误判。现象是某台ECS明明服务正常却频繁被SLB标记为异常并摘除流量把问题定位到健康检查配置才发现检查路径指向的接口返回了302重定向而SLB只认2xx和3xx之外的状态码为异常。解决方法是把健康检查路径指向一个只返回200的专用接口不要指向带登录跳转的业务页面。第二个坑是会话保持过期。现象是用户隔一段时间就莫名其妙退出登录重新登录后过一会儿又掉。原因是SLB的会话保持超时时间设置得比应用自身的Session过期时间短导致用户在应用Session还没失效时负载均衡已经把同一用户的请求分发到了另一台后端ECS。解决方法是把SLB的会话保持超时设置为后端Session有效期的2到3倍或者在后端引入Redis共享Session存储让多台ECS之间无状态地切换。第三个坑是权重分配失效。现象是新增的ECS已经配好权重但观察流量始终打不到新机器。原因多半是新ECS没有加进后端服务器组对应的监听端口里或者安全组没有放行SLB的健康检查来源IP。解决方法是逐个检查三层配置安全组放行、后端端口监听、负载均衡后端组状态三层都通流量才会过来。6. 切换上线与回滚兜底内网拨测、DNS切换、旧环境保留6.1 切换前的完整检查清单所有迁移工作做完真正上线前要过的清单长这样检查项操作通过标准OSS资源完整性对比统计上传前后文件总数和总大小完全一致OSS回源兜底随机抽几个旧URL确认OSS访问正常全部200RDS数据一致性行数和最新时间戳对比完全一致RDS增量延迟查看同步链路延迟监控秒级内ECS应用服务逐个访问服务端口确认监听全部正常SLB健康检查观察后端服务器状态显示正常域名TTL把DNS解析记录的TTL临时调小60秒左右提前调小TTL是上线阶段的关键操作。原方案里域名解析一条正常配置生产切换时如果还保留默认TTLDNS缓存可能需要几小时甚至一天才会全部刷新到新地址。我把TTL在切换前48小时调到60秒等切换完成确认运行稳定后再调回默认值。这样做相当于给自己留了一粒后悔药回滚时不用干等DNS缓存过期。6.2 内网拨测和正式切换正式切换前不要直接去改DNS先做内网拨测。在ECS上模拟请求访问SLB带上线上域名确认完整链路是通的curl -H Host: www.example.com http://10.0.x.x/healthz-H指定Host头让SLB按域名路由到正确的监听器。10.0.x.x是SLB实例的内网IP地址。这一步能验证内网链路、监听转发和后端健康检查整套逻辑同时不产生任何线上影响。如果返回200说明链路没问题如果超时或返回502就逐段排查ECS安全组、SLB监听和后端服务状态。内网拨测通过后再操作域名解析把A记录从ECS的公网IP切换到SLB的公网IP。DNS切换之后再跑一遍同样的curl命令这次把地址改成SLB的公网IP确认域名解析的最终访问路径是通的。6.3 回滚与灰度验证切换完成不代表马上销毁旧环境。我的习惯是把旧的ECS保留至少一个星期RDS源库保留只读快照OSS回源兜底规则也继续保留。一旦线上发现异常回滚路径是从DNS层面把A记录改回旧ECS的IP旧环境还能正常服务整个过程控制在分钟级。从那以后我每次做迁移都强制把回滚方案写在切换之前宁可回滚手段用不上也不能出问题时手忙脚乱。这套SLB、ECS、OSS、RDS的迁移流程完整走一遍大概需要两三个工作日大头时间都花在数据校验和健康检查上真正操作命令反而很快。希望这份整理好的迁移手记能帮到你对照着做少交点学费。本文还有配套的精品资源点击获取