简介围绕阿里云核心云产品这份docx系统梳理SLB负载均衡、ECS云服务器、OSS对象存储与RDS关系型数据库的基础概念及协同应用并重点落到系统数据迁移场景。内容按服务模块展开涵盖OSS的Bucket与Object、存储类型、上传下载及管理方式RDS的实例、数据库、账户权限、备份恢复与迁移功能SLB的监听器、后端服务器、会话保持、健康检查及产品架构与高可用方案。目录清晰适合刚接触阿里云或需要规划数据迁移的运维与开发人员作为入门速查手册。资源包内含1个docx文档体积约1.78MB虽以文字讲解为主但结构完整、层级分明方便按章节查阅。该资源已有776人学习下载能够为读者提供从单服务理解到组合架构设计的参考路径是一份实用的云资源与迁移学习资料。1. 阿里云SLB-ECS-OSS-RDS这套组合到底是给什么系统准备的如果你手里的业务系统还是老式单机部署——一台服务器既跑Web服务、又存数据库文件、静态图片也堆在本地磁盘——那么阿里云SLB-ECS-OSS-RDS这套组合就是把这套老架构拆成四个能独立伸缩的层ECS负责计算、SLB负责入口流量分发、RDS负责关系型数据、OSS负责静态文件和备份。最典型的场景是存量系统上云原来部署在自建机房或旧云主机上的应用要迁到阿里云并顺手把架构捋直。做这件事的人通常是一个运维或全栈开发手里捏着一个能跑但不敢乱动的老系统目标不是重写而是平移顺便把单点隐患拔掉。这套方案真正解决的问题有三个第一把数据库从应用服务器里拆出来避免磁盘写满或数据库进程占用过高CPU时整个Web服务跟着躺平第二把用户上传的图片、导出文件、日志这类对象数据从ECS本地盘挪到OSS让ECS可以随时销毁重建而不丢数据第三用SLB在前面顶着后续扩容只需往后端组里加ECS不用改DNS。适合的人群是系统还在用MySQL或PostgreSQL、有大量静态资源需要存储、对可用性有要求但不想直接上K8s的中小型团队。2. 迁移前把资源规格定明白SLB、ECS、OSS、RDS的选型与账单口径2.1 四个产品在迁移里各自承担的角色边界讲落地之前先把四个服务的职责边界划清楚否则后面操作时会反复纠结“这个东西到底该放哪”。ECS是计算节点跑你的应用进程。Spring Boot、Nginx、PHP-FPM、Python的Gunicorn这些有状态的进程跑在ECS上。注意这里说的是“有状态”是加了引号的——严格讲ECS本身应该尽量无状态你的代码包要从构建机拉日志要往外送本地盘只放临时文件。但现实中存量系统迁移往往做不到这么干净所以第一步先做到“应用代码和数据文件分离”。SLB是流量入口它不跑业务逻辑只做四层或七层的转发。SLB把用户的请求按权重分发给后端的ECS同时做健康检查——后端ECS的端口如果不响应SLB会自动把它摘掉不往这个节点转发新请求。对用户来说访问的还是SLB那个固定IP或域名后端换机器、加机器用户无感知。RDS是托管数据库MySQL、PostgreSQL、SQL Server都有。你不需要自己装数据库软件、不用自己做主从复制、不用操心半夜磁盘满没满。迁移时把你的数据导入RDS实例应用侧把数据库连接地址改成RDS的内网域名即可。RDS自动做每天备份还能一键恢复到某个时间点。OSS是对象存储存的是“文件”图片、附件、音视频、冷备数据、数据库备份文件。OSS的特点是无限容量、按量计费、自带CDN回源配合。跟ECS本地盘最大的区别是ECS销毁或重置系统OSS里的数据纹丝不动。2.2 规格怎么定先看QPS、再看存储量、最后看备份策略规格选型容易犯的错是“按CPU核数拍脑袋”。我一般按这个顺序推算第一步数清楚最大并发。打开现有Nginx的access.log统计高峰时段每分钟请求数乘以单请求平均耗时得到需要一个ECS扛多少QPS。一个2核4G的ECS跑一个优化过的Spring Boot或Go服务大概能扛300~800 QPS具体取决于业务逻辑是查缓存还是查库。如果你现在的日志显示高峰只有几十QPS那2核4G起步足够了不用一上来就买8核16G。第二步算数据库规格。RDS的性能瓶颈通常在连接数和IOPS。先看现有数据库的“最大连接数”配置再看慢查询数量。如果现在MySQL的max_connections是200日常使用率已经到70%那买RDS时选择连接数不低于旧配置的规格。RDS的规格列表里每个档位都会标注最大连接数和IOPS上限照着旧库的监控数据配对就行。第三步决定OSS的存储类型。存量图片、日志、备份选“低频访问”即可单价便宜一半只是读取时要收一点点数据取回费用。如果业务是用户高频访问图片才选“标准存储”。这一步能省不少钱尤其是历史图片几年才翻一次的场景。SLB的规格唯一要关注的是“按固定带宽还是按流量计费”。如果业务流量平稳选按带宽流量有明显的波峰波谷就选按使用流量峰值时段多付一点闲时少付。实例创建后监听、后端权重、健康检查这些都可以随时调整所以规格选错的后悔药很多不用太紧张。2.3 购买前的资源配置清单购买之前先列一张表相当于迁移项目的物料清单。这是我从几个项目里总结的通用模板照着填空即可资源规格参考数量说明ECS2核4G / 40G ESSD2台应用节点先买两台组成SLB后端组SLB按流量计费1个七层HTTP监听后续升级HTTPSRDSMySQL 8.0 / 2核4G / 100G1个主实例不开只读OSS Bucket标准 低频两个Bucket2个一个放热数据一个放冷备安全组放行80、443、221组ECS和RDS共用时要按IP白名单收敛注意一个容易漏掉的东西域名和SSL证书。如果业务是HTTPS访问SLB上要挂证书。阿里云有免费证书可以申请有效期三个月到期需要手动续期——这件事我会在避坑章节展开因为它是个经典翻车点。3. ECS与SLB先行落地把计算节点和流量入口从旧机房搬上阿里云3.1 两种上云姿势自定义镜像迁移 vs 新装系统重部署老系统迁移到ECS通常从二选一开始到底是把旧服务器做成镜像直接导入还是在新ECS上重新部署一遍环境我的建议是如果旧服务器是CentOS 7或Ubuntu 18.04这类主流系统、且应用是通过systemd或supervisor管理的优先做自定义镜像迁移。具体做法是把旧服务器的数据盘和系统盘分别打包通过阿里云“导入镜像”功能上传到OSS再基于这个镜像创建ECS。好处是应用运行环境、JDK版本、环境变量、Nginx配置全部原样带过去不用重新踩一遍环境配置的坑。缺点是镜像里可能带着旧机器特有的驱动和垃圾文件ECS启动后需要清理。如果旧服务器系统太老、PHP版本过低、或者应用依赖的环境已经乱成一锅粥那就老老实实新装系统重部署。虽然累一点但环境干净后续维护省心。判断标准很简单旧服务器的装机文档还在不在。在的话重部署不在的话镜像迁移后慢慢清理。3.2 后端ECS的基本初始化系统参数、JDK/Maven源、部署目录新ECS开机后第一件事不是装应用而是把系统参数调成适合跑业务的样子。以下是我每次都会执行的一组命令# 关闭防火墙的SELinux避免Nginx和Java进程出现诡异权限问题 setenforce 0 sed -i s/^SELINUXenforcing/SELINUXdisabled/ /etc/selinux/config # 调整文件描述符上限Java应用和Nginx高并发下默认1024不够用 echo * soft nofile 655350 * hard nofile 655350 /etc/security/limits.d/90-nofile.conf ulimit -n 655350 # 设置时区并同步时间日志排查和定时任务都依赖它 timedatectl set-timezone Asia/Shanghai yum install -y ntpdate ntpdate ntp.aliyun.com # 配置阿里云yum镜像源安装依赖会快很多 mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bak curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo yum clean all yum makecache # 安装基础工具链 yum install -y vim wget lrzsz net-tools telnet这段命令的逻辑分为四层第一层关SELinux因为SELinux开启状态下Nginx反向代理到Java进程的回环连接可能被拦截报错表现又极难排查第二层调文件描述符Java的Netty或Tomcat在连接数超过1024后会出现“Too many open files”这个错在旧服务器上多半也遇到过第三层统一时区和时间数据库迁移和日志时间戳比对都需要两端时钟一致第四层换阿里云镜像源后续yum install的速度差一个量级。如果是Java项目还要顺带配置Maven的阿里云仓库镜像。在~/.m2/settings.xml里加上mirror节点否则从中央仓库拉依赖在高峰期能卡到你怀疑网络mirror idaliyunmaven/id mirrorOfcentral/mirrorOf name阿里云公共仓库/name urlhttps://maven.aliyun.com/repository/public/url /mirror这里有个细节阿里云Maven仓库有多个public是聚合仓库包含central和jcenter的代理日常用它就够了。如果项目里用到spring-cloud-alibaba的早期版本还要加一个https://maven.aliyun.com/repository/spring的镜像否则某些旧版本依赖会拉不到。3.3 配置SLB监听与后端服务器组监听协议、权重、会话保持ECS准备好两台之后开始配置SLB。在控制台购买SLB实例时地域要跟ECS一致这样后端流量走内网不额外产生公网流量费。实例创建完成后进入“监听”页面添加监听这里有几个参数必须说清楚第一是监听协议。业务是HTTP请求就选“HTTP”不要选“TCP”除非你明确知道自己在做什么。选HTTP的好处是SLB能识别URL路径可以做按路径转发也能拿到客户端真实IP放进X-Forwarded-For头。选TCP的话SLB只是透传端口后端的Nginx日志里看到的客户端IP全变成SLB的内网IP排查问题时会很头疼。第二是后端服务器组。把两台ECS加入后端组端口填应用实际监听端口比如Java应用是8080Nginx是80。权重默认100就行两台权重一致就是各分一半流量。如果你想让某一台先验证新版本把它的权重临时调成10另一台保持100就能实现灰度引流。第三是健康检查。SLB默认的健康检查路径是根路径/如果应用的根路径返回404或直接连接拒绝SLB就判定节点不健康把所有流量都打到另一台上。如果你的应用根路径没有内容要在健康检查配置里改成一个真实存在的接口路径比如/health后端应用也要实现这个接口并返回200。第四是会话保持。如果业务登录态是存在Session里的、没有用Redis共享那必须开启“会话保持”并设置超时时间。否则用户第一次请求打到A机器登录成功刷新页面时被SLB转发到B机器Session不存在用户被强制重新登录。这个开关在SLB的监听配置里默认是关闭的忘记开的话迁移上线当天就会接到大量投诉。4. OSS与RDS落地数据迁移是这一步的重头戏4.1 RDS用mysqldump迁移MySQL数据参数怎么给RDS实例创建好之后会拿到一个内网域名和端口默认端口MySQL是3306。接下来要做的是把旧数据库的数据导入RDS。这里我不推荐在旧服务器上直接用mysqldump导完再上传常见做法是先在RDS控制台建好目标数据库和账号然后用一条命令从旧库直接导到RDS。先确认两边的MySQL版本。如果旧库是5.7、RDS是8.0语法兼容性问题不多但MySQL 8.0默认的认证插件是caching_sha2_password旧版本的应用驱动可能连不上——这个踩坑细节我在下一章展开。以下是迁移命令# 在旧服务器上执行将全库导出并通过管道直接导入RDS mysqldump -h旧库IP -uroot -p旧密码 \ --single-transaction --set-gtid-purgedOFF \ --default-character-setutf8mb4 \ --databases business_db order_db | \ mysql -hRDS内网域名 -uroot -pRDS密码 \ --default-character-setutf8mb4参数说明--single-transaction是InnoDB表导出时开启一个一致快照不影响线上业务写入--set-gtid-purgedOFF是MySQL 5.6及以上才有的参数如果不加导出文件里会带上GTID信息导入RDS时会报“GTID_PURGED can only be set when GTID_EXECUTED is empty”之类的错误--default-character-setutf8mb4必须两边都指定否则遇到emoji或生僻字会转成乱码。执行完这条管道注意看终端最后有没有输出“completed”字样。另外强烈建议导入完成后在RDS上执行一遍表行数比对-- 在RDS上执行与旧库的count结果逐表比对 SELECT table_name, table_rows FROM information_schema.tables WHERE table_schemabusiness_db ORDER BY table_name;table_rows是估算值但数量级对不上时能立刻暴露漏表或中断的问题。精确比对的方法是用COUNT(*)抽样几张核心表不用全量。4.2 OSS用ossutil把存量静态文件迁到Bucket并修正访问域名数据迁移的另一半是静态文件。旧系统里用户上传的图片、附件、导出报表通常散落在ECS的/data目录、FTP服务器、甚至NFS挂载盘里。OSS迁移我用的是阿里云官方命令行工具ossutil因为它支持增量同步和断点续传针对动辄几十GB的附件目录很稳。安装和迁移命令如下在旧服务器上执行# 下载并配置ossutilAK/SK在阿里云控制台RAM子账号里生成 curl -o ossutil https://gosspublic.alicdn.com/ossutil/1.7.19/ossutil-v1.7.19-linux-amd64.zip unzip ossutil cd ossutil-v1.7.19-linux-amd64 ./ossutil config -e oss-cn-beijing.aliyuncs.com -i LTAI**** -k yourSecretKey # 把本地/data/upload目录全量同步到OSS的hot-bucket/upload路径下 ./ossutil cp -r -f /data/upload oss://hot-bucket/upload/ \ --parallel 8 --part-size 20MB --update --delete参数含义--parallel 8表示同时开8个线程并发上传带宽够的话可以调高到16--part-size 20MB是分片大小超过这个阈值的文件会自动分片上传支持失败后断点续传--update是只上传本地比OSS更新的文件跑第二遍时就是纯增量--delete是把OSS里有但本地已删除的文件同步删掉保证两边完全一致。这三个参数组合起来相当于给迁移做了一个“可重复执行的同步脚本”第一次全量之后每次跑都是增量。如果你的存量文件在MinIO或其他S3兼容存储里ossutil也支持直接对接写法是先把MinIO的桶通过s3协议的Endpoint配置成第三方源再执行同样的cp命令。这个场景在存量项目里非常常见公司内部早就用MinIO做了统一存储上云时把MinIO桶里的对象搬迁到OSS文件不用经手本地磁盘直接服务端中转。4.3 应用侧切换配置文件里的地址从旧服务改成云上的Endpoint数据进了RDS、文件进了OSS最后一步是把应用配置改过来。这一步没有统一命令因为每个应用的配置方式不一样但有一个共同原则把配置项集中管理避免散落在代码里。对于Java Spring Boot项目常见做法是在application.properties里改如下内容# 数据库连接指向RDS的内网域名 spring.datasource.urljdbc:mysql://rm-xxxxx.mysql.rds.aliyuncs.com:3306/business_db?useUnicodetruecharacterEncodingutf8mb4useSSLfalse spring.datasource.usernamemigration_user spring.datasource.passwordnewpassword # 文件访问路径改为OSS的Bucket公共读URL app.upload.urlhttps://hot-bucket.oss-cn-beijing.aliyuncs.com/upload/ app.upload.endpointoss-cn-beijing.aliyuncs.com app.upload.access-key-idLTAI**** app.upload.access-key-secretyourSecretKey改完配置后还要检查应用代码里是否有类似File file new File(/data/upload/ filename)这种直接写本地磁盘的代码。如果存在必须改成把文件写入OSS常见做法是引入aliyun-oss-sdk用OSSClient的putObject方法替换本地文件写入。这一步是最容易被忽略的——很多人以为“文件路径改个URL就行”结果应用启动正常、列表页正常但新上传的文件直接写到ECS本地盘过了几天ECS磁盘满了才发现问题。5. 迁移避坑从丢数据和流量中断里总结的排查清单5.1 现象SLB健康检查显示“后端异常”但ECS上的服务明明在跑迁移上线当天最常撞见的诡异问题SLB实例的健康检查一直报红色后端ECS显示“异常”但登录ECS用curl访问本地端口却一切正常。原因出在安全组上。SLB的健康检查请求来自阿里云内部的探测IP段并不走公网。如果ECS安全组的入方向规则只放行了源IP为“0.0.0.0/0”的80端口而没有放行SLB所在VPC的网段或SLB的健康检查IP探测包就会被安全组拦截。于是出现“本机访问通、外网访问不通、SLB判定异常”的经典三体不一致。解决方法是到ECS所属安全组里为SLB监听端口增加一条来源为SLB所在VPC的网段放行规则。更简单的做法在控制台的SLB实例详情页找到“健康检查”的探测源IP段把这个IP段加到安全组规则里。排查路径不复杂但第一次遇到时很容易被“服务明明在跑”带偏方向。5.2 现象RDS数据迁移后业务报“字段超长”或“字符集乱码”数据导入RDS完成后应用启动正常但用户提交表单时报Data too long for column或者历史数据里中文全部变成乱码。原因有两个分别对应两个现象。字段超长是因为旧库的字符集是utf8mb3即常规的utf8单字符最大3字节而RDS新建库的默认字符集如果是utf8mb44字节字符能存但某些字段长度定义比如VARCHAR(200)在utf8mb4下实际能存的字数变少字段定义没变的场景下就可能报超长。解决是在建库时明确指定字符集并且在mysqldump导出时指定--default-character-setutf8mb4导入后逐字段检查超长数据把VARCHAR长度要么调大、要么改成TEXT。乱码的原因更隐蔽旧库的实际字符集虽然是utf8但客户端连接的字符集设置是latin1历史数据在写入时就已经被错误转码存成了双重编码。这类“历史遗留脏数据”在迁移中不能靠参数解决只能写脚本清洗。我的经验是迁移前先导出几条典型中文记录用hex()函数看字节判断是哪种编码再决定清洗方案不要盲目把全库的字符集设置改掉。5.3 现象OSS文件上传后访问404但Bucket列表里能看到对象文件确实传上去了控制台能看到对象但通过URL访问时返回404。这个问题的核心是Bucket权限设置和跨域规则。如果Bucket是“私有”权限URL必须带签名才能访问如果应用代码里没有对URL做签名拼接那肯定404。解决方法是如果这些静态文件是公开访问的把Bucket权限改为“公共读”如果某些文件涉及用户隐私必须私有则不能改权限需要应用代码用SDK生成带有效期的签名URL。另一个新手坑是Bucket所属地域和Endpoint不一致。OSS的访问域名格式是bucketname.oss-cn-beijing.aliyuncs.com如果你在控制台复制的是oss-cn-hangzhou的Endpoint访问时也会失败。这个错看起来低级但在切换配置的高压状态下非常容易发生。5.4 现象迁移当晚访问高峰SLB把请求打到尚未就绪的节点SLB的健康检查通过了但用户反馈一部分请求超时。这个现象往往出现在更新应用代码或重启ECS之后。原因在于ECS的“就绪”标准和SLB的“健康”标准不是一回事。健康检查只探测端口是否响应但JVM可能还在加载类、连接池可能还没建立完成的阶段端口虽然监听了但请求在应用层排队超时。SLB按权重把流量打过来这部分请求就直接掉进黑洞。解决方法是不要用SLB默认的“检查间隔2秒、超时3秒、不健康阈值3次”参数跑生产。把检查间隔调到5秒、超时时间调到5秒、不健康阈值调到5次并且把健康检查的URL指向一个真正能做“依赖检查”的接口比如这个接口里轮询一次数据库连接池是否就绪。这样SLB的判定才跟业务真实可用状态对齐。5.5 现象SSL证书续期后网站打不开证书过期没人记得迁移到SLB之后证书卸载工作从ECS转移到了SLB这件事有利有弊。好处是后端ECS的Nginx不用再配置证书坏处是证书到期前一个月阿里云会发短信提醒但如果你用的是一个三个月有效期的免费证书到期日正好赶在项目忙碌期很容易忽略。解决方法是把证书续期这件事做成自动化或半自动化。常见做法是设置一个每月1号的定时任务用脚本调阿里云API检查证书列表如果发现剩余天数少于30天就推送到钉钉或企业微信机器人。SSL证书续期本身在阿里云控制台点几次就能完成但“没人记得去点”才是真正的坑。6. 迁移后的验证技巧用拨测与回退方案把上线风险压到最低迁移完成不代表上线完成我一般会在切换DNS或修改SLB指向后用一套固定的验证流程过一遍耗时约一小时但能拦下90%以上的低级失误。第一类验证是连通性。登录一台不在阿里云VPC内的机器用curl带-H Host: 业务域名访问SLB的公网IP确认HTTP状态码是200、响应时间在预期范围内。这一步验证的是SLB转发链路是否完整不受DNS缓存影响。第二类验证是数据完整性。在RDS上抽查三张核心表执行行数COUNT比对在OSS上随机下载一个文件比对MD5值确认存储链路和文件内容都没问题。第三类验证是业务链路。模拟一次完整的用户操作注册或登录、上传一张图片、触发一次数据库写入、再读取这条记录。注意看应用日志里是否出现连接RDS或OSS的报错。第四类验证是回退演练。把SLB的监听停掉把流量切回旧服务器的入口确认业务恢复。这不是真要做回退而是确认回退路径是通的。没有回退路径的迁移是一场赌博一旦线上出问题你只能一边在监控台里挠头一边被业务方盯着。关于回退路径有两个年份要记住RDS的备份RDS已经自动做了OSS数据有版本管理可以开但ECS上的代码版本要自己在发布记录里留一份。我现在的习惯是每次迁移改动的配置文件都拷贝一份带日期后缀的副本放在ECS的/tmp目录下回退时直接复制回去就行。这个习惯帮我处理过不止一次上线后的突发状况。最后还要提一句SSL证书。如果你在SLB上挂了证书验证阶段务必用openssl s_client -connect 域名:443看一眼证书剩余有效期并确认证书链完整。阿里云免费证书三个月过期一次建议同时在日历上建一个提前两周的提醒。这套验证流程做完整个迁移才算真正落了地。从单机到SLB-ECS-OSS-RDS的组合改变的不仅是部署位置更是遇到故障时还能不能睡个安稳觉——希望帮到你。本文还有配套的精品资源点击获取 用SLB-ECS-OSS-RDS四件套完成存量系统上云：迁移步骤、选型与避坑全解析
简介围绕阿里云核心云产品这份docx系统梳理SLB负载均衡、ECS云服务器、OSS对象存储与RDS关系型数据库的基础概念及协同应用并重点落到系统数据迁移场景。内容按服务模块展开涵盖OSS的Bucket与Object、存储类型、上传下载及管理方式RDS的实例、数据库、账户权限、备份恢复与迁移功能SLB的监听器、后端服务器、会话保持、健康检查及产品架构与高可用方案。目录清晰适合刚接触阿里云或需要规划数据迁移的运维与开发人员作为入门速查手册。资源包内含1个docx文档体积约1.78MB虽以文字讲解为主但结构完整、层级分明方便按章节查阅。该资源已有776人学习下载能够为读者提供从单服务理解到组合架构设计的参考路径是一份实用的云资源与迁移学习资料。1. 阿里云SLB-ECS-OSS-RDS这套组合到底是给什么系统准备的如果你手里的业务系统还是老式单机部署——一台服务器既跑Web服务、又存数据库文件、静态图片也堆在本地磁盘——那么阿里云SLB-ECS-OSS-RDS这套组合就是把这套老架构拆成四个能独立伸缩的层ECS负责计算、SLB负责入口流量分发、RDS负责关系型数据、OSS负责静态文件和备份。最典型的场景是存量系统上云原来部署在自建机房或旧云主机上的应用要迁到阿里云并顺手把架构捋直。做这件事的人通常是一个运维或全栈开发手里捏着一个能跑但不敢乱动的老系统目标不是重写而是平移顺便把单点隐患拔掉。这套方案真正解决的问题有三个第一把数据库从应用服务器里拆出来避免磁盘写满或数据库进程占用过高CPU时整个Web服务跟着躺平第二把用户上传的图片、导出文件、日志这类对象数据从ECS本地盘挪到OSS让ECS可以随时销毁重建而不丢数据第三用SLB在前面顶着后续扩容只需往后端组里加ECS不用改DNS。适合的人群是系统还在用MySQL或PostgreSQL、有大量静态资源需要存储、对可用性有要求但不想直接上K8s的中小型团队。2. 迁移前把资源规格定明白SLB、ECS、OSS、RDS的选型与账单口径2.1 四个产品在迁移里各自承担的角色边界讲落地之前先把四个服务的职责边界划清楚否则后面操作时会反复纠结“这个东西到底该放哪”。ECS是计算节点跑你的应用进程。Spring Boot、Nginx、PHP-FPM、Python的Gunicorn这些有状态的进程跑在ECS上。注意这里说的是“有状态”是加了引号的——严格讲ECS本身应该尽量无状态你的代码包要从构建机拉日志要往外送本地盘只放临时文件。但现实中存量系统迁移往往做不到这么干净所以第一步先做到“应用代码和数据文件分离”。SLB是流量入口它不跑业务逻辑只做四层或七层的转发。SLB把用户的请求按权重分发给后端的ECS同时做健康检查——后端ECS的端口如果不响应SLB会自动把它摘掉不往这个节点转发新请求。对用户来说访问的还是SLB那个固定IP或域名后端换机器、加机器用户无感知。RDS是托管数据库MySQL、PostgreSQL、SQL Server都有。你不需要自己装数据库软件、不用自己做主从复制、不用操心半夜磁盘满没满。迁移时把你的数据导入RDS实例应用侧把数据库连接地址改成RDS的内网域名即可。RDS自动做每天备份还能一键恢复到某个时间点。OSS是对象存储存的是“文件”图片、附件、音视频、冷备数据、数据库备份文件。OSS的特点是无限容量、按量计费、自带CDN回源配合。跟ECS本地盘最大的区别是ECS销毁或重置系统OSS里的数据纹丝不动。2.2 规格怎么定先看QPS、再看存储量、最后看备份策略规格选型容易犯的错是“按CPU核数拍脑袋”。我一般按这个顺序推算第一步数清楚最大并发。打开现有Nginx的access.log统计高峰时段每分钟请求数乘以单请求平均耗时得到需要一个ECS扛多少QPS。一个2核4G的ECS跑一个优化过的Spring Boot或Go服务大概能扛300~800 QPS具体取决于业务逻辑是查缓存还是查库。如果你现在的日志显示高峰只有几十QPS那2核4G起步足够了不用一上来就买8核16G。第二步算数据库规格。RDS的性能瓶颈通常在连接数和IOPS。先看现有数据库的“最大连接数”配置再看慢查询数量。如果现在MySQL的max_connections是200日常使用率已经到70%那买RDS时选择连接数不低于旧配置的规格。RDS的规格列表里每个档位都会标注最大连接数和IOPS上限照着旧库的监控数据配对就行。第三步决定OSS的存储类型。存量图片、日志、备份选“低频访问”即可单价便宜一半只是读取时要收一点点数据取回费用。如果业务是用户高频访问图片才选“标准存储”。这一步能省不少钱尤其是历史图片几年才翻一次的场景。SLB的规格唯一要关注的是“按固定带宽还是按流量计费”。如果业务流量平稳选按带宽流量有明显的波峰波谷就选按使用流量峰值时段多付一点闲时少付。实例创建后监听、后端权重、健康检查这些都可以随时调整所以规格选错的后悔药很多不用太紧张。2.3 购买前的资源配置清单购买之前先列一张表相当于迁移项目的物料清单。这是我从几个项目里总结的通用模板照着填空即可资源规格参考数量说明ECS2核4G / 40G ESSD2台应用节点先买两台组成SLB后端组SLB按流量计费1个七层HTTP监听后续升级HTTPSRDSMySQL 8.0 / 2核4G / 100G1个主实例不开只读OSS Bucket标准 低频两个Bucket2个一个放热数据一个放冷备安全组放行80、443、221组ECS和RDS共用时要按IP白名单收敛注意一个容易漏掉的东西域名和SSL证书。如果业务是HTTPS访问SLB上要挂证书。阿里云有免费证书可以申请有效期三个月到期需要手动续期——这件事我会在避坑章节展开因为它是个经典翻车点。3. ECS与SLB先行落地把计算节点和流量入口从旧机房搬上阿里云3.1 两种上云姿势自定义镜像迁移 vs 新装系统重部署老系统迁移到ECS通常从二选一开始到底是把旧服务器做成镜像直接导入还是在新ECS上重新部署一遍环境我的建议是如果旧服务器是CentOS 7或Ubuntu 18.04这类主流系统、且应用是通过systemd或supervisor管理的优先做自定义镜像迁移。具体做法是把旧服务器的数据盘和系统盘分别打包通过阿里云“导入镜像”功能上传到OSS再基于这个镜像创建ECS。好处是应用运行环境、JDK版本、环境变量、Nginx配置全部原样带过去不用重新踩一遍环境配置的坑。缺点是镜像里可能带着旧机器特有的驱动和垃圾文件ECS启动后需要清理。如果旧服务器系统太老、PHP版本过低、或者应用依赖的环境已经乱成一锅粥那就老老实实新装系统重部署。虽然累一点但环境干净后续维护省心。判断标准很简单旧服务器的装机文档还在不在。在的话重部署不在的话镜像迁移后慢慢清理。3.2 后端ECS的基本初始化系统参数、JDK/Maven源、部署目录新ECS开机后第一件事不是装应用而是把系统参数调成适合跑业务的样子。以下是我每次都会执行的一组命令# 关闭防火墙的SELinux避免Nginx和Java进程出现诡异权限问题 setenforce 0 sed -i s/^SELINUXenforcing/SELINUXdisabled/ /etc/selinux/config # 调整文件描述符上限Java应用和Nginx高并发下默认1024不够用 echo * soft nofile 655350 * hard nofile 655350 /etc/security/limits.d/90-nofile.conf ulimit -n 655350 # 设置时区并同步时间日志排查和定时任务都依赖它 timedatectl set-timezone Asia/Shanghai yum install -y ntpdate ntpdate ntp.aliyun.com # 配置阿里云yum镜像源安装依赖会快很多 mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bak curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo yum clean all yum makecache # 安装基础工具链 yum install -y vim wget lrzsz net-tools telnet这段命令的逻辑分为四层第一层关SELinux因为SELinux开启状态下Nginx反向代理到Java进程的回环连接可能被拦截报错表现又极难排查第二层调文件描述符Java的Netty或Tomcat在连接数超过1024后会出现“Too many open files”这个错在旧服务器上多半也遇到过第三层统一时区和时间数据库迁移和日志时间戳比对都需要两端时钟一致第四层换阿里云镜像源后续yum install的速度差一个量级。如果是Java项目还要顺带配置Maven的阿里云仓库镜像。在~/.m2/settings.xml里加上mirror节点否则从中央仓库拉依赖在高峰期能卡到你怀疑网络mirror idaliyunmaven/id mirrorOfcentral/mirrorOf name阿里云公共仓库/name urlhttps://maven.aliyun.com/repository/public/url /mirror这里有个细节阿里云Maven仓库有多个public是聚合仓库包含central和jcenter的代理日常用它就够了。如果项目里用到spring-cloud-alibaba的早期版本还要加一个https://maven.aliyun.com/repository/spring的镜像否则某些旧版本依赖会拉不到。3.3 配置SLB监听与后端服务器组监听协议、权重、会话保持ECS准备好两台之后开始配置SLB。在控制台购买SLB实例时地域要跟ECS一致这样后端流量走内网不额外产生公网流量费。实例创建完成后进入“监听”页面添加监听这里有几个参数必须说清楚第一是监听协议。业务是HTTP请求就选“HTTP”不要选“TCP”除非你明确知道自己在做什么。选HTTP的好处是SLB能识别URL路径可以做按路径转发也能拿到客户端真实IP放进X-Forwarded-For头。选TCP的话SLB只是透传端口后端的Nginx日志里看到的客户端IP全变成SLB的内网IP排查问题时会很头疼。第二是后端服务器组。把两台ECS加入后端组端口填应用实际监听端口比如Java应用是8080Nginx是80。权重默认100就行两台权重一致就是各分一半流量。如果你想让某一台先验证新版本把它的权重临时调成10另一台保持100就能实现灰度引流。第三是健康检查。SLB默认的健康检查路径是根路径/如果应用的根路径返回404或直接连接拒绝SLB就判定节点不健康把所有流量都打到另一台上。如果你的应用根路径没有内容要在健康检查配置里改成一个真实存在的接口路径比如/health后端应用也要实现这个接口并返回200。第四是会话保持。如果业务登录态是存在Session里的、没有用Redis共享那必须开启“会话保持”并设置超时时间。否则用户第一次请求打到A机器登录成功刷新页面时被SLB转发到B机器Session不存在用户被强制重新登录。这个开关在SLB的监听配置里默认是关闭的忘记开的话迁移上线当天就会接到大量投诉。4. OSS与RDS落地数据迁移是这一步的重头戏4.1 RDS用mysqldump迁移MySQL数据参数怎么给RDS实例创建好之后会拿到一个内网域名和端口默认端口MySQL是3306。接下来要做的是把旧数据库的数据导入RDS。这里我不推荐在旧服务器上直接用mysqldump导完再上传常见做法是先在RDS控制台建好目标数据库和账号然后用一条命令从旧库直接导到RDS。先确认两边的MySQL版本。如果旧库是5.7、RDS是8.0语法兼容性问题不多但MySQL 8.0默认的认证插件是caching_sha2_password旧版本的应用驱动可能连不上——这个踩坑细节我在下一章展开。以下是迁移命令# 在旧服务器上执行将全库导出并通过管道直接导入RDS mysqldump -h旧库IP -uroot -p旧密码 \ --single-transaction --set-gtid-purgedOFF \ --default-character-setutf8mb4 \ --databases business_db order_db | \ mysql -hRDS内网域名 -uroot -pRDS密码 \ --default-character-setutf8mb4参数说明--single-transaction是InnoDB表导出时开启一个一致快照不影响线上业务写入--set-gtid-purgedOFF是MySQL 5.6及以上才有的参数如果不加导出文件里会带上GTID信息导入RDS时会报“GTID_PURGED can only be set when GTID_EXECUTED is empty”之类的错误--default-character-setutf8mb4必须两边都指定否则遇到emoji或生僻字会转成乱码。执行完这条管道注意看终端最后有没有输出“completed”字样。另外强烈建议导入完成后在RDS上执行一遍表行数比对-- 在RDS上执行与旧库的count结果逐表比对 SELECT table_name, table_rows FROM information_schema.tables WHERE table_schemabusiness_db ORDER BY table_name;table_rows是估算值但数量级对不上时能立刻暴露漏表或中断的问题。精确比对的方法是用COUNT(*)抽样几张核心表不用全量。4.2 OSS用ossutil把存量静态文件迁到Bucket并修正访问域名数据迁移的另一半是静态文件。旧系统里用户上传的图片、附件、导出报表通常散落在ECS的/data目录、FTP服务器、甚至NFS挂载盘里。OSS迁移我用的是阿里云官方命令行工具ossutil因为它支持增量同步和断点续传针对动辄几十GB的附件目录很稳。安装和迁移命令如下在旧服务器上执行# 下载并配置ossutilAK/SK在阿里云控制台RAM子账号里生成 curl -o ossutil https://gosspublic.alicdn.com/ossutil/1.7.19/ossutil-v1.7.19-linux-amd64.zip unzip ossutil cd ossutil-v1.7.19-linux-amd64 ./ossutil config -e oss-cn-beijing.aliyuncs.com -i LTAI**** -k yourSecretKey # 把本地/data/upload目录全量同步到OSS的hot-bucket/upload路径下 ./ossutil cp -r -f /data/upload oss://hot-bucket/upload/ \ --parallel 8 --part-size 20MB --update --delete参数含义--parallel 8表示同时开8个线程并发上传带宽够的话可以调高到16--part-size 20MB是分片大小超过这个阈值的文件会自动分片上传支持失败后断点续传--update是只上传本地比OSS更新的文件跑第二遍时就是纯增量--delete是把OSS里有但本地已删除的文件同步删掉保证两边完全一致。这三个参数组合起来相当于给迁移做了一个“可重复执行的同步脚本”第一次全量之后每次跑都是增量。如果你的存量文件在MinIO或其他S3兼容存储里ossutil也支持直接对接写法是先把MinIO的桶通过s3协议的Endpoint配置成第三方源再执行同样的cp命令。这个场景在存量项目里非常常见公司内部早就用MinIO做了统一存储上云时把MinIO桶里的对象搬迁到OSS文件不用经手本地磁盘直接服务端中转。4.3 应用侧切换配置文件里的地址从旧服务改成云上的Endpoint数据进了RDS、文件进了OSS最后一步是把应用配置改过来。这一步没有统一命令因为每个应用的配置方式不一样但有一个共同原则把配置项集中管理避免散落在代码里。对于Java Spring Boot项目常见做法是在application.properties里改如下内容# 数据库连接指向RDS的内网域名 spring.datasource.urljdbc:mysql://rm-xxxxx.mysql.rds.aliyuncs.com:3306/business_db?useUnicodetruecharacterEncodingutf8mb4useSSLfalse spring.datasource.usernamemigration_user spring.datasource.passwordnewpassword # 文件访问路径改为OSS的Bucket公共读URL app.upload.urlhttps://hot-bucket.oss-cn-beijing.aliyuncs.com/upload/ app.upload.endpointoss-cn-beijing.aliyuncs.com app.upload.access-key-idLTAI**** app.upload.access-key-secretyourSecretKey改完配置后还要检查应用代码里是否有类似File file new File(/data/upload/ filename)这种直接写本地磁盘的代码。如果存在必须改成把文件写入OSS常见做法是引入aliyun-oss-sdk用OSSClient的putObject方法替换本地文件写入。这一步是最容易被忽略的——很多人以为“文件路径改个URL就行”结果应用启动正常、列表页正常但新上传的文件直接写到ECS本地盘过了几天ECS磁盘满了才发现问题。5. 迁移避坑从丢数据和流量中断里总结的排查清单5.1 现象SLB健康检查显示“后端异常”但ECS上的服务明明在跑迁移上线当天最常撞见的诡异问题SLB实例的健康检查一直报红色后端ECS显示“异常”但登录ECS用curl访问本地端口却一切正常。原因出在安全组上。SLB的健康检查请求来自阿里云内部的探测IP段并不走公网。如果ECS安全组的入方向规则只放行了源IP为“0.0.0.0/0”的80端口而没有放行SLB所在VPC的网段或SLB的健康检查IP探测包就会被安全组拦截。于是出现“本机访问通、外网访问不通、SLB判定异常”的经典三体不一致。解决方法是到ECS所属安全组里为SLB监听端口增加一条来源为SLB所在VPC的网段放行规则。更简单的做法在控制台的SLB实例详情页找到“健康检查”的探测源IP段把这个IP段加到安全组规则里。排查路径不复杂但第一次遇到时很容易被“服务明明在跑”带偏方向。5.2 现象RDS数据迁移后业务报“字段超长”或“字符集乱码”数据导入RDS完成后应用启动正常但用户提交表单时报Data too long for column或者历史数据里中文全部变成乱码。原因有两个分别对应两个现象。字段超长是因为旧库的字符集是utf8mb3即常规的utf8单字符最大3字节而RDS新建库的默认字符集如果是utf8mb44字节字符能存但某些字段长度定义比如VARCHAR(200)在utf8mb4下实际能存的字数变少字段定义没变的场景下就可能报超长。解决是在建库时明确指定字符集并且在mysqldump导出时指定--default-character-setutf8mb4导入后逐字段检查超长数据把VARCHAR长度要么调大、要么改成TEXT。乱码的原因更隐蔽旧库的实际字符集虽然是utf8但客户端连接的字符集设置是latin1历史数据在写入时就已经被错误转码存成了双重编码。这类“历史遗留脏数据”在迁移中不能靠参数解决只能写脚本清洗。我的经验是迁移前先导出几条典型中文记录用hex()函数看字节判断是哪种编码再决定清洗方案不要盲目把全库的字符集设置改掉。5.3 现象OSS文件上传后访问404但Bucket列表里能看到对象文件确实传上去了控制台能看到对象但通过URL访问时返回404。这个问题的核心是Bucket权限设置和跨域规则。如果Bucket是“私有”权限URL必须带签名才能访问如果应用代码里没有对URL做签名拼接那肯定404。解决方法是如果这些静态文件是公开访问的把Bucket权限改为“公共读”如果某些文件涉及用户隐私必须私有则不能改权限需要应用代码用SDK生成带有效期的签名URL。另一个新手坑是Bucket所属地域和Endpoint不一致。OSS的访问域名格式是bucketname.oss-cn-beijing.aliyuncs.com如果你在控制台复制的是oss-cn-hangzhou的Endpoint访问时也会失败。这个错看起来低级但在切换配置的高压状态下非常容易发生。5.4 现象迁移当晚访问高峰SLB把请求打到尚未就绪的节点SLB的健康检查通过了但用户反馈一部分请求超时。这个现象往往出现在更新应用代码或重启ECS之后。原因在于ECS的“就绪”标准和SLB的“健康”标准不是一回事。健康检查只探测端口是否响应但JVM可能还在加载类、连接池可能还没建立完成的阶段端口虽然监听了但请求在应用层排队超时。SLB按权重把流量打过来这部分请求就直接掉进黑洞。解决方法是不要用SLB默认的“检查间隔2秒、超时3秒、不健康阈值3次”参数跑生产。把检查间隔调到5秒、超时时间调到5秒、不健康阈值调到5次并且把健康检查的URL指向一个真正能做“依赖检查”的接口比如这个接口里轮询一次数据库连接池是否就绪。这样SLB的判定才跟业务真实可用状态对齐。5.5 现象SSL证书续期后网站打不开证书过期没人记得迁移到SLB之后证书卸载工作从ECS转移到了SLB这件事有利有弊。好处是后端ECS的Nginx不用再配置证书坏处是证书到期前一个月阿里云会发短信提醒但如果你用的是一个三个月有效期的免费证书到期日正好赶在项目忙碌期很容易忽略。解决方法是把证书续期这件事做成自动化或半自动化。常见做法是设置一个每月1号的定时任务用脚本调阿里云API检查证书列表如果发现剩余天数少于30天就推送到钉钉或企业微信机器人。SSL证书续期本身在阿里云控制台点几次就能完成但“没人记得去点”才是真正的坑。6. 迁移后的验证技巧用拨测与回退方案把上线风险压到最低迁移完成不代表上线完成我一般会在切换DNS或修改SLB指向后用一套固定的验证流程过一遍耗时约一小时但能拦下90%以上的低级失误。第一类验证是连通性。登录一台不在阿里云VPC内的机器用curl带-H Host: 业务域名访问SLB的公网IP确认HTTP状态码是200、响应时间在预期范围内。这一步验证的是SLB转发链路是否完整不受DNS缓存影响。第二类验证是数据完整性。在RDS上抽查三张核心表执行行数COUNT比对在OSS上随机下载一个文件比对MD5值确认存储链路和文件内容都没问题。第三类验证是业务链路。模拟一次完整的用户操作注册或登录、上传一张图片、触发一次数据库写入、再读取这条记录。注意看应用日志里是否出现连接RDS或OSS的报错。第四类验证是回退演练。把SLB的监听停掉把流量切回旧服务器的入口确认业务恢复。这不是真要做回退而是确认回退路径是通的。没有回退路径的迁移是一场赌博一旦线上出问题你只能一边在监控台里挠头一边被业务方盯着。关于回退路径有两个年份要记住RDS的备份RDS已经自动做了OSS数据有版本管理可以开但ECS上的代码版本要自己在发布记录里留一份。我现在的习惯是每次迁移改动的配置文件都拷贝一份带日期后缀的副本放在ECS的/tmp目录下回退时直接复制回去就行。这个习惯帮我处理过不止一次上线后的突发状况。最后还要提一句SSL证书。如果你在SLB上挂了证书验证阶段务必用openssl s_client -connect 域名:443看一眼证书剩余有效期并确认证书链完整。阿里云免费证书三个月过期一次建议同时在日历上建一个提前两周的提醒。这套验证流程做完整个迁移才算真正落了地。从单机到SLB-ECS-OSS-RDS的组合改变的不仅是部署位置更是遇到故障时还能不能睡个安稳觉——希望帮到你。本文还有配套的精品资源点击获取