无服务器 PHP - 原生方式

刚刚我在DEV社区看到的一篇文章，感觉很有意思，记录分享之。
我被另一篇文章触动了，该文章声称为 PHP 提供无服务器支持的大部分努力都集中在 AWS 上，并且 AWS 已经对 PHP 提供了本机支持。

从技术上讲，这两种说法都不正确。

首先，AWS 没有对 PHP 的原生支持。在无服务器世界中，支持一种语言意味着给定一个用该语言编写的函数，只需要一个调用方法（HTTP 调用、队列触发器等）来运行它。当您转到 AWS Lambda 并启动一个函数时，您应该能够选择一种语言、编写一个函数并运行它。这意味着您提供代码，AWS 提供运行时来执行它，并且它可以正常工作。

AWS 没有为 PHP 提供该功能。 AWS 提供的是一种定义自定义运行时的方法，您可以在该运行时下执行代码。这意味着您不仅需要提供一个函数，还需要提供运行代码和定义运行时（在本例中为 PHP 解释器）以执行它所需的所有引导程序。或者，您可以提供用于相同目的的 Docker 映像。

问题

AWS 的 PHP 无服务器方法的问题在于，考虑到您是在特定环境中进行设置，这样做的好处不值得付出努力。如果您有时间，请执行 AWS 链接上列出的步骤，然后考虑：

即使在 AWS 中，您也可以简单地设置一个 EKS 集群（AWS 最终改进了他们的工具，足以在几分钟内拥有一个具有合理安全默认值的生产集群）并部署类似 OpenFAAS 之类的东西，它允许您在优化下以各种语言部署无服务器功能容器。这是您在 PHP 上使用 Lambda 的第二个解决方案所获得的结果。

但是拥有 EKS 集群的好处是您可以通过 OpenFAAS（或其他类似的无服务器环境 - 还有 Apache OpenWhisk，我应该对它们进行比较）执行无服务器功能，并在一个应用程序中部署全服务器（？我猜）应用程序Kubernetes 集群并受益于服务网格、自动缩放等优点。

可是等等！还有更多！ Kubernetes 设置也是可移植的！除了创建集群本身，如果明天您决定说“再见 AWS，你好 Azure！”您可以随身携带设置并在几分钟内启动并运行。

GCP 提供什么

与此相反，Google Cloud Functions for PHP 提供了一切，包括 boostrap。这意味着您可以编写一个简单的函数，该函数采用与 PSR 兼容的 RequestInterface 并返回一个字符串响应。

没错，遗憾的是，目前您必须返回一个普通字符串，尽管计划是最终能够返回 ResponseInterface。

除此之外，thins 非常简单。您可以将代码打包在一个 zip 中，以及一个用于依赖项的供应商文件夹。您可以创建具有各种函数的脚本，只要函数满足采用单个 RequestInterface 的标准，就可以将其选为入口点。

令人惊喜的是，相当基本的 PHP 函数（读取环境变量、解码 JSON 请求并使用 env 值 + JSON 请求中的一些字符串进行响应）的性能与 Cloud Functions 上的大多数其他产品相当（针对 Node 和 Go 进行了测试）。大约 100 毫秒的热调用，与冷调用的主要区别是这个普通的 PHP 函数花费的时间更长一些（~1.4s vs 0.6s）。

不要无服务器和框架

只要您不打算将无服务器功能用作穷人的网络服务器并在其背后抛出一个具有复杂路由的框架，这应该是一种补充 API 容量的体面方式。

为什么不是在无服务器函数平台上使用 PHP 框架的好方法？

这是因为整个运行时会上升并最终在函数结束后消失。当请求被触发时，在平台端这是（大致）发生的情况：

运行时已配置

该函数是自举的

函数运行（并且，对于解释语言，加载自定义依赖项）。

现在，PHP 可以并且确实在连续执行之间使用字节码缓存（该函数保持“温暖”一段时间）但最终运行时被“破坏”。

现在，想象一下使用一个框架。在每次执行时，框架都必须使用其依赖项进行 boostrap。由于它属于函数（作为入口点），因此必须在函数本身内完成。您将加载配置管理器、DI 容器、路由器、配置文件以及框架所需的其他内容。

在常规服务器上，事物会缓存在本地持久化的字节码缓存 (opcache) 中。当您使用各种参数调用各种端点时，每次调用所需的东西都会进入该缓存。

在无服务器执行中，雪上加霜的是，您不仅需要在最初预热函数，而且如果函数通过框架路由器管理不同的路由，则每条路由都需要稍微不同的代码，因此即使在连续调用之间

当该特定路由的依赖项不是“暖”的时，有五种情况......所以从技术上讲，它是一堆“冷”请求，导致（有点）较低的性能。 

转：https://dev.to/andreidascalu/serverless-php-the-native-way-odb