#109: Building serverless apps in PHP with Bref | ft Matthieu Napoli
55:56 Share

本期节目由 Memento 赞助，Memento 是一款值得信赖的无服务器缓存，只收取您使用的费用。要了解更多信息，请访问 goldmemento.co/theburningmonk。大家好，欢迎回到 Real World Serverless 的另一期节目。今天我们邀请到了 Matthew Napoli。嘿，伙计，你好吗？嗨，谢谢你邀请我。我很好，希望你也一样。

是的。我们，是的，我们最近在西雅图的 AWS Hero 峰会上终于见面了。我对 Bref 感兴趣已经有一段时间了。我听到一些人在公开场合谈论它，我还和，我想，嗯，

一家正在使用 Bref 的公司谈过话，他们对它非常满意。所以，是的，我想和你谈谈 Bref，也许我们可以从这个用于构建 Lambda 函数的 PHP 框架开始。你之前在和我们交谈时提到，PHP 有一些有趣的生命周期，这使得它与其他语言大不相同。在我们深入探讨之前，你想先花一点时间介绍一下自己吗？

你的背景，你是如何接触到无服务器的。我知道你以前也为无服务器框架工作过一段时间。所以，是的，跟我们说说你自己吧。当然。所以，首先，我住在法国。目前，我是一名顾问。我创建了自己的公司，主要从事 Bref 的工作，并使用 PHP 创建无服务器应用程序。所以主要的是我

是的，一些背景。我是一名开发者。让我开始接触无服务器的主要原因是我从不喜欢做系统管理员的工作。我曾经使用过服务器，也使用过容器，但我不想让其他人也经历这些。我希望它能像这样简单：我编写我的应用程序，然后将其部署到云端，它就能正常工作。显然，我们都知道它并不像那样简单，即使它应该那样简单。

但这就是我开始接触无服务器 AWS Lambda 的原因，如果我可以这么说的话。我几乎一直都在使用 PHP。所以当我了解到 Lambda 时，我想在 Lambda 上运行 PHP。那是 2017 年的时候。

当时 Lambda 本身并不支持 PHP。现在 Lambda 仍然不原生支持 PHP，所以我启动了一个名为 Bref 的项目，这是一个开源的 PHP 运行时，它基本上允许你在 Lambda 上运行 PHP，并在 Lambda 上运行 PHP 框架。所以我把它作为一个开源项目开始。当时我有工作，然后我辞掉了工作，我想开始工作

理想情况下是全职从事这个项目，但显然你必须在某个地方赚钱。所以我开始做一些自由职业，做咨询。所以从 2017 年开始，我一直都在做这些事情的结合。我确实在无服务器框架公司工作了一段时间。是的，我想是两年，或者三年，在这样一个大型的开源项目上工作真的非常有趣。

是的。我想对于 PHP 来说，你拥有几乎类似于 Lambda 的执行模型，一个请求在一个单独的进程中处理。从这个意义上说，在这个单一进程中没有并发性。

我想对于不熟悉 PHP 的人来说，你能解释一下 PHP 的生命周期与其他语言（例如 Node 或 Java）有何不同吗？这些语言采用不同的并发方法。是的，我想当时这是一个梗，PHP 社区的人们正在发现 Lambda，他们说，哦，这就像 PHP，但适用于所有语言。而

其他社区的人们会发现 Lambda 并说：“哦，这只是将 PHP 模型应用于其他语言。”但这显然比这更复杂。所以大多数运行的 PHP 应用程序都使用一个执行模型，比如一个名为 PHP FPM（FastCGI Process Manager）的引擎。

这个想法很简单，那就是在 PHP 中，你的代码一次处理一个请求。

因此，如果你有 10 个并行请求，你就有 10 个子进程，比如 PHP 子进程。所以一个一次处理一个请求。因此，当你编写代码时，你永远不会考虑，哦，这个变量或这个内存空间是否被不同的请求访问或使用？或者如果我设置一个全局变量，我不知道，比如用户会话在一个全局变量中。

也许我会在不同的请求之间泄漏会话。在 PHP 中不会发生这种情况，因此这使得开始编程应用程序的体验非常简单。因此，在 Lambda 中，你也有同样的想法，一个 Lambda 实例一次只处理一个请求或一次调用。所以这就是我开玩笑说 PHP 是

最适合无服务器的语言之一，因为它的执行模型。但这是一种悖论，它并不是像那些主要语言那样被 Lambda 支持。

是的，至少不是原生支持。我想这就是 Bref 的用武之地，对吧？所以对于 Bref，我知道你有一种可以部署到 Lambda 的应用程序结构方式。但你是否也提供了一个自定义运行时来运行 PHP 应用程序？是的，没错。

只是为了好玩，Bref 的历史始于当时在 Lambda 上，没有所谓的自定义运行时。当时支持一些运行时，比如 Node 和 Python 以及其他一些，你不能做其他任何事情。所以第一个 Bref 版本实际上是 Node 函数，带有一个 Node 脚本，

它会将 PHP 作为子进程执行，并将请求作为 CLI 参数传递，并将响应作为 CLI 参数返回。从某种意义上说，这与许多年前使用 Apache（我认为它被称为 CGI）所做的事情相同，我同意这效率不高。但是，你知道，它有效。我知道一些公司实际上已经将其投入生产，即使它当时是实验性的。

但这就是它过去运行的方式。现在情况大不相同了。显然，Lambda 引入了自定义运行时的概念。因此，您可以添加对任何语言的支持。

