为什么我将Laravel应用程序迁移到AWS无服务器（以及为什么我可以节省您的时间和金钱）

>本文探讨了在无服务器上部署Laravel应用程序的好处，与传统的EC2托管对比。 作者分享了他们的经验从资源密集的EC2设置迁移到具有成本效益且可扩展的无服务器体系结构。

---

---

>

>扰流板：这不仅是要省钱 - 尽管我的钱包并不抱怨。 >

---

想象一下：您已经构建了一个出色的Laravel应用程序 - 您的杰作，数字瑞士军刀，其功能非常有用，可以切黄油或用户反馈。 但是有一个渔获。每个月，您都需要支付未充分利用的EC2实例。缩放感觉就像在飓风中停放一艘游轮。

听起来很熟悉吗？它对我做了。

>

三年前，我做了大多数开发人员所说的疯狂的事情：我将PHP部署到AWS Lambda。 “ PHP？在无服务器上？这就像把菠萝放在披萨上！”他们说。

，但是三年后，我在这里，自豪地吃了我的菠萝披萨。让我告诉你为什么Laravel在无服务器上是您不知道需要的云升级。

>

---

传统的Laravel托管问题

（或：为什么我的EC2实例存在生存危机）

> 在无服务器之前，我的Laravel应用程序驻留在EC2上。对于初学者，EC2是亚马逊的虚拟专用服务器的版本，您可以在其中租用一块机器来运行代码。听起来很棒，对吧？直到现实比流氓

。

a）首先：存在成本composer update

>运行EC2实例就像拥有一个特斯拉，以防万一要驾驶24/7。我的应用程序并不总是很忙，但这并没有停止仪表。在EC2实例，加载平衡器和共享存储空间之间，我每月在大部分时间闲置的服务器堆栈上花费约110美元。我的钱包？像泰坦尼克号一样沉没。

我知道，

在宏伟的方案中并不多，但是作为独奏开发商/企业家，每一美元都很重要。

b）然后：缩放噩梦

ec2实例就像那个朋友过度反应的朋友。

交通峰值？

“我现在崩溃了，谢谢！”

>

