近期，HamCQ 社区所在的运行服务器临近过期，综合一年以来的运营数据及平台收支情况，本站在 11 月 10 日至 11 月 17 日期间，利用夜间时间段进行了迁移工作，希望能够保障社区的运行状态，为大家提供更长久的服务。

迁移过程中，由于时间有限，且过于专注技术方案的实施，没有提前撰写对应的公告说明，收到了非常多用户的无法访问反馈，恰巧 @BH4ERY 在抖音及 B 站等平台上宣传社区，即便是在夜间 0 点 到 2 点的时间段迁移，也有十几位用户发送邮件、QQ、微信、留言咨询无法访问的情况，彼时虽然睡意朦胧，却给了我极大地鼓舞。

此次硬件迁移情况：

阿里云实例：ecs.s6-c1m2.large（1 台） => ecs.e-c1m1.large （同地域 2 台）
单机配置：2 核 (vCPU) 4 GiB => 2 核 (vCPU) 2 GiB

此次平台迁移大致流程：

1、购买新服务器套餐，尝试同地域挂载磁盘，但由于新套餐硬件续费有要求，旧服务器磁盘有进行过扩容，遂采用后续方案。
2、进行旧服务器磁盘内容清理，由 92% 缩减至 65%，为下一步工作做好铺垫。
3、对旧服务器快照备份，CDN 解析至维护界面，保证无新业务数据流入。
4、使用 SMC 迁移中心，重新制作镜像文件，内网迁移大致花费了 40 分钟完成。
5、购买新服务器套餐，从镜像文件启动，初步完成迁移工作。

原本以为工作到此结束，没想到运行一段时间后，频繁的收到高负载报警，相同的应用程序在旧服务器上运行稳定，且各项占用指标对于新服务器也符合，这时候才意识到阿里云的共享型实例：「不同实例 vCPU 会争抢物理 CPU 资源，并导致高负载时计算性能波动不稳定，有可用性 SLA 保证，但无性能 SLA 保证」，尤其 E 实例所带来的新问题……

于是，便采购了 2 个同地域服务器套餐，简单画了个图。

如下图所示，请求流量由 DCDN 进来后，到达 A 服务器所在的 WAF 层，清洗后转发至 B 服务器的 Nginx 服务。同地域的 2 台服务器，用 VPC 对等连接打通内网环境（免连接费、流量费、带宽无上限，延迟低），A/B 两台服务同时运行 PHP-FPM 进程，但由于 B 服务器运行 MySQL ，需要较多的资源保证，且 A 服务有较多闲置资源，便通过 Nginx 配置负载，将大部分 PHP 处理放置 A 服务器，并开启 Zend-Opcache，其中，通过 NFS 实现了对应入口文件的挂载。

以上是本次迁移工作的大致情况，按照现有指标，进行简单压力测试后，能够应对社区日常及五五节活动流量。

采用如上方案是希望能够兼顾「面包和爱情」，特地记录此次过程，非常欢迎大佬们在评论区提出宝贵的意见和建议～