Spring Boot Serverless 實戰系列 | 性能調優

作者：西流（阿里云函式計算專家）

導讀：Spring Boot 是基于 Java Spring 框架的套件，它預裝了 Spring 的一系列組件，讓開發者只需要很少的配置就可以創建獨立運行的應用程式，在云原生的環境中，有大量的平臺可以運行 Spring Boot 應用，例如虛擬機、容器等，但其中最有吸引力的，是以 Serverless 的方式運行 Spring Boot 應用，

我將通過一系列文章，從架構，部署，監控、性能、安全等 5 個方面來分析 Serverless 平臺運行 Spring Boot 應用的優劣，為了讓分析更有代表性，我選擇了 Github 上 star 數超過 50k 的電商應用 mall 作為示例，這是系列文章的第四篇， 本文向大家展示如何對 Serverless 應用進行性能調優，

實體啟動速度優化

在之前的文章實戰教程中，相信大家都感受到 Serverless 的便捷之美，只需上傳代碼包和鏡像就能夠輕松上線一個彈性高可用的 Web 應用，

但是它仍存在首次啟動“冷啟動延時”的問題，Mall 應用實體的啟動大約 30 秒左右，用戶會感受較長時間的冷啟動延時，在這個“即時時代”應用程式回應慢多少會有些瑕不掩瑜，（“冷啟動”是指函式服務于特定呼叫請求時的狀態，當一段時間沒有請求后，Serverless 平臺則會回收函式實體；等到下一次再有請求時，系統會再次實時拉起實體，該程序稱之為冷啟動，）

在優化冷啟動之前，我們要先分析清楚冷啟動各個階段的耗時，

首先在函式計算（FC） 控制臺的服務配置界面，開啟鏈路追蹤功能，

對 mall-admin 服務發起請求，成功后查看 FC 控制臺，我們能夠看到相應的請求資訊，注意關閉“僅查看函式錯誤”，這樣才會顯示所有請求，指標監控和呼叫鏈路資料收集會存在一定延時，如果沒有顯示，請等待一會再重繪，找到冷啟動標記的請求，點擊 “更多” 下的 “請求詳情”，

呼叫鏈路會顯示冷啟動各個環節的耗時，冷啟動包含以下幾個環節：

代碼準備（PrepareCode）：主要是下載代碼包或者鏡像，由于我們已經啟用了鏡像加速功能，不需要下載全部的鏡像，因此這一步的延時非常短，

運行時初始化（RuntimeInitialization）：從啟動函式開始，到函式計算（FC）系統探測到應用埠就緒為止，這中間包含了應用啟動時間，在命令列執行 s mall-admin logs 查看相應的日志時間，我們也能看到 Spring Boot 應用的啟動需要花大量的時間，

應用初始化（Initialization）：函式計算提供了 Initializer 介面，用戶可以將一些初始化邏輯放在 Initializer 中執行，

呼叫延時（Invocation）：處理請求的延時，這個延時非常短，

從上述鏈路追蹤圖來看，實體啟動時間是瓶頸，但是我們可以采取多種方式來優化，

使用預留實體

Java 類應用普遍會啟動較慢，應用在初始化時，也需要和很多外部服務互動，耗時較長，這類流程是業務邏輯需要的，很難優化延時，因此函式計算提供了預留實體功能，預留實體的起停由用戶自己控制，沒有請求也會常駐在那，因此不會有冷啟動的問題，當然用戶需要為整個實體的運行付費，即便實體沒有處理任何請求，

在函式計算控制臺，我們可以在“彈性伸縮”頁面為函式設定預留實體，

用戶在控制臺中配置最小和最大實體數，平臺會預留最小實體數目的實體，最大實體是指該函式下實體的上限，用戶也可以設定定時預留和按指標預留的規則，

創建預留規則后，系統就會創建預留實體，當預留實體就緒后，我們再訪問函式就不會有冷啟動，

優化實體啟動速度

延遲初始化

在 Spring Boot 2.2 及更高版本中，可以開啟一個全域延遲初始化標志，這將提高啟動速度，但代價是第一個請求的延遲時間可能變長，因為需要等待組件首次初始化，

可在 s.yaml 中為相關應用配置以下環境變數

