割接关键思路解析：停服维护、无缝升级如何设计

0. 引言

前文讲解了割接的相关检查项及命令，本文继续讲割接的关键思路：停服维护和无缝升级该如何设计。通过入口层 Nginx 与数据层 MySQL 两个典型案例，覆盖平滑升级原理、停服割接流程与不停服割接的架构设计。

1. 割接与迁移的区别

割接可以理解为迁移中的一个关键部分，但两者并不等同：修改程序配置、做版本升级都需要割接操作，却不属于网站迁移的范围。

割接过程分为两种：

多数场景选择停服割接：不停服割接对方案设计和人员成本要求高，需要前期大量细致分析。在业务低峰期牺牲一部分用户访问换成本，是更务实的做法。

2. Nginx 版本平滑升级

Nginx 支持平滑割接，核心是 reload 指令。Nginx 进程包含 master 进程（管理与分配流量）和 work 进程（处理用户请求）。

升级到新版本 B 后执行 nginx reload：不影响 A 版本现有 master/work 进程的工作，直接启用 B 版本的 master 与 work 进程。老流量继续由 A 版本处理完毕，新流量交给 B 版本；A 版本处理完所有存量请求后 master 优雅退出，完成平滑过渡。

回滚同样平滑：编译升级后 Nginx 会生成 nginx.old 二进制文件（老版本），用 nginx.old 执行 reload 即可回滚到旧版本。

3. Nginx 版本升级步骤

1. 无论旧版本是 yum 还是编译安装，新版本升级都选择源码方式，从官方下载对应源码；
2. 用 nginx -V 查看旧版本编译参数，在新版本编译时保持参数一致；
3. 编译完成后用新版本 nginx -c 做语法测试；
4. 测试通过后执行 nginx reload 平滑升级。

重点注意三点：确认服务是否支持平滑升级、明确升级后的回滚方式、正式环境操作前先在测试环境模拟一次升级。

4. MySQL 停服割接

MySQL 的迁移与升级必须慎重细致，通常由 DBA 负责。停服割接流程：

1. 入口层切维护页：把入口层请求流量切换到维护页面（静态页面，不操作数据库），通常用 Nginx 实现：
   • 方式一：rewrite ^(.*)$ /maintain.html break; 将所有请求转发到维护页；
   • 方式二：借助 Lua 更灵活，可基于源 IP 开白名单——非白名单 IP 302 跳转到维护页，技术/测试人员可正常访问网站做完整验证。
2. 数据层检查：锁老库写入、只允许读取，完成数据一致性、数据库状态、流量是否完全关闭等检查项；
3. 逻辑层切换：修改连接数据库的地址与连接池信息；
4. 流量切回：撤销维护页面，恢复对外服务。

架构上建议把传统逻辑层拆分为业务逻辑层和服务逻辑层（中台），数据层变更只改中台与数据库的关联配置，不干扰业务层。

5. MySQL 不停服割接

不停服割接对人员投入和 DBA 技术能力要求更高，核心是解决"老库与新库数据差异如何填补"，有两条思路：

思路一：日志重放填平

• 在服务逻辑层完整保留一份业务 CUD 日志（对数据的增、删、改）；
• 新库做成主从，并把新库的主库配置为老库的从库，通过 binlog 实时同步；
• 切换后数据仍有差异，用自研 Migration Tools 基于业务日志重放填平差异。

思路二：服务层双写

• T1 时间点发布代码版本，同时开启双写（老库 + 新库）；
• T2 时间点割接，老库停写、流量全部切到新库；
• T1 之前的历史数据，用数据同步工具把老库数据同步到新库。

6. 小结

割接设计的核心决策是停服还是不停服：停服割接靠"维护页 + 检查清单 + 连接切换"三步走，成本低、风险可控；不停服割接靠"CUD 日志重放"或"双写 + 存量同步"填补数据差异，适合核心链路。无论哪种方式，都要先验证平滑升级能力、备好回滚手段、测试环境先行。Nginx reload 与 MySQL 割接这两套思路，分别代表了无状态层与有状态层的升级范式。

下一章讲解 Nginx 高性能优化配置，看承载入口流量的关键组件如何压榨性能。