一、背景

Wordpres是国外常见的、流行的建站应用程序，基于PHP软件开发以MySQL数据库为核心，小巧快速。Wordpress拥有超过20年的软件生态体系，大量第三方免费插件、收费插件都可通过社区获得。Wordpress可快速满足内容发布（CMS）、在线商城等多种类型的动态网站构建和管理。搭建Wordpress是相对简单、快速的，根据不同的业务需求、访问量，在做架构设计时候可能有许多不同角度的考量。这里分享如下。

二、Wordpress技术栈演进的几个阶段

1、第一阶段-单机起步

在Wordpress启动之初，是在一台低性能的EC2 t3示例上，以Amazon Linux单机形式运行web server/php/mysql，组件都是on EC2手工部署管理。为提升访问速度：

• 增加CloudFront做CDN提升访问速度
• 配置Wordpress的全站SSL插件，使用了AWS Certificate Manager（ACM）生成SSL证书，用于保护CloudFront的内容传输，发布https网站而非http网站
• 使用Route53解析域名

2、第二阶段-托管化改造

为了提升性能和可管理性，降低运维复杂度，可进行动静态内容分离，并从EC2自建服务切换到托管服务：

可靠性：

• 将EC2打包制作为AMI，配置为多台
• EC2之前增加ALB，ALB再被CloudFront即成
• 数据库选用合适的RDS
• 监控在CloudWatch上设置Dashboard和对应的告警规则
• 主站增加WAF ACL，使用托管规则保护Linux/PHP/Wordpress/SQL等风险

动静态分离：

• CloudFront从一个发布点拆分为2个发布点，PHP网站是动态，上传到S3的图片是静态，动态内容和静态内容有不同缓存策略、不同的安全WAF ACL防护策略
• 安装Wordpress的S3文件扩展，为EC2配置IAM Role允许写入S3，Wordpress上传图片文件将自动写入S3，S3读写要使用IAM Role而非AKSK

3、第三阶段-容器化

引入容器化，重构了计算和存储环境。

计算：

• 使用ECS提供服务，在Cloud9上构建最小化的容器镜像，编写docker image的start服务脚本
• 制作apache+php镜像，解决wordpress需要的大量PHP扩展库问题，同时避免使用第三方php镜像内部的依存库版本等问题
• 定义ECS task，并在ECS上启动Service
• 使用ECS Fargate模式而非ECS EC2模式，从成本考量，建议切换到ECS Fargate Spot模式

存储：

• 计算和存储分离，原先Wordpress的www目录打包进入docker，要分拆到独立存储服务，容器Image build最小化，无须加载Wordpress目录
• 使用EFS文件系统做外部挂载，在ECS容器服务上设置挂载规则
• Cloud9 IDE上挂载EFS，满足编辑开发要求

安全：

• 为Wordpress Admin等后台页增加WAF验证码保护
• 为顶级域名增加S3跳转等

4、第四阶段-性能和安全

性能：

• 引入Redis缓存，安装Wordpress WP-Cache插件，配置托管的Redis服务，降低数据库压力

安全性：

• 在动静态分离的基础上，从静态内容中，再次分离受保护的视频内容，避免大流量恶意DDOS
• 视频内容发布到独立的S3存储桶，开启CloudFront签名的Signed-Cookie检查
• 在Wordpress的PHP上增加PHP计算CloudFront签名的算法，与CloudFront对接
• 为视频发布点配置独立的WAF规则

三、Wordpress on AWS 最佳实践

以上整个架构演进思路的几个阶段，是按照配置复杂度简单划分的，实际上并没有严格的阶段划分标准，可整体一步到位，也可分批根据需要部署。具体采用哪一种架构设计方式主要取决于业务需求，包括：

• 要部署多复杂的Wordpress网站，用什么模块，是否有开放的用户注册、生成评论、订单等内容，评估安全性、可用性等整体设计
• 预期访问量，需要评估性能，评估弹性能力
• 预期用户交互方式，评估安全防护角度，包括是否需要开启Shield以及WAF Anti-DDOS规则等

将以上几个部分的架构部署在AWS上的架构图：

整个架构设计过程中，无时无刻地都应遵循AWS最佳架构Well Architecture的思想，从五个关键支柱做好架构设计。他们包括：

• 安全性：日常打补丁，暴露最小范围（关闭端口），配置最小权限（IAM Policy最低权限），不用的服务都封掉；开启WAF等、Guardduty等各种防护等，禁用S3 Public，防止便利、限流限速（Time-rate）等；设置监控并采集安全访问日志。
• 可靠性：避免单点故障，使用托管服务的冗余能力，大部分服务都配置为多AZ可自动切换容灾；进行冷备份；设置适当的弹性规则；设置监控和告警阈值。
• 性能：选择合适的机型，后转向ARM架构Graviton机型；基础架构的配置启用弹性能力；在应用层卸载和分流，引入动静态分离等；实施缓存；
• 成本优化：选择合适的机型；通过Trust-advisor监控配置是否有浪费；缩小架构避免over-engineering浪费资源；
• 运维优化：脚本化的容器构建、发布、补丁、版本更新；定制监控Dashboard；开始RDS高级监控了解Slowsql等。