在 Lambda 上。这就是 Bref 所做的。因此，你无需编译 PHP（例如用于在 Amazon Linux 上运行的二进制文件），也无需编写所有粘合代码，Bref 会为你提供这些。因此，你拥有所谓的自定义运行时，也称为层。它是一个 zip 文件，包含 PHP 二进制文件，包含

启动 PHP 二进制文件的粘合代码，启动 PHP FPM，连接 Lambda 和自定义运行时 API，并执行所有必要的连接。因此，如果您是 PHP 公司或开发者，您无需考虑如何在 Lambda 上运行 PHP。您可以直接使用该自定义运行时。感觉就像它是一个原生支持的运行时。

好的，明白了。是的，我访问过你的网站，我看到你用来配置函数和应用程序的语法实际上与无服务器框架非常相似。我想你从如何构建应用程序和指定函数方面获得了一些灵感。

我想既然我们在这里，你有什么可以展示给我们，以便让那些不熟悉 Bref 的人看到使用 Bref 的感觉，以及如何部署你的函数等等？当然，我会分享我的屏幕。实际上，目前的 Bref 使用无服务器框架。这就像无服务器框架。它的工作方式，所以这是你在无服务器框架中使用的相同的 YAML 语法。这意味着你必须在你的机器上安装

无服务器框架，也就是无服务器 CLI。这是一个 serverless.yml 的示例，相同的文件。你必须安装无服务器框架 CLI。主要区别在于，那么当它不被原生支持时，你如何支持 PHP 呢？无服务器框架可以在 Node.js、Python 和任何语言中部署函数。只是运行时，你没有原生 PHP。所以这里的运行时，PHP 8.3 FPM，

这是无服务器框架的 Bref 插件提供的。

因此你必须在这里包含这一行。这个 Bref 插件实际上会扩展无服务器框架，并添加对部署 PHP 运行时的支持。所以这指向的是，我想，一个本地插件。你是否也向 NPM 发布了这个插件？是的，没错。这正是人们想到无服务器框架插件时所想到的。你必须将它们发布到 NPM 并使用 NPM 安装它们。这说得通。这是一个 Node 生态系统。我想做的是提供……

对于 PHP 开发人员来说，一种他们甚至不必考虑 NPM 的体验。所以 vendor 实际上与 node_modules 相同，但对于 PHP 来说。所以你使用 Composer 安装 Bref，它就像 PHP 的 NPM。所以不是 package.json，而是 composer.json。我安装 Bref。通过此安装，我拥有运行时的代码。我有 PHP 代码，但是如果我们打开它，

所以我里面有 PHP 代码，但我们还有一个 index.js 文件，那是无服务器框架插件。所以我可以使用相对路径，因为我知道由于 Composer 的工作方式，它将始终是此路径。我可以跳过，你知道，node_modules 和 NPM。

好的。所以这只是为了让那些使用 PHP 的人不必考虑 Node。他们只需要，我想他们仍然需要 Node 才能安装无服务器框架。但是之后，当涉及到管理插件之类的东西时，你有点把他们从，我想，无服务器框架生态系统中赶走了。只是想让他们使用 Bref。是的。所以大多数人都不知道这是如何工作的，或者它做了什么。

我认为他们，就像我说的那样，你真的不必理解。它只是有效。这就像你在 NPM 上有一个 Bref 包一样，你只需要使用，你知道，Bref，但 Bref 没有在 NPM 上分发，因为它是一个，哎呀，它是一个 PHP 包。好的，明白了。

所以你可以在这里看到，我有一个警告，因为我有 IDE 拥有的 serverless.yml 验证，它不识别 PHP，因为那不被支持。但是由于插件，它实际上是有效的。它实际上是被支持的。所以我有一个警告，我可以安全地忽略它。其余的实际上非常非常熟悉。如果你使用 Node.js 编写过无服务器应用程序，我可以使用 URL true，你知道，但是是的，非常熟悉。

我想这是基于无服务器框架版本 3 的，因为我知道版本 4，他们正在进行很多不同的更改。是的，这实际上是 Brave 社区中的一个主题，我们如何处理这些版本？所以 Brave 目前与 v3 和 v4 兼容，我想同时支持两者，并且我想继续支持两者，原因是对于 Bref 用户来说，

他们不会直接与无服务器框架交互。所以他们中的一些人会乐意迁移到版本 4 并使用不再是开源或完全开源的产品，并可能支付许可证费用，这很好。我喜欢支持那些想要支持开源项目的公司。这很棒。

有些人会想要留在 v3 上，我尊重这一点，因为当你开始使用 Bref 时，这并不是协议的一部分。所以我想做的是为无服务器框架 v3 提供长期支持，并基本上让人们尽可能长时间地继续使用 Bref 和 serverless.yml。最重要的是，我还正在研究……所以问题是，现在你看到的是当前的 Bref 体验。你正在编写 serverless.yml，它运行得非常好。

对于那些使用过该框架的人来说，它在部署应用程序方面非常出色。就像在这里，我可以部署单个文件，但我可以部署 Laravel 应用程序、Symfony 应用程序，如果我想的话，还可以部署大型应用程序。当你可能有队列时，它确实开始变得复杂，但主要是数据库，就像大多数 HP 应用程序都有关系数据库一样。也许他们想使用 Redis 进行缓存，也许是 VPC。

所以我想做的是提供 serverless.yml 的替代方案，这使得部署 PHP 应用程序变得更加简单，因为大多数 PHP 应用程序，你知道，非常标准。就像我们谈论 LAMP 堆栈一样，Linux、Apache、MySQL 和 PHP。所以大多数，我看到大多数 Bref 用户都想要数据库。那是，

