無伺服器TOP3大關鍵問題及解決方案

無伺服器計算風靡一時，遵循以下提示可消除其中的非計算瓶頸，避免程式限制和任務排隊，並保持功能的及時響應…

無伺服器計算提供了一個基礎架構，允許將伺服器資源應用於系統，以便擴充套件並有效提供計算能力，但省去了伺服器管理帶來的麻煩，這意味著沒有人需要在執行時關心單個伺服器（坦率地說，沒有人真正關心過），這使得將一組伺服器外包到雲提供商具有成本效益，而無伺服器介面通過最小化合同使外包關係變得儘可能簡單。

關於無伺服器，許多人的直接反應是嘗試用圖表和與其各自無伺服器功能相關的告警來替換附加到伺服器的圖表和告警。然而，這並未從根本上解決應用程式管理挑戰。正如沒有人真正關心伺服器一樣，沒有人真正關心無伺服器功能。

大部分人關心的只是系統為使用者提供的服務水平，這意味著有價值的監控必須關注可能出錯的事情，並且在無伺服器的情況下，出錯不再關注伺服器層面，因為伺服器容量耗盡等錯誤已經被有效隱藏。那麼，典型的無伺服器問題是什麼？又是如何表現的呢？

冷啟動成本

這是無伺服器系統經常出現且被頻繁討論的問題，為了最大限度提高利用率，無伺服器提供商有時會選擇完全關閉非活動功能。當負載恢復時，啟動成本會導致響應時間延長。當一個業務功能由連結在一起的許多無伺服器功能組成時，這種效果可能會複雜化。

解決方法：許多使用者人為ping功能以確保服務活著。要通過鏈式服務網路有效應用此策略，必須瞭解它們之間的端到端關係，以便依賴鏈中的所有服務保持活動狀態，從而使業務的端到端跟蹤必不可少。

資源請求

無伺服器平臺會限制無伺服器功能將執行的併發請求數，通常是在某個帳戶和單個功能級別。一旦達到併發限制，進一步的使用者請求將排隊，從而導致響應時間延長。雖然限制有效計算資源池似乎有悖常理，但這確實可以防止潛在花銷（不要忘記，容量按消費基礎計費）。

解決方法：提高門檻或者確保合理設定資源以滿足響應時間和併發方面的任何非功能性要求。同樣，需要端到端的可見性，因此可以快速確定受限制的內容，以及限制對終端使用者體驗的影響。

非計算瓶頸

如果解決了所有無伺服器限制，就可以支援儘可能多的併發請求。根據具體情況，這並不意味著麻煩徹底解決，如果等待讀取或寫入資料，就需要無限縮放lambda等待資料訪問，同時需要為非生產性等待付費。

功能懸掛的確切原因隨永續性儲存的不同而有差異：

• 雲資料儲存：雲資料服務變得越來越有彈性，但許多仍需要根據併發讀寫卷配置資源。
• 傳統系統：沒有哪個功能是孤島，許多做無伺服器的使用者正在使用無伺服器功能（有時是大型機，有時是傳統的基於伺服器的部署）包裝現有系統。雖然很容易提高閾值以允許功能擴充套件，但這隻意味著很容易壓倒無法輕易擴充套件的後端。

解決方案：為了確保後端系統能夠承受理論上的最大負載，請將它們與功能限制器一起調整。這有助於確保系統端到端地順利執行，從而避免不必要的成本和客戶不滿。在某些情況下，可能需要複製資料以使不同的系統從不同的位置訪問（當然，這以增加資料管理複雜性為代價，可能導致不一致的風險蔓延到資料中）。

此外，在事務級別瞭解系統端到端流程，對識別和告警生產瓶頸以及端到端分析至關重要。

無伺服器ops是devops

無伺服器最普遍的含義是，開發人員配置程式碼，在無伺服器計算中為生產提供整個包，而不僅僅是功能部件，這意味著一旦使用IDE除錯生產問題，最好熟悉某種效能管理解決方案，因為至少一半“錯誤”可能會與部署相關。系統命運完全在個人手中，應用程式級別的端到端可見性至關重要。

參考連結：
https://www.infoworld.com/article/3338111/serverless-computing/the-top-3-serverless-problems-and-how-to-solve-them.html