Serverless 技術正在獲得越來越多的認可。CNCF 2019年報告顯示，41% 的受訪者表示已經在使用 Serverless，另外 20% 的受訪者表示計劃在未來 12-18 個月內採用 Serverless 技術。
Serverless 技術關注者對其價值點討論⼤多是基於公有云場景的雲函數等產品，其關注點在資源支付方式更加細粒度，和公有云Baas的粘合上，和私有云環境中業務團隊關注的價值不太契合；在我們對業界落地場景調研以及同業務團隊⼀起實踐後，我們發現私有云環境中業務團隊關心的Serverless價值可概括爲三點：
-
提效： 加快業務團隊迭代效率， Serverless對開發流水線重新對分工，業務開發人員聚焦業務，無需操心運維和擴容等諸多事項；
-
降本：按需實時彈性可避免資源浪費，最大程度發揮資源優勢；
-
解耦：支持事件觸發，將各個組件通信的邏輯變成事件進⾏解耦合，非常適合業務的擴展和變化；
其中“提效”和“降本”爲核心價值，解耦爲重要考慮點。
我們認爲Serverless出現不是爲了替代現有的Serverful（傳統雲）框架，兩者是互補的關係，Serverless有其業務場景優勢（後續⽂章再展開），合適最重要。筆者目前工作是聚焦輕舟Serverless（“輕舟”系網易研發的雲原生基礎設施平臺代號）和業務團隊⼀起實現業務開發的提效、降本和解耦。當前開源Serverless方案很多，而選型強大活躍開源社區方案讓我們能夠持續改進自己的Serverless平臺。基於此訴求，我們很早便選型了Knative，因爲從一開始其社區非常活躍，有Google，IBM，RedHat等大公司參與，其次是標準先行。而事實也在慢慢印證了我們的選擇。
如圖所示， Knative 佔據了 34% 的份額，遙遙領先於第⼆名 OpenFaaS，Knative 是搭建 Serverless 平臺的首選。（ 數 據 來 源 於 CNCF 2019 年 社 區 調 查 報 告 ）
目前，網易輕舟雲原生團隊已經和網易雲音樂前端團隊合作共建雲音樂Serverless部署平臺ALPACA，將Serverless用於前端場景。該平臺架構如下圖。
其中輕舟負責底層能力，Knative是其中的核心能力，我們基於其業務場景，對Knative進行了壓測分析，也做了性能調優POC，本文主要從性能角度，基於Serverless前端使用場景對Knative進行分析，嘗試揭開Knative核心數據路徑性能真相併給出調優思考。
⼀、Knative系統內的數據路徑分析
本文暫不討論流量如何導⼊到ALPACA平臺，先聚焦到ALPACA平臺Knative系統內部本身。
Knative系統內部數據路徑是， Knative網關->Activator->Queue Proxy->業務App；社區推薦使用的方式是不注入Sidecar以獲取更佳的性能，因此我們討論場景是“不注入Sidecar，管控面使用Pilot，Knative網關使用輕舟的API網關產品”。
Knative系統內部默認的數據路徑如上圖，用戶業務流量經過一層Knative網關，經過Activator 到達Queue Proxy 代理組件，最後到達應用程序。
從上圖可知，默認情況下流量經過三層代理（Knative網關、Activator、Queue Proxy）後纔到達應用APP，每⼀層代理均可能是性能的攔路虎。
我們的分析思路如下：
-
Knative網關這⼀層承載了流量管理、灰度發佈等功能必須存在，當前使用輕舟API網關產品充當，性能均調優過，本身性能沒什麼問題，非本次核心關注點
-
App爲用戶的業務代碼性能無法控制，平臺層面不可操作，也非關注點
於是將性能分析要點集中到剩餘的兩層代理（Activator 和Queue Proxy）上。
首先Activator作用是：
-
冷啓動充當看門人，業務POD 0-1流量會經過Activator組件
-
突發流量的保護者，將Activator加⼊到核心路徑，充當緩衝，流量將會在Activator緩存（0.8版本加入功能）
其次Queue Proxy作用是：
Queue Proxy以Sidecar⽅式和應⽤容器部署到同⼀個Pod，Queue Proxy是爲了配合完成擴縮容事宜以及滿足App可觀測性要求，以Sidecar方式部署主要考慮到對App應用無侵入，功能描述如下：
-
完成觀測性數據收集向Autoscaler同步當前的併發監控，以便實現自動伸縮功能
-
代理業務容器,完成指標的統計，並將對應的數據彙報給後端的⽇志/監控/分佈式跟蹤服務
Activator必要性分析
談到Activator必要性，需要先了解當前Serverless 難題“冷啓動”，所謂冷啓動是Serverless縮容到0 後，重新從0擴容到1的過程，該過程目前是非常慢的，也是業界難題，根據社區對Knative冷啓動分析得知，冷啓動時間大概6s ，很顯然6s的冷啓動任何業務都⽆法容忍；當前可以儘量優化冷啓動時間，但是想達到ms級別，做到業務⽆感知，挑戰非常大，目前有兩種解決思路：
方向1: 溫啓動，通過冗餘方式建立預熱池來解決，當需要0-1時候，從預熱池取，然後將用戶程序注入，省去建立容器的過程
方向2: 通過默認預留實例來規避
目前該問題我們先通過方向2來解決，至於方向1也在考慮，但是涉及到的開發工作量大，且需要對K8s框架改動，需要根據需求觸發。所以目前在我們使用場景中不需要Activator幫助從0-1擴容。
對於突發流量保護功能，在使⽤場景中可降低擴容觸發的併發要求，預留出一定的Pod計算能力來抵禦突發流量；因此在目前業務場景中，Activator存在必要性⼀般，可以考慮將其從核心數據路徑中徹底去除。
QueueProxy必要性分析
Queue Proxy核心作用是收集App的指標（併發、RPS等）來決定擴容，當前以Sidecar⽅式部署是非常有必要的：
- 將核心指標統計邏輯提煉到Queue Proxy，對App無任何代碼邏輯侵⼊，基礎設施和應用App業務邏輯分離，獨立運維
- 收集擴容指標支持跨語言
所以Queue Proxy Sidecar是非常有必要的，但是相比裸業務容器而言，會增加⼀層代理（該場景就像服務網格Server Sidecar⼀樣），導致業務容器性能降低，這是選擇這種架構所要付出的資源成本，我們要做的就是將該成本降到最小。
如上圖，總結下分析結論，從性能⾓度出發，我們需要關注：
將Activator從數據路徑中去除
重點關注Queue Proxy 和App路徑
關注Knative網關和Queue Proxy路徑
⼆、開源Knaitve性能實際測
從上文的分析結論可知，我們得到了具體的性能關注點，於是對這些關注點進行實際的性能測試。
在Knative框架下，性能可以通過CPU和實例個數橫向擴展性能，所以後續測試均固定在單個業務容器，通過對比測試來發現性能瓶頸，業務容器選型社區簡單的go語言實現的helloworld服務程序（鏡像爲hub.c.163.com/qingzhou/knative/demo/helloworld-go:v0.1），採用測試工具Hey（https://github.com/rakyll/hey ）使⽤HTTP長連接進行測試。
測試環境
- Knative serving 0.14
- 物理機容器
- 輕舟網關
- 三臺獨立的物理機器避免相互影響
測試方法
- 部署測試server kservice
root@pubt1-k8s59:/home/liuqinlong# cat performance.yaml
apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
name: helloworld-go
namespace: default
spec:
template:
metadata:
labels:
app: helloworld-go
annotations:
autoscaling.knative.dev/maxScale: "1"
autoscaling.knative.dev/minScale: "1"
spec:
containers:
- image: hub.c.163.com/qingzhou/knative/demo/helloworld-go:v0.1
env:
- name: SIMPLE_MSG
value: "helloworld-go"
- 測試命令
hey -z 60s -c 70 --host "helloworld-go.default.example.com" "<http://10.178.67.100/>"
- Knaitve原生性能數據測試
- 默認數據路徑進行壓測
如下結果顯示，雖然Activator採用HPA進行性能擴展，但是其擴容非常慢，如果性能測試時候沒有來得及擴容Activator，對整個延遲影響效果巨⼤只有920Qps。即使Activator擴容成了8個發現p90延時也在7ms以上，Qps約7千。
避坑說明：在測試過程中，需要確認Activator HPA擴容是否生效，筆者測試過程中默認環境中沒有安裝metrics-server導致Activator無法HPA擴容。整個核⼼路徑中Activator 默認限制單個CPU，其使用率達到100%，導致QPS非常低（才920），P90延遲要111ms，p99延遲要195.2ms
- 原生容器對比含有Queue Proxy sidecar 的容器
經過前文的分析Queue Proxy以Sidecar⽅式存在是Knative 架構要求，當前測試case情況下，加⼊Queue Proxy Sidecar後，相⽐原⽣容器，QPS從3.9w->3.1w，P90 延遲翻倍（2.5->4.2）。
相對來說，在相同併發壓力情況下，因爲新增⼀層代理延遲肯定提升，QPS會跟着降低。但是我們發現CPU損失代價有些大，CPU使⽤率達到了1497% （Server CPU才482.4%），理論測試的App爲hello world程序業務邏輯⾮常簡單，業務處理延遲不長，Queue Proxy 和當前測試App CPU使用率比值最好是1:1，所以Queue Proxy存在CPU異常消耗的問題，需要進行調優解決。
注意：v0.14 Queue Proxy 性能要比v0.9版本Queue Proxy性能要好，後⽂Queue Proxy測試版本均採⽤的是v0.14版本，下面給出性能對比：
QPS提升 (31891.7207-20505.6853)/20505.6853 = 55%（計算過程後文不再贅述）。
測試結論
- Activator加⼊到數據路徑中，在沒有擴容情況下，性能⾮常差QPS只有920，經過HPA擴容成8個後，QPS可達7776.1257
- 業務容器引入Sidecar後，數據路徑變長，相同壓⼒下QPS從3.9w -> 3.1w，P90延遲翻倍（2.5->4.2），但是CPU使⽤率達到了1497%，和Server CPU消耗差距約三倍，需對Queue Proxy⾼CPU問題進行分析
- Knative社區對Queue Proxy也在不斷優化中，社區v0.14 Queue Proxy相比v0.9版本的Queue Proxy性能提升明顯，QPS 2w->3w，延遲 6ms->4.2 ms
三、Knaitve數據路徑性能優化
經過對Knative性能測試，進⼀步確認了下面性能調優點：
1.數據路徑上去除Activator
2.Queue Proxy 和App路徑優化
3.優化Knative Gateway性能
數據路徑上去除Activator
分析對比去除Activator路徑帶來的性能收益，如下表，將Activator移出核心數據路徑後，QPS能力提升三倍（7776.1257 -> 25569.5698），且P99延遲大幅降低
Queue Proxy 和App路徑優化
1.組件優化
經過對Queue Proxy-> App路徑分析，有兩種優化方法，闡述如下：
優化方向一： 優化Queue Proxy
優化Queue Proxy HTTP代理解析過程，延遲大幅度降低（4.2->2.4 ms），且CPU使用率大幅度降低（代理CPU使用率接近Server CPU使用率），QPS小幅度提升。
優化方向二：將Queue Proxy替換成Envoy
優化後QPS相對社區Queue Proxy版本提升23%，延遲也大幅度降低，代理CPU使用率接近ServerCPU使用率。
2.框架優化
框架上協議棧穿透，通過sockmap以及sock redirect特性加速Queue Proxy和業務容器App之間通信。原理如下圖：
基於輕舟的基於EBPF的高性能網絡加速組件–SOPS，開啓該功能，測試結果如下：
- 針對於Queue Proxy代理，組件優化+協議棧穿透, QPS提升26%
- 針對於Envoy Proxy代理，協議棧穿透，QPS提升44%
- 在當前測試Case場景下，協議棧穿透，可以提升業務容器QPS上限約20%。
Knative系統內全路徑測試結果
注：單位百分百CPU支撐的Qps= Qps/（Gateway（cpu%）+ QueueProxy（cpu%） + server（cpu%））
- 輕舟調優的Queue Proxy可以將QPS提升23%，連同SOPS一起可將QPS提升43%
- 使用Envoy替代Queue Proxy可將QPS提升39%，連同SOPS一起可將QPS提升到55%
- 輕舟調優的Queue Proxy 可以將Queue Proxy CPU佔比高問題解決
- 使用Envoy替換Queue Proxy可將QPS額外提升12%，單位CPU百分比支撐的QPS基本一致
Knative社區也在討論Envoy代替Queue Proxy，但是具體何時未知，考慮到工作量較大，我們打算follow社區進度；從性能角度和使用場景考慮，當前優化Queue Proxy也不差，所以先優化Queue Proxy來滿足業務需求。
優化Knative Gateway性能
網關性能優化方面輕舟網關團隊已經做了較多工作，性能也較爲可觀，在Knative當前使用場景，我們計劃將Gateway底層網絡更換成輕舟高性能網絡，繼續降低延遲，提升Gateway性能天花板，降低CPU使用率，使得單位百分比CPU支撐更多的業務QPS。
總結
Knative框架內，默認情況下引入了三層代理路徑，固定壓力（70連接）下測試發現，默認情況下Knative性能表現非常不佳；經過調優（去除Activator 這⼀層代理+ 使用Queue Proxy v0.14並優化+ 使用Sops加速Queue Proxy和App路徑）Knative框架性能表現還是非常優異的。
和裸業務容器相比：
1、單位百分比CPU支撐的QPS 5：1
2、鏈路的變長，當前測試場景和測試方法下，鏈路延遲p90提升 2.5->4.7 約2.2ms
從性能角度看Knative業務容器和裸業務容器，直接使用容器性能是最好的，使用Knative業務容器犧牲還是可以接受的。
下面進一步探討，Knative 和 K8s到底是什麼關係？
從功能角度看，Knative框架是K8s補充，工作在業務層次，解決業務的 “什麼時候該擴容”，“怎麼擴容”，“什麼時候觸發業務運行”等問題，是專業搞定業務自動擴縮容和事件觸發的功能組件。
Knative框架支持功能並不什麼新鮮事情，其功能特性，完全可以通過，K8s容器 + 智能網關+ 自定義擴容數據收集機制和併發控制+自己編碼事件機制來代替+上層業務封裝邏輯來替代，但是需較多的研發投入，而且對接API 爲私有API接口，對用戶有綁定。
從自動擴容角度看，業務的擴縮容也可以通過HPA來完成，但是這種方案速度較慢，一般3-5分鐘，無法適應業務快速擴容需求。
我們基於K8s角度對Knative框架下一個定義：Knaitve=K8s++，是⼀種對K8s補充，是一種通過犧牲CPU和局部的延遲，換取業務流量管理能力（紅綠髮布、回滾、流量管理）和業務擴展能⼒（自動擴容能力、事件機制等）的開源軟件框架。
四、業務流量導⼊Knative
前文性能分析均是基於單個業務Pod，Knative本身性能可從單個業務Pod橫向擴展出多個業務Pod來進行性能擴容而且其非常擅長這一點，這裏不贅述。下面介紹業務流量如何從外部導入Knative系統，因爲 Knative系統內部擴展性沒什麼問題，我們需要使得接入Knative系統部分具備更強的橫向擴展能⼒，以滿足業務擴容的性能需求。
在選型之初，我們打算按照如下架構圖，流量接入到Knative系統。流量經過Nginx Https代理 -> 輕舟網關-> 輕舟Knative網關 -> Queue Proxy -> 業務App，其中：
Nginx：主要作用是HTTPS加密
輕舟網關：主要做URL路徑和域名路徑的轉換、業務降級
輕舟Knative網關：主要實現紅綠髮布、流量管理等功能
上圖中業務路徑比較長，特別是經過了三次7層網關（Nginx、輕舟網關、輕舟Knative網關），且Nginx和輕舟網關存在能力集重複問題，所以我們打算做如下調整：
使用輕舟網關接管Nginx的HTTPS的能⼒，縮短七層代理的路徑，採用輕舟網關自動降級功能，業務降低避免了人爲操作，爲了方案的可擴展（性能橫向擴展、未來IPv6需要等）和部署的靈活性，引入低延時的輕舟的四層LB。架構如下圖，做到各個層可橫向擴展。
因爲方案降級需求，輕舟網關需要連雲外的降級資源，但Knative網關無法管理該雲外資源，所以目前無法將Knative網關和輕舟網關融合成一個網關。未來Serverless平臺不再需要雲外的降級資源，再將輕舟網關和輕舟Knative網關合並，達到如下流量框架，進一步縮短流量路徑，達到最佳性能。
實現輕舟網關和輕舟Knative網關的融合需要修改Knative，原因是：Knative默認通過域名來區分應用，非常適合公有云，但是往往私有云業務場景，域名是固定且受限的，甚至有時候固定嵌入到客戶端代碼中，所以通過域名進行應用區分非常不適合，對於HTTP協議來說，我們需要使用請求路徑來區分應用。
五、總結和展望
基於雲原生化的泛前端部署平臺依賴的底層Knative場景，通過分析，我們發現Knative社區默認情況下性能非常差，配置調優（不注入Sidecar + 將Activator從數據路徑中去除後+使用Queue Proxy v0.14版本）後，除Queue Proxy CPU偏高外，性能還可以，特別是經過調優Queue Proxy、框架上協議棧穿透優化以及業務流量導入路徑縮短後，性能可滿足絕大部分業務需求，目前社區對於性能也在繼續優化中（v0.14相比v0.9 QPS性能約有55%提升），我們相信社區Knative數據路徑的性能會越來越好。
作者簡介：
劉勤龍，網易杭州研究院資深雲計算開發工程師，7年服務端開發和優化經驗，負責網易輕舟四層負載均衡數據面設計，參與輕舟服務網格性能優化，目前專注於輕舟雲原生Serverless平臺底層的開發和優化工作。主要關注Kubernetes、Istio、Knative、Cilium等技術領域。