那是 90% 的人。所以我想提供，这是我现在正在做的事情，但我想要提供一种比这更简单的体验。但无论如何，这正在进行中。所以我不想过多地谈论即将发生的事情，但我们现在有什么？就是这样。

好的。是的。好的。问题是，你使用 Bref 命令还是使用 serverless deploy？Serverless deploy，它会完成它的工作。我在开始播客之前已经部署过了，这样速度会快一点，但是是的，你会得到通常的体验，你会在这里得到 URL。如果我打开它，并且我祈祷一切顺利。这是我默认拥有的 PHP 脚本。

在这里，如果我们查看它，它是一个非常简单的 php 文件，所以实际上，如果你在过去 20 年里见过 php，它看起来像这样，你混合了 php 语言和 html，这只是为了演示，大多数时候它是一个带有正确代码的真实框架，并且你拥有模板等等，它比这要干净得多，但这只是为了演示

好的，明白了。那么在这种情况下，对于那些，我想，习惯于来自 PHP 背景的人来说，如何……

他们必须如何重写应用程序？因为这也是我们经常在其他语言中遇到的挑战之一。你知道，你来自 Node.js，你习惯于编写 Express 应用程序，突然 Lambda 强制你，或者如果你想遵循单一职责函数，你最终必须以不同的方式编写你的应用程序。我想对于 PHP 来说，

你可能也有类似的情况，你习惯于使用框架编写 Web 应用程序。现在使用 Bref，你仍然必须以某种方式构建你的应用程序，以便你拥有 index.php 文件，以及可能用于不同端点的其他 .php 文件。

你知道流量高峰如何导致中断吗？我们本周的赞助商 Memento 可以提供帮助。您是否需要易于配置的基础设施，即使在负载非常大的情况下也能保持强大和响应迅速？您是否希望缓存能够大规模运行，而无需费力地管理和扩展缓存集群？

无需担心单个节点或集群节点会被突然的流量高峰压垮。Memento 为您提供最快的上市时间和最可靠的大规模性能。那么您准备好应对下一个流量高峰了吗？立即访问 gomemento.co/theburningmonk 了解更多信息。好的，回到节目。

你是否也支持 LambdaLift 模型，你可以使用你现有的，我不知道，什么流行的 PHP Web 框架，并且可以直接在 Lambda 函数中运行你的代码？

是的。所以这就是，我不知道 PHP 和生态系统是否与其他语言不同，但我确实看到了，老实说，在 Lambda 上运行单体应用取得了巨大的成功。

我知道很长一段时间以来，我一直都在关注我从社区的不同人那里听到的最佳实践。但这最终回到了观察人们大规模使用 Bref，构建真实的应用程序。并且使用遗留应用程序取得了如此巨大的成功。我有一个关于这方面的案例研究，这非常有趣。我们稍后可以讨论。但是使用遗留单体应用或

或者甚至是使用 Laravel 或 Symfony（这些流行的框架）编写的新的应用程序。你将它放在一个 Lambda 函数中。所以你看到的处理程序文件 index.php，在这里实际上也是一样的。对于 Symfony 和 Laravel，通常只有一个入口点，那就是 index.php。然后你让框架进行路由。所以你不会使用 API 网关进行路由。你只有一个 Lambda 函数，它运行整个应用程序，API，网站，等等。

这运行得非常好。我看到一些人试图将其拆分。我说的是 HTTP 路由，但这通常需要大量的工作。当你这样做时，你会脱离框架。所以我想在语言方面，也许……

我知道我曾经使用过 Express.js，例如，Express.js 提供的层或功能很有用，但它们与 Laravel 的功能并不相同。因此，如果你用 API 网关及其路由和中间件替换 Express.js，并使用授权器，你会获得类似的价值，并且不会因此而损失太多。但是如果你用 API 网关替换 Laravel，你会损失很多。

所以我认为对于 PHP 来说，更有动力坚持使用一个 Lambda 函数，使用一个框架，它运行得非常好。当然，一个例外是当你想要处理，你知道，你有 SQS 队列，或者你想，你知道，对于作业，比如使用 SQS 的队列，你可以有多个队列。你可以使用 SNX 或 EventBridge 在微服务之间进行通信。这在 PHP 中运行得非常好，并且被使用，在这些情况下，你拥有函数。我通常看到的模式是一个函数用于 API 或网站，另一个函数用于处理队列，一个用于事件桥事件，等等。

好的，让我们更深入地探讨一下，因为我真的很喜欢你提到的这一点，如果你正在使用 ExpressJS，并且你正在使用正确的模块化级别构建应用程序，所以你不仅仅是将所有业务逻辑直接放入你的 ExpressJS 或 Fastify 或任何框架中的请求处理程序中。我过去曾在一些公司工作过，他们无法摆脱那个开源 Web 框架。

因为代码中没有分离。没有模块化。所有业务逻辑都直接位于请求处理部分。而不是拥有你自己的，我想，处理创建用户命令或任何其他命令的抽象，你拥有你自己的用于不同端点的抽象，这些抽象最终会调用你的业务逻辑。如果你这样做，那么你的，

你的代码与你在 Lambda 中为各个端点拥有各个函数的情况非常相似。API 网关取代了你 Express 中的大部分配置和横切关注点，身份验证。中间件被 API 网关为你做的东西所取代。但我并不完全理解你的意思……我理解你所说的，好的，当你使用 StateNode 时，你不会损失太多。

