1. 無伺服器的魅力

1.1. 對於某些應用程式，負載在工作時間可能很高，而在非工作時間可能很低或者不存在

1.2. 其他應用程式後臺流量可能在99%的時間里都很低

• 1.2.1. 一旦到了一些大型節目的門票發佈時間，負載需求可能會在數小時內飆升至平均水平的10000倍，然後回落至正常水平

1.3. 主流機構的IT系統從內部部署轉到公有雲平臺部署似乎是不可避免的

• 1.3.1. 雲平臺的兩個巨大的魅力在於，它們按需付費的計費方式和快速擴展（和縮減）虛擬資源以滿足不斷變化的工作負載和數據量的能力

• 1.3.2. 系統長時間使用的資源越多，月底的雲賬單金額就越大

• 1.3.2.1. 超支的原因有很多，包括缺乏自動擴展方案的部署、長期不合理的容量規劃，以及雲架構利用不足導致系統占用空間過大

• 1.3.3. 架構上的重大決策遍及雲上系統設計和部署的方方面面

• 1.3.3.1. 如果負載增加，彈性應用程式可以啟動新的虛擬機來增加容量，通常是利用雲提供的負載均衡服務

• 1.3.3.2. 你的成本基本上與選擇的VM類型、部署持續時間以及應用程式存儲和傳輸的數據量成正比

1.4. 主流的雲供應商提供了一種替代方法來顯式配置虛擬的處理資源，它們被稱為無伺服器平臺，不需要靜態配置任何計算資源

• 1.4.1. 使用AWS Lambda或GAE(Google App Engine)等技術，應用程式代碼在請求到達時按需載入和執行

• 1.4.2. 如果沒有活躍的請求，基本上不使用資源，也無須支付費用

1.5. 無伺服器平臺還為你管理自動縮放（向上和向下）

• 1.5.1. 當請求同時到達時，平臺創建額外的處理能力來處理請求，併在理想情況下提供始終如一的低響應時間

• 1.5.2. 當請求負載下降時，額外的處理能力將停用，並且不會產生任何費用

1.6. 影響成本因素

• 1.6.1. 所選擇的用於執行請求的處理實例的類型

• 1.6.2. 請求的數量和處理每個請求所持續的時間

• 1.6.3. 每個應用伺服器實例在無伺服器基礎設施上駐留的時長

2. GAE

2.1. GAE(Google App Engine)是Google的第一個產品

• 2.1.1. 作為GCP（Google Cloud Platform，谷歌雲平臺）的一部分

2.2. GAE有兩種類型，即標準環境和靈活環境

• 2.2.1. 基本區別在於，標準環境由GAE更緊密地管理，在支持的開發語言版本方面存在限制

2.3. GAE標準環境

• 2.3.1. 對於長時間處於非活動狀態的應用程式來說是非常合適的，沒有實例便不會產生任何成本

• 2.3.2. GAE的標準環境是一個非常強大的可擴展應用程式平臺

2.4. 自動擴展

• 2.4.1. 隨著請求負載的增長，GAE調度器將動態載入更多實例來處理請求

• 2.4.2. 目標CPU利用率

• 2.4.2.1. 設置CPU利用率閾值，超過該閾值將啟動更多實例來處理流量

• 2.4.2.2. 該參數的範圍是0.5(50%)至0.95(95%)

>  2.4.2.2.1. 預設值為0.6(60%)

• 2.4.3. 最大併發請求數

• 2.4.3.1. 設置在調度程式生成新實例之前實例可以接受的最大併發請求數

• 2.4.3.2. 預設值為10，最大值為80

• 2.4.4. 目標吞吐量利用率

• 2.4.4.1. 與最大併發請求數的值結合在一起使用，以指定何時啟動新實例

• 2.4.4.2. 範圍為0.5(50%)至0.95(95%)

>  2.4.4.2.1. 預設值為0.6(60%)

• 2.4.4.3. 當一個實例的併發請求數達到最大併發請求數乘以目標吞吐量利用率時，調度程式會嘗試啟動一個新實例

• 2.4.5. 三種設置相互影響，讓配置工作變得有些複雜

• 2.4.6. max-pending-latency參數

• 2.4.6.1. 指定了GAE在啟動其他實例來處理請求和減少延遲之前，允許請求在掛起隊列中等待的最長時間

• 2.4.6.2. 預設值為30 ms

• 2.4.6.3. 值越低，應用程式擴展的速度就越快，可能會讓你付出更多的費用

3. AWS Lambda

3.1. AWS Lambda是Amazon的無伺服器平臺

• 3.1.1. 底層設計原則和主要功能與GAE及其他無伺服器平臺相似

3.2. Lambda函數生命周期

• 3.2.1. Lambda函數可以用多種語言構建，並支持常見的服務容器，如Java的Spring和Python的Flask

