阿里云上云架构实战：SLB、ECS、OSS、RDS与数据迁移避坑指南

简介这份文档面向云计算运维、后端开发及系统架构入门者围绕阿里云SLB、ECS、OSS、RDS四大核心服务讲解各服务的基本概念与在系统数据迁移中的实际应用帮助读者建立从负载均衡、云服务器到对象存储与关系数据库的整体认知。资源包内含1个docx文件约1.78MB内容以图文并茂的文档形式组织涵盖OSS的桶、对象与存储类型RDS的实例、数据库与账户以及SLB的监听器、后端服务器、健康检查与证书管理等模块并延伸至产品架构、高可用设计与应用场景。目录层级清晰从服务概述到快速入门逐层展开便于按需查阅与系统学习。目前已有777人学习下载适合作为云服务选型、迁移方案设计与日常运维的参考手册也可用于梳理知识体系与查漏补缺。1. 从一台 ECS 到整套云上架构SLB、OSS、RDS 与数据迁移到底在解决什么很多团队上阿里云的第一步是买一台 ECS 把应用跑起来数据库、文件、入口全塞在同一台机器上。业务量一涨问题就来了单机扛不住并发、图片视频把磁盘撑爆、数据库和 Web 抢 CPU、机器一挂全站下线。这时候「阿里云服务器」这套组合拳才真正登场——用 SLB 做流量入口和负载均衡用 ECS 承载无状态应用用 OSS 存对象文件用 RDS 托管数据库最后把老系统里的数据平滑迁过去。这套架构不是堆产品而是把「接入层、计算层、存储层、数据层」拆开各自独立扩容和容灾。本文面向正在做上云改造或系统迁移的工程师从选型理由讲到可复现的配置命令再到迁移过程中那些让人半夜爬起来排障的坑帮你把这条链路真正跑通。2. SLB 与 ECS 接入层把流量分发和计算节点拆开2.1 为什么入口要用 SLB 而不是直接绑 ECS 公网 IP单台 ECS 直接暴露公网 IP最直接的问题是没法做水平扩展。你加第二台机器用户还是访问第一台的 IP流量不会自动分过去。SLBServer Load Balancer解决的就是这个它给你一个固定的服务地址后端挂多台 ECS按权重或连接数分发请求。更关键的是SLB 能屏蔽后端变化——你扩容、缩容、换机器前端地址不变用户无感知。从选型上看阿里云 SLB 分两种传统型CLB和应用型ALB。传统型工作在四层TCP/UDP性能高、延迟低适合长连接、游戏、数据库代理这类场景应用型工作在七层HTTP/HTTPS支持基于域名、路径、Header 的转发规则适合 Web 应用和微服务。常见做法是对外 HTTP 服务用 ALB内部 RPC 或 TCP 服务用 CLB。热搜里提到的「f5 和 slb」对比本质是硬件负载均衡和云原生负载均衡的取舍——F5 功能强但贵且要自己运维SLB 按量付费、免运维中小团队优先选 SLB。配置 SLB 的核心参数有三个监听端口、后端服务器组、健康检查。健康检查尤其重要它决定了 SLB 怎么判断一台 ECS 是否还活着。检查间隔太短会误杀太长则故障切换慢。一般 Web 服务设 2 秒间隔、连续 3 次失败摘除比较稳妥。2.2 用 CLI 创建 SLB 并挂载两台 ECS 的最小命令下面用阿里云 CLI 走一遍创建 CLB、配置监听、挂载后端的最小流程。前提是你已经装好 aliyun CLI 并配置了 AccessKey。# 1. 创建负载均衡实例按量付费公网类型 aliyun slb CreateLoadBalancer \ --RegionId cn-hangzhou \ --LoadBalancerName web-slb \ --AddressType internet \ --LoadBalancerSpec slb.s1.small \ --PayType PayOnDemand # 2. 创建 TCP 80 监听后端端口 8080 aliyun slb CreateLoadBalancerTCPListener \ --RegionId cn-hangzhou \ --LoadBalancerId lb-xxxxxxxx \ --ListenerPort 80 \ --BackendServerPort 8080 \ --Bandwidth -1 \ --HealthCheckConnectPort 8080 \ --HealthCheckInterval 2 \ --HealthyThreshold 3 \ --UnhealthyThreshold 3 # 3. 把两台 ECS 加入默认服务器组 aliyun slb AddBackendServers \ --RegionId cn-hangzhou \ --LoadBalancerId lb-xxxxxxxx \ --BackendServers [{ServerId:i-aaa,Weight:100},{ServerId:i-bbb,Weight:100}]第一段创建实例LoadBalancerSpec决定性能规格测试环境用slb.s1.small就够。第二段建监听Bandwidth -1表示不限速按量付费下按实际流量计费健康检查参数直接决定故障摘除速度。第三段挂后端Weight是权重两台机器配置相同时都设 100如果新机器刚上线想先接少量流量可以设成 10 观察。提示ECS 的安全组必须放行 SLB 过来的流量。SLB 回源用的是内网地址安全组入方向要允许后端端口否则健康检查一直失败控制台显示后端「异常」。2.3 ECS 侧要做的三件事安全组、内网、无状态SLB 配好只是接入层通了ECS 本身还有三件事必须处理。第一是安全组只放行必要端口公网入口尽量只留 SLB 回源和运维跳板不要把 8080 直接暴露到公网。第二是内网互通SLB 和 ECS 要在同一地域同一 VPC跨 VPC 需要走云企业网延迟和配置复杂度都会上升。第三是无状态化这是很多人忽略的如果应用把 session 存在本地磁盘或内存SLB 轮询到另一台机器时用户就掉登录了。常见做法是把 session 存到 Redis 或 RDS或者用 JWT 把状态放客户端。ECS 选型上通用型 g 系列适合大多数 Web 应用计算型 c 系列适合 CPU 密集内存型 r 系列适合缓存和数据库。系统盘建议 ESSD云盘 IOPS 比普通云盘高一个量级数据库和日志写入频繁时差别很明显。镜像方面阿里云 CentOS Stream 9 镜像已经比较成熟但生产环境更推荐 Alibaba Cloud Linux内核针对云环境做过优化长期维护也更省心。3. OSS 对象存储把文件和数据库从 ECS 上剥出去3.1 什么时候该用 OSS什么时候不该用OSS 是对象存储适合存图片、视频、备份、日志、静态网页这类「一次写入、多次读取、很少修改」的文件。它的优势是容量几乎无限、按量付费、自带多副本容灾还能直接配 CDN 加速。但 OSS 不是文件系统不支持随机写和文件锁所以数据库文件、需要频繁改写的配置文件不能放 OSS。判断标准很简单如果这个文件是用户上传后基本不改的放 OSS如果应用需要频繁 open/seek/write留在 ECS 云盘或迁到 RDS。热搜里的「oss 对象存储」「阿里云存储桶」说的就是它Bucket 是 OSS 里的顶层容器命名全局唯一创建时要选地域和存储类型。标准存储适合热数据低频访问适合备份归档适合长期冷数据价格依次降低但取回成本升高。3.2 用 ossutil 做本地目录到 Bucket 的增量同步命令行工具 ossutil 是运维最常用的 OSS 操作入口下面这段做本地目录到 Bucket 的增量同步只上传新增和修改过的文件。# 配置 AccessKey首次执行 ossutil config \ -e oss-cn-hangzhou.aliyuncs.com \ -i LTAIxxxxxxxx \ -k xxxxxxxxxxxxxxxx # 增量同步本地 uploads 目录到 Bucket 的 media 前缀下 ossutil sync /data/uploads/ oss://my-bucket/media/ \ --update \ --delete \ --jobs 10--update表示只上传比 OSS 上更新的文件--delete表示本地删了的文件 OSS 也删--jobs 10是并发数。这里有个坑--delete很危险如果本地目录挂载异常变成空目录会把 OSS 上的文件全删掉。生产环境建议先不加--delete观察一段时间确认同步逻辑没问题再加。注意AccessKey 不要写进脚本提交到代码仓库。用 RAM 子账号只授予这个 Bucket 的读写权限主账号 AK 权限太大泄露后果严重。3.3 应用侧接入 OSS 的 SDK 写法与签名直传应用上传文件有两种模式服务端中转和客户端直传。服务端中转是文件先传到 ECS再由 ECS 传到 OSS简单但浪费 ECS 带宽。客户端直传是浏览器或 App 直接传 OSSECS 只负责签发上传凭证省带宽但要做签名。下面用 Python SDK 演示服务端生成上传签名前端拿到签名后直传。import oss2 from oss2.credentials import EnvironmentVariableCredentialsProvider # 从环境变量读取凭证避免硬编码 auth oss2.ProviderAuth(EnvironmentVariableCredentialsProvider()) bucket oss2.Bucket(auth, oss-cn-hangzhou.aliyuncs.com, my-bucket) # 生成带过期时间的上传签名 URL前端 PUT 这个地址即可 url bucket.sign_url(PUT, media/photo.jpg, 3600) print(url)sign_url第一个参数是 HTTP 方法第二个是对象 key第三个是过期秒数。前端拿到 URL 后用 PUT 请求把文件体发过去就行不需要再经过 ECS。这里的关键是权限控制签名 URL 只对这一个 key 有效过期即失效比把 AK 发给前端安全得多。热搜里「阿里云认证 sdk」相关的困惑多半就是凭证管理没做对记住一条任何情况下 AK 都不进客户端。4. RDS 与数据迁移把数据库从自建搬到托管4.1 自建 MySQL 和 RDS 的取舍自建数据库在 ECS 上你要自己装 MySQL、配主从、做备份、盯慢查询、处理磁盘满。RDS 把这些都托管了自动备份、故障切换、监控告警、读写分离、按需升配。代价是价格比自建高且部分底层参数不能改。对大多数中小团队RDS 省下的人力成本远超差价。RDS 选型看三个维度规格CPU 内存、存储类型ESSD 云盘、版本MySQL 8.0 还是 5.7。高可用版是主备双节点主库挂了自动切备库生产环境必选基础版单节点便宜但故障要手动恢复只适合测试。存储空间要留余量RDS 磁盘满了会锁写比 ECS 磁盘满更麻烦因为你还得走控制台扩容。4.2 用 DTS 做不停机迁移的完整步骤数据迁移是整套方案里最容易翻车的环节。常见做法是用阿里云 DTS数据传输服务支持结构迁移、全量迁移、增量同步三步走能做到源库继续写、目标库实时追平最后切换时只停几分钟。操作步骤大致如下在 DTS 控制台创建迁移任务源库填自建 MySQL 地址目标库填 RDS 实例。选择迁移类型结构迁移 全量迁移 增量迁移三个都勾上。配置迁移对象选要迁的库表大表可以单独限速避免打满源库 IO。启动任务等全量完成、增量延迟降到秒级。业务低峰期停写源库等增量延迟归零切换应用连接串到 RDS。-- 迁移前在源库确认没有外键和触发器阻碍 SELECT TABLE_NAME, CONSTRAINT_NAME FROM information_schema.TABLE_CONSTRAINTS WHERE CONSTRAINT_TYPE FOREIGN KEY AND TABLE_SCHEMA your_db; -- 迁移后在 RDS 上核对行数逐表比对 SELECT COUNT(*) FROM your_db.orders;第一段查外键DTS 迁移时外键可能导致建表顺序问题常见做法是先迁数据后加外键。第二段是迁移后核对行数对不上说明有数据丢失或重复必须查清楚再切流量。增量同步阶段要盯延迟指标延迟突然涨说明源库有大事务或 DTS 限速了。提示迁移期间源库的 binlog 格式必须是 ROW且保留时间要覆盖整个迁移窗口。如果 binlog 被清理增量同步会断只能重来。4.3 迁移后的连接串切换与回滚预案切流量不是改个配置就完事。应用连接池里还有旧连接直接改地址会导致一批请求失败。稳妥做法是先把 RDS 地址配成新数据源应用双写或灰度读观察一段时间再全量切。切换后旧库不要马上删保留至少一周作为回滚兜底。连接串里几个参数要调maxPoolSize按 RDS 规格设别超过实例最大连接数connectionTimeout设短一点故障时快速失败而不是卡住rewriteBatchedStatementstrue能显著提升批量插入性能。热搜里「阿里云 rds 使用」的高频问题一半出在连接数打满一半出在慢查询没优化迁到 RDS 不等于性能自动变好索引和 SQL 该优化还得优化。5. 避坑与排查迁移路上那些让人后悔的瞬间5.1 现象SLB 健康检查全红后端 ECS 明明在跑原因通常是安全组没放行 SLB 回源地址段或者 ECS 上应用只监听了 127.0.0.1 而不是 0.0.0.0。解决检查安全组入方向规则确认应用监听地址用netstat -tlnp看端口绑定情况。5.2 现象OSS 同步脚本跑完文件少了一批原因多半是文件名含特殊字符或中文ossutil 默认编码处理不一致。解决加--encoding-type url参数或者迁移前统一重命名文件。另一个可能是并发太高触发限流降低--jobs重试。5.3 现象DTS 增量同步延迟越来越大原因是源库有大事务长时间不提交或者 DTS 规格太低追不上写入速度。解决排查源库长事务升级 DTS 规格大表迁移单独限速错峰执行。5.4 现象RDS 磁盘突然满了应用写不进去原因是 binlog 保留时间太长或慢日志堆积。解决控制台调小 binlog 保留天数清理慢日志开启存储自动扩容。生产环境建议提前设告警磁盘到 80% 就处理。5.5 现象迁移后应用报时区或字符集错误原因是源库和 RDS 的时区、字符集配置不一致。解决迁移前统一成utf8mb4和08:00连接串里显式指定serverTimezone和characterEncoding别依赖默认值。6. 进阶技巧用 Terraform 把这套架构固化成代码手工在控制台点出来的架构下次再搭一套还得重来而且容易漏配。把 SLB、ECS、OSS、RDS 用 Terraform 描述成代码既能版本管理又能一键复制环境。下面是一个精简的骨架展示 VPC、SLB、RDS 怎么串起来。# 定义 VPC 和交换机 resource alicloud_vpc main { vpc_name prod-vpc cidr_block 172.16.0.0/12 } resource alicloud_vswitch web { vpc_id alicloud_vpc.main.id cidr_block 172.16.1.0/24 zone_id cn-hangzhou-h } # RDS 实例高可用版 resource alicloud_db_instance mysql { engine MySQL engine_version 8.0 instance_type rds.mysql.c1.large instance_storage 100 category HighAvailability vswitch_id alicloud_vswitch.web.id } # SLB 实例 resource alicloud_slb_load_balancer web { load_balancer_name web-slb address_type internet load_balancer_spec slb.s1.small }category HighAvailability决定主备双节点instance_storage单位是 GB。Terraform 的好处是terraform plan能提前看到变更影响避免手滑删库。配合远程 state 存储可以放 OSS团队协作时不会互相覆盖。验证迁移是否成功我一般会做三件事一是用压测工具对 SLB 地址打一轮看后端两台 ECS 流量是否均匀二是抽样比对源库和目标库的关键表数据三是模拟一台 ECS 宕机确认 SLB 能自动摘除、业务不中断。这三步过了才算真正迁移完成。我自己踩过最深的坑是迁移当晚忘了改应用的连接池配置旧连接池还指向源库切了 SLB 但数据库没切干净结果一半请求写旧库一半写新库数据对不上。从那以后我养成的习惯是任何迁移都先写回滚步骤再写执行步骤回滚方案没想清楚就不动手。希望帮到你。本文还有配套的精品资源点击获取