无服务器php是一项令人兴奋的新技术，有可能消除托管php应用程序的大量负担。从无服务器php中获得最大收益的一种类型的应用程序是wordpress。无服务器php减轻了扩展wordpress的负担，同时提供了与顶级主机相同的性能优势。
为了理解无服务器php如何与wordpress配合使用，我们将看看现代wordpress服务器架构的当前状态。在过去的十年中，这种架构已经发生了很大的变化。（您可以在此处阅读更多相关信息。仅仅使用apache服务器托管wordpress网站的日子已经一去不复返了！现在托管wordpress网站还有很多。
好消息是，托管无服务器wordpress网站看起来很像现代wordpress服务器堆栈。最大的变化是，您将用云提供商的服务替换许多架构组件。
现在，您将使用的服务以及它们如何组合在一起将因云提供商而异。对于无服务器php，最受欢迎的云提供商是aws。这就是为什么我们将专注于aws上的无服务器wordpress架构。
同样值得注意的是，这与使用ymir的体系结构相同。唯一的区别是ymir负责为您管理这一切。（这也是为什么它是一个devops平台。但是，如果您不介意自己或借助其他工具（例如无服务器框架）将所有部分放在一起，本文将帮助您实现这一目标。
让我们从现代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服务器架构，让我们看看它如何转换为无服务器。我们讨论它的原因是基本组件保持不变。不同之处在于，所有这些组件都将由特定的aws服务处理。
全尺寸
使用 cloudfront 的 http 缓存
因此，让我们回到我们的浏览器，您的http请求将首先命中的是cloudfront。cloudfront 是 aws 内容交付网络。您可以使用它为您的无服务器wordpress网站做很多不同的事情。
wordpress网站仅使用cloudfront（或任何其他cdn）来缓存css / js文件和媒体文件等资产。但您也可以将其用作http缓存。这是真正的性能提升所在。
使用cloudfront作为http缓存将显着减少wordpress站点的响应时间。但是，由于 cloudfront 也是一个内容交付网络，因此这种减少适用于所有访问者，无论他们身在何处。与大多数不是全局分布的wordpress http缓存pg电子试玩链接的解决方案相比，这是一个很大的差异。
如果您不想使用 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的理想平台。
麻将胡了pg电子网站的版权属于：月萌api www.moonapi.com，转载请注明出处
