WordPress站点可扩展架构搭建及wp-content迁移问题咨询

问题1：是否需同时保留本地与共享wp-content？安装的插件/主题能否在多服务器共享？ #

• 不需要同时保留本地和共享的wp-content，必须统一使用共享存储的wp-content。如果共存，多服务器会出现文件不一致（比如A服务器安装的插件在B服务器上缺失），导致功能异常。
• 插件和主题完全可以在多服务器间共享，这是共享存储的核心价值——保证所有Auto Scaling实例使用完全一致的wp-content文件，避免版本或文件缺失问题。

问题2：是否必须使用EFS？wp-content能否独立存储在每台服务器？ #

• 不是必须使用EFS，也可以用S3配合插件（如WP Offload Media）处理用户上传的媒体资源，但对于插件、主题的核心代码文件，共享存储是更可靠的方案。
• wp-content不能独立存储在每台服务器：Auto Scaling的实例是动态创建销毁的，新实例没有旧实例的插件/主题文件；修改内容（如安装插件、更新主题）后，其他服务器无法同步，会出现部分实例功能正常、部分异常的情况，完全失去扩缩容的意义。

问题3：迁移wp-content是否有其他步骤？部分插件需特殊操作吗？ #

必要迁移步骤 #

1. 确认权限配置：Web服务器进程（如www-data、apache）必须拥有EFS挂载目录的读写权限，否则会因文件无法访问出现404。
2. 修复数据库中的资源URL：你遇到的CORS和404问题，是因为数据库中存储的资源URL仍指向旧域名mysite.fr，跨域名访问时触发限制。需要执行SQL替换，将wp_posts、wp_postmeta等表中的https://www.mysite.fr/wp-content/替换为相对路径或统一的CDN/多域名兼容路径。
3. 配置CORS规则：在CloudFront或Web服务器上添加CORS响应头，允许指定域名（如mysite.eu、mysite.fr）或所有域名访问静态资源（字体、CSS、JS等）。例如Nginx配置：

   location ~* \.(ttf|woff|woff2|css|js)$ {
       add_header Access-Control-Allow-Origin "*";
   }
   

特殊插件处理 #

• 缓存类插件（如WP Rocket、W3 Total Cache）：需配置将缓存文件存储到EFS共享目录，或改用Redis等分布式缓存服务，避免单服务器缓存不一致。
• 生成本地文件的插件（如表单插件的临时文件、导出工具的生成文件）：需修改插件的存储路径到EFS目录，确保多服务器能访问到这些文件。

问题4：按需扩缩容的架构是否存在缺失？当前方案是否合理？ #

• 你的核心架构方向是合理的，属于AWS上WordPress可扩展部署的标准框架，但存在几个关键缺失：
  1. 分布式缓存层：仅靠CloudFront不够，需添加Redis或Memcached作为对象缓存，存储WordPress的数据库查询结果、用户会话等，减少RDS压力，同时保证多服务器缓存一致性。
  2. 自动化初始化流程：Auto Scaling的新实例需要自动完成EFS挂载、wp-config配置、Web服务启动等操作，不能手动配置。可通过Launch Template配合用户数据脚本实现全自动化初始化。
  3. 缓存优化策略：避免全局清除CloudFront缓存，改用基于内容版本号、URL参数的缓存键策略，或使用WordPress插件自动刷新修改页面的缓存，降低服务器负载波动。
  4. 精细化健康检查：在ALB和Auto Scaling Group中配置严格的健康检查规则（如检查静态资源可访问性、核心页面返回状态），确保异常实例被及时替换。
• 补全上述缺失后，这套架构可以稳定支撑WordPress的按需扩缩容需求。

内容的提问来源于stack exchange，提问作者Juloblairot