高效能無伺服器工程的6個最佳實踐

banq發表於2018-11-20
伺服器

當你寫下你的前幾個lambdas時，效能是你最不想要的，你最關心的是許可權，安全性，身份和訪問管理（IAM）角色和觸發器，這些都是為了進行“hello world”試用之後，讓您的第一個無伺服器能夠部署正常執行。但是，一旦您的使用者開始依賴您的lambdas提供的服務，就應該專注於高效能無伺服器。
當您嘗試生產高效能無伺服器應用程式時，需要記住以下一些關鍵事項。

1.可觀察性
無伺服器處理擴充套件非常好。但隨著規模與複雜性的相互作用，減速和錯誤是不可避免的。
可觀察性不僅僅是日誌記錄或指標 - 這兩者都是無伺服器的。您可以深入瞭解雲監視，以便在每次呼叫lambda時獲取日誌記錄資訊，並且AWS控制檯提供了充分的方法來檢視執行時間，記憶體使用和其他關鍵指標的平均值。
但是可觀察性是我們如何從外部分析系統而不破解其內部結構。日誌記錄和指標都不能真正做到這一點，因為日誌記錄提供的資訊太精細，無法告訴您如何處理請求，而度量標準只能指出問題的症狀而不是其原因。該解決方案是真實的儀器，可以對跟蹤資訊進行取樣，併為您提供一般和異常資料。

2.想想函式的請求路徑
一旦觸發一個函式lambda，就尋找各種資訊，發出各種Web請求，檢查配置檔案，獲取各種上下文，不要在一個函式中做太多事，登出這個被呼叫的lambda，尋找可實現你目標的函式。

3.不要重寫您的程式碼
以下列出了常見的謊言：

  • “在迭代之前一定要製作一個陣列的副本，改變副本會更有效”
  • “不要連線字串，即使它只是兩個字串仍然加入一個陣列，這將節省記憶體”
  • “全域性變數的效能比良好的變數要糟糕得多”

所有這些都是由善意的人提供的，他們希望幫助人們編寫更具效能的JavaScripts。所有這些都忽略了一個基本事實：  JavaScript是一種更高階的語言。

可以透過減少必須執行的操作來改程式序：
  • 將多個請求組合到其他服務;
  • 當你有足夠的匹配時就立即停止迴圈;
  • 返回有用的錯誤資訊;
  • 失敗優雅。

但除了這些最基本的最佳實踐之外，重寫程式碼並不是解決效能問題的方法

4.從本地開始
我認識的每個人在無伺服器開發的早期都有類似的經歷：當你的lambda開始做一些有點複雜的事情時，你會發現自己對你的配置和功能程式碼做了幾十個小的調整。每次更改時，您都必須等待程式碼部署，然後堆疊的其餘部分才能生效。而不是“儲存，構建，重新整理”，您的開發週期看起來更像是“儲存，開啟控制檯，部署，等待，重新整理，等待，重新整理，等待，等待，重新整理”

可以複製lambdas和API端點以及許多其他資源到本地docker容器中。

5.本地永遠不會複製你的整個堆疊
要真正模擬無伺服器流，您需要有一個堆疊來部署程式碼。
具體情況可能因團隊規模而異，但基本上您需要某種階段或測試版本的堆疊，您可以在其中測試我們的程式碼。

6.管理程式碼，而不是配置
建立YAML，管理你的堆疊。

相關文章