無伺服器並不意味著DevOpsLess或NoOps

　　當選擇無伺服器和Lambda來搭建雲架構時，你需要了解固有的限制，以便在應用程式和程式碼的規模以及複雜性開始增長時進行擴充套件。

　　在構建應用程式程式碼時，無伺服器是快速升級的一個好選擇，但有一個常見的誤解，即無伺服器意味著DevOpsLess或NoOps，而事實並非如此。

　　更重要的是，有時你必須提前在設計和架構上進行投資，以避免後來遇到瓶頸或招致大量技術債務。

　　 一、無伺服器問題的快速概述

　　當應用程式開始增長時，如果你不提前計劃，很快就會遇到無伺服器正規化特有的挑戰。很多人在開始嘗試無伺服器時很可能意識不到，為什麼他們需要提前設計。

　　 節流

　　Lambda節流是可以同時執行的例項數量的結果。

　　AWS Lambda預設一個賬戶的區域併發限制為1000，也就是可以同時處理1000個請求。一旦到達上限，新的請求會被節流。當然你可以請求提高此閾值，不過要注意，這會產生成本影響。因此在檢查架構設計並確保你確實需要它之前，不應自動提高閾值。

　　需要直面的現實是，你同時執行的事件或服務越多，你就會越快地遇到瓶頸。如果你計劃安全在無伺服器架構上執行，那麼就有必要在編寫第一行程式碼的時候就考慮到這一點。

　　即使今天你只需要滿足小規模請求的設計，但必須儘早考慮，當你有數千個（甚至更多）租戶或客戶時，這是否會線性縮放。根據構建資源、Lambda和微服務的方式（以及每個服務的“微”程度），如果將服務分解為太小的塊，則最終可能會由於過多並行事件的限制而中斷整個服務鏈流。

　　這意味著需要充分了解當前正在處理的流量（以每分鐘事件的形式），甚至是服務處理的峰值和異常流量。所有這些都需要考慮，此外還需要考慮每種呼叫所採用的通訊呼叫方法——同步或非同步（稍後會更深入地研究）——其中，使用同步呼叫，每個服務或系統呼叫都會疊加起來，並可能使系統過載。

　　重要的是要意識到節流的工作方式並不是完全可預測的。因此，即使你有適當的監視以確保你不會達到1000個並行事件，並且你認為你已經覆蓋了，但這實際上可能在你的第一個峰值時發生，其中節流可能發生在更低的閾值，因為這本質上是意外行為(但在AWS文件中有記錄)。因此，一個好的實踐是，以一種能夠在這種情況發生時恢復的方式構建你的系統(例如等冪性和重試)。

　　 超時

　　顧名思義，無伺服器不執行在永遠執行的伺服器上，它們提供臨時執行時，函式執行時最多隻有15分鐘的總視窗。這可能會影響服務可以處理的輸入的大小。當你從頭開始設計函式時，輸入的大小隨著處理時間的增加而不斷增加，你可能會在執行時遇到超時。

　　因此，對於執行時隨輸入大小線性擴充套件的服務或函式，建議的設計模式是將輸入拆分為塊或批處理，並在不同的Lambda中處理它們。這樣做時，使用佇列也是一個很好的實踐，從而避免節流。

　　 事件大小

　　事件驅動的設計模式在基於無伺服器的系統中很常見，很多時候需要鏈中的各種服務來進行事件處理，包括API閘道器、SQS（Amazon Simple Queue Service）、事件橋接器、SNS（Amazon 的釋出/訂閱服務），其中每種服務都有不同的事件大小限制。你使用的每個資源可能都有需要注意的不同大小限制，在傳送大型有效負載時，沿鏈傳遞資料可能會中斷。

　　這意味著你不能在資源之間傳送無限的有效負載，並且在構建函式和服務時需要注意這一點。鏈中的每一個資源都能夠處理不同大小的有效負載，這意味著如果不提前考慮這一點，並確保可以在系統服務和資源中接收此有效負載，則會遇到失敗事件。

　　一種解決方案，本質上是一種變通方法，可以透過利用支援有效負載大小的不同資源，在S3儲存桶中傳遞大型有效負載。（提示：搜尋“AWS 服務配額”以瞭解有關你使用的資源的更多資訊，這是一個很好的入門參考）

　　 冪等性

