3月底，在云界有一件盛事發生。
亞馬遜云科技于3月30日舉辦亞馬遜云科技創新大會。據會議信息顯示，這屆大會的高主題是“全面擁抱Serverless時代”。
有心的朋友應該注意到了，從去年到今年，無論是此前的AWS re:Invent大會還是阿里云云棲大會，抑或是即將召開的這個會議，Serverless都是當仁不讓的主角。
不管是AWS還是阿里云，都在堅定推進核心產品全面Serverless化。中美兩大云巨頭同時押Serverless，無疑是在向全行業傳遞出這樣的信號：Serverless 是云計算的未來。
那么Serverless真有這么香嗎？
“無服務器（Serverless）”這個概念最早出現在2012年，但真正為人熟知卻始于——2014年Amazon Lambda服務推出時，時至今日，這一理念已經成為業內熱詞。
所謂“無服務器”，并不是指真的無需服務器，其指代的更多是一種云應用程序開發和執行模型。允許開發人員構建和運行代碼，而無需管理服務器，也無需為閑置的云基礎架構付費。
當選擇無服務器和Lambda來搭建云架構時，你需要了解固有的限制，以便在應用程序和代碼的規模以及復雜性開始增長時進行擴展。
在構建應用程序代碼時，無服務器是快速升級的一個好選擇，但有一個常見的誤解，即無服務器意味著DevOpsLess或NoOps，而事實并非如此。
更重要的是，有時你必須提前在設計和架構上進行投資，以避免后來遇到瓶頸或招致大量技術債務。
一、無服務器問題的快速概述
當應用程序開始增長時，如果你不提前計劃，很快就會遇到無服務器范式特有的挑戰。很多人在開始嘗試無服務器時很可能意識不到，為什么他們需要提前設計。
1.問題一：節流
Lambda節流是可以同時運行的實例數量的結果。
AWS Lambda默認一個賬戶的區域并發限制為1000，也就是可以同時處理1000個請求。一旦到達上限，新的請求會被節流。當然你可以請求提高此閾值，不過要注意，這會產生成本影響。因此在檢查架構設計并確保你確實需要它之前，不應自動提高閾值。
需要直面的現實是，你同時運行的事件或服務越多，你就會越快地遇到瓶頸。如果你計劃安全在無服務器架構上運行，那么就有必要在編寫第一行代碼的時候就考慮到這一點。
即使今天你只需要滿足小規模請求的設計，但必須盡早考慮，當你有數千個（甚至更多）租戶或客戶時，這是否會線性縮放。根據構建資源、Lambda和微服務的方式（以及每個服務的“微”程度），如果將服務分解為太小的塊，則最終可能會由于過多并行事件的限制而中斷整個服務鏈流。
這意味著需要充分了解當前正在處理的流量（以每分鐘事件的形式），甚至是服務處理的峰值和異常流量。所有這些都需要考慮，此外還需要考慮每種調用所采用的通信調用方法——同步或異步（稍后會更深入地研究）——其中，使用同步調用，每個服務或系統調用都會疊加起來，并可能使系統過載。
重要的是要意識到節流的工作方式并不是完全可預測的。因此，即使你有適當的監視以確保你不會達到1000個并行事件，并且你認為你已經覆蓋了，但這實際上可能在你的第一個峰值時發生，其中節流可能發生在更低的閾值，因為這本質上是意外行為(但在AWS文檔中有記錄)。因此，一個好的實踐是，以一種能夠在這種情況發生時恢復的方式構建你的系統(例如等冪性和重試)。
2.問題二：超時
顧名思義，無服務器不運行在永遠運行的服務器上，它們提供臨時運行時，函數運行時最多只有15分鐘的總窗口。這可能會影響服務可以處理的輸入的大小。當你從頭開始設計函數時，輸入的大小隨著處理時間的增加而不斷增加，你可能會在運行時遇到超時。
因此，對于運行時隨輸入大小線性擴展的服務或函數，建議的設計模式是將輸入拆分為塊或批處理，并在不同的Lambda中處理它們。這樣做時，使用隊列也是一個很好的實踐，從而避免節流。
3.問題三：事件大小
事件驅動的設計模式在基于無服務器的系統中很常見，很多時候需要鏈中的各種服務來進行事件處理，包括API網關、SQS（Amazon Simple Queue Service）、事件橋接器、SNS（Amazon 的發布/訂閱服務），其中每種服務都有不同的事件大小限制。你使用的每個資源可能都有需要注意的不同大小限制，在發送大型有效負載時，沿鏈傳遞數據可能會中斷。
這意味著你不能在資源之間發送無限的有效負載，并且在構建函數和服務時需要注意這一點。鏈中的每一個資源都能夠處理不同大小的有效負載，這意味著如果不提前考慮這一點，并確保可以在系統服務和資源中接收此有效負載，則會遇到失敗事件。
一種解決方案，本質上是一種變通方法，可以通過利用支持有效負載大小的不同資源，在S3存儲桶中傳遞大型有效負載。（提示：搜索“AWS 服務配額”以了解有關你使用的資源的更多信息，這是一個很好的入門參考）
4.問題四：冪等性
所謂的冪等性，是分布式環境下的一個常見問題，一般是指我們在進行多次操作時，所得到的結果是一樣的，即多次運算結果是一致的。也就是說，用戶對于同一操作，無論是發起一次請求還是多次請求，最終的執行結果是一致的，不會因為多次點擊而產生副作用。
由于前文中列出的所有挑戰，故障總是會發生，因此會出現延遲。Lambdas和無服務器資源通常構建在重試機制上。這就是冪等性至關重要的地方。服務需要為給定的輸入交付相同的結果，無論它們被重試或部分重試了多少次(這意味著即使只重試了流的一部分，結果仍然需要相同)。
你需要提前設計冪等性，以便重試和重放不會影響生產系統的狀態。一個好的做法是確保在運行數據時為每個實例創建唯一的但不隨機的確定性ID。這是正確執行此操作的良好指南。
5.問題五：內存泄漏
若要了解內存泄漏是如何發生的，首先需要了解運行代碼的機制是如何工作的，因為它也有其局限性。對于Lambda函數，相同的Lambda運行程序會被一次又一次地重用，直到它死去。也許它可以完美運行1000次，但它可能會在第1001次運行時開始崩潰，并可能導致你的服務出現問題。
例如，使用相同解釋器的Python/ target=_blank class=infotextkey>Python代碼會被反復使用。如果這段代碼在每個運行中都添加全局內存對象，這些對象可能會通過不同的運行實例傳遞，這可能會導致內存泄漏，即超出實例內存限制。然后你的Lambda就會崩潰。
在使用共享資源和多租戶架構時，這一點尤其重要。你需要確保不會留下未使用的資源、敏感數據或其他垃圾。在租戶隔離方面，如果使用共享內存，則需要非常小心，確保數據不會在實例之間泄漏，因為數據可能會在租戶之間泄漏。
6.問題六：同步與異步調用
無服務器中的同步調用可能會導致許多問題（比如前文中提到的“節流”）。在可能且不需要立即響應的情況下，異步調用模式是無服務器的首選模式。
無服務器通常被設計成異步和無狀態的，而不是同步和有狀態的，因此發揮技術的優勢總是最好的。當你確實需要同步調用時，請確保有適當的保護措施(如使用API網關)，并通過適當的日志記錄獲得可見性。
二、設計無服務器應用程序的復原能力和健壯性
對于那些希望快速運行、專注于交付和推出產品、不想在基礎設施管理上耗費過多的人來說，無服務器是一個很好的選擇。不過在選擇運行無服務器時，你需要記住，這意味著使用許多不同的AWS資源，了解每種資源如何獨立工作、如何協同工作以及它們的局限性和缺陷非常有必要。
要發揮無服務器的優勢，需要建設適當的“護欄”，從而盡可能規避上述問題。
首先，與不可預測的動態云環境中的所有云原生應用程序一樣，對于無服務器應用程序，通過監控、日志記錄和追蹤，確保對應用程序的工作方式具有適當的可見性尤為重要。
再者，談到在無服務器上運行時，另一個常見且不容忽視的問題是成本。設計和構建應用程序的方式也會直接影響成本。你需要有適當的機制，以避免過度濫用資源，從計費警報和常規的具有成本意識的系統設計開始，這是無服務器的一個極其重要的實踐。
另外，確保安全性和數據隱私也很重要，以免在使用共享資源和多租戶時危及關鍵數據。有一些優秀的DevSecOps工具可以幫助你做到這一點。
當你了解了無服務器的工作原理后，你可以優化設計、架構和應用程序代碼，進而實現顯著的成本改進，同時獲得更好的性能、安全性和容錯能力。
三、寫在最后
Lambda的推出開啟了云計算的新時代，隨后，微軟、谷歌、IBM等大廠也先后推出了自己的Serverless產品。云產品的全面Serverless化逐漸成為時之所趨。
一旦Serverless進入規模化使用階段，一方面，資源的使用由平臺統一調度，按需使用，整個云計算資源的使用成本有望實現大幅降低；另一方面，編程方式會隨著Serverless的發展產生很大不同。我們有理由相信，Serverless將成為IT基礎設施變革中不可輕忽的拐點。
參考鏈接：https://thenewstack.io/serverless-doesnt-mean-devopsless-or-noops/
