企业官网建设流程全解析

简介：这是一份面向云计算运维与系统迁移人员的阿里云服务实战文档，聚焦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 的 SDK（oss2或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. RDS：MySQL 迁移的增量追赶是怎么做到「不掉数据」的

静态文件迁完，接着是数据库。相比把图片传上去就完事，数据库迁移要复杂得多——业务不会停下来等你。迁移期间源库还在持续写入，怎么保证切到 RDS 时不丢数据？这就是全量 + 增量迁移机制要解决的问题。

3.1 全量 + 增量的时序配合

迁移的时序可以拆成三个阶段。第一阶段做全量迁移：把源库当前时刻的数据快照倒进 RDS。第二阶段做增量迁移：持续把源库新产生的数据变更同步到 RDS，让两边数据不断逼近。第三阶段是追平：当增量延迟降到几秒甚至更小，选择一个窗口把应用停掉或切到只读，等最后一次增量追平，然后切换连接串。

这里最值得追问的是增量同步的实现基础。MySQL 主从同步依赖 binlog（二进制日志），DTS 这类数据迁移服务本质上是模拟了一个「从库」——它连接到源库，拉取 binlog，解析其中的事务和行变更，再在目标库重放。所以源库必须先开启 binlog，并且迁移账号要有REPLICATION SLAVE, REPLICATION CLIENT权限，否则服务端连 binlog 都读不到。

3.2 增量同步支持的 SQL 操作与类型限制

不是所有 SQL 都能被增量同步。常见可支持的包括INSERT、UPDATE、DELETE、REPLACE这些 DML，DDL 里的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-purged=OFF这类逻辑备份工具长期用惯了的人，切到 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。切换后延迟和流量费用同时下降。判断方式是登录 ECS，ping一下 OSS 的内网域名，能通就走内网；不通则检查是否跨 Region。

5.2 增量迁移一直追平不了，任务延迟几十分钟

现象：全量迁移完成，增量迁移显示有延迟，并且延迟时间持续不减甚至增大。

原因：增量同步的速度取决于源库 binlog 的产生速度、迁移任务的规格和源库与目标库之间的网络带宽。如果源库有大量耗时的批量 UPDATE/DELETE，binlog 会产生大量行变更记录；迁移任务规格过小或者源库、目标库跨地域，延迟就会积累。

解决：把迁移任务换成更高规格；尽量让源库和目标库在同一个地域；如果延迟是大事务导致的，可以在业务低峰期拆分大批量操作，减小单个 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到 ECS，MySQL 直接用mysqldump倒过去。上线后第一周就踩了三个坑：图片外网流量超预算、数据库主键冲突、一台 ECS 被打挂后 SLB 还在往它转发请求。后来才明白，云上每个服务都把「某个横切面的问题」解决到了极致——OSS 解决了存储的 Scale-out，RDS 解决了数据库的运维，SLB 解决了流量的可控性——而你真正要做的是让数据流和每一层的设计对齐。

从那以后我每次迁移都强制自己把过程拆成「理解存储模型 → 核对同步机制 → 配置健康检查 → 切换流量」四步走，一步一步验证之后再动正式环境。这份阿里云四件套的迁移材料最有价值的地方，就是把这四步的标准答案都写了出来。希望帮到你——下次做同类迁移时，能少走我用血泪换来的那些弯路。

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