但这与 Laravel 或 Symfony 不同。我没有完全理解这一点。当你使用 Lambda 进行单一职责函数时，你还会从这些框架中获得哪些其他东西？是的，这是一个好问题。所以我想做到详尽无遗，但我想要——显然，这是我的即兴发挥。但如果我只是考虑身份验证，

我长期以来都是 Symfony 用户。我最近越来越多地使用 Laravel，并且我对 Laravel 开箱即用的功能数量感到震惊。所以如果我们只考虑身份验证，如果我们使用 Laravel 进行身份验证和处理用户，开箱即用，你会得到，显然你会得到登录、注销表单和类似的

使用密码进行身份验证，但你也会得到密码轮换。密码被安全地加密和哈希，而无需轮换密钥。你开箱即用地拥有多因素身份验证。你拥有团队管理。你忘记了密码，所有电子邮件都会为你发送。你可以在身份验证页面上设置一些速率限制。

我知道对于这一个部分，也就是身份验证，你只需要这么多东西。而且你显然拥有权限系统，你可以在不同的路由上设置权限，并拥有中间件进行身份验证，比如这些路由是私有的，这些是公共页面，并且你拥有角色。所以你可以说对于某些用户，你可以访问此路径，而不能访问此路径。所以当你只看这部分时，你使用 Laravel 可以获得这么多，如果你放弃

比如从你的 PHP 应用程序的整个请求流中删除身份验证，那么你会失去所有这些。

如果你查看所有其他中间件或，你知道，你可以使用 Laravel 获得的 HTTP 逻辑，是的，这不是我想放弃的东西。所以这是一种，我并不是说这是一个对每个人来说都很简单的决定，而且总是相同的，但我看到很多中小型公司使用该框架，并且可能不会与该框架分离

是有意义的，因为你通过充分利用框架可以获得很多好处。在其他一些情况下，显然你可能想要与框架分离。对我来说，这与与 AWS 分离的逻辑相同。有些公司可能会说，哦，我们需要在我们的代码和

AWS SDK、Event Bridge、Event Message Format 甚至 SQS 行为以及 AWS 提供的任何其他内容之间有一个抽象层吗？我们需要从这些内容中抽象出来吗？我想这取决于情况，因为如果你只是开始使用 AWS 服务，那么你可以开始使用，它可以正常工作。是的，这取决于公司和你的目标，你可能想要分离，或者你可能想要立即使用它并获得它的全部好处。

好的。好的。所以我想这有点让我想起了使用 Amplify 时获得的那种东西，因为 Amplify 在你的 GraphQL 模式上为你提供了额外的指令和类似的东西，以便你可以对一些细粒度的访问控制位进行建模。

你可能必须在 Cognito 和你自己的解析器代码之间实现这些。所以通过对你的领域进行建模，Amplify 为你提供了更多可以为你做更多事情的工具。我想在这里关于身份验证的情况也是类似的，中间件本身提供了更多开箱即用的功能，包括登录、注销屏幕，如果你想要更，我想，更符合品牌的东西，你必须自己构建这些东西。你拥有你自己的徽标和颜色等等，这对于 Cognito 来说并不容易。所以托管了域名。好的。所以我们多次提到了 Laravel。如果人们使用 Laravel，那么也有 Laravel Vapor。那么那里的决定是什么呢？他们如何选择使用 Bref 与 Vapor？

是的，这是一个好问题。Bref 是多种事物的组合。Vapor 也是多种事物的组合。所以为了澄清，你拥有 PHP 运行时本身。在这两种情况下，它几乎是一样的。Vapor 和 Bref 的工作方式非常相似。

我认为没有人们可能会注意到的区别。主要区别在于部署体验，我想。Vapor 不是基于 CloudFormation，也不是基于 serverless.yml 或类似的东西。大多数部署发生……你有一个 yml 配置文件，但大多数部署发生在他们的……他们有一个 SaaS。它将 SaaS 部署到你的 AWS 帐户中。所以你有一个 UI，你通过 Vapor 部署到你的 AWS 帐户中。而

是的，就是这样。对于 Bref，你拥有 serverless.yml 文件，你使用 CloudFormation 无服务器框架将其部署到你的帐户中。我还未提及的一点是，Bref 实际上与 CDK 兼容。我们确实发布了一些 CDK 结构。它与 SAM 甚至 Terraform 兼容，因为它是，再次，你拥有运行时，然后你拥有

你想要使用的任何部署工具。所以如果你对无服务器框架不感兴趣，你可以使用这些东西。所以是的，主要区别在于 Bref 从你的机器部署到 AWS，Vapor 从 SaaS 部署到 AWS。并且因为他们这样做，他们能够

例如，提供一些指标，一个仪表板，你可以在其中查看有关你部署的应用程序的一些信息，老实说，我真的很喜欢这一点。Vapor 的体验是我在某个时候渴望用 Bref 实现的目标。所以几年前，我发布了 Bref 仪表板，这是一个 AWS 控制台的替代方案，你可以在其中查看你的应用程序、日志、指标等，

但同样，因为我没有 SaaS，你必须在你的机器上本地运行应用程序，它使用你的本地凭据并连接到 AWS，并显示你拥有访问权限的任何内容。这说得通吗？所以这里的模型有点不同。而我实际上……是的。继续，继续。

我想因为你使用的是无服务器框架，因此是 CloudFormation，你还会获得 CloudFormation 提供的其他功能，例如能够设置输出和导出，以便你可以拥有多个可能相互引用的应用程序，因为你可以创建这些，比如 CloudFormation 输出，或者创建类似 SSM 参数的东西，以便你可以与可能想要调用你的 API 的其他服务共享你的 API URL

