無服務器啟動-服務器崩潰！ · HighScalability 中文示例

# 無服務器啟動-服務器崩潰！ > 原文： [http://highscalability.com/blog/2015/12/7/the-serverless-start-up-down-with-servers.html](http://highscalability.com/blog/2015/12/7/the-serverless-start-up-down-with-servers.html) [![teletext.io](https://img.kancloud.cn/b9/51/b9513cc1ca8c4516b99cdef225a35eab_288x288.png)](https://teletext.io/ "Teletext.io - content as a service") *這是來自 [Teletext.io](https://teletext.io/ "Teletext.io") 的 [Marcel Panse](http://www.linkedin.com/in/marcelpanse "Marcel Panse") 和 [Sander Nagtegaal](http://www.linkedin.com/in/centrical "Sander Nagtegaal") 的來賓帖子。* 在早期的 [Peecho 時代](http://www.peecho.com/ "Peecho")中，我們[寫了一篇文章](http://highscalability.com/blog/2011/8/1/peecho-architecture-scalability-on-a-shoestring.html "Peeacho architecture - scalability on a shoestring")，解釋了如何使用 [Amazon Web Services](http://aws.amazon.com/ "Amazon Web Services") 構建真正可擴展的架構。自動縮放，無情的解耦，甚至對未使用的服務器容量進行自動出價，都是我們當時用來操縱的技巧。現在，是時候將其進一步邁出一步了。我們想介紹 [Teletext.io](https://teletext.io/ "Teletext.io - content as a service") ，也稱為*無服務器啟動*-再次完全基于 AWS 構建，但僅利用了 [Amazon API Gateway](https://aws.amazon.com/api-gateway/ "Amazon API Gateway") ， [Lambda](https://aws.amazon.com/lambda/ "AWS Lambda") 函數， [DynamoDb](https://aws.amazon.com/dynamodb/ "AWS DynamoDb") ， [S3](https://aws.amazon.com/s3/ "AWS S3") 和 [Cloudfront](https://aws.amazon.com/cloudfront/ "AWS Cloudfront") 來實現。 ## 約束的美德我們喜歡規則。在我們之前的初創公司 [Peecho](http://www.peecho.com/ "Peecho printing") 中，產品所有者必須為每個想要添加到正在進行的 sprint 中的用戶故事支付*五十次俯臥撐*。現在，在我們目前的公司 [myTomorrows](https://mytomorrows.com/ "myTomorrows - expanding access to drugs in development") 中，我們的*開發人員舞會*頗具傳奇色彩：在每日站立時，您只能在跳舞時講*- 導致有史以來最高效的會議。* 這種思維方式一直貫穿于我們的產品開發。乍一看似乎違反直覺，但限制了創造力。例如，我們所有的徽標設計都是通過技術制圖工具 [Omnigraffle](https://www.omnigroup.com/omnigraffle "Omnigraffle") 完成的，因此我們無法使用可怕的*鏡頭光斑*等。無論如何-最近，我們發起了另一個計劃 [Teletext.io](https://teletext.io/ "Teletext.io") 。因此，我們需要一個新的限制。 *在 Teletext.io，我們不允許使用服務器。連一個都沒有。* 這是一個不錯的選擇。我們將解釋原因。 ## 為什么服務器損壞在過去的幾年中，Amazon 云已經使我們非常滿意能夠使用 EC2 服務器實例的自動擴展群集，并在其頂部具有負載平衡器。這意味著，如果您的一臺服務器出現故障，則可以自動啟動新服務器。當出現意外的高峰流量時，也會發生同樣的情況。然后將啟動額外的服務器。盡管這很酷，但也有缺點。 * 首先，即使您沒有任何流量或收入，您**仍需要保持最少數量的服務器實例**處于活動狀態，以便能夠為任何訪問者提供服務。這要花錢。 * 其次，由于云實例在操作系統之上運行已安裝的軟件，因此您不僅需要維護自己的代碼，還需要**確保服務器軟件保持最新**并可以運行。 * 第三，您**不能以精細的方式**向上或向下擴展，但一次只能一臺完整的服務器。在基于帶有微服務的 API 的體系結構中，這意味著小任務的開銷很大。幸運的是，現在有解決此問題的選項。首先讓我們看一下眼前的問題。 ## 抓癢我們全新的解決方案源于個人對自定義軟件中*內容管理*的不滿。在大多數初創企業中，按鈕，儀表板，幫助部分甚至整個網頁中的 HTML 文本必須由*程序員*而不是文本編寫者來管理和部署。對于開發人員和編輯人員而言，這確實很煩人。多年來，我們試圖找到一種可以正確解決此問題的分布式內容管理服務。我們失敗了。因此，幾個月前，我們受夠了，并決定只需要自己構建一些東西。 ## 計劃我們計劃創建一個非常簡單的基于 Java 的服務，該服務可以使用 HTML 的通用數據屬性標記元素來注入集中托管的內容。它應該能夠處理本地化和動態插入數據。最重要的是，它應該為內容編寫者提供一種在自己的應用程序中使用嵌入式 WYSIWYG 編輯器隨時更改文本的方法。除了一些用戶體驗警告之外，這里還面臨三個技術挑戰。 1. 由于實時網站依靠它來獲取內容，因此這種新的商品服務應該永遠不會失敗。曾經 2. 它應該非常非常快，因此您的訪問者甚至不會注意到內容正在加載。 3. 內容應由 Google 編制索引。第三個問題與體系結構本身無關。可信賴的搜索引擎以神秘的方式運轉，因此我們所能做的就是[測試假設](http://www.centrical.com/test/google-json-ld-and-javascript-crawling-and-indexing-test.html "Google crawling an indexing test for javacript insertion and JSON-LD structured data")。劇透：是的，它有效。不過，前兩個問題的解決方案掌握在您自己手中。這些都可以通過低成本的巧妙解決方案來解決。 ## 建筑模塊讓我們深入研究基于 Amazon Web Services 的一些最新功能的系統構建塊。 ### Amazon API 網關 [Amazon API Gateway](https://aws.amazon.com/api-gateway/ "Amazon API Gateway") 是一項托管的 AWS 服務，允許開發人員在 AWS 管理控制臺中單擊幾下即可創建任意規模的 API。該服務可以觸發其他 AWS 服務，包括 Lambda 函數。 ### AWS Lambda 而不是運行云實例，我們使用 [AWS Lambda](https://aws.amazon.com/lambda/ "AWS Lambda") 。該名稱源自希臘字母 lambda（λ），用于表示在函數中綁定變量。 AWS Lambda 使您可以在不維護任何服務器實例的情況下運行代碼。您可能會想到具有單個任務的原子無狀態功能，該功能可能會運行有限的時間（當前為一分鐘）。這些功能可以用 Javascript（Node.js），Python 或 Java 編寫。如果您上傳 Lambda 代碼，Amazon 將負責以高可用性運行和擴展代碼所需的一切。 Lambda 并行執行。因此，如果發出一百萬個請求，則將執行一百萬個 Lambda 函數，而不會損失速度或容量。據亞馬遜稱，“擴展功能沒有基本限制”。最好的是，從開發人員的角度來看，Lambda 函數在不執行時甚至不存在。它們僅在需要時出現。而沒有上升的事物，也不會下降的事物。 ### DynamoDB Lambda 函數將其數據存儲在數據存儲中。因為我們的規則說不允許我們使用任何服務器，所以我們不能使用關系數據庫服務（RDS）。相反，我們使用 Amazon 的大型托管數據存儲 DynamoDB。 [Amazon DynamoDB](https://aws.amazon.com/dynamodb/ "AWS DynamoDb") 是適用于所有規模的所有應用程序的 NoSQL 數據庫服務。它受到完全管理，并支持文檔和鍵值存儲模型。 Netflix，AirBnB 和 IMDb 等其他用戶已經證明了該服務的可擴展性。 ## 建筑我們的系統分為三個部分： 1. 內容管理 2. 內容傳遞 3. 我們的網站關注點的分離是設計使然。內容管理 API 或我們自己的網站中的問題絕不會導致客戶網站的中斷。因此，內容的交付應完全自主。 ### 內容管理 [![Teletext.io - editing dynamic content with Amazon Gateway API, DynamoDb and Lambda](https://img.kancloud.cn/8e/e0/8ee0133664f903f4bfac764f94b882c3_438x720.png)](https://teletext.io/help/introduction "Teletext.io - editing dynamic content with Amazon Gateway API, DynamoDb and Lambda") 內容管理部分是編輯者用來編輯 HTML 和文本的部分。編輯者只能通過連接到 [AWS IAM](https://aws.amazon.com/documentation/iam/ "AWS Identity and Access Management") 的 [AWS Cognito 身份池](https://aws.amazon.com/cognito/ "AWS Cognito")使用他們的 Google 帳戶登錄，而該池僅使用 Javascript。為了加載草稿內容，存儲編輯并發布結果，將調用 Amazon API Gateway，從而觸發 Lambda 函數。 Lambda 函數全部與單個 API 調用有關，并將其數據存儲在 DynamoDb 中。如您所見，沒有服務器可能崩潰或卡住。 ### 內容傳送如前所述，我們決定將內容的交付與編輯功能完全脫鉤，因此即使災難來襲，您的應用程序仍能正常工作。當編輯者決定將新內容發布到他的應用程序的實時版本時，另一位 Lambda 立即將草稿內容作為平面 JSON 文件復制到 [S3](https://aws.amazon.com/s3/ "AWS S3") ，這是亞馬遜用于文件的數據存儲。 JSON 文件包含元數據和描述內容的 i18n 本地化 HTML 字符串。 [![Teletext.io - publishing static content with S3 and Cloudfront](https://img.kancloud.cn/86/c8/86c81bd7dd8a49094d95ad858fdabe5d_438x486.png)](https://teletext.io/help/introduction "Teletext.io - publishing static content with S3 and Cloudfront") 從此處開始，應用程序中的 Teletext.io 腳本可以通過 [Cloudfront](https://aws.amazon.com/cloudfront/ "AWS Cloudfront") CDN 訪問這些文件，從而確保高可用性和高性能。我們添加了一個巧妙的預取算法，以確保在您需要它們之前在瀏覽器中檢索并緩存了最受歡迎的文件，因此無需實際加載內容即可配置下次點擊。由于發布的內容的傳遞不涉及服務器端邏輯，因此它確實非常快速且實用。 ### 我們的網站 [![Teletext.io static single page app in S3 with proper routing for deeplinking](https://img.kancloud.cn/86/0c/860c805b68fcab6bd2cdc37da84e1f60_438x486.png)](https://teletext.io/ "Teletext.io static single page app in S3 with proper routing for deeplinking") 但是[我們的網站](https://teletext.io/ "Teletext.io - content management as a service")呢？我們選擇了一個簡單但有效的概念-再次沒有服務器。該網站是使用 [React 框架](https://facebook.github.io/react/ "Facebook React JS")作為單頁應用程序，并使用[作為單個靜態文件](http://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteHosting.html "Static single-page website in S3")部署到 S3 的。然后，將 Cloudfront 配置為最上方的內容交付機制，從而確保了來自世界各地許多端點的超快速內容交付。同樣，此方法基于平面文件傳遞，因此非常健壯。靜態應用使用 HTML5 pushState 和 React Router 進行 URL 處理。通常，存在一個問題。如果您訪問根以外的特定 URL，則 Web 服務器必須動態呈現與前端動態呈現的相同的路由。目前這在 S3 中是不可能的。但是，我們找到了一個技巧，我們想在這里分享。 1. 在 S3 中將應用程序配置為[一個靜態網站，其根指向主文件。](http://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteHosting.html "Static single-page app in S3") 2. 不要添加任何 S3 重定向規則。甚至不添加自定義錯誤頁面。 3. 創建一個指向 S3 存儲桶的 Cloudfront 發行版。 4. 在 Cloudfront 中創建一個自定義錯誤響應，該響應也指向主文件。確保執行固定的 200 響應。結果是，所有 URL 路徑（根目錄除外）均在 S3 中導致 404 響應，然后觸發緩存的 Cloudfront 自定義錯誤響應。最后的答復只是您的單頁應用程序。現在，在瀏覽器中，您可以根據當前路徑處理所有路由。只有一個缺點。在任何情況下，您都無法返回實際的 404 HTTP 響應代碼。但是，作為回報，您將獲得一個超便宜，超可擴展的單頁面應用程序。 ### 實用津貼使用 Lambda 會對您的開發過程產生影響。不過，支持正在改善。例如，以前無法對 Lambda 函數進行版本控制。這導致測試和部署的風險很大。但是，亞馬遜[最近推出了其版本控制系統](http://docs.aws.amazon.com/lambda/latest/dg/versioning-aliases.html "Versioning AWS Lambda")，現在我們可以使用*可變別名*。這意味著現在可以具有可以獨立更新的同一功能的不同版本，類似于測試環境還是生產環境。 ## 結果我們的免費增值服務現已向客戶開放。我們吃自己的狗食，所以我們也用它。在以下 GIF 中，您可以在我們自己的網站上看到正在使用的功能。 [![Teletext.io demo: inline content management inside custom software](https://img.kancloud.cn/04/95/0495aa275638826bb3218b9560f6a614_1034x524.png)](https://teletext.io/ "Teletext.io - content management as a service") 但是，系統的真正可擴展性在我們的每月 AWS 賬單中顯示。 ### 成本成本完全取決于實際使用情況。為簡單起見，我們將忽略臨時免費層，以及我們使用的許多小型服務。 * 使用 **Lambda** ，您**只為您消耗的**計算時間付費-當代碼未運行時不收費。還有一個永久的免費套餐。 * **Amazon API Gateway** 沒有**沒有最低費用或啟動費用**。您只需為收到的 API 調用和轉移的數據量付費。 * **DynamoDb** 的費用也基于**按使用量付費**，盡管定價有些復雜。簡而言之，它基于存儲，讀取和寫入。 * 然后是 S3 和 Cloudfront。基本上，您需要為存儲和帶寬付費。我們剛剛開始-為了計算成本，我們做了一些假設。讓我們考慮一個相當大的網站作為我們的普通客戶。我們猜測這樣的客戶端每月使用 1000 個 API 調用（僅用于編輯），因此需要 1GB 的數據輸入，并需要大約 10GB 的與流量相關的數據。永久性存儲我們估計為 500MB。我們預計 Lambda 執行時間不會超過 2 秒。對于幾個不同數量的此類客戶，我們的每月費用將如下所示（四舍五入，以美元為單位）。 | 顧客 | 網關 API | 拉姆達 | DynamoDb | S3 | 云前 | 總 | | --- | --- | --- | --- | --- | --- | --- | | 0 | 0 | 0 | 0 | 0.25 | 1.00 | 1.25 | | 100 | 9.50 | 0 | 3.50 | 1.50 | 85.00 | 99.50 | | 1000 | 93.50 | 4.00 | 3.50 | 15.00 | 850.00 | 966.00 | | 10000 | 935.00 | 35.00 | 3.50 | 150.00 | 8050.00 | 9173.50 | | 100000 | 9350.00 | 410.00 | 3.50 | 1500.00 | 76700.00 | 87963.50 | 如您所見，**成本主要由 CDN** 決定，而 CDN 在大流量時變得越來越便宜。 API 和關聯的 Lambdas 屬性所占的比例要小得多。因此，如果您構建的服務較少依賴 Cloudfront，則可以做得更好。 ## 關閉服務器憑借對創造力約束的熱愛，我們成功啟動了無需維護服務器，自動擴展，負載平衡器和操作系統的初創企業。這不僅是一個具有幾乎無限的峰值容量的真正可擴展的解決方案，而且是一個非常便宜的解決方案-尤其是在牽引力出現之前的早期。所以...服務器崩潰了！ [在 HackerNews](https://news.ycombinator.com/item?id=10690842) 上/ [在 Reddit](https://www.reddit.com/r/programming/comments/3vwrf4/on_high_scalability_building_a_company_using_only/) 上先生們，很棒的帖子。我喜歡它！請通過類似的方式檢查我們的項目：https://github.com/MitocGroup/deep-microservices-todo-app（無服務器 Web 應用程序）和 https://github.com/MitocGroup/deep-framework（無服務器 Web 框架）。如果有興趣，讓我們聯系（我的電子郵件地址在 Github 上：）最好的祝愿，尤金一世。由于您沒有使用大多數/任何 Cloudfront，因此您是否考慮過改用 Cloudflare 之類的設備，無論系統中有多少客戶端，您都需要支付固定費率？消除了 Cloudfront 擴展成本耶穌哭了。難以置信。您能為新手指出一些好的教程嗎？可怕。幾乎可以追溯到 80 年代。 > 如您所見，沒有服務器可能崩潰或卡住。是的，Amazon 完全沒有服務器在運行。而且，您的 Cloudfront 成本是可悲的，并且您不懂工程。 F *** ing 硅谷趕時髦的人。我認為您的 Dynamo 定價不正確。我無法想象擁有 3.5 萬美元/月的 10 萬客戶的存儲和吞吐量。而且，CDN 數量是如此之高，甚至不使用它可能也很有意義。您可以花 7.6 萬美元從一級提供商那里購買 10PB CDN 流量。感謝您分享您的故事 Marcel 和 Sander，有趣的方法。請調整您的文章標題，因為*非常*令人誤解。您并不是在談論無服務器設置，而是在談論擺脫管理自己的服務器的麻煩。他們將其稱為[平臺即服務（PAAS）](https://www.wikiwand.com/en/Platform_as_a_service)。這不是什么新鮮事物，請參閱已建立的解決方案，例如 [Heroku](https://www.heroku.com/home) 和 [Google App Engine](https://cloud.google.com/appengine/) ，僅提及其中兩個。順便說一句，您還沒有真正解決您的大膽挑戰＃1（“這項新的商品服務永遠都不會失敗。您認為他們不受故障影響嗎？（提示：他們幾個月前才遇到問題...）。通過不必自己維護服務器，當然可以減少錯誤：許多中斷是由系統更新和/或人為錯誤引起的。我一直在考慮采用這種架構，但我擔心的一件事是安全性。您將所有（通常）服務器端邏輯用于身份驗證或數據庫訪問配置在哪里？在每個 lambda 函數內部？還是作為每個 lambda 函數隨后調用的單獨的 lambda 函數（看起來可能是多余的）？我正在為我的雇主開發此模式：API 網關-> Lambda-> DynamoDB。沒有要管理的服務器。甜。但這是一個相當新的模式，因此某些主題的文檔可能參差不齊。許可有點麻煩。但是我明白了：與機架，堆疊和管理我們自己的服務器相比，這看起來更便宜，更可靠（我們每年比 AWS 停機更多）。可伸縮性問題在該模型中消失了：我可以在免費的 AWS 層上構建整個基于微服務的應用程序，而要將該基礎架構擴展到具有數百萬用戶的全球應用程序所需的唯一事情就是：我的信用卡。哇-一篇相當不錯的好文章的評論中有很多無知和仇恨。 @Jos de Jung-標題不是*很有誤導性，它已經死了。您只是不了解這些單詞的含義，也不了解它們的含義（根據您的其他評論）（提示：它比 PaaS 復雜得多）。標題為“無服務器**啟動**”-表示它們作為啟動公司不擁有或租賃任何服務器。它是 100％準確的。他們還需要購買在 AWS 服務器上運行的計算時間，存儲空間，cdn 等。* @the_dude-好像您今天忘記服藥了... Marcel Panse 和 Sander Nagtegaal-感謝出色的文章和靈感。我將在下一個項目中積極使用此模型。祝您好運！嗨，EvanZ，很高興聽到您正在考慮這一點，但您需要做一些閱讀工作！ AWS 提供了兩種內置機制（Cognito，IAM）以及一種可以調用自己的安全提供者的集成模式。我當前的實現是使用 Cognito。干杯， ws 這荒謬地更加復雜，并且如果沒有更多的話甚至容易失敗。亞馬遜仍然可能失敗，并且由于使用了這么多服務，因此鏈中任何地方的任何失敗都可能導致問題。小型 EC2 實例可以解決所有這些問題。為了安全起見，請使用 2 進行故障轉移。對于此應用程序，99％的用戶僅在讀取數據，因此這兩個小型實例將永遠永久擴展。您只需在任何基本的 webapp 框架中進行編程并像往常一樣進行部署。 Digital Ocean 甚至會更便宜，并且有許多 CDN 都比 CloudFront 便宜。同樣，他們絕對不會推出 50TB 的數據，對于高度可壓縮的文本內容來說，這是一個荒謬的帶寬。這就像是說他們將為前 100 個新聞站點提供所有文字一樣。另外，他們的商業模式糟透了，因為我看不出誰愿意為此付出代價。通常，需要編輯的文本（例如 CMS 中的文章）已經具有編輯器。網站上的文本多長時間隨機更改一次？即使這樣，開發人員僅輸入新文本并部署多長時間？糟糕的公司，胡扯的工程和無用的博客文章。我一直在使用相同的模式通過 Angular2 在站點上進行構建。我一直想創建一個個人站點來用作博客，并作為共享項目/設計的垃圾場。除此之外，我真的不想處理后端的建設，維護和付款。 S3 作為污垢很便宜，并且可以保證 5 9s 的正常運行時間（即比我一個人可以管理的更好）。因此，我創建了一個 Angular2 SPA（單頁應用程序），配置了 S3 重定向，并將路徑重寫添加到了角度路由器。我真的希望我能引起 Angular 開發團隊的注意，以便他們可以改進路由器來處理無服務器的邊緣情況，包括 html 歷史記錄重寫。使用 grunt 和 s3 插件可以輕松實現自動化。就像 Je??kyll 一樣，Markdown 將用作所有內容的格式，不同之處在于沒有編譯步驟。我創建了一個 Web 組件，可將 markdown 直接轉換為 html（即不久將支持 AJAX 請求的內聯緩存）。它正在開發中，但可以在[ [](http://dev.evanplaice.com) 中看到開發版本一旦功能完全正常，我計劃寫一下該過程：使用 Angular2 / ES6 構建網站；使用 JSPM；創建一個 ng2 Web 組件。在此之前，如果您有興趣，請隨時在 GitHub 上查看我的句柄。這是一個好主意 Giggaflop。有人在 cloudflare 上這樣做嗎？我很好奇可能會出現什么問題以及它是否會起作用。謝謝。對于那些正在尋找可以為無服務器架構創建最佳實踐的演示 Web 應用程序的人，請查看我們的 SansServer 項目（ [https://github.com/bclemenzi/sans-server](https://github.com/bclemenzi/sans-server) ）。該項目利用在 Maven 安裝時使用自定義 Java 注釋在 AWS 中自動構建和配置的基于 Java 的 Lambda 函數。還非常關注支持多個開發人員和環境。我創建了一個新框架，以將 JAVA 應用程序部署到 AWS Lambda + API Gateway 基礎架構 https://github.com/lambadaframework/lambadaframework 嘿，馬塞爾，感謝您對我們所有人（尤其是我）的教育，這些人在服務器方面都愚蠢，現在我知道很多，這一切都感謝您。繼續寫作和分享這樣的讀物:) 很棒的帖子。只是一個問題。您在項目中的哪里存儲圖像等？ “我們的開發人員舞會具有傳奇色彩：在每日站立比賽中，您只能在跳舞時講話，這是有史以來最高效的會議。” 你一定是在跟我開玩笑。這是有關此博客文章中涉及的主題的全面分步教程。 [http://serverless-stack.com](http://serverless-stack.com) 后端教程包括有關由 Cognito 保護的 Lambda + API Gateway 的章節。前端教程包括有關在 S3 + CloudFront + SSL + Route53 自定義域上托管的 React SPA 的章節。本教程詳細介紹了如何構建 CRUD 無服務器 API 并將其完全連接到 AWS 上的 React SPA。 API 函數在 ES6 中，并且已通過 Cognito 用戶池進行了身份驗證。它還顯示了如何在 S3 上托管您的應用程序以及如何使用 CloudFront 和 Route 53 將其提供服務。這是一個端對端教程，顯示了實際的無服務器架構。有趣的帖子。我還在一個后端團隊中工作，該團隊使用無服務器 AWS Lambda 作為我們的 node.js 后端開發工具。我們發現，無服務器減輕了我們管理服務器部分（操作部分）的負擔。但是，我們注意到，與使用基于 Express JS 的 node.js 服務器的時間相比，我們的開發速度正在下降。這是因為我們無法啟動在我們自己的本地開發計算機中運行的&服務，也無法在其中調試我們的服務。無服務器 AWS Lambda 上的調試問題對我們來說很繁瑣：它要求我們將代碼部署到 AWS 上，調用它，然后通過查看一堆 Cloudwatch 的日志流（我們的代碼有一堆 console.log 以了解其中發生了什么）。基于這個事實，我想聽聽您的想法，當您無法在本地計算機上運行&無服務器調試代碼時，如何提高團隊開發效率？干杯。也許嘗試從命令行測試代碼？這是我的方法：＃！ / usr / bin / env 節點 var question_id =（process.argv.length > = 3）？ process.argv [2]：“ test2”; var lambda = require（“ ../ index.js”）; var AWS = require（'aws-sdk'）; AWS.config.loadFromPath（“ ./ awscfg.json”）; var context = { functionName：“ testFunction”， AWS：AWS， DB：new AWS.DynamoDB（）， DBCLIENT：new AWS.DynamoDB.DocumentClient（）， SES ：新的 AWS.SES（） }; var Decision = {[ questionId：question_id，評分：“優秀”，文本：“哇！” } var request = { 方法：“ acceptProAnswer”，參數：決策， ID：1 } lambda.handler（請求，上下文，函數（錯誤，響應）{ console.log（“ handler：error：” +錯誤+“ response：” + JSON.stringify（response））; }）精彩的文章。對于諸如*不比...* 和*并非真正無服務器*可靠的大量評論，我強烈建議您學習這項技術。這是我們所有人都使用的技術堆棧-只是配置更智能。構建 H / A 解決方案并消除 SPOF 幾乎是微不足道的。我關心的是性能，但是在 Lamba 工作了幾個月后，我感到非常高興。很高興看到其他人繼續使用這項技術。它消除了新技術公司的巨大啟動障礙