• 3.2.2. 對於每種語言（即Node.js、Python、Ruby、Java、Go以及基於.NET的代碼）​，Lambda支持許多運行時版本

• 3.2.3. Lambda函數必須設計為無狀態的，以便Lambda運行時環境可以按需擴展服務

• 3.2.4. 當Lambda函數定義的API對應的請求首次到達時，Lambda會下載該函數的代碼，初始化運行時環境和所有特定實例（例如，創建資料庫連接）​，最後調用函數代碼處理程式

• 3.2.5. Lambda的初始調用被稱為冷啟動，所花費的時間取決於所選的語言環境、函數代碼的大小以及初始化函數所花費的時間

• 3.2.5.1. 與GAE一樣，Node.js和Go等輕量級語言的初始化時間通常需要幾百毫秒，而較重的Java或.NET可能需要一秒或更長時間

• 3.2.5.2. 通過預置併發(provisioned concurrency)可以降低冷啟動的成本

• 3.2.6. API一旦執行完成，Lambda就可以使用已部署的函數運行時環境處理後續請求

• 3.2.6.1. 意味著不會產生冷啟動成本

• 3.2.7. Lambda不會向同一運行時實例發送多個併發請求

• 3.2.7.1. 考慮冷啟動成本，所有併發請求都將產生額外的響應時間

3.3. 執行中的註意事項

• 3.3.1. 在定義Lambda函數時，你需要指定分配給運行時環境的記憶體大小

• 3.3.1.1. 與GAE不同的是，你無須指定要使用的vCPU的數量

• 3.3.2. Lambda函數是按每次執行的毫秒數進行計費的

• 3.3.2.1. 每毫秒的成本隨著分配給運行時環境的記憶體量的增加而增加

• 3.3.2.2. 分配的記憶體量越大，Lambda函數的執行速度可能就會越快

• 3.3.2.3. 找到以更低成本提供更快響應時間的最佳點是一項可以獲得高額回報的性能調整實驗

>  3.3.2.3.1. Lambda只有一個參數（記憶體分配）可以改變，讓實驗變得簡單

3.4. 可擴展性

• 3.4.1. 隨著函數併發請求數量的增加，Lambda將部署更多運行時實例來擴展處理能力

• 3.4.2. 當請求負載下降時，Lambda會通過停止未使用的實例來縮小規模

• 3.4.3. 所有Lambda函數針對請求突發的情況都有內置的併發限制

• 3.4.3.1. 一旦達到突發限制，函數就能以每分鐘500個實例的速度進行擴展

• 3.4.4. 如果一個函數負載突然意外升高，它會消耗突發限制資源，並對同一時刻其他希望擴展的函數的可用性產生負面影響

• 3.4.5. 預留併發(reserved concurrency)

• 3.4.5.1. 可以對部署在同一區域同一AWS賬戶下的每個Lambda函數相關的併發級別進行微調

• 3.4.5.2. 每個單獨的函數可以關聯一個小於突發極限的值

>  3.4.5.2.1. 該值定義為可同時執行的函數的最大實例數

• 3.4.5.3. 具有預留併發性的Lambda函數始終擁有專用於自身調用的執行能力

>  3.4.5.3.1. 不會因該區域中其他函數的併發調用而意外“餓死”

• 3.4.5.4. 預留的容量限制了該函數的最大駐留實例數

>  3.4.5.4.1. 當實例數達到預留的值時，無法處理的請求會失敗並返回一個HTTP 429的錯誤

3.5. AWS Lambda提供了一個強大而靈活的無伺服器環境

• 3.5.1. 經過適當配置，可以有效地擴展運行環境，以處理高容量、突發性的請求負載

4. 總結

4.1. 當你的應用程式每天可能需要處理數百萬個請求時，即使降低10%的成本也可以節省大量資金

• 4.1.1. 相同的代碼，相同的請求負載，不同的配置參數

• 4.1.2. 對於多個相互依賴的配置參數，你不太可能通過直覺和專業知識找到“最佳”配置

4.2. 無伺服器平臺是構建可擴展應用程式的強大工具

• 4.2.1. 它們消除了許多部署的複雜性，這主要與管理和更新顯式分配的虛擬機集群相關

4.3. 可以使用一些重要的參數來調整底層無伺服器平臺管理你的函數的方式

• 4.3.1. 參數都具有平臺特異性，但很多都與性能和可擴展性有關，最終會影響你支付的費用

4.4. 想要利用無伺服器計算的優勢，就需要你從雲服務提供商購買雲服務

4.5. 無伺服器平臺是實現微服務架構的常用技術

• 4.5.1. 微服務是一種架構模式，用於將應用程式分解為多個可獨立部署和擴展的部分