在整个架构设计思路中，安全是重中之重。Wordpress作为PHP开发的脚本程序，容易出现安全漏洞，从Linux OS、Web Server（Apache）、动态程序（php-fpm）和扩展（PHP扩展），再到Wordpress应用本身都有出现漏洞的风险。开启多种AWS安全服务，主要是WAF针对Linux、PHP、Wordpress、SQL的托管规则，再结合WAF的Bot判定和IP Reputation库，辅以Rate-based规则，直接封掉恶意请求。运行中要定期分析日志，手工增加屏蔽规则；同时关注Wordpress社区发布新版本，随时修复漏洞。在此基础上，还要实施冷备份。

四、Wordpress转向静态化方案

转向静态化的过程需要面临几个关键阶段，参考思路如下。

1、基础内容转换工作

• (1) 使用Wordpress自己的Backup功能，将所有内容导出为单一XML文件，下载到本机。
• (2) 使用第三方工具将上一步生成的XML文件转换为Markdown格式，例如blog-to-markdown等，由此将生成几百个独立的Markdown文件，每个Markdown文件可独立编辑、校对，即可导入静态建站工具生成页面。
• (3) 选择某个静态网站页面生成工具，对Markdown进行渲染，获得初始版本网页。

首个静态网站版本完成。

2、内容和素材检查和修复

• (4) 使用ai-agent矫正上传图片的文件路径等问题。在没有使用wordpress的S3插件时上传图片操作会将文件写入到Web Server的wp-content目录内。转换成静态后这些被引用的图片应完全位于S3独立存储桶，而不是与Markdown生成的内容页面共用一个存储桶。这里可使用ai-agent帮忙编写脚本检查并替换，并可生成脚本批量测试可访问性。
• (5) 优化CloudFront的缓存逻辑，对于首页（标题索引）、单篇内容页、图像素材，根据他们URL不同来区分缓存规则，区分缓存有效期；在CloudFront创建多个缓存策略（Cache policy），然后在发布点下添加多条行为规则，根据文件名/路径匹配不同缓存策略。

至此主要内容迁移完成。

3、原包含签名机制的视频迁移

• (6) 使用ai-agent逐个检查Markdown中包含视频的文章是否包含正确的视频地址。这是因为在wordpress导出为XML文件时候，嵌入视频的插件（Emedded Video）并未正确导出视频URL的。注意这里是嵌入视频的插件，Wordpress导出的直接超链接引用外部视频是正常的。方法是对Wordpress数据库的SQL的wp_posts表的wp_contens字段进行全文检索，确认原先有嵌入视频正常。此处使用ai-agent可大大提升检查和修复效率。
• (7) 视频素材的独立存储桶对应的CloudFront发布点上配置WAF，对引用视频启用WAF ACL的bot校验和限流，避免恶意请求。如果希望使用以前在Wordpress上额外开发的基于PHP语言的CloudFront Signature，可能存在性能问题，因为计算签名开销比较大，在Lambda函数中计算很可能超时，需要调大Lambda分配中的内存以获取更高vCPU算力，这样成本会上升不过会依然保持Serverless的状态。如果并发访问较高，在提供CloudFront Signature时候可考虑用独立的EC2/Container环境提供签名API，这样将不再是完全的Serverless，而是需要维护EC2和容器环境。具体取舍可根据业务要求来确定。

至此视频素材库迁移完成。

4、模版优化

• (8) 使用ai-agent开发方式，优化模版，调整分页、标签、页面背景、div位置和宽度、超链接格式、高亮显示、禁用黑暗模式等。
• (9) 使用ai-agent逐个检查Markdown中引用的代码片段的语言标签，分别标记shell、python等，确认他们标记正确，因为静态网站的渲染时候带有正确的标签后页面渲染会包含高亮显示，否则会出现显示效果异常。

5、运维优化

• (10) 全静态化网站意味着内容的管理仅靠文件版本来进行，无法像动态网站那样决定显示数据库中的哪一条。因此，可打开存储桶的Versioning版本管理功能，并设置S3 Lifecycle生命周期规则，将过期的旧版本过期删除。在存储分层管理方面，因为S3自动分层对小于128KB大小的对象无效，且S3IA不频繁访问层也不会生效，因此对于以HTML页面为主的全静态网站场景，无须使用自动分层。如果网站中包含大量图片、引用素材，他们平均体积远大于128KB，那么建议上传文件时候就把所有文件的存储层设置为自动分层，或者使用S3 Lifecycle将存量文件转换为S3自动分层存储类型。
• (11) Cross-region S3 replication as backup。静态化网站的备份可通过应用端读取S3存储桶的方式实现，不过这样会导致大量对S3的遍历访问。另一种办法是，开启S3的复制规则，将S3所有文件复制到另一个区域、甚至另一个账号的存储桶。由此在作为生产环境的当前存储桶受到错误删除或者其他破坏时候，就可以从远端的存储桶恢复文件。

五、小结

本文介绍了Wordpress在AWS云上部署最佳实践，并介绍了从Wordpress迁移到静态博客的思路。虽然谈到了从Wordpress迁移出来（migration out），但继续使用Wordpress其实并没有什么问题，根据AWS最佳架构的实践做好安全防护，可有效保障业务的正常运行。架构设计以满足特定时间的业务要求为主，避免偷工减料的同时，也避免over-engineering，才能在可靠性、成本、性能、可扩展性中间获得最佳平衡。

最后修改于 2025-09-25