面對現實吧。 調試性能問題很困難，但更難解決。

假設您發現了令人反感的代碼，這些代碼正在拖慢您的應用的運行速度。 最終會有一段時間，您發現該代碼減速是同步的或線性執行的。 解決這些有問題的代碼段的最有效方法之一是將最重的工作負載委派給以后的時間和地點。

盡管有無數種工作負載委派解決方案，但近年來在第三方服務器上執行代碼（也稱為無服務器功能）的想法變得越來越流行。

無服務器功能非常有用，因為我們可以配置處理這些工作負載的執行時間和頻率。 此外，我們只為使用的時間和計算能力付費。 無需使用永遠運行的服務器，即使不使用它也要消耗主機成本。

Amazon Web Services中的無服務器功能

在Amazon Web Services（或AWS）中，無數功能被稱為Lambda。 盡管Lambdas和其他無服務器功能使我們在其他計算機上執行代碼有很多好處，但在執行方式上卻有一些限制。

由于我們從技術上是從AWS租用硬件和軟件，因此他們可以確定運行代碼的硬件規格和環境。

對于Amazon，這意味著在Ubuntu（Linux）環境中運行和執行代碼。 我們需要考慮有關AWS Lambda部署和執行環境的特定限制 。

盡管它們都很重要，但我想談談一些限制，這些限制將決定我們如何設計和實現功能。

內存和時間限制

當我們最終嘗試將工作委派給AWS Lambda時，我們需要以不超過128MB內存使用限制和執行限制的方式進行操作。 每個功能還必須花費不到300秒（五分鐘）的時間來執行。

盡管您可以在五分鐘內完成很多工作，但是我發現圍繞模塊化的重點設計Lambda函數很有用。 這意味著將功能設計為通過Lambda多次處理較小的工作單元，而不是一次發送大量要執行的數據。

使用模塊化的Lambda實現，我們應該能夠在這些限制下處理我們需要的任何東西。

臨時存儲

AWS Lambdas中的存儲也有點有趣。 我們還只能在Lambda的文件系統的一部分中/tmp最多寫入512MB。

盡管我們當然可以在Lambda中對數據建模，但我們依賴于外部資源來檢索和永久存儲執行結果數據。 我們最終關心的是創建一段代碼，該代碼可以計算事物的結果并將其發送到另一個要存儲的地方。

部署包大小

另一點值得注意的是部署程序包限制。 雖然我們編寫的帶有代碼的文件應該很容易就在該限制之內，但是我們不能忘記依賴關系。

AWS Lambdas要求我們在部署程序包中提取每個依賴項。 因此，我們需要確保我們的代碼和依賴項之和不超過此限制！

語言限制

最后，最大的限制之一是在Lambda中只允許執行某些語言。 對于AWS Lambda，這些語言是（在撰寫本文時）Python，Go，JavaScript和Java。

如果應用程序是用其中一種語言編寫的，那么您很幸運！ 您所要做的就是導入代碼，一切順利。

但是，我想逐步說明為什么即使您的應用程序不是用其中一種語言編寫的，使用Lambda仍然有意義。

Ruby和Python的示例

我最近的許多工作都是基于Python Lambda的，該Lambda被基于Ruby的應用程序調用。 因此，我將演示使用這兩種語言的示例。

Python和Ruby都是動態語言 。 盡管AWS不為Lambda提供Ruby支持，但它們確實支持Python。 為Ruby代碼庫編寫Python Lambda很有道理，因為它們的樣式和結構相似。 亞馬遜還有一個很棒的Ruby SDK ，我們將使用它來調用和管理Lambda。

讓我們開始編寫Python Lambda：

index.py

def handler(event, context):input_message = event.get('message')print(input_message)return {'message': 'Well, hey there Ruby application!'}

您可以按照Amazon的教程來學習如何將這段代碼作為Lambda進行部署。 設置完成后，我們將需要一些有關Lambda的信息：

• 部署Lambda的AWS區域
• 您的AWS訪問密鑰和訪問密鑰
• Lambda的名稱

掌握了這些信息之后，我們就可以開始編寫Ruby應用程序了。 在開始之前，請記住將AWS Ruby SDK添加到項目的Gemfile 。

app.rb

require ‘aws-sdk’ require 'json'credentials = Aws::Credentials.new('access-key', 'access-key-secret')lambda_client = Aws::Lambda::Client.new(region: 'lambda-aws-region',credentials: credentials )app_payload = { message: "Hello Python Lambda!" }response = lambda_client.invoke({function_name: "SampleAWSFunction",invocation_type: "RequestResponse",payload: app_payload })parsed_response = JSON.parse(resp.payload.string) puts parsed_response

考慮到這一點，我們現在可以運行app.rb并從Lambda獲得實時響應！

包起來

通過此基本示例，我們現在可以使用AWS支持的任何語言將更復雜的基于Ruby的代碼委托給Lambda函數。

盡管我們的示例相對于Python更為偏愛，但AWS和其他無服務器功能提供商所提供的自由是能夠為當前工作選擇最佳語言。

是否需要使用線程來構建性能更高的東西？ 也許嘗試使用Java或Go這樣的語言來實現您的功能。 想留在類似于Ruby的地方嗎？ 堅持使用此Python模板或嘗試JavaScript！

選擇AWS堆棧之外的語言并運行自己的解決方案在許多方面絕對具有吸引力，但使用AWS Lambda的穩定性，成本和效率是該服務的最大賣點。 對我而言，僅憑這些原因，就可以提供一種有效且具有成本效益的方法，以幫助您更好地平衡應用程序中的同步執行瓶頸。

在使用AWS Lambdas時，我發現有趣的另一件事是，每個人都有自己獨特的解決方案和使用它們的實現。

但是，每種體系結構都需要時間，試驗和錯誤才能開發。 如果做對了，在解決應用程序速度和執行時間問題上，投資和挫敗感將得到巨大回報。

最終，我們需要權衡使用Lambda的成本以及它們在我們的主應用程序服務器上釋放的時間。 您最終也有一天會發現自己完全利用了無服務器架構！

無論哪種方式，了解有關AWS的Lambda Functions之類的無服務器解決方案的更多信息都將為您提供另一種解決日益增長的軟件應用程序中的速度和性能問題的方法。 這可能并不總是補救措施，但它是幫助事情在未來更快更強大的有效解決方案。

翻譯自: https://www.javacodegeeks.com/2018/06/expanding-tech-stack-aws-lambdas.html

總結

以上是生活随笔為你收集整理的使用AWS Lambdas扩展技术堆栈的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。