或引用其他服务，传递信息，如共享 VPN、VPC ID、安全组等等，而 Vapor 更侧重于 Laravel 本身，所以更少关注 CloudFormation。所以如果你想将其他东西带入你的应用程序配置中，他们是否允许你配置，比如将 DynamoDB 表作为应用程序的一部分或其他类似的东西？

不，但是您拥有 AWS 账户。所以假设您，我见过好几次人们从 Vapor 开始，他们的 Laravel 应用程序运行良好，数据库也运行良好。但是，您想走出 LAMP 堆栈，例如使用 EventBridge 或 SNS，甚至 SES 和 DynamoDB 等。

您必须手动操作。您必须自己弄清楚 AWS。然后你就完全脱离了 Vapor。所以我希望拥有与 Vapor 一样好的体验，但要受到限制，这就是我的目标，你知道，我的，我的北极星就像那种体验，嗯，呃，

寻找一个好的解决方案，这样你就不会局限于拥有一个 SaaS，拥有对您帐户的管理员访问权限（这对某些公司来说是一个障碍），并停留在 CloudFormation 中，并为您提供更轻松地走出基础的工具。部署 Laravel 应用程序是一回事，然后您会像您说的那样，例如 DynamoDB 表格或其他任何东西。您无需从 AWS 开始就从头开始。

这是我正在探索的一个名为 BraveCloud 的东西，这是一个我目前正在试验的项目，您可以在您的帐户中部署 SaaS，但您也可以自行托管某些东西，这是一种解决第三方访问帐户问题的方法。它全部基于 CloudFormation。因此，您可以像在 serverless.yml 或 SAM 或 CDK 中一样，自带配置

或构造并部署 DynamoDB 表格或您想要的任何内容。因此，您可以轻松地开始，然后扩展而无需从头开始。这就是我的愿景。我试图记住这些约束来找到一个良好的体验，因为我不是，所以 Bref 的受众我认为与您可能正在经历的并不相同，例如

一些 Bref 用户和公司，他们想使用 AWS。他们看到 Bref，他们想，哦，也许我们会使用 Bref。但我们想使用 AWS。我们将接受 AWS 培训，我们将学习 AWS，我们将尽可能多地使用它。这就像少数派。大多数 Bref 用户都想要一个可扩展、冗余、易于部署的应用程序，而无需启动 Kubernetes 集群并变得过于疯狂。因此 AWS 是一个优势，但他们并不真的想

接受培训成为 AWS 大师。我想提供尽可能轻松地进入 AWS 的途径。好的，好的。所以我想在这种情况下，您所说的意思是，好吧，让我们继续。就 Bref 与 Laravel Vapor 相比而言，Laravel Vapor 是关于将您的 PHP 应用程序部署到 Lambda，以便您获得所有可扩展性、冗余性和 DevOps 自动化等功能。

但一旦您想走出代码范围，它就不会帮助您。您想开始使用其他 AWS 服务，而 Bref 因为它是基于 CloudFormation 的，所以您可以创建一个应用程序，一个基于 AWS 的应用程序，一个使用 PHP 的云原生应用程序，您可以拥有所有不同的工具。但是您接下来要说的是，实际上许多公司并不是那种想要构建云原生应用程序的公司，他们只是想要

构建一个在云中运行的 PHP 应用程序。所以也许他们没有直接考虑。他们想使用 EventBridge。他们想使用 SNS。他们只想从使用数据库的 PHP 应用程序开始，该数据库连接到例如 RDS。好的，明白了。绝对的。大多数人实际上只有一个 ASP。

AWS CloudFormation 堆栈，一个应用程序，或者只是一些，但我们不是在谈论一起工作的微服务。您有一个大型应用程序，您正在寻找替代方案……通常的路径是您从 VPS 或服务器或其他任何东西开始。你有一件事，它有效

但是，当您需要多台服务器来实现冗余时，您就会跨越一个阈值，因为业务现在需要它，或者您达到了扩展限制。因此，您需要从 1 到 N。因此，您可以选择，我是否想维护多台服务器并进行负载平衡，并在其中一台服务器崩溃时进行恢复？

我是否使用 Kubernetes 并让 n 变成无限大，那么我必须管理集群，或者我是否使用 Lambda？因此，Lambda 是一种替代方案。但是您仍然有一些公司全力投入 AWS 和微服务，它们并不完全遵循相同的模式，但我认为这在很多情况下是少数。通常我称 Lambda 和 Brave 为 AWS 的入门毒品，因为他们开始了。然后他们想，哦，实际上，

我们可以使用 SES，并且每当 S3 上上传新文件时，我们可以使用一个事件来执行此操作。也许我们可以将其推送到该新服务中，以便营销团队或其他任何团队可以进行补充工作。因此，他们像这样慢慢地开始使用 AWS，然后他们扩展。我发现看到这一点非常有趣。一旦他们进入 AWS，它就会启用新事物。所以这通常不是第一个目标。

对。是的，因为这很有道理。因为在 PHP 服务器上，如果您只是在构建，如果在 VPS 上运行，那么您可以拥有 cron 作业。我看到人们这样做，你知道，所有 cron 作业和后台任务都在与您的 API 服务器相同的服务器上运行。显然，这在基于 Lambda 执行的服务器上不会真正有效。

模型，因此您必须开始考虑，如果我需要一个每天运行的 cron 作业，你知道，在每一天结束时，我不能像以前那样把它塞进我的应用程序层，我必须有一个单独的东西由计划在

每天的特定时间。这会让您开始研究 EventBridge、cron 表达式和 Lambda 函数，然后从那里开始，也许会公开到 S3 进行存储，也许会公开到 DynamoDB 进行数据库。好的。