　　所謂的冪等性，是分散式環境下的一個常見問題，一般是指我們在進行多次操作時，所得到的結果是一樣的，即多次運算結果是一致的。也就是說，使用者對於同一操作，無論是發起一次請求還是多次請求，最終的執行結果是一致的，不會因為多次點選而產生副作用。

　　由於前文中列出的所有挑戰，故障總是會發生，因此會出現延遲。Lambdas和無伺服器資源通常構建在重試機制上。這就是冪等性至關重要的地方。服務需要為給定的輸入交付相同的結果，無論它們被重試或部分重試了多少次(這意味著即使只重試了流的一部分，結果仍然需要相同)。

　　你需要提前設計冪等性，以便重試和重放不會影響生產系統的狀態。一個好的做法是確保在執行資料時為每個例項建立唯一的但不隨機的確定性ID。這是正確執行此操作的良好指南。

　　 記憶體洩漏

　　若要了解記憶體洩漏是如何發生的，首先需要了解執行程式碼的機制是如何工作的，因為它也有其侷限性。對於Lambda函式，相同的Lambda執行程式會被一次又一次地重用，直到它死去。也許它可以完美執行1000次，但它可能會在第1001次執行時開始崩潰，並可能導致你的服務出現問題。

　　例如，使用相同直譯器的Python程式碼會被反覆使用。如果這段程式碼在每個執行中都新增全域性記憶體物件，這些物件可能會透過不同的執行例項傳遞，這可能會導致記憶體洩漏，即超出例項記憶體限制。然後你的Lambda就會崩潰。

　　在使用共享資源和多租戶架構時，這一點尤其重要。你需要確保不會留下未使用的資源、敏感資料或其他垃圾。在租戶隔離方面，如果使用共享記憶體，則需要非常小心，確保資料不會在例項之間洩漏，因為資料可能會在租戶之間洩漏。

　　 同步與非同步呼叫

　　無伺服器中的同步呼叫可能會導致許多問題（比如前文中提到的“節流”）。在可能且不需要立即響應的情況下，非同步呼叫模式是無伺服器的首選模式。

　　無伺服器通常被設計成非同步和無狀態的，而不是同步和有狀態的，因此發揮技術的優勢總是最好的。當你確實需要同步呼叫時，請確保有適當的保護措施(如使用API閘道器)，並透過適當的日誌記錄獲得可見性。

　　 二、設計無伺服器應用程式的復原能力和健壯性

　　對於那些希望快速執行、專注於交付和推出產品、不想在基礎設施管理上耗費過多的人來說，無伺服器是一個很好的選擇。不過在選擇執行無伺服器時，你需要記住，這意味著使用許多不同的AWS資源，瞭解每種資源如何獨立工作、如何協同工作以及它們的侷限性和缺陷非常有必要。

　　要發揮無伺服器的優勢，需要建設適當的“護欄”，從而儘可能規避上述問題。

　　首先，與不可預測的動態雲環境中的所有云原生應用程式一樣，對於無伺服器應用程式，透過監控、日誌記錄和追蹤，確保對應用程式的工作方式具有適當的可見性尤為重要。

　　再者，談到在無伺服器上執行時，另一個常見且不容忽視的問題是成本。設計和構建應用程式的方式也會直接影響成本。你需要有適當的機制，以避免過度濫用資源，從計費警報和常規的具有成本意識的系統設計開始，這是無伺服器的一個極其重要的實踐。

　　另外，確保安全性和資料隱私也很重要，以免在使用共享資源和多租戶時危及關鍵資料。有一些優秀的DevSecOps工具可以幫助你做到這一點。

　　當你瞭解了無伺服器的工作原理後，你可以最佳化設計、架構和應用程式程式碼，進而實現顯著的成本改進，同時獲得更好的效能、安全性和容錯能力。

　　 三、寫在最後

　　Lambda的推出開啟了雲端計算的新時代，隨後，微軟、谷歌、IBM等大廠也先後推出了自己的Serverless產品。雲產品的全面Serverless化逐漸成為時之所趨。

　　一旦Serverless進入規模化使用階段，一方面，資源的使用由平臺統一排程，按需使用，整個雲端計算資源的使用成本有望實現大幅降低；另一方面，程式設計方式會隨著Serverless的發展產生很大不同。我們有理由相信，Serverless將成為IT基礎設施變革中不可輕忽的拐點。

　　原文連結：https://thenewstack.io/serverless-doesnt-mean-devopsless-or-noops/