无服务器PHP是一项令人兴奋的新技术，有可能消除托管PHP应用程序的大量负担。从无服务器PHP中获得最大收益的一种类型的应用程序是WordPress。无服务器PHP减轻了扩展WordPress的负担，同时提供了与顶级主机相同的性能优势。
为了理解无服务器PHP如何与WordPress配合使用，我们将看看现代WordPress服务器架构的当前状态。在过去的十年中，这种架构已经发生了很大的变化。（您可以在此处阅读更多相关信息。仅仅使用Apache服务器托管WordPress网站的日子已经一去不复返了！现在托管WordPress网站还有很多。
好消息是，托管无服务器WordPress网站看起来很像现代WordPress服务器堆栈。最大的变化是，您将用云提供商的服务替换许多架构组件。
现在，您将使用的服务以及它们如何组合在一起将因云提供商而异。对于无服务器PHP，最受欢迎的云提供商是AWS。这就是为什么我们将专注于AWS上的无服务器WordPress架构。
同样值得注意的是，这与使用Ymir的体系结构相同。唯一的区别是Ymir负责为您管理这一切。（这也是为什么它是一个DevOps平台。但是，如果您不介意自己或借助其他工具（例如无服务器框架）将所有部分放在一起，本文将帮助您实现这一目标。
现代WordPress服务器架构
让我们从现代WordPress服务器架构开始。它看起来是什么样子的？下图显示了浏览器请求WordPress页面时所发生情况的大局。
全尺寸
PHP 之前的缓存
首先，您的浏览器发出的HTTP请求将命中HTTP缓存。此HTTP缓存可以是内容交付网络（也称为CDN）（如Cloudflare），专用服务器（如Varnish）或页面缓存插件的组合。但无论你使用什么，目标都是一样的。
您想要缓存WordPress响应。
这是因为如果PHP（以及扩展的WordPress）比你的HTTP缓存慢得多。因此，您希望 HTTP 响应尽可能多地来自 HTTP 缓存。如果HTTP缓存无法响应您的请求，则会将请求转发到WordPress。
在 PHP 端进行缓存
一旦你点击PHP，事情就更简单了。PHP版本越高，WordPress的运行速度就越快。这就是为什么你总是尝试使用WordPress支持的最高PHP版本。
优化的最后一点是当WordPress对MySQL数据库进行查询时。这些查询通常是WordPress响应您的请求的大部分缓慢的原因。为了使WordPress更快，您希望尽可能减少WordPress的查询数量。
您可以通过使用对象缓存插件来实现此目的。对象缓存插件将MySQL查询的结果存储在高性能持久缓存中。（通常是Memcached或Redis。然后，它会在执行查询之前检查缓存，并返回结果（如果存在）。（就像HTTP缓存对我们的HTTP请求所做的那样。
这大大减少了WordPress响应请求所需的时间。特别是如果您的WordPress项目具有进行大量查询的插件，例如WooCommerce。这就是为什么它是现代WordPress服务器架构的重要组成部分。
无服务器 WordPress 架构
现在我们已经了解了现代WordPress服务器架构，让我们看看它如何转换为无服务器。我们讨论它的原因是基本组件保持不变。不同之处在于，所有这些组件都将由特定的AWS服务处理。
全尺寸
使用 CloudFront 的 HTTP 缓存
因此，让我们回到我们的浏览器，您的HTTP请求将首先命中的是CloudFront。CloudFront 是 AWS 内容交付网络。您可以使用它为您的无服务器WordPress网站做很多不同的事情。
WordPress网站仅使用CloudFront（或任何其他CDN）来缓存CSS / JS文件和媒体文件等资产。但您也可以将其用作HTTP缓存。这是真正的性能提升所在。
使用CloudFront作为HTTP缓存将显着减少WordPress站点的响应时间。但是，由于 CloudFront 也是一个内容交付网络，因此这种减少适用于所有访问者，无论他们身在何处。与大多数不是全局分布的WordPress HTTP缓存解决方案相比，这是一个很大的差异。
如果您不想使用 CloudFront 执行页面缓存，也可以将其配置为仅缓存 CSS/JS 文件和媒体文件。您也可以自由地不使用 CloudFront，也可以使用其他内容交付网络或不使用其他内容交付网络。但请注意，如果没有内容交付网络，性能就不会那么好。
在前往 Lambda 的路上：API 网关或弹性负载均衡
如果 CloudFront 无法响应请求，它会将请求转发到 AWS Lambda 上托管的无服务器 PHP 应用程序。现在，就像普通的PHP应用程序一样，无服务器PHP应用程序不会暴露在互联网上。您需要使用另一个服务来充当两者之间的中介。
对于常规的PHP应用程序，这将是您的Web服务器的角色。但是对于无服务器PHP，本身没有Web服务器。相反，您需要使用两个服务之一与 AWS Lambda 进行通信。这些是 API 网关或弹性负载均衡。
通常，您需要使用 API 网关。（这就是为什么它是图中所示的原因。只有在每月处理数亿个请求时，才应使用负载均衡器。（例如，与 API 网关相比，使用负载均衡器处理 10 亿个请求之间，每月可节省数千美元。但是大多数WordPress网站没有获得那么多流量，因此使用API网关是更便宜的选择。
接口网关类型
AWS还有两个不同的API网关：HTTP API和REST API。您可以使用其中任何一个。也就是说，两者之间有一些重要的区别。
首先是成本问题。REST API 的成本高于 HTTP API。这是因为 REST API 比 HTTP API 具有更多的功能。
这些额外功能是什么？好吧，它提供了http到https重定向。但是，如果您使用 CloudFront 执行页面缓存，则不需要这样做。它将处理 http 到 https 重定向。
它还提供边缘优化的缓存。但这也是CloudFront为我们处理的事情。事实上，您不能同时使用 REST API 边缘优化缓存和 CloudFront。
REST API 还支持通配符子域。仅当您要承载子域多站点安装时，这才重要。否则，您也不需要它。（您还可以使用 CloudFront 函数解决具有通配符子域的 HTTP API 限制。
这一切都是为了向您展示大多数时候您不需要其他REST API功能。因此，您最好少付一些钱，改用HTTP API。
Lambda
一旦请求到达 API 网关或负载均衡器，它就会转换为事件。此事件触发要运行的 Lambda 函数。
此 Lambda 函数有两个组件。将事件转换为 PHP FastCGI 请求的 PHP 运行时。另一个是你的WordPress项目，这是FastCGI请求将运行的项目。
现在，您可以创建一个PHP运行时，但使用现有的运行时可能更好。Bref 是适用于 AWS Lambda 的流行的开源 PHP 运行时，因此它是一个不错的选择。否则，Ymir的PHP运行时也是开源的。
弹性切口
如果您使用的是对象缓存，则需要 Memcached 或 Redis 缓存。ElastiCache是管理这些的AWS服务。因此，如果要使用持久性对象缓存，则需要创建一个。
如果您决定使用一个，请注意，您需要将 Lambda 函数放在私有子网上才能访问它。反过来，这将需要一个 NAT 网关。您还可以将 NAT 网关替换为充当网关的特定 EC2 实例。（您可以在此处阅读有关如何执行此操作的信息。
专有网络
这是启动虚拟私有云（也称为VPC）的好时机。AWS 要求将某些资源（例如缓存和数据库）（我们接下来会看到这些资源）连接到 VPC。有些必须在私有子网（无法访问互联网的网络）上，而另一些也可以位于公共子网（可以访问互联网的网络）上。
如果您全部不使用 ElastiCache，则您与 VPC 的交互将非常少。您只需要 RDS 数据库的公有子网。下面是一个更新的图表，显示了没有 ElastiCache 的 VPC。
全尺寸
如果您需要使用像ElastiCache这样的私有资源，事情会更加复杂。这是需要添加前面讨论的 NAT 网关的位置。但是，您还需要更改某些资源以使用私有子网，例如您的 Lambda 函数。（默认情况下，Lambda 函数不需要子网。
您还需要一个堡垒主机来连接到资源。堡垒主机是充当私有子网的网桥的 EC2 实例。例如，如果要连接到数据库服务器（如果它位于私有子网上），则需要堡垒主机。
全尺寸
上图显示了与 ElastiCache、NAT 网关、堡垒主机和私有子网相同的架构。如您所见，还有更多的活动部件。在VPC配置方面也更加复杂。
断续器
我们的无服务器WordPress架构的最后一个组件是数据库。RDS是管理MySQL和MariaDB等关系数据库的服务。
如果使用公有子网，则数据库将可公开访问。只要您不共享数据库服务器地址，这就不是一个安全问题。但是，这使得在创建强密码时使用强密码变得更加重要。
也就是说，如果它位于私有子网上，则无论如何都应设置强密码！但是，您不必担心数据库可公开访问。但是，正如我们在 VPC 中提到的，您需要创建一个堡垒主机来连接到它。
媒体上传呢？
我们还没有谈到的一件事是上传。当您没有服务器时，上传会发生什么情况？好吧，这部分比我们迄今为止看到的要复杂得多！
全尺寸
上图是更新的图表，向您展示了我们的无服务器WordPress架构在媒体上传时的样子。通过 CloudFront 的请求开始时，情况也是如此。一旦请求到达 CloudFront，它将决定这是无服务器 PHP 请求还是媒体文件请求。（不仅仅是上传的文件）
如果它是媒体文件，则请求将转到 S3，这是最知名的 AWS 服务。它是一种文件存储服务，可让您以低廉的价格将文件存储在云中。有很多WordPress插件可让您将文件上传到S3。
大多数 S3 插件的工作原理
也就是说，与插件相比，当您将S3与无服务器WordPress一起使用时，存在一些显着差异。最大的一个是您如何将WordPress媒体文件发送到S3。使用插件，它看起来像这样：
您将媒体文件上传到WordPress服务器，就像通常没有插件一样。插件本身会在文件进入服务器后注意将文件上传到S3。大多数情况下，这发生在使用WordPress cron的后台。
文件上传如何与S3和无服务器WordPress一起使用？
使用无服务器时，您无法执行此操作，因为没有服务器可以先将文件上传到。相反，您需要立即将其上传到 S3。执行此操作的正确方法是使用签名 URL。
签名 URL 是可用于在 S3 上执行操作的临时 URL。因此，您需要做的是联系S3，它将创建一个签名的URL。然后，您可以使用此签名 URL 将文件上传到 S3，而不会影响您的安全性。
这在实践中要困难得多，因为WordPress并不容易接管这个过程。您也无法直接访问服务器上的文件来创建不同的文件大小。因此，您还需要开发一种方法来创建它们。
到目前为止，这是无服务器WordPress架构中更复杂的方面。这并不是因为AWS有什么具体的东西。这只是因为WordPress是一个古老的软件。它的创建者设计它假设你总是有一个服务器上传文件。（大多数S3上传插件也是如此。没有简单的方法可以告诉它你不想这样做。
也就是说，WordPress非常可扩展。您可以编写一个插件（如Ymir插件），该插件可以劫持WordPress媒体上传过程。（另一个支持直接上传的插件是Media Cloud。这是它与无服务器一起使用所必需的。
与众不同，但也很熟悉
如您所见，无服务器WordPress安装与现代WordPress服务器架构并不完全相同。但它基于相同的基本面。只是您必须依赖AWS等云提供商的服务。
但这也是很多房东已经做的事情。他们依赖于内容交付网络（CloudFront），托管数据库（RDS）和托管Redis缓存（ElastiCache）等服务。因此，两者之间有一些相似的元素。
但是，正如媒体上传问题所强调的那样，无服务器的许多架构挑战都来自WordPress本身。这并不是说它不能在Lambda上运行。它的一些内部工作原理假设总会有一个服务器存在。
也就是说，克服这些问题是值得的。如果您需要扩展WordPress，或者更重要的是WooCommerce，则尤其如此。无服务器提供了无与伦比的扩展潜力。这也是为什么它是WooCommerce的理想平台。
版权属于：月萌API www.moonapi.com，转载请注明出处