我明白了。所以我想您正在谈论一些不同的客户，他们有不同的采用模式。您是否有成功的案例可以分享，例如今天在网站上使用 Bref 的客户？它说你们有一些，是什么，上个月用 Bref 处理了 600 亿条消息。所以显然一些相当大的客户已经在使用了。

是的，360 亿次 Lambda 调用。我不使用 Lambda 调用，因为它对新用户来说有点不清楚。所以我使用请求或作业，但这是所有 Ref 用户的 Lambda 调用，并且实时刷新。我的意思是，显然有一个缓存，但这是来自 CloudWatch 的指标。这是我通过在 Ref 内部实现的匿名遥测来收集的指标。

但是，基本上 BREF 已大规模使用，并且遍布许多公司。我通常会遇到的问题是，对于哪种项目、哪种应用程序，Bref 或 Lambda 和 PHP，所有 PHP？它适合在哪里？我认为答案并不在于项目本身。为了说明这一点，这些是我通常会提供的示例。

所以我有一些非常小的项目，比如我的博客，或者你知道，我运行在 Lambda 上的一些小项目，因为它非常便宜。它非常简单，我推送它，它就被部署了，已经有五年了。我不再玩了。它仍然运行。顺便说一句，我过去使用过 VPS，然后保持更新，例如

我有 VPS，我有一个旧的 PHP 版本。我部署一个新网站。它不起作用。我需要升级 Apache。我需要升级 PHP 版本。我需要确保 MySQL 已更新，然后是安全性。对于小型网站来说，使用 Lambda 简单得多。

然后，我认为，中等范围，我有一些公司每月有 1 亿或 1 亿个请求。甚至更大规模，例如 Sua Musica。这是我所知道的最大的 Bref 网站。Sua Musica 是一个巴西网站，就像一个巴西 iTunes。它在巴西非常受欢迎，他们使用 Bref 运行。

他们每月处理超过 10 亿个使用 PHP 和 Graph 的 HTTP 请求。所以这是一个巨大的规模。所以这些是一些例子，你知道，甚至在他们用它做什么？它到处都是。

有些人只是使用 pref 运行 API 或应用程序。有些人只转换作业，后台作业，因为应用程序在服务器上运行良好，而且很好。只是处理尖峰工作负载的作业，后台作业，在服务器上不起作用。所以他们转移到

只将那一部分转移到 sqs 和 lambda，它会飞起来，因为您可以从零扩展到几乎无限……所以一些客户这样做，而且……同样，一些客户全力以赴使用微服务，我有一个关于 Trezo 的故事，这是一家法国公司，他们就像，他们是一家银行，他们就像一家银行即服务，用于……新银行，所以如果你像

我在想他们的客户。我不认为 Revolut 是其中之一，但 Lydia 是其中之一。以及一些在法国广为人知的参与者，当我实际上使用时，在 Trezor 上运行。所以他们当时拥有的一个巨大的单体遗留 PHP 应用程序正在服务器上运行。所以他们所做的是将该应用程序迁移到单个 Lambda 函数中。

整个事情，即使这不是一个好的模式，但这就是他们所做的。显然，他们进行了大量的测试，例如负载均衡器以逐步切换流量等等，但是

最终，他们将旧的单体代码库放在一个用于 HTTP API 的 Lambda 函数中，并且它有效。它实际上提高了他们的响应时间。它减少了事故数量。因此，他们仅仅将遗留应用程序迁移到单个 Lambda 函数就得到了改进。然后他们进行了第二次迁移，将遗留应用程序拆分为不同的微服务。

借助 API Gateway，基于路径，它会转到不同的 API Gateway，然后转到不同的 Lambda 函数。两步迁移，获取遗留应用程序并将其放在 Lambda 上只是为了使用托管的可扩展性和简单性，然后将其拆分为微服务，然后他们采用。我不确定他们是否使用 SNS 或 EventBridge 进行通信，但是，然后您可以利用 AWS 提供的所有功能。

对他们来说，这次迁移非常成功。但我试图说的是，有些人只停留在单体 API 上。有些人甚至走得更远。您在所有这些点都有好处，你知道。

是的，我认为这是一个越来越流行的模式。人们想要使用无服务器或专门的 Lambda，因为您可以获得所有可扩展性、安全性和冗余性优势，但他们不想重写整个应用程序。因此，Lambda 提升方法非常适合这种情况。但我认为很多

也许无服务器生态系统中的人们，包括我自己，仍然希望人们更多地考虑细粒度的 Lambda 函数，以便您拥有更细粒度的访问控制和监控等功能。我想，这可能是一个问题，然后是给你的。对于使用例如 Bref 运行单体的人来说，

可观察性如何？因为这意味着您有一组用于延迟和错误的指标。然后您如何调试，例如，一条路由出现错误并触发警报，但所有内容都来自一条路由。您会做些什么？您可以在 PHP 生态系统中利用哪些东西来使调试更容易？

是的，这部分不是很好。我认为这是 PHP 没有赶上无服务器生态系统其余部分的一件事，因为您有很多现有的工具或 SaaS 来监控无服务器应用程序。其中一些，大多数，我不知道，我不知道确切的数字，但它们不支持 PHP。所以，

是的，这不是最好的故事，我会这么说。我看到人们所做的是只使用来自 CloudWatch 的 API 网关指标和日志，并尝试继续使用它。我正在开发 X-Ray 集成，因为我认为这对 PHP 来说非常缺乏。我们没有对 PHP 的 X-Ray 支持。所以你可以忘记它。这是我想修复的事情。

