贵阳市网站优化,wordpress 彩色序号,定制软件app开发公司,网站平台开通微信支付背景
随着云原生应用架构的快速发展#xff0c;微服务架构已经成为了构建现代应用的主要方式之一。而在微服务架构中#xff0c;服务间的通信变得至关重要。为了实现弹性和可伸缩性#xff0c;许多组织开始采用服务网格技术来管理服务之间的通信。
Istio作为目前最受欢迎的…背景
随着云原生应用架构的快速发展微服务架构已经成为了构建现代应用的主要方式之一。而在微服务架构中服务间的通信变得至关重要。为了实现弹性和可伸缩性许多组织开始采用服务网格技术来管理服务之间的通信。
Istio作为目前最受欢迎的服务网格之一提供了一套强大的功能以简化服务网格的管理和操作。它通过引入一组专门的代理即Sidecar来实现在服务之间进行流量管理、监控和安全控制等功能。
在Istio中Sidecar是一种特殊的代理它与每个服务实例一起部署并负责处理该实例与其他服务之间的通信。它位于服务容器内部与应用程序实例一同运行并通过拦截和转发网络流量来提供服务网格的功能。
然而正因为Sidecar与每个服务实例一同运行它也可能引入一些潜在的性能问题其中一个主要问题就是延迟。
由于每个服务实例都需要与其对应的Sidecar进行通信这增加了请求路径的长度和网络延迟。此外Sidecar还要负责执行各种功能如流量管理、监控和安全控制等这也会对性能产生一定的影响。 针对Sidecar引入的延迟问题业内常用采用eBPF sockops 技术来优化在同一个节点下短路两个进程间的socket 通信也就是让tcp 报文不用经过TCP/IP 协议栈。 加速后的流量路径示意图如下 阿里云服务网格最近上线了sidecar 加速组件, 接下来我们来测试验证下特别是对比其开启前后实际的加速效果。
安装部署和环境介绍
环境准备
首先按照文档创建一个ASM 实例笔者采用当前ASM 最新版本v1.18 企业版
然后创建一个ACK 集群ASM sidecar 加速组件仅支持ACK 托管版本和ACK 专有版本集群。笔者创建了一个ACK托管版本实例 版本使用v1.26, 集群包含3节点节点操作系统镜像使用了文档推荐的Alibaba Cloud Linux3。并把ACK 添加到ASM 实例下。
环境信息如下
✅ASM 实例 ✅ACK 集群 网络CNI 插件选用了terway 部署测试例子
这里采用了从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: offname: 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/hostnamecontainers:- name: capturedvolumeMounts:- name: shared-datamountPath: /var/lib/fortioimage: fortio/fortio:latest_releaseargs:- reportports:- containerPort: 8080protocol: TCPvolumes:- name: shared-dataemptyDir: {}根据Sidecar Acceleration 组件文档提示组件开启不能加速已有存量TCP 连接因此笔者通过DestinationRule 配置了 客户端侧的相关连接池配置通过设置连接的空闲时间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 后压测流量路径变为
[ fortioclient - sidecar ] - [ sidecar - fortioserver ]
Yaml 配置简单说明如下
1 考虑到envoy 路由和负载均衡能力大部分功能由 outbound sidecar 起作用上述配置特意调大了 outbound sidecar 的CPU 设置其CPU limit为4000m, concurrency 对应调整为4 性能最优避免压测客户端成为瓶颈。
为了测试多阶段都能加速的效果特意通过pod 亲和性将fortioclient 和 fortioserver 调度到同一个节点。
3每一轮的压测结果可以通过fortioclient 的 8080 端口访问进行查看。
压测方法
1) http 请求性能压测
kubectl exec deployment/fortioclient -c captured -- fortio load -c 64 -qps 14000 -t 30s -a -r 0.00005 -httpbufferkb64 -labels http-after-install-acceleration-perf-test-1 http://fortioserver:8080/echo?size10242) 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其中labels 是对应这一轮压测的名称可用于区别多轮压测结果。
qps 需要根据实际压测场景进行调整。设置为0 表示无上限。设置为非零表示采用固定QPS 进行压测。
fortio 相关参数含义可以参考官方链接文档 https://github.com/fortio/fortio
性能测试
为了避免压测时相关干扰信息可以将日志暂时关闭。在ASM 控制台的可观测配置下操作关闭即可。 首先进行一轮环境的QPS 上限测试。对比开启前后的QPS 是否有提升。
压测相关参数设置
64 并发QPS 不设上限持续压测30shttp payload 1024 (1KB) size
kubectl exec deployment/fortioclient -c captured -- fortio load -c 64 -qps 0 -t 30s -a -r 0.00005 -httpbufferkb64 -labels http-after-install-acceleration-perf-test-1 http://fortioserver:8080/echo?size1024压测结果 也可以通过fortioclient 的loadbalancer ip 访问查看相关直方图可以看到大部分请求的latency 分布情况。 测试开启 Sidecar Acceleration加速组件后效果 在ACK 控制台的组件管理菜单下找到加速组件点击安装
安装提示成功后再次使用同样的压测命令进行压测
kubectl exec deployment/fortioclient -c captured -- fortio load -c 64 -qps 0 -t 30s -a -r 0.00005 -httpbufferkb64 -labels http-after-install-acceleration-perf-test-1 http://fortioserver:8080/echo?size1024压测结果 开启前后对比
从QPS 角度来看13521 / 11461.0 1.179739987784661 18% 左右的QPS 提升。
Latency 角度来看: 4.732/5.583 0.8475729894322049, 平均 AVG latency 降低16% 左右。
我们可以通过fortio UI 提供的直方图可以直观地看出加速组件开启后延迟更低大部分请求在低延时区域。 未开启加速组件之前的请求对比有超出一部分请求在较高的延时区域。 笔者进行了多轮压测排除了相关环境抖动因素。 调整并发进行多轮压测QPS 基本提升都能保证在15% 左右。
然后再次进行了一组TCP 的压测对比
压测相关参数配置
64 并发1024 payload持续压测30s
开启前
执行如下命令进行压测;
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进行多轮压力测试多轮压测差异不大排除干扰信息。 开启后
执行如下命令
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 负载均衡纯转发不用做HTTP报文解析。
因此在这种场景下报文通过TCP/IP 协议栈所占用的时间比重相对较高。我们通过Latency 对比也可以看出。
Latency 前后对比
0.746 ms / 1.172.ms 0.636 接近40% 的latency 降低。
总结
服务网格下的Sidecar 代理业务服务的收发请求并提供业务层面的流量控制路由、负载均衡等功能会引入一定的Latency 延迟。 通过eBPF 技术部署sidecar 加速组件将同节点下两个进程间的TCP 报文进行socket 短路可以提升一定的性能HTTP 场景下QPS 可提升15% 左右, 有效地降低业务请求的Latency 。
实际业务场景下对于Latency 敏感型的业务我们可以通过pod 亲和性将上下游的依赖服务部署在同一个节点采用Sidecar Acceleration Using eBPF 组件来保证服务更低的Latency 和 更高的QPS 。
