為什麼我將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中文網其他相關文章！