没有流量？
• “我仍然会燃烧你的钱！” 管理自动化感觉就像教鱼做杂耍一样，有可能，但是要花多少钱？手动调整缩放组，配置负载平衡器以及祈祷您不会过分的感觉就像我从未申请过的第二份工作。
> c）和最后：devOps，无薪实习生
• 没有人告诉我Laravel Development具有Sysadmin责任的一面：
  • 应用安全补丁。
  • >调试nginx/apache配置在上午3点。
  >
  • 窃窃私语sudo命令，希望他们这次能够工作。

  我没有注册这一生。

  >

  ---

  这是我开始探索替代方案的时候，无服务器作为这些头痛的完美解决方案。

  ---

  aws无服务器：云中PHP的复兴
  >让我们澄清一个神话：无服务器并不意味着“没有服务器”。这只是意味着服务器是别人的问题。在这种情况下，当我专注于我真正喜欢的东西时，AWS会处理繁重的工作：编码。

  a）lambda：事件驱动的巫师

  aws lambda就像一个超级英雄，只有在您需要时出现。它可以响应事件执行您的代码 - HTTP请求，SQS消息，计划的任务，您可以命名。当工作完成后，它的消失速度比开发人员聚会时的免费披萨快。

  >
  >
  没有空闲费用
  • ：您仅支付执行时间（以毫秒为单位）。
  >自动缩放魔术
  • ：得到100,000个请求的峰值吗？ lambda在不汗流的情况下处理它（或清空您的银行帐户）。> >
  无状态
  • ：这就像每次新的开始一样，一种迫使您模块化思考的设计。
  b）托管服务：无名英雄

  >无服务器不仅是lambda，而且是一个生态系统。 AWS用“正常工作”的托管服务代替您的DIY基础架构

  数据库
  ：SQL Lovers的Aurora Serverless（MySQL/Postgres）之类的选项。
  • s3
  ：存储文件而不担心磁盘空间。
  • > sqs
  ：将长期运行的工作解除并异步处理。
  • > c）php悖论
  我会承认：无服务器的php不是
  天生

  。这就像要求鱼爬树一样，它会抱怨，但最终会这样做。传统上依赖PHP-FPM的Laravel需要进行一些调整才能在Lambda的短暂世界中壮成长：

  • >会话：将它们移至诸如mysql或redis之类的外部数据库。
  >
  • 文件存储：使用Laravel的facade将所有存储操作重定向到S3。 Storage
  >队列管理
  • ：将SQS配置为异步任务执行的默认驱动程序。
  >缓存
  • ：利用redis或dynamoDB而不是本地存储等外部服务。> > 启动时间优化
  ：最小化冷的开始是通过修剪脂肪（未使用的依赖性）。
  • > >>环境变量
  ：用AWS Secrets Manager或参数存储替换
  • 用于集中和安全配置管理的参数存储。> .env
  >
  记住，无服务器不仅仅是用lambda函数替换服务器。这是关于重新思考您的体系结构 - 当您专注于构建时，请使用AWS处理操作疼痛点。

  ---

  无服务器如何解锁Laravel的全部电势

  ---

  >那么，Laravel上的无服务器上是否会兑现其承诺？
  3. >无服务器不仅是流行语，而且是变革性的变化。 Laravel在无服务器上的美丽在于它能够解决传统托管弱点的能力，同时更快，更可扩展和具有成本效益的解决方案。但是，当您深入研究这些好处的结合时，真正的魔术就会发生。让我们分解吧。

     >

     a）寒冷开始：将神话与现实分开
  当Lambda初始化一个新实例时，
  >冷启动就会发生。可以将其视为PHP从午睡中醒来。批评者像对待启示录一样对待他们，但它们易于管理：>

  现实

  ：典型的冷始于php laravel大约3-5秒。
  solutions

  ：

  >
  • laravel octane ：在请求之间保持应用程序的活力，以减少启动时间。随后的请求以〜200ms或更少的时间进行处理。
  • >配置并发：AWS预热端点的预热实例（额外的费用，但值得关键端点）
    >。
    对于大多数应用程序，低流量期间的3秒延迟是可以接受的。大多数用户不会注意到寒冷的开始，尤其是在Lambda保持“温暖”的交通尖峰期间。
    • b）无痛缩放 在传统托管中进行通常感觉像是一场永无止境的战斗。使用无服务器，缩放变得毫不费力：在突然的交通涌动中，不再需要调整自动化规则或越过手指。 AWS lambda删除了猜测，默认情况下水平缩放。> 这是一个示例：
    • 方案：您的应用程序流行了吗？是的！
    • >旧的EC2设置：您开始体验延迟，急于登录AWS，手动调整实例数，并为最好的？哦，别忘了在可用区域中正确平衡这些实例。
    • 新的lambda设置：AWS自动根据需要创建尽可能多的实例，处理数千个并发请求而无需举起手指。您抓住一些爆米花并观看CloudWatch指标，例如Netflix系列？。
    >这不仅是便利，而且是安心的。当您专注于庆祝应用程序的成功时，Lambda进行了繁重的工作。最好的部分？您只需支付使用时间的计算时间，而不是为了“以防万一”。

    c）成本效率：MVP

    >无服务不仅省钱，就像拥有一个您只为消费的东西付费的全罐自助餐。

    我的旧EC2设置：
    〜$ 110
    • /月。 4x T3.SMALL EC2实例：
      $ 60.00
      • 1x负载平衡器：
      $ 16.40
      • > > 1x EB（EC2实例之间共享存储）：
      $ 7.80
      • > 1x rds mysql实例（db.t4g.medium）：
      〜$ 26.00
      lambda：
    〜$ 34
    • /月（节省60％！）>。 lambda，API网关〜2.5m请求（〜500ms / 512MB内存） /月：
      $ 4.80
      • >
      >托管服务（S3，SQS，CloudWatch）：
      • 〜$ 2.90 >
      rds mysql实例（db.t4g.medium）：〜$ 26.00
      • >
    简而言之，无服务器不仅可以节省金钱，还可以释放精神带宽。我浪费的资源越少，担心过度提供的资源，我就越专注于构建令人惊奇的东西。

    在这一点上，我仍在使用MySQL实例作为数据库引擎。未来的帖子将探索迁移到DynamoDB以进一步降低成本。

    d）维护自由：与操作噩梦说再见

    >无服务器使我摆脱了服务器维护的束缚。以下是：

    >

    不再手动更新

    ：AWS处理安全补丁，操作系统更新和运行时改进，这意味着您始终在安全和最新的基础架构上运行。

    >

    简化的配置
    • ：使用API​​ Gateway和S3之类的服务，管理NGINX配置和自定义部署的复杂性成为过去。 弹性容量
    ：忘记了未使用的服务器资源的付款或在流量峰值期间争先恐后地提供更多。 lambda自动扩展以满足需求并在闲置时停止计费。
    • 专注于功能，而不是消防：我以前花在应用补丁或调试生产问题的时间用于构建功能并改善用户体验。
    • >无服务器不仅减少维护，还消除了使您无法编码的操作分散注意力。
    • 但是，Laravel对每个人都无服务吗？
    >像Laravel在无服务器上一样革命性，它不是通用的解决方案。对于某些应用程序，无服务器的无状态和事件驱动的性质似乎是一个梦想成真。对于其他人来说，这可能就像试图将方形钉在圆孔中。在跳上无服务器潮流之前，让我们退后一步，评估它是否适合您的项目。>>>>>

    a）无状态的性质：双刃剑

    4. 会话

       ：使用数据库（mysql/postgres）或redis;没有更多的文件系统依赖。

    文件

    ：将文件重定向到S3，或者完全避免使用S3预先签名的URL。
    logs

    ：将laravel配置为将它们流到CloudWatch中。

    • 配置：移动变量到AWS Secrets Manager或参数商店，用于集中管理。
    • >队列：将作业迁移到AWS SQS以进行可扩展队列和消息处理。
    • b）供应商锁定注意事项
    > AWS服务是神奇的，但它们也是专有的：>
    • 是否想从SQS迁移到Redis队列？准备重写代码。
    • >想从Lambda搬到Docker？喝咖啡：这将是一个漫长的夜晚。

    c）当不选择无服务器

    时

    >无服务器并不是所有工作负载的银色子弹。如果：

    >
    • 您需要> websockets：虽然可以使用API​​ Gateway Websocket API或第三方工具等服务来实现，但它增加了复杂性。
    您的应用程序具有重型计算负载
    • ：AI/ML推理或视频编码之类的任务可能会达到Lambda的15分钟时间限制。 您依赖于状态服务
    ：假定持续磁盘或服务器状态的应用程序对重构可能是昂贵的。

    ---

    下一步是什么？

    5. Serverless上的Laravel有可能改变您的构建和部署应用程序的方式，但是真正的魔术在于实现。准备好飞跃并为您的Laravel应用程序提供无服务器处理吗？请继续关注第2部分，在这里，我将指导您确切的步骤，使这种体系结构栩栩如生。

       >
    一个问题：您对无服务器的最大恐惧是什么？在下面分享它，我将在第2部分中介绍前三名！

    ---

    >

以上是为什么我将Laravel应用程序迁移到AWS无服务器（以及为什么我可以节省您的时间和金钱）的详细内容。更多信息请关注PHP中文网其他相关文章！