背景

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

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

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

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

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

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

阿里云服務(wù)網(wǎng)格最近上線了sidecar 加速組件, 接下來我們來測試驗證下，特別是對比其開啟前后實際的加速效果。

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

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

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

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

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

• ?ASM 實例

• ?ACK 集群

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

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

這里采用了從istio 官方的benchmark 工具下抽離出的簡化版壓測程序。

---
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 組件文檔提示，組件開啟不能加速已有存量TCP 連接，因此，筆者通過DestinationRule 配置了 客戶端側(cè)的相關(guān)連接池配置，通過設(shè)置連接的空閑時間30s 來保證前后多輪測試，連接總是新建的。（前后兩輪測試間隔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 開啟了sidecar自動注入。

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

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

Yaml 配置簡單說明如下：

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

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

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

壓測方法：

1) ?http 請求性能壓測

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 請求性能壓測

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 是對應(yīng)這一輪壓測的名稱，可用于區(qū)別多輪壓測結(jié)果。

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

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

性能測試

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

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

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

• 64 并發(fā)
• QPS 不設(shè)上限
• 持續(xù)壓測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

壓測結(jié)果：

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

測試開啟 Sidecar Acceleration加速組件后效果：

在ACK 控制臺的組件管理菜單下找到加速組件，點擊安裝；

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

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

壓測結(jié)果：

開啟前后對比：

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

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

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

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

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

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

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

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

開啟前：

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

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)行多輪壓力測試，多輪壓測差異不大，排除干擾信息。

開啟后：

執(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

開啟前后直方圖對比：

QPS 前后對比：

85665/54564.9 = 1.5699653073679234 , 50%多的QPS 提升，這是因為對于TCP 來說，sidecar/envoy 僅做tcp 負(fù)載均衡純轉(zhuǎn)發(fā)，不用做HTTP報文解析。

因此，在這種場景下，報文通過TCP/IP 協(xié)議棧所占用的時間比重相對較高。我們通過Latency 對比也可以看出。

Latency 前后對比：

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

總結(jié)

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

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