作者 | 阿里雲 Serverless 高階開發工程師 蕭起
聽說你也做過這樣的技術選型
小王是一名程式設計師，公司的應用是跑在自建機房的伺服器上，所有的底層服務和運維都需要自己親自下手來做，每次升級、機器擴容都帶來比較大的運維壓力，同時為了能及時擴容堆了不少閒置的機器，機器成本一直比較高。最近公司新開發了兩個應用系統，小王在做技術選型，打算擁抱雲端計算，把新應用部署在雲上，設計一套高彈性、低成本、運維簡單，能輕鬆應對業務突發流量上漲的架構方案，讓自己可以把更多精力投入到業務開發中，減輕自己的運維負擔。
這兩個應用有幾個共同的特點：
- 兩個應用都屬於線上應用，對呼叫延遲、服務穩定性有比較高的要求
- 應用流量隨業務變化比較大，而且很難提前預估業務量會上漲多少，對彈性有比較高的要求。
- 有明顯的業務低峰期，低峰期呼叫量比較低，預計低峰期主要集中於晚上。
- 應用啟動時間長：一個是 Java SpringBoot 的訂單系統，一個是基於大規格映象的 AI 圖片識別系統，啟動時間將近1分鐘。
小王的需求總結起來有三個：
- 一是希望在運維上省事省心，交付 jar 包或者映象後，只需簡單的配置應用就能執行起來，不用專門花費精力搞運維、監控、告警。
- 二是彈效能力要好，業務流量上漲時，可以自動地及時擴容，流量下降後，再自動縮容。
- 三是通過使用雲端計算，提高資源利用率，在成本上更有優勢。
下面就拆開看小王是如何一步一步進行技術選型的。
服務高度整合，免運維，高彈性
在做技術選型時，小王考慮過三種技術架構：SLB+雲伺服器+彈性伸縮的傳統架構、K8s 架構、函式計算 （FC ）架構。
傳統架構需要自己搞 SLB 負載均衡；配置彈性伸縮服務，不斷除錯找到合適的伸縮策略；還要自己採集日誌來建立告警和監控大盤。這一套下來運維和部署成本其實不是很低，有沒有更省事的方案呢？
小王進一步調研了 K8s 架構，k8s 的 Services 與 Ingress 規則可以管理到應用層的訪問，這樣就不用自己搞SLB負載均衡了，同時使用HPA來根據應用水位來水平伸縮。這樣看似很不錯，但真正測試時發現，HPA的伸縮是分鐘級別的，縮容慢一點倒是問題不大，但流量上漲快的時候，擴容總是延後幾分鐘，會導致部分請求延時增高或失敗，影響了服務可用性。如果把擴容的指標閾值調低些，倒是能夠解決這個問題，但同時降低了資源利用率，成本上漲了不少。另外還需要自己搞日誌採集、告警和監控大盤，運維成本也有不少。而且小王之前沒有接觸過k8s，k8s繁多的各種概念理解起來著實也有不少的成本。
基於FC的架構能夠很好的解決上面幾個問題。首先，FC 支援預留模式和基於例項指標的自動伸縮能力，這種模式下能夠做到更靈敏和快速的擴縮容能力，並保證在擴縮容期間請求延時保持平穩；其次，FC高 度整合了眾多開箱即用的功能，體驗絲滑又省心，如：提供http觸發器，省去對接閘道器、SLB的工作；控制檯提供完整的可觀測能力，輕鬆檢視請求、例項狀態和執行日誌。最後，FC只需要為呼叫和呼叫時使用的活躍資源付費，無呼叫時不產生費用，能夠充分提高資源利用率，減低成本。
下面我們來具體介紹下預留模式的使用，以及如何通過閒置計費來降低預留的使用成本。
預留模式，完美解決冷啟動
FC支援按量和預留兩種使用模式，按量模式是通過請求自動觸發例項的建立和擴縮容，在呼叫量增加時建立例項，在請求減少後銷燬例項。按量模式充分提高了資源利用率，但對於小王這種啟動時間比較長的應用，按量模式建立例項時會有明顯的冷啟動現象。為了解決這種冷啟動問題，FC提供了預留的使用模式。使用者配置預留後，FC會建立指定數量的預留例項常駐於系統中，直到使用者更新預留配置將其釋放。當有請求時，會優先排程上預留例項上，預留例項用滿後，新請求會觸發按量例項的建立。同時為了使預留例項量更好地貼合業務曲線，還提供了預留定時伸縮和按指標伸縮能力，來提高預留例項的利用率。點選這裡檢視更多詳情。
通過這樣的方式，即解決了應用冷啟動時間長的問題，又保證了預留例項維持在比較高的利用率水平。即使偶爾有比較大的流量波動，也可以臨時擴容出按量例項來響應請求，儘量保證流量快速上漲情況下服務的質量。
閒置計費，降本大殺器
在真實的使用場景中，為了保證應用請求的低延時，即使在沒有請求時，也要保持一定數量的預留例項，這就造成了成本的上升。有沒有辦法既做到低延時，又做到低成本呢？函式計算為了幫助使用者降低這種場景下的使用成本，推出了預留例項的閒置計費功能，下面我們來具體瞭解下這個功能。
閒置計費
根據預留例項是否在處理請求，我們將例項區分為閒置、活躍兩種狀態，併為兩種狀態分別設定了計費單價。活躍計費單價與原有的資源使用單價保持一致，閒置計費單價是活躍計費單價的20%，開啟閒置計費後能夠幫助您節省大量的成本。
預設情況下，閒置計費功能處於關閉狀態，此時預留模式的例項無論是否正在處理請求，FC都會為其分配CPU，並讓例項始終處於活躍狀態，以保證例項在無請求時依然可以正常執行後臺任務。開啟閒置計費功能後，當預留模式的例項無請求時，FC會將例項上的CPU凍結，使該例項進入閒置狀態。
通過增加閒置計費，對於預留例項也做到了只為真正使用的CPU資源付費。當預留例項處於閒置時，只需支付20%的費用，就能應對例項冷啟動的問題。這將幫助使用者明顯降低預留例項的使用成本，同時使用者也可以更少的關心預留例項的利用率問題，放心大膽的使用預留例項。
我們以上圖為例，假設預留例項的利用率為60%，原有的使用成本為1。使用閒置計費後費用為60% 1 + 40% 20% *1 = 0.68，能夠帶來32%的費用下降。
配置方式
可以通過控制檯和SDK兩種方式進行預留例項和閒置計費的配置。
登入函式計算控制檯，在首頁->彈性管理頁面選擇建立規則，即可進行『閒置計費』的配置。同時可以使用SDK進行配置，支援Java、Go、Node.js等多種語言，詳情可以參考API線上除錯。
開啟閒置計費後，可以在費用中心-賬單詳情-明細賬單中查到彈性例項和效能例項的閒置資源使用費用（計費賬單一般延時3~6小時產出）。
結語
函式計算（FC）一直致力於為使用者提供高彈性、免運維、低成本的全託管計算服務。本次閒置計費功能的釋出，能夠幫助使用者進一步降低使用預留例項的成本，讓使用者只為真實使用的預留資源付費。函式計算會逐步釋放更多serverless 的技術紅利，在效能、成本、體驗上不斷為使用者提供更極致的表現。
文件連結:
彈性管理：https://help.aliyun.com/document_detail/185038.html
計費概述：https://help.aliyun.com/document_detail/54301.html
更多內容關注 Serverless 微信公眾號（ID：serverlessdevs），彙集 Serverless 技術最全內容，定期舉辦 Serverless 活動、直播，使用者最佳實踐。