背景

隨著云原生應(yīng)用架構(gòu)的快速發(fā)展，微服務(wù)架構(gòu)已經(jīng)成為了構(gòu)建現(xiàn)代應(yīng)用的主要方式之一。而在微服務(wù)架構(gòu)中，服務(wù)間的通信變得至關(guān)重要。為了實(shí)現(xiàn)彈性和可伸縮性，許多組織開(kāi)始采用服務(wù)網(wǎng)格技術(shù)來(lái)管理服務(wù)之間的通信。

Istio作為目前最受歡迎的服務(wù)網(wǎng)格之一，提供了一套強(qiáng)大的功能，以簡(jiǎn)化服務(wù)網(wǎng)格的管理和操作。它通過(guò)引入一組專門(mén)的代理（即Sidecar）來(lái)實(shí)現(xiàn)在服務(wù)之間進(jìn)行流量管理、監(jiān)控和安全控制等功能。

在Istio中，Sidecar是一種特殊的代理，它與每個(gè)服務(wù)實(shí)例一起部署，并負(fù)責(zé)處理該實(shí)例與其他服務(wù)之間的通信。它位于服務(wù)容器內(nèi)部，與應(yīng)用程序?qū)嵗煌\(yùn)行，并通過(guò)攔截和轉(zhuǎn)發(fā)網(wǎng)絡(luò)流量來(lái)提供服務(wù)網(wǎng)格的功能。

然而，正因?yàn)镾idecar與每個(gè)服務(wù)實(shí)例一同運(yùn)行，它也可能引入一些潛在的性能問(wèn)題，其中一個(gè)主要問(wèn)題就是延遲。

由于每個(gè)服務(wù)實(shí)例都需要與其對(duì)應(yīng)的Sidecar進(jìn)行通信，這增加了請(qǐng)求路徑的長(zhǎng)度和網(wǎng)絡(luò)延遲。此外，Sidecar還要負(fù)責(zé)執(zhí)行各種功能，如流量管理、監(jiān)控和安全控制等，這也會(huì)對(duì)性能產(chǎn)生一定的影響。

針對(duì)Sidecar引入的延遲問(wèn)題，業(yè)內(nèi)常用采用eBPF sockops 技術(shù)來(lái)優(yōu)化，在同一個(gè)節(jié)點(diǎn)下，短路兩個(gè)進(jìn)程間的socket 通信，也就是讓tcp 報(bào)文不用經(jīng)過(guò)TCP/IP 協(xié)議棧。 加速后的流量路徑示意圖如下：

阿里云服務(wù)網(wǎng)格最近上線了sidecar 加速組件, 接下來(lái)我們來(lái)測(cè)試驗(yàn)證下，特別是對(duì)比其開(kāi)啟前后實(shí)際的加速效果。

安裝部署和環(huán)境介紹

環(huán)境準(zhǔn)備

首先，按照文檔，創(chuàng)建一個(gè)ASM 實(shí)例，筆者采用當(dāng)前ASM 最新版本v1.18 企業(yè)版

然后，創(chuàng)建一個(gè)ACK 集群，ASM sidecar 加速組件僅支持ACK 托管版本和ACK 專有版本集群。筆者創(chuàng)建了一個(gè)ACK托管版本實(shí)例 ，版本使用v1.26, 集群包含3節(jié)點(diǎn)，節(jié)點(diǎn)操作系統(tǒng)鏡像使用了文檔推薦的Alibaba Cloud Linux3。并把ACK 添加到ASM 實(shí)例下。

環(huán)境信息如下：

• ?ASM 實(shí)例

• ?ACK 集群

網(wǎng)絡(luò)CNI 插件選用了terway

部署測(cè)試?yán)?/h4>

這里采用了從istio 官方的benchmark 工具下抽離出的簡(jiǎn)化版壓測(cè)程序。

