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. 微服務是一種架構模式，用於將應用程式分解為多個可獨立部署和擴充套件的部分