我有一个 WordPress 网站，目前我完全在亚马逊 Lightsail实例。它得到了适当的备份；可用性还行；安全性很好；这是一个易于维护的简单设置。还不错。
我想通过将网站迁移至亚马逊 Elastic Beanstalk并对站点的后端进行一些其他重大更改（使站点数据库独立于 PHP 服务器、迁移到 nginx 等）。这出于多种原因都是有益的，其中最主要的是：EBS 是一个比 Lightsail 更强大的服务器设置。
这亚马逊提供的教程在 Beanstalk 上创建 WordPress 网站建议只安装/wp-content/uploads/在亚马逊弹性文件系统，默认配置脚本会为客户执行此操作。这样做的缺点是核心 WordPress 文件不会在 EC2 实例之间共享；而是在每个实例上复制，因此在您的站点上运行 WordPress 更新过程意味着某些实例实际上不会更新，从而产生不良行为。
本教程建议通过以下方式更新 WordPress（和插件）可怕的过程使用 WordPress（测试版）导出工具导出所有网站内容，然后使用（测试版）导入工具在运行更新的 WordPress 的新 Beanstalk 环境上重新导入。
我并不严格反对自动化这个过程，以便更新 WordPress 对我来说更容易，但我很重视保持最新的更新，所以我想优化这样做，并且我怀疑对我（或任何客户）来说最好的解决方案是在更新系统或插件的过程中使用 WordPress 的测试版导入和导出工具。
例如，有时这些更新是安全更新，WordPress 提供了自动修补系统，这对于最大限度地提高站点安全性非常有利。但是，由于我之前概述的更新挑战，如果核心 WordPress 文件未在 EC2 实例之间共享，则自动修补将无法按预期工作。
尽管如此：
如果我将所有 WordPress 文件（而不仅仅是目录/wp-content/uploads/）放在共享 EFS 存储上，可能会遇到哪些架构或系统问题？
当然，我会做自己的测试，看看事情进展如何，但我想知道在尝试这样做时要注意什么，以及在哪里设定我的期望。
答案1
（注意：我不是专家，但正在寻找一个未解答的问题，以便我可以回复 serverfault.com）
我首先会尝试扩展 Lightsail。文档 (https://aws.amazon.com/lightsail/features/) 讨论使用负载均衡器拥有多个实例。你试过吗？查看 CloudWatch 监控以了解您的实例有多忙。水平扩展可能会为您带来更快的响应时间。此外，您可以扩展 Lightsail 以使用独立数据库实例。
在我看来，Word Press 在计算效率方面堪称一流。它可以加载一百个脚本来执行单个请求。精简可以有所帮助。有任何不需要的插件吗？代码可以合并成更少的模块吗？可能有优化/分析工具可以帮助您加快网站速度。
另外，请考虑您的网站中有多少是静态文件服务，有多少是计算文件。将静态文件卸载到 AWS S3 是一个很好的解决方案。此外，实施 CDN 缓存（例如 AWS CDN）可以缩短非计算页面加载的响应时间，并可能将内容移到更靠近用户所在的位置。最后，但经常被忽视的是，您的用户需要发出多少 HTTP 请求才能加载给定页面。您是否有许多需要加载的 JS 库？考虑将它们合并到一个文件中，以便在单个事务中加载。使用 Chrome 或 Firefox 中的浏览器开发工具可以真正帮助您查明延迟的来源。
如果您想采用管理服务器的方法，那么更新 WP 可以用更简单的方法完成。我建议您开始使用 Docker 容器。然后，您只需在 N 个服务器上运行一个映像，并使每个映像保持最新。使用 AWS ECR 作为您的映像。当您想要更新 WP 或插件时，您可以构建一个新的容器映像版本。然后使用 AWS EKS 或 Fargate 允许您以滚动方式推出新版本。这都是宠物与牛主题的一部分。您不需要对单个服务器（容器）进行维护，但如果有变化，您可以丢弃旧的并部署新的。
但是，在经历了这一切之后，如果你仍然想走通用存储的路线，我不建议你使用 EFS。那样的话你得不到安全性。相反，我会在每台服务器上运行 S3 文件缓存。每当 S3 中发生更改时，它都会在本地提取文件，这样每个人都能获得更改。示例缓存是https://github.com/s3fs-fuse/s3fs-fuse/wiki/Fuse-Over-Amazon。
我会进行测试，看看在运行时是否有任何对 WP 文件的写入。如果有，并且写入的内容取决于实例，则您必须将这些目录保留为服务器上的本地目录。