企业官网建设流程全解析

简介：这份文档面向云计算运维、后端开发及系统架构入门者，围绕阿里云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，流量不会自动分过去。SLB（Server 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 直接传 OSS，ECS 只负责签发上传凭证，省带宽但要做签名。

下面用 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（数据传输服务），支持结构迁移、全量迁移、增量同步三步走，能做到源库继续写、目标库实时追平，最后切换时只停几分钟。

操作步骤大致如下：

1. 在 DTS 控制台创建迁移任务，源库填自建 MySQL 地址，目标库填 RDS 实例。
2. 选择迁移类型：结构迁移 + 全量迁移 + 增量迁移，三个都勾上。
3. 配置迁移对象，选要迁的库表，大表可以单独限速避免打满源库 IO。
4. 启动任务，等全量完成、增量延迟降到秒级。
5. 业务低峰期停写源库，等增量延迟归零，切换应用连接串到 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设短一点，故障时快速失败而不是卡住；rewriteBatchedStatements=true能显著提升批量插入性能。热搜里「阿里云 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 但数据库没切干净，结果一半请求写旧库一半写新库，数据对不上。从那以后我养成的习惯是：任何迁移都先写回滚步骤，再写执行步骤，回滚方案没想清楚就不动手。希望帮到你。

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