PrestaShop 从 Hestia 迁移到 DirectAdmin

PrestaShop 从 Hestia 迁移到 DirectAdmin

PrestaShop 迁移并不意味着必须移动整个技术栈。在本案例中，我仅用一个晚上就将后端从旧的 Hestia 环境迁移到了基于 DirectAdmin 的新主机。前端保留在原有平台上，新闻通讯和 CRM 服务也维持原状。迁移范围更加聚焦：确保新后端能够处理多商店电商系统的 REST API、缓存和 cron 任务。

实际工作时间约为三到四个小时。文件传输是最简单的部分。真正的工作在于验证迁移后路由、Redis、cron、缓存失效以及特定商店的 API 响应是否仍然正常工作。

本次 PrestaShop 迁移中移动的内容

后端部署到了一个现代化的共享主机方案上，该方案配备 NVMe 存储、分配的 CPU 和分配的 RAM。主机面板显示了预期的套餐和磁盘配额。

我没有移动所有内容，这是有意为之。

已移动：

保留原位：

我倾向于这种窄范围的 PrestaShop 迁移，因为它能减少干扰。如果同时移动前端、营销栈和后端，会引入太多变量。在这里，我希望验证一个清晰的业务系统。

路由是第一个问题

PrestaShop 作为多商店后端运行。这意味着一个后端必须正确响应两个商店的请求。在旧主机上，面板规则和现有的 URL 行为隐藏了一些复杂性。在新主机上，REST 调用必须在 PrestaShop 重定向或规范化请求之前保留商店上下文。

解决方案是正确路由带有商店前缀的 REST 调用：

这在纸面上看起来微不足道。但在实践中，正是这类细节会让迁移感觉像是失败了，即使文件、数据库和 DNS 都是正确的。在我的工作中，我会先检查路由，然后再去责怪 PHP、Redis 或数据库。

Redis 有帮助，但缓存清除更重要

Redis 通过 Unix socket 启用：

text /home/account/.redis/redis.sock

随后 PrestaShop 使用 Redis 作为缓存后端。API 响应速度有所提升，但缓存只有在正确的时间清除时才有意义。

后台办公室是事实来源。当有人在 PrestaShop 中更改价格、产品描述、PageBuilder 块、类别或活动时，前端 API 必须提供最新数据。仅启用缓存是不够的。我还必须将缓存清除连接到相关的 PrestaShop hooks。

我直接验证了行为：

这就是“已启用缓存”和“缓存可信赖”之间的区别。在电商领域，这种区别至关重要。

Cron 作业需要仔细筛选

第一次检查 Hestia cron 时，发现了一些属于其他服务而非 PrestaShop 后端的作业。这些作业不应出现在新主机上，因为该服务不属于本次迁移范围。

相关的 PrestaShop 作业位于旧的 live Hestia 服务器上：

我没有迁移一个已挂起的 CRM 作业。我也跳过了 Hestia 的内部系统作业。DirectAdmin 拥有自己的维护和备份流程，因此复制面板残留物只会造成混乱。

最初将一个数据库转储作业映射为谨慎的开发转储。一旦确认主机面板已经处理备份，我就将其移除。除非有明确的恢复理由，否则重复备份流程只会增加噪音。

后端迁移的性能结果

我对每个商店的相同公共 REST 端点进行了 12 次测试：

text /rest/pagebuilder/placements

结果如下：

Stage 服务器是一个简单的参考服务器，响应一致。新主机对两个商店的响应速度仍然更快。

新主机还显示出较高的服务器平均负载，大约在 10-13 之间。SSH 显示物理主机上的 CPU 线程数多于账户分配数，因此该数字本身并不令人担忧。账户看起来很空闲：Redis 几乎处于闲置状态，PHP 工作进程未驱动 CPU，检查时数据库的活动查询负载也很低。

这就是为什么我在共享主机上谨慎对待平均负载。它反映的是主机整体状况，而不仅仅是单个账户。如果您的提供商销售具有明确 CPU 和 RAM 规格的套餐，询问这些限制如何通过 CloudLinux 或 LVE 执行仍然很有帮助。

我用于迁移的 AI 工作流

我使用 Codex 作为操作代理，执行 SSH、DirectAdmin API 工作、服务器检查、crontab 更改、计时测试和 PrestaShop 覆盖工作。

对于审查，我使用我的开放工作流 ai-collab-bridge。理念很简单：一个 AI 实施更改，然后另一个 AI 接收包含 diff、上下文和聚焦问题的审查包。这样，Claude Code 就可以作为第二位技术读者审查工作，而不是对松散的摘要做出反应。

这在 PrestaShop 迁移中很重要，因为存在许多小决策：

当 AI 必须展示其检查过程时，它才真正有用。“它能工作”是不够的。一次有用的迁移运行应展示命令、状态码、缓存行为、cron 状态以及有意未移动的部分。

我从这次迁移中吸取的教训

不要盲目复制面板行为。Hestia 和 DirectAdmin 以不同方式解决主机维护问题。Hestia 面板的 cron 不属于 DirectAdmin。

保持后端迁移范围狭窄。如果前端已经在其他地方运行，移动它只会增加风险。

从后台办公室的角度验证缓存。电商变更发生在价格、库存、文案和活动编辑中。无法清除的缓存会成为业务问题。

反复测量同一个端点。一次 `curl` 请求说明不了什么。每个商店运行十二次给了我更清晰的信号。

不要在脚本中硬编码数据库密码。需要时从应用程序的现有配置中读取，并让主机面板负责备份。

结果

迁移后，在我的测试中，后端的响应速度快于旧的 live 服务器和 stage 参考服务器。Redis 和 LiteSpeed 提供了帮助。DirectAdmin API 足以满足我所需的面板设置。事实证明 OPcache 内存是主机级别的设置，因此这属于主机支持范畴，而非应用代码。

主要结果并非更低的 TTFB。重要的结果是后端仍然表现得像一个电商后端：后台办公室拥有数据，API 按商店响应，变更时清除缓存，cron 仅运行属于新主机的作业。

FAQ

迁移花了多长时间？

活跃的后端迁移大约花了三到四个小时。加上计时测试、cron 清单、缓存验证和支持说明，工作量接近四到五个小时。

为什么你没有移动所有内容？

前端已经在其他地方运行。新闻通讯自动化和 CRM 有各自的环境。狭窄的后端移动降低了风险。

为什么 Redis 很重要？

Redis 提高了后端缓存速度，但真正的价值在于将缓存清除连接到 PrestaShop hooks。如果没有这一点，后台办公室的更改可能无法到达 API。

为什么在共享主机上难以读取平均负载？

平均负载通常显示整个主机队列，而不仅仅是您的账户。在这次迁移中，账户看起来很空闲，而主机显示出较高的负载。这就是为什么应该由支持人员确认 CloudLinux 或 LVE 限制。

为什么在服务器迁移中使用 AI？

当 AI 基于证据工作时非常有用：配置读取、计时测试、cron 比较、API 检查和记录的变更。通过开放工作流进行同行审查，使得让另一个模型检查风险变得更加容易。