---
apiVersion: v1
kind: Service
metadata:name: fortioserver
spec:ports:- name: http-echoport: 8080protocol: TCP- name: tcp-echoaport: 8078protocol: TCP- name: grpc-pingport: 8079protocol: TCPselector:app: fortioservertype: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:labels:app: fortioservername: fortioserver
spec:selector:matchLabels:app: fortioservertemplate:metadata:labels:app: fortioserverannotations:sidecar.istio.io/proxyCPULimit: 2000mproxy.istio.io/config: |concurrency: 2spec:containers:- name: capturedimage: fortio/fortio:latest_releaseports:- containerPort: 8080protocol: TCP- containerPort: 8078protocol: TCP- containerPort: 8079protocol: TCP
---
apiVersion: v1
kind: Service
metadata:annotations:service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-switch: "off"name: fortioclient
spec:ports:- name: http-reportport: 8080protocol: TCPselector:app: fortioclienttype: LoadBalancer
---
apiVersion: apps/v1
kind: Deployment
metadata:labels:app: fortioclientname: fortioclient
spec:selector:matchLabels:app: fortioclienttemplate:metadata:annotations:sidecar.istio.io/proxyCPULimit: 4000mproxy.istio.io/config: |concurrency: 4labels:app: fortioclientspec:affinity:podAffinity:requiredDuringSchedulingIgnoredDuringExecution:- labelSelector:matchExpressions:- key: appoperator: Invalues:- fortioservertopologyKey: "kubernetes.io/hostname"containers:- name: capturedvolumeMounts:- name: shared-datamountPath: /var/lib/fortioimage: fortio/fortio:latest_releaseargs:- reportports:- containerPort: 8080protocol: TCPvolumes:- name: shared-dataemptyDir: {}

根據(jù)Sidecar Acceleration 組件文檔提示，組件開(kāi)啟不能加速已有存量TCP 連接，因此，筆者通過(guò)DestinationRule 配置了 客戶端側(cè)的相關(guān)連接池配置，通過(guò)設(shè)置連接的空閑時(shí)間30s 來(lái)保證前后多輪測(cè)試，連接總是新建的。（前后兩輪測(cè)試間隔30s 以上即可）

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:name: fortioserver
spec:host: fortioserver.default.svc.cluster.localtrafficPolicy:connectionPool:tcp:maxConnections: 100http:idleTimeout: 30s

拷貝如上yaml ，kubectl apply 即可。注意部署前已將default namespace 開(kāi)啟了sidecar自動(dòng)注入。

壓測(cè)模型： 很簡(jiǎn)單就是 fortioclient -> fortioserver , 注入sidecar 后，壓測(cè)流量路徑變?yōu)?#xff1a;

[ fortioclient -> sidecar ] -> [ sidecar -> fortioserver ]

Yaml 配置簡(jiǎn)單說(shuō)明如下：

1） 考慮到envoy 路由和負(fù)載均衡能力大部分功能由 outbound sidecar 起作用，上述配置特意調(diào)大了 outbound sidecar 的CPU ，設(shè)置其CPU limit為4000m, concurrency 對(duì)應(yīng)調(diào)整為4 （性能最優(yōu)），避免壓測(cè)客戶端成為瓶頸。

2. 為了測(cè)試多階段都能加速的效果，特意通過(guò)pod 親和性將fortioclient 和 fortioserver 調(diào)度到同一個(gè)節(jié)點(diǎn)。

3）每一輪的壓測(cè)結(jié)果可以通過(guò)fortioclient 的 8080 端口訪問(wèn)進(jìn)行查看。

壓測(cè)方法：

1) ?http 請(qǐng)求性能壓測(cè)

kubectl exec deployment/fortioclient -c captured -- fortio load -c 64 -qps 14000 -t 30s -a -r 0.00005 -httpbufferkb=64 -labels http-after-install-acceleration-perf-test-1 http://fortioserver:8080/echo?size=1024

2) tcp 請(qǐng)求性能壓測(cè)

kubectl exec deployment/fortioclient -c captured -- fortio load -c 64 -qps  0 -t 30s -a -r 0.00005  -labels tcp-after-install-acceleration-perf-test-1 tcp://fortioserver:8078

其中l(wèi)abels 是對(duì)應(yīng)這一輪壓測(cè)的名稱，可用于區(qū)別多輪壓測(cè)結(jié)果。

qps 需要根據(jù)實(shí)際壓測(cè)場(chǎng)景進(jìn)行調(diào)整。設(shè)置為0 表示無(wú)上限。設(shè)置為非零表示采用固定QPS 進(jìn)行壓測(cè)。

fortio 相關(guān)參數(shù)含義可以參考官方鏈接文檔： https://github.com/fortio/fortio

性能測(cè)試

為了避免壓測(cè)時(shí)相關(guān)干擾信息，可以將日志暫時(shí)關(guān)閉。在ASM 控制臺(tái)的可觀測(cè)配置下操作關(guān)閉即可。

首先進(jìn)行一輪環(huán)境的QPS 上限測(cè)試。對(duì)比開(kāi)啟前后的QPS 是否有提升。

壓測(cè)相關(guān)參數(shù)設(shè)置：

• 64 并發(fā)
• QPS 不設(shè)上限
• 持續(xù)壓測(cè)30s
• http payload 1024 (1KB) size

kubectl exec deployment/fortioclient -c captured -- fortio load -c 64 -qps 0 -t 30s -a -r 0.00005 -httpbufferkb=64 -labels http-after-install-acceleration-perf-test-1 http://fortioserver:8080/echo?size=1024