我有一个更好的包。我在我自己的项目中使用它，它非常棒。我之前没有使用过 X-Ray，就是因为这个原因。所以我发现 X-Ray 非常有趣。但是，我认为您有 New Relic、Datadog。它有点分散。您有一些专门针对 PHP 的分析工具。您有 Tideways，您有 Blackfire。所以他们可以提供……

例如，对单个路由或单个调用的深度跟踪，你知道。有些更多的是关于按路由聚合的。但我要说实话，我认为它不如 Node.js 中大多数情况下存在的东西，以及您可以在 Node.js 中获得的东西好。所以，是的，然后我不确定您是否按路由拆分。使用 API Getaway，您可以观察到，例如，您可以按 HTTP 路由查看平均延迟。

是的，您启用了可以使用的详细指标，但这显然会带来额外的成本，额外的，你知道，也许仪表板将有更多内容需要查看才能找出，好的，如果存在聚合，则存在更高的延迟，哪个端点为此负责。但那是……

所以更详细的路由，您会以额外的成本获得 API 网关方面的更详细的指标，当然。是的。我看到的大多数人都不走这条路。他们有一个单一的延迟功能。

他们有一个单一的端点，所以他们有一个单一的延迟指标。然后我看到很多 Sentry 的使用，它主要用于错误，但它也具有跟踪功能。这并不完美，但能够拥有与 X-Ray 相同的行为实际上还不错。这是一件事。您有与 Sentry 非常相似的替代方案，但主要侧重于错误，例如 Bugsnag 或类似的东西。

好的，明白了。那么性能和冷启动呢？PHP 会导致一些运行时吗？然后还有 PHP，我想，Laravel 应用程序本身。那么它们是否会引入大量的冷启动？我不知道 PHP 冷启动特性与 Node 或 Python 等相比如何。

我试图确保我有正确的数字。但是，如果您只使用 PHP 层，那么您将拥有一个 hello world，我没有提到的一件事是，我们实际上在 Brave 中有三个运行时。一个是用于运行控制台命令的。让我们忽略它，因为它是一个非常利基的用例。所以我们有两个运行时。我在演示中展示的一个以及我们从一开始就一直在讨论的一个是 FPM 运行时。所以它使用 PHP FPM 运行。

就像您在任何服务器上运行的东西一样，所以它与无服务器 Web 适配器模式非常相似。这是最常用的一个。这个的冷启动时间约为 300 毫秒。

当用作具有层的自定义运行时时。那是基础的东西。我认为大部分时间都是启动 PHP 进程，但也包括在内部下载 zip 文件，Lambda 下载或启动运行时。涉及一些延迟。所以它还不错，但它不是最好的。显然，它不是最快的。

第二个运行时是关于在没有 FPM 的情况下运行 PHP 代码的。这主要用于 EventBridge、SQS，任何不涉及 HTTP 的内容。这个的冷启动时间为 250 毫秒。所以它稍微快一点，因为它不包含 FPM 二进制文件。它只是小一点。

但是，这就像一个空的应用程序。如果您使用默认的 Laravel 应用程序，它会很大，尤其因为它包含所有 API 的整个 AWS SDK。我认为它包含供应商的代码超过 100 MB，就像 PHP 的节点模块一样。所以它很大。如果您不预编译或预缓存某些内容，则会涉及初始化。所以它可以高达一秒钟。

通常，默认的 Bref 体验是您只需部署它即可工作，因为我们会在运行时编译内容。但是，如果您要进入生产环境并想要优化冷启动，您可以这样做。您可以预缓存路由并预缓存

我不知道，比如视图，您可以预缓存很多东西，它会变得更好一些。我会说，使用真实应用程序的平均值约为 500 毫秒。所以这是您必须准备好接受的事情。

但是，大多数时候，您必须权衡冷启动的利弊。所以我想就冷启动而言，它与您在 Node 中获得的结果非常相似，这取决于应用程序的大小。但这只是关于……的影响有多大，例如 Laravel 或 Symfony 对您的整体冷启动时间的影响。

但我认为现在很多都取决于您的流量模式，而不是其他任何东西，因为主动初始化。您可以节省很多冷启动，或者至少在函数为用户请求提供服务之前让它们发生。如果您的模式相当稳定，那么您可能会没事。但是，如果您有相当尖锐且可预测的流量模式，那么您可能会看到更多冷启动。

因此，您可能需要付出更多努力来确保在发生调用时，您的 SLA 仍然可以接受。这也许是，我不确定您是如何进行预缓存的，它是如何工作的？我不熟悉 PHP。所以这是一个您在编译 PHP 应用程序时可以打开的标志吗？它实际上不是特定于 PHP 的。它是特定于框架的，例如 Symfony 和 Laravel，它们都有自己的缓存。我的意思是，他们……

他们将一些视图或 PHP 配置文件预编译成优化的 PHP 文件。所以它都是基于文件的。因此，您可以在部署之前运行一个命令，它只会以更优化的方式存储数据。仅适用于特定数据结构，例如配置、视图，一些主要配置内容可以预解析和优化。所以它都是基于文件的。它可以部署在正在部署的存档中。

当你……实际上，是的。好的，继续。对不起，我只是想问你一个问题。所以这是我对它的一种假设，但我看到的另一个优势是拥有单体应用程序，您有一个用于整个 API 的 Lambda 函数，这当然不是魔术，但您应该拥有，这就是我的想象，更少的冷启动。因为……