SPRING_MAIN_LAZY_INITIATIALIZATION=true

關閉優化編譯器

默認情況下，JVM 有多個階段的 JIT 編譯，雖然這些階段可以逐漸提高應用的效率，但它們也會增加記憶體使用的開銷，并增加啟動時間，對于短期運行的 Serverless 應用，請考慮關閉此優化，以犧牲長期效率換取更短的啟動時間，

可在 s.yaml 中為相關應用配置以下環境變數：

JAVA_TOOL_OPTIONS="-XX:+TieredCompilation -XX:TieredStopAtLevel=1"

s.yaml 中設定環境變數示例：

如下圖所示，對 mall-admin 函式配置環境變數，然后執行 sudo -E s mall-admin deploy 部署，

登錄實體檢查環境變數是否配置正確：

在控制臺函式詳情頁的請求串列中找到對應的請求，點擊更多中的“實體詳情鏈接”，

在實體詳情頁中點擊“登錄實體”，

在 shell 界面中執行 echo 命令，查看對應的環境變數是否設定正確，

注意：對于非預留實體，一段時間沒有請求后，函式計算系統會自動回收實體，此時無法再登入實體（上面的實體詳情頁面中的登錄實體按鈕會變灰），所以請執行呼叫后，在實體被回收之前盡快登錄，

配置合理的實體引數

當我們選擇了應用實體規格，比如 2C4G 或者 4C8G，接下來我們希望知道一個實體處理多少請求可以既能充分利用資源又能夠保證性能，當處理的請求超過一個限制后，系統能夠快速彈出實體，保證應用性能平滑，

如何度量實體過載有多個維度，例如 qps 超過一定閾值，或者實體 CPU/Memory/Network/Load 等指標超過閾值等等，函式計算使用實體并發度（Instance Concurrency）來作為實體負載的度量和實體伸縮的依據，

實體并發度（Instance Concurrency）是指一個實體能同時執行的請求數，例如將實體并發度設定為 20，則意味著一個實體在任意時刻最大能同時執行 20 個請求，

注意：請區分實體并發度和 QPS 的區別，

使用實體并發度來度量負載有如下優勢：

系統能夠迅速統計實體并發度指標值進行擴縮容，CPU/Memory/Network/Load 等實體級別的指標通常是后臺統計，需要花費數十秒的指標統計后才能進行伸縮，難以滿足在線應用的彈性伸縮要求，

在各種條件下，實體并發度指標都能夠穩定的反映系統負載高低，如果以請求延時作為指標，系統難以區分是實體過載導致延時變大，還是下游服務成為瓶頸導致延時變大，例如一個典型的 Web 應用，通常會訪問 MySQL 資料庫，如果資料庫成為瓶頸，請求延時變大，此時擴容不但毫無意義，而且會壓垮資料庫，讓情況更加惡化，QPS 和請求延時相關，也會有上述問題，

實體并發度作為伸縮依據雖然有上述優點，但用戶常常并不知道該設定多大的實體并發度，我推薦按照下述流程確定合理的并發度：

1、將應用函式的最大實體數設定為 1，確保壓測到單個實體的性能，

2、使用負載壓測工具對應用進行壓測，查看 tps 和請求延時等指標，

3、逐步調大實體并發度，如果性能仍然良好，則繼續調大；如果性能不符合預期，則調小并發度，

相關鏈接

1）Spring Boot：
https://spring.io/projects/spring-boot

2）Mall：
https://github.com/macrozheng/mall

3）Serverless Devs 安裝檔案：
http://serverlessdevs.com/zhcn/docs/installed/cliinstall.html

4）函式計算：
https://www.aliyun.com/product/fc

點擊此處，前往 Serverless Devs 主頁查看更多！
發布云原生技術最新資訊、匯集云原生技術最全內容，定期舉辦云原生活動、直播，阿里產品及用戶最佳實踐發布，與你并肩探索云原生技術點滴，分享你需要的云原生內容，

關注【阿里巴巴云原生】公眾號，獲取更多云原生實時資訊！

標籤：其他

上一篇：Spring Boot Serverless 實戰 | Serverless 應用的監控與除錯

下一篇：《認知覺醒》讀書筆記