壓測(cè)結(jié)果：

也可以通過(guò)fortioclient 的loadbalancer ip 訪問(wèn)查看相關(guān)直方圖，可以看到大部分請(qǐng)求的latency 分布情況。

測(cè)試開(kāi)啟 Sidecar Acceleration加速組件后效果：

在ACK 控制臺(tái)的組件管理菜單下找到加速組件，點(diǎn)擊安裝；

安裝提示成功后，再次使用同樣的壓測(cè)命令進(jìn)行壓測(cè)：

kubectl exec deployment/fortioclient -c captured -- fortio load -c 64 -qps 0 -t 30s -a -r 0.00005 -httpbufferkb=64 -labels http-after-install-acceleration-perf-test-1 http://fortioserver:8080/echo?size=1024

壓測(cè)結(jié)果：

開(kāi)啟前后對(duì)比：

從QPS 角度來(lái)看，13521 / 11461.0 = 1.179739987784661， 18% 左右的QPS 提升。

Latency 角度來(lái)看: 4.732/5.583 = 0.8475729894322049, 平均 AVG latency 降低16% 左右。

我們可以通過(guò)fortio UI 提供的直方圖可以直觀地看出，加速組件開(kāi)啟后，延遲更低，大部分請(qǐng)求在低延時(shí)區(qū)域。 未開(kāi)啟加速組件之前的請(qǐng)求，對(duì)比有超出一部分請(qǐng)求在較高的延時(shí)區(qū)域。

筆者進(jìn)行了多輪壓測(cè)，排除了相關(guān)環(huán)境抖動(dòng)因素。

調(diào)整并發(fā)進(jìn)行多輪壓測(cè)，QPS 基本提升都能保證在15% 左右。

然后，再次進(jìn)行了一組TCP 的壓測(cè)對(duì)比

壓測(cè)相關(guān)參數(shù)配置：

• 64 并發(fā)
• 1024 payload
• 持續(xù)壓測(cè)30s

開(kāi)啟前：

執(zhí)行如下命令進(jìn)行壓測(cè);

kubectl exec deployment/fortioclient -c captured -- fortio load -c 64 -qps  0 -t 30s -a -r 0.00005 --payload-size 1024  -labels tcp-not-install-acceleration-perf-test-1 tcp://fortioserver:8078

進(jìn)行多輪壓力測(cè)試，多輪壓測(cè)差異不大，排除干擾信息。

開(kāi)啟后：

執(zhí)行如下命令：

kubectl exec deployment/fortioclient -c captured -- fortio load -c 64 -qps  0 -t 30s -a -r 0.00005 --payload-size 1024  -labels tcp-after-install-acceleration-perf-test-1 tcp://fortioserver:8078

開(kāi)啟前后直方圖對(duì)比：

QPS 前后對(duì)比：

85665/54564.9 = 1.5699653073679234 , 50%多的QPS 提升，這是因?yàn)閷?duì)于TCP 來(lái)說(shuō)，sidecar/envoy 僅做tcp 負(fù)載均衡純轉(zhuǎn)發(fā)，不用做HTTP報(bào)文解析。

因此，在這種場(chǎng)景下，報(bào)文通過(guò)TCP/IP 協(xié)議棧所占用的時(shí)間比重相對(duì)較高。我們通過(guò)Latency 對(duì)比也可以看出。

Latency 前后對(duì)比：

0.746 ms / 1.172.ms = 0.636 ，接近40% 的latency 降低。

總結(jié)

服務(wù)網(wǎng)格下的Sidecar 代理業(yè)務(wù)服務(wù)的收發(fā)請(qǐng)求，并提供業(yè)務(wù)層面的流量控制（路由）、負(fù)載均衡等功能，會(huì)引入一定的Latency 延遲。 通過(guò)eBPF 技術(shù)（部署sidecar 加速組件）將同節(jié)點(diǎn)下兩個(gè)進(jìn)程間的TCP 報(bào)文進(jìn)行socket 短路可以提升一定的性能，HTTP 場(chǎng)景下QPS 可提升15% 左右, 有效地降低業(yè)務(wù)請(qǐng)求的Latency 。

實(shí)際業(yè)務(wù)場(chǎng)景下，對(duì)于Latency 敏感型的業(yè)務(wù)，我們可以通過(guò)pod 親和性將上下游的依賴服務(wù)部署在同一個(gè)節(jié)點(diǎn)，采用Sidecar Acceleration Using eBPF 組件來(lái)保證服務(wù)更低的Latency 和 更高的QPS 。