您总是在公共网站或 API 上有一些流量，这意味着您不太可能在一些路由上出现冷启动，这些路由较少，你知道，它们接收的流量较少。在我看来，是的，冷启动对于单体应用程序来说会更糟糕，但与此同时，您会获得更少的冷启动。我不知道您是否有这些的具体数字，这些，

是的，有一些具体的数字可以比较应用程序的代码启动次数，这些代码启动次数作为单个单体或作为单个函数运行。但在大多数情况下，如果您有足够的流量来维持

而且在整个 API 中相当稳定。如果相同的流量模式在不同的端点上大致相同，那么这些端点将具有相同的特性，就以下方面而言，好的，您实际上不会看到很多冷启动，因为流量稳定。但是，如果您遇到这种情况，对于整个 API 来说，有一个很好的钟形曲线，

但是，因为您有很多不同的路由，并且使用模式如此不同，以至于某些端点将没有任何内容，然后砰的一声，然后砰的一声。那么情况可能是您在某些端点上看到更多冷启动，但在其他端点上，您还可以。所以它真的取决于流量模式。我认为对于我使用的大多数应用程序来说，当然，

使用模式对几乎每个人来说都是一样的。您使用 Twitter，您进来，阅读您的 feed，您进行交互。每个人都会定期做一些事情，所以没有人真正使用的事情

您可能会遇到更糟糕的冷启动。例如，没有人真正访问页面来阅读法律文件，或者也许没有人真正访问页面来设置配置文件，更新个人资料图片或类似的东西。因此，可能有一些端点几乎没有人使用。所以你会看到，你知道，

更多冷启动，但因为它们只占总请求计数的一小部分。因此，如果您正在测量例如 P99 延迟，比较两者，它可能会平衡。

但是，如果您有一个总体上流量不多的应用程序。所以如果您像，你知道，一个相当受欢迎的应用程序，那么钟形曲线就足以确保每个端点，所有这些流行的端点，也都会有一个钟形曲线。但是，如果您刚开始，您正在启动一个新应用程序，只有例如，我不知道，每小时数百个请求。所以你的钟形曲线，你知道，它会……

它将足以维持一个或两个 LambdaLift 实例，因为每隔几分钟就会有一个请求。但它将不足以维持具有单个端点的单个函数，因为它意味着一个端点每 20 分钟会收到一个请求。每次都会是冷启动。因此，您可能需要一个基线流量量

来维持在您拥有一个函数对应一个端点与 LambdaLift 时不会出现很多冷启动。当您拥有非常低的吞吐量 API 时，这是正确的。但是，一旦您每天或每小时获得一定数量的请求，差异可能会消失。是的，有道理。好的，很有趣。

所以我想这就是我想到的一切。您还有什么想分享的吗？任何类型的未来项目或您想告诉我们的事情，让大家注册，例如 Bref 的书籍、课程，也许？

好吧，这是每年的这个时候，通常我会等待每一个，我的意思是，我说我只发布了两个主要版本的 Bref，但我正在开发版本 3。所以这是我进行大量头脑风暴的时刻，我试图思考 Bref 中缺少什么。从运行时本身来看，我正在考虑升级，你知道，在 Lambda 上，有 Amazon Linux 版本，所以我正在尝试升级 Amazon Linux 版本，这意味着

重新编译 PHP 并更改很多幕后看不见的东西，这真是令人沮丧的工作，但必须完成。这是我正在努力的事情。我还致力于支持 Lambda 流式响应。这是我非常想做的事情，但它在技术上同时在自定义运行时中实现，并使其与框架一起工作，并为 PHP 用户提供一个不错的 API。

正确地做到这一点需要一些时间，所以这并不简单。所以是的，我正在努力实现 Brevv3，也试图找到，正如我提到的那样，Bref 从面向无服务器框架的东西过渡到更像

主要原因是无服务器框架正在发生变化。有 v4，它的开源模型和商业模型略有不同。因此，找到一种方法来支持和继续维护您的无服务器框架 v3，同时支持 v4，以及使用 CDK、SAM 和 Terraform 进行扩展，例如为 ref 用户提供选项。

并致力于这个最终选项，我再次称之为 Brave Cloud，这是一个更简单的配置体验，您可以非常简单地拥有应用程序，以及数据库、VPC、缓存，并使用 UI 进行操作。

是的，这是目前占用我大量时间的事情。我对进展感到非常兴奋。在这些事情上工作真的很有趣。它仍在测试阶段。如果任何收听此内容的人有兴趣，我很乐意获得一些关于该产品的反馈。但是，希望我很快就能展示一些东西。这就是我现在正在做的所有事情。

好的，听起来不错。所以是的，如果任何收听的人正在使用 PHP 并想探索使用 PHP 与 Lambda，那么是的，尝试使用 Bref 并让 Mathieu 知道您的反馈，以便您可以帮助塑造 Bref 的未来版本。所以是的，Mathieu，非常感谢您来到这里，祝一切顺利，希望今年在 reInvent 见到您。是的，我希望如此。我真的很希望如此。我还没有预订任何航班，但我真的很想去。

好的，听起来不错。完美的。我会在那儿见你的。好的，保重，伙计们。下次见。感谢 Memento 对本集的支持。要了解有关其实时数据平台以及它们如何帮助您加快产品开发的更多信息，请访问 gomemento.co/theburningmonk 获取更多信息。

这就是另一集《真实世界无服务器》的全部内容。要访问节目笔记，请访问 realworldserverless.com。如果您想学习如何构建可用于生产环境的无服务器应用程序，请查看我在 productionreadyserverless.com 上即将推出的课程。下次见。