【福利活動】1分鐘Serverless部署PHP商城實驗班上線啦！
帶你體驗如何使用 Serverless 應用引擎 SAE 快速部署一個PHP商城，並體驗 SAE 帶來的彈性伸縮、應用監控等強大能力。
完成實驗，即可獲得價值10元的貓超卡和價值5元阿里雲通用代金券！快來參加吧！
活動時間：2月6日 - 2月17日
活動連結（建議 PC 端訪問）：
https://developer.aliyun.com/...
背景介紹
全託管的 Serverless 計算平臺能給使用者帶來更少的運維代價、更強的穩定性和更快的彈效能力。
Serverless 的目標之一是免運維，但仍舊存在一些障礙，在 Serverless 場景特有的一些關鍵服務配置比如“併發度”、“最小例項數”、“最大例項數”，如何配置引數才是最合適的？怎麼確定自己配置的引數是否合理？仍舊一直是讓使用者頭痛的事情。
本文介紹了函式計算團隊在自動化推薦 Serverless 函式最佳配置上的思考和相關工作，希望幫助使用者解決目前使用 Serverless 的痛點問題，徹底解放使用者的雙手，釋放 Serverless 服務的價值。
評估 Serverless 服務最佳配置的難點
使用者使用 Serverless 服務的預期是：更低的成本、更快的彈性、更優的效能、更穩定的環境，這同時也是 Serverless 平臺承諾提供給使用者的能力。儘管如此，很多使用者在使用過程中還是出現了各種問題：
- 為什麼使用 Serverless 後發現成本還變高了？
- 為什麼使用 Serverless 的冷啟動時間那麼長？
- 在 Serverless 平臺上的效能延遲表現為什麼更差了？
Serverless 平臺能提供一定的基礎能力，但是針對不同的業務邏輯，需要採取合適的配置才能更好的發揮 Serverless 的效果。但是如何評估某函式的最佳配置，其中涉及到多變數的協同最佳化問題，並不是一個簡單的問題。具有以下幾個難點：
難點1：成本和效能的權衡
- 一定的單例項多併發數，可以提高單例項並行處理請求的數量，減少例項數，從而降低成本；
- 併發數過高時，會增加資源競爭，導致效能延遲增加，從而增加成本；
- 較低的例項規格單價成本更低，但是延時更大；較高的例項規格單價成更高，但是延時可能更低
如何針對使用者的偏好場景（效能優先還是成本優先），為使用者推薦最佳的函式配置，成為首先需要考慮的一大難點。
難點2：不同函式業務邏輯的複雜度
除了成本和效能維度的衡量，針對不同型別的函式邏輯，不同的配置引數效果也有差異。很多函式業務邏輯複雜，只針對單一邏輯分支進行評估最佳配置並不代表整體的最優；不合適的配置可能增大使用者非預期的成本。比如：
- 對於 CPU 密集型的函式，規格增加對單例項效能的提升有較大的改善
- 對於 IO 密集型的函式，規格增加對單例項效能的提升存在邊際效應遞減的情況，當超過某規格後，規格的提升對效能提升的效果基本沒有
比如下圖展示了 CPU 密集型函式在不同規格下的壓測資料：
CPU 密集型的規格越高，maxTPS 越大；並且規格與 maxTPS 呈現明顯的線性關係。
規格越大，maxRT 越低 ，說明CPU密集型的函式，增大資源規格可以顯著降低 RT。但是規格增大到 4G、8G 後，對 RT 的降低效果邊際效應遞減。
下圖展示了 IO 密集型函式在不同規格下的壓測資料：
規格的提升對 IO 密集型的效能改善作用有限，特別到了高規格，比如 3G 後，maxTPS 增幅不大
難點3: 函式配置對平臺側資源的影響
函式的併發度、最小例項數、最大例項數等配置會影響到平臺側資源池的容量規劃，如何保證單函式的資源剛性交付，多函式的資源隔離；如何最佳化平臺側彈性排程能力，提高平臺側的資源利用率，是另一個難點問題。
- 較低的單例項併發度，函式流量波動變化的場景，會提前達到單例項併發上限，導致例項擴縮容頻繁，對使用者體感來說的冷啟動更頻繁，對平臺來說需要建立和維護更多的例項個數，整體的資源利用率偏低
- 最大例項數的配置，如何保證例項資源的剛性交付
如何評估 Serverless 服務的最佳配置
透過以上幾個難點分析，我們知道評估 Serverless 服務的最佳配置並非易事，下面的幾個演化階段，介紹了使用者使用 Serverless 進行服務配置的方式變化，從青銅到王者，我們一直在為使用者提供最好的 Serverless 服務努力。
青銅使用者：拍腦袋設定
在上線初期，使用者需要面對一堆配置引數，如果是初次使用函式計算的新使用者，還需要翻看文件才瞭解配置含義，反覆折騰後也不知道配置引數多少才合適，最後還是“拍腦袋”隨便設定了一個值。
白銀使用者：人工反覆調整
函式上線後，可能會發現之前的配置不合理，仍舊需要反覆修改函式配置驗證。如果修改了函式邏輯，可能會發現之前的配置會出現問題，比如請求延遲變大，或者函式偶然出現 OOM 錯誤。
有一些經驗的開發者會選擇自己進行壓測，確定函式的最佳配置。但是壓測的使用具有一定的門檻，並且壓測得到資料一般使用者也不知道怎麼分析，可能會產生更多的疑問。最終折騰一番，使用者也不是很確定壓測得到的配置是否是最符合自己預期的最優選擇。
為了解決青銅和白銀使用者的這些困擾，我們推出了自動化推薦配置的王者功能。
王者：效能探測+資料分析的自動化推薦
近期函式計算重磅推出了函式的效能探測功能，效能探測的目的是幫助使用者評估函式單個例項在不同規格下的效能上限，並且推薦出滿足使用者預期延遲的最佳併發度和函式規格配置。
具體的探測方法，根據 little's law 排隊理論，我們知道服務的吞吐量、併發數和響應時間之間存在著一個等式關係：併發數 = 請求的平均延遲 * TPS
如果我們使用圖形化表示，如下圖所示：
橫座標是併發數，左邊的縱座標是 TPS，右邊的縱座標是延遲。由於每個伺服器的處理能力都有限，所以會出現
- 吞吐量-併發數：隨著併發數上升，吞吐量先上升後平緩，可能出現下降，即效能惡化；
- 延遲-併發數：當併發度過高時，延遲會變高，甚至會急劇惡化；
透過效能探測，我們會得到每種規格的關鍵效能資料：
- 每個規格的最高能承受的 QPS：基於此，使用者如果對業務流量比較清楚，可以計算得到函式所需的最小例項數和最大例項數。
- 推薦的最佳規格和規格下的最佳併發度。
比如使用者預期自己的函式呼叫端到端延遲是 1000 毫秒，那麼我們會根據 1000 毫秒的延遲限制，推薦出最佳的規格，以及該規格下的最佳併發度，即滿足延遲限制的最高 QPS 時對應的併發度。
整個功能採用流程圖的方式指引，先壓測單例項，再壓測多例項，因為在效能表現平穩的系統，多例項的效能是單例項效能的線性疊加，所以只需要壓測出單例項的效能，就可以推算出多例項的效能。
使用者能夠根據引導使用效能探測，並得到推薦結果；同時效能探測功能是完全免費的，使用者只需要為函式承接的請求流量付費，不需要為壓測功能付費。
單例項壓測結果分析頁面：
單例項壓測資料詳情頁面：
目前函式效能壓測功能已經在函式計算控制檯上線，具體詳細的使用方式可以參考文件。
效能探測推薦的函式配置優先保證滿足效能需求，實現最高的資源利用率，但是真正實現最低成本配置，需要結合函式線上歷史流量資料分析，進行推薦。
在進行成本最佳化推薦規格時，不僅需要達到節約成本的目的，還需要保證不破壞現有服務的 QoS，即效能不會因為例項規格的降低，而導致延遲增大。
比如下面這張圖表示使用者實際資源使用量較低，實際配置的規格偏大，我們可以推薦更低的規格，以幫助使用者節約成本。
透過結合效能探測+歷史流量資料分析，可以自動化給使用者推薦得到保證效能的同時，成本最低的最佳函式配置。
至尊王者：智慧動態調整併發度
最後我們期待的至尊王者，是徹底解放使用者的雙手，能夠智慧動態地調整函式的併發度，不管流量變化或業務邏輯如何變化，使用者再也不需要關心或重新配置函式併發度的大小。
智慧動態併發度未來一個演化方向，在這種模式下，使用者不需要透過手動配置引數，而是在函式執行時動態調整，根據例項 CPU 負載的健康指標自動調整到最佳值。函式計算也會繼續努力，打造體驗更好的，更幫使用者節省成本，更 Serverless 的自動化配置方案。
總結與展望
目前效能探測功能已經在函式計算控制檯開放，基於歷史流量評估能夠降低成本的最佳配置也會在近期公測開放。基於效能探測的自動化推薦函式配置功能，極大降低了使用者上手以及運維函式配置的複雜度，期望能給使用者使用 Serverless 帶來王者般的體驗。
參考
Little's Law Wikipedia
RobustScaler: QoS-Aware Autoscaling for Complex Workloads
更多內容關注 Serverless 微信公眾號（ID：serverlessdevs），彙集 Serverless 技術最全內容，定期舉辦 Serverless 活動、直播，使用者最佳實踐。