*作者：蕭起｜阿里雲 Serverless 高階開發工程師*

## 聽說你也做過這樣的技術選型

小王是一名程式設計師，公司的應用是跑在自建機房的伺服器上，所有的底層服務和運維都需要自己親自下手來做，每次升級、機器擴容都帶來比較大的運維壓力，同時為了能及時擴容堆了不少閒置的機器，機器成本一直比較高。最近公司新開發了兩個應用系統，小王在做技術選型，打算擁抱雲端計算，把新應用部署在雲上，設計一套高彈性、低成本、運維簡單，能輕鬆應對業務突發流量上漲的架構方案，讓自己可以把更多精力投入到業務開發中，減輕自己的運維負擔。

這兩個應用有幾個共同的特點：

-   兩個應用都屬於線上應用，對呼叫延遲、服務穩定性有比較高的要求。

-   應用流量隨業務變化比較大，而且很難提前預估業務量會上漲多少，對彈性有比較高的要求。

-   有明顯的業務低峰期，低峰期呼叫量比較低，預計低峰期主要集中於晚上。

-   應用啟動時間長：一個是 Java SpringBoot 的訂單系統，一個是基於大規格映象的 AI 圖片識別系統，啟動時間將近 1 分鐘。

小王的需求總結起來有三個：

-   一是希望在**運維**上省事省心，交付 jar 包或者映象後，只需簡單的配置應用就能執行起來，不用專門花費精力搞運維、監控、告警。

-   二是**彈效能力**要好，業務流量上漲時，可以自動地及時擴容，流量下降後，再自動縮容。

-   三是透過使用雲端計算，提高資源利用率，在**成本**上更有優勢。

下面就拆開看小王是如何一步一步進行技術選型的。

## 服務高度整合，免運維，高彈性

在做技術選型時，小王考慮過三種技術架構：SLB + 雲伺服器 + 彈性伸縮的傳統架構、K8s 架構、函式計算 （FC） 架構。

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b1806a04de1c4768a37440dea7d7256d~tplv-k3u1fbpfcp-zoom-1.image "1.png")

傳統架構需要自己搞 SLB 負載均衡；配置彈性伸縮服務，不斷除錯找到合適的伸縮策略；還要自己採集日誌來建立告警和監控大盤。這一套下來運維和部署成本其實不是很低，有沒有更省事的方案呢？

小王進一步調研了 K8s 架構，K8s 的 Services 與 Ingress 規則可以管理到應用層的訪問，這樣就不用自己搞 SLB 負載均衡了，同時使用 HPA 來根據應用水位來水平伸縮。這樣看似很不錯，但真正測試時發現，HPA 的伸縮是分鐘級別的，縮容慢一點倒是問題不大，但流量上漲快的時候，擴容總是延後幾分鐘，會導致部分請求延時增高或失敗，影響了服務可用性。如果把擴容的指標閾值調低些，倒是能夠解決這個問題，但同時降低了資源利用率，成本上漲了不少。另外還需要自己搞日誌採集、告警和監控大盤，運維成本也有不少。而且小王之前沒有接觸過 K8s，K8s 繁多的各種概念理解起來著實也有不少的成本。

基於 FC 的架構能夠很好的解決上面幾個問題。首先，FC 支援預留模式和基於例項指標的自動伸縮能力，這種模式下能夠做到更靈敏和快速的**擴縮容**能力，並保證在擴縮容期間請求延時保持平穩；其次，FC 高度整合了眾多**開箱即用**的功能，體驗絲滑又省心，如：提供 http 觸發器，省去對接閘道器、SLB 的工作；控制檯提供完整的可觀測能力，輕鬆檢視請求、例項狀態和執行日誌。最後，FC 只需要為呼叫和呼叫時使用的活躍資源付費，**無呼叫時不產生費用**，能夠充分提高資源利用率，減低成本。

下面我們來具體介紹下預留模式的使用，以及如何透過閒置計費來降低預留的使用成本。

## 預留模式，完美解決冷啟動

FC 支援**按量**和**預留**兩種使用模式，按量模式是透過請求自動觸發例項的建立和擴縮容，在呼叫量增加時建立例項，在請求減少後銷燬例項。按量模式充分提高了資源利用率，但對於小王這種啟動時間比較長的應用，按量模式建立例項時會有明顯的冷啟動現象。

為了解決這種冷啟動問題，FC 提供了預留的使用模式。使用者配置預留後，FC 會建立指定數量的預留例項常駐於系統中，直到使用者更新預留配置將其釋放。當有請求時，會優先排程上預留例項上，預留例項用滿後，新請求會觸發按量例項的建立。同時為了使預留例項量更好地貼合業務曲線，還提供了預留定時伸縮和按指標伸縮能力，來提高預留例項的利用率。文末附錄彈性管理 **[** **1]** 檢視更多詳情。

透過這樣的方式，即解決了應用冷啟動時間長的問題，又保證了預留例項維持在比較高的利用率水平。即使偶爾有比較大的流量波動，也可以臨時擴容出按量例項來響應請求，儘量保證流量快速上漲情況下服務的質量。

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/03938eb8c22c4ae491d4e0a382acc2b8~tplv-k3u1fbpfcp-zoom-1.image "2.png")

## 閒置計費，降本大殺器

在真實的使用場景中，為了保證應用請求的低延時，即使在沒有請求時，也要保持一定數量的預留例項，這就造成了成本的上升。有沒有辦法既做到低延時，又做到低成本呢？函式計算為了幫助使用者降低這種場景下的使用成本，**推出了預留例項的閒置計費功能**，下面我們來具體瞭解下這個功能。

### 閒置計費

根據預留例項是否在處理請求，我們將例項區分為閒置、活躍兩種狀態，併為兩種狀態分別設定了計費單價。活躍計費單價與原有的資源使用單價保持一致，閒置計費單價是活躍計費單價的 20%，開啟閒置計費後能夠幫助您節省大量的成本。

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9723b7d737f847b78ef8133d9cf64053~tplv-k3u1fbpfcp-zoom-1.image "3.png")

預設情況下，閒置計費功能處於關閉狀態，此時預留模式的例項無論是否正在處理請求，FC 都會為其分配 CPU，並讓例項始終處於活躍狀態，以保證例項在無請求時依然可以正常執行後臺任務。開啟閒置計費功能後，當預留模式的例項無請求時，FC 會將例項上的 CPU 凍結，使該例項進入閒置狀態。

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/963fb6a4c70a47a5af66e4260c9eb047~tplv-k3u1fbpfcp-zoom-1.image "4.png")

透過增加閒置計費，對於預留例項也做到了只為真正使用的 CPU 資源付費。當預留例項處於閒置時，只需支付 20% 的費用，就能應對例項冷啟動的問題。這將幫助使用者明顯降低預留例項的使用成本，同時使用者也可以更少的關心預留例項的利用率問題，放心大膽的使用預留例項。

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/13050afbbc1948d9af4522fa20ab0cb8~tplv-k3u1fbpfcp-zoom-1.image "5.png")

我們以上圖為例，假設預留例項的利用率為 60%，原有的使用成本為 1。使用閒置計費後費用為 60% * 1 + 40% * 20% *1 = 0.68，能夠帶來 32% 的費用下降。

### 配置方式

可以透過控制檯和 SDK 兩種方式進行預留例項和閒置計費的配置。

登入函式計算控制檯，在首頁->彈性管理頁面選擇建立規則，即可進行【閒置計費】的配置。同時可以使用 SDK 進行配置，支援 Java、Go、Node.js 等多種語言，詳情可以參考 API 線上除錯 **[2** **]** 。

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8d68c18c1e6b4ea592d20c77bbc9bbec~tplv-k3u1fbpfcp-zoom-1.image "6.png")

開啟閒置計費後，可以在費用中心-賬單詳情-明細賬單中查到彈性例項和效能例項的閒置資源使用費用（計費賬單一般延時 3~6 小時產出）。

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/669b168720e944cd99e0fc043709f4b3~tplv-k3u1fbpfcp-zoom-1.image "7.png")

## 結語

函式計算 （FC） 一直致力於為使用者提供高彈性、免運維、低成本的全託管計算服務。本次閒置計費功能的釋出，能夠幫助使用者進一步降低使用預留例項的成本，讓使用者只為真實使用的預留資源付費。函式計算會逐步釋放更多 Serverless 的技術紅利，在效能、成本、體驗上不斷為使用者提供更極致的表現。

***參考文件連結：***

[1] 彈性管理：

*<https:>*

[2] API 線上除錯：

*<https:>*

[3] 計費概述：

*<https:>*

點選[**此處**](https://www.aliyun.com/product/fc)，瞭解函式計算 FC 更多功能詳情！</https:></https:></https:>

閒置計費 | Serverless 冷啟動與成本間的最優解

相關文章