使用eBPF加速阿里云服务网格ASM-低调大师

使用eBPF加速阿里云服务网格ASM

2023-10-13 378

背景

随着云原生应用架构的快速发展，微服务架构已经成为了构建现代应用的主要方式之一。而在微服务架构中，服务间的通信变得至关重要。为了实现弹性和可伸缩性，许多组织开始采用服务网格技术来管理服务之间的通信。

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-echo
    port: 8080
    protocol: TCP
  - name: tcp-echoa
    port: 8078
    protocol: TCP
  - name: grpc-ping
    port: 8079
    protocol: TCP
  selector:
    app: fortioserver
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: fortioserver
  name: fortioserver
spec:
  selector:
    matchLabels:
      app: fortioserver
  template:
    metadata:
      labels:
        app: fortioserver
      annotations:
        sidecar.istio.io/proxyCPULimit: 2000m
        proxy.istio.io/config: |
          concurrency: 2
    spec:
      containers:
      - name: captured
        image: fortio/fortio:latest_release
        ports:
        - containerPort: 8080
          protocol: TCP
        - containerPort: 8078
          protocol: TCP
        - containerPort: 8079
          protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
  annotations:
      service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-switch: "off"
  name: fortioclient
spec:
  ports:
  - name: http-report
    port: 8080
    protocol: TCP
  selector:
    app: fortioclient
  type: LoadBalancer
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: fortioclient
  name: fortioclient
spec:
  selector:
    matchLabels:
      app: fortioclient
  template:
    metadata:
      annotations:
        sidecar.istio.io/proxyCPULimit: 4000m
        proxy.istio.io/config: |
           concurrency: 4
      labels:
        app: fortioclient
    spec:
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - fortioserver
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: captured
        volumeMounts:
        - name: shared-data
          mountPath: /var/lib/fortio
        image: fortio/fortio:latest_release
        args:
        - report
        ports:
        - containerPort: 8080
          protocol: TCP
      volumes:
      - name: shared-data
        emptyDir: {}

根据Sidecar Acceleration 组件文档提示，组件开启不能加速已有存量TCP 连接，因此，笔者通过DestinationRule 配置了客户端侧的相关连接池配置，通过设置连接的空闲时间30s 来保证前后多轮测试，连接总是新建的。（前后两轮测试间隔30s 以上即可）

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: fortioserver
spec:
  host: fortioserver.default.svc.cluster.local
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        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 -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

其中labels 是对应这一轮压测的名称，可用于区别多轮压测结果。

qps 需要根据实际压测场景进行调整。设置为0 表示无上限。设置为非零表示采用固定QPS 进行压测。

fortio 相关参数含义可以参考官方链接文档： https://github.com/fortio/fortio

性能测试

为了避免压测时相关干扰信息，可以将日志暂时关闭。在ASM 控制台的可观测配置下操作关闭即可。

首先进行一轮环境的QPS 上限测试。对比开启前后的QPS 是否有提升。

压测相关参数设置：

64 并发
QPS 不设上限
持续压测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

压测结果：

也可以通过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 -httpbufferkb=64 -labels http-after-install-acceleration-perf-test-1 http://fortioserver:8080/echo?size=1024

压测结果：

开启前后对比：

从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 。

微信关注我们

原文链接：https://my.oschina.net/u/3874284/blog/10117446

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

Apache Doris 在小鹅通的应用实践

本文导读：随着网络直播规模的不断扩大，在线知识服务在直播行业中迎来了广阔的发展机遇。小鹅通作为一家以用户服务为核心的技术服务商，通过多平台直播与推流服务吸引和转化潜在用户，同时通过直播数据分析平台，帮助商家分析直播指标数据、分析用户观看情况、构建精准用户画像。然而，随着直播用户数量的激增，平台在写入和查询方面的支持逐渐无法满足业务需求，为了应对挑战，小鹅通开启了架构升级之旅。本文将详细介绍小鹅通直播数据分析平台的优化过程，分享小鹅通基于 Apache Doris 优化写入与查询性能、完善用户标签功能和保障平台稳定性等实践经验，为商家提供了更精细化的用户经营支持。（作者｜小鹅通大数据开发工程师宫贺）深圳小鹅网络技术有限公司，是一家以知识产品与用户服务为核心的技术服务商，创始至今已累计生产了 2000 万个知识产品，已服务的商家规模达 160 万，其中不乏腾讯学堂、华夏基金、西贝、吴晓波频道、十点读书、凯撒旅游等各行业一线知名品牌。作为私域运营的一站式工具，针对商家业务痛点，小鹅通提供了多方面的闭环解决方案，包括产品与服务交付、营销获客、用户运营、组织角色管理、品牌价值输出等以实现业...

2023-10-13

382

本文分享自华为云社区《走向批处理-交互式分析一体化： Trino容错模式深度测评与思考》，作者：HetuEngine九级代言。本文系华为云大数据研发团队原创，原创作者：文博，梦月 1 Trino简介 2020年12月27日，Presto社区大佬们——Martin Traverso、 Dain Sundstrom 以及 David Phillips 宣布将开源项目PrestoSQL的名字更名为TrinoDB（本文简称Trino）。 Trino是一款开源的高性能、分布式SQL查询引擎，专门用于对各种异构数据源运行交互式分析查询，支持从GB到PB的数据量范围。Trino专门为交互式分析而设计，可以对来自不同数据源的数据（包括：Hive、AWS S3、Alluxio、MySQL、Kafka、ES等等）进行合并查询，并提供良好的自定义连接器编程扩展框架。适用于期望响应时间从亚秒到数分钟不等的分析师场景。在诞生之初，Trino是为了填补当时 Facebook 内部实时查询和 ETL 处理之间的空白。Trino的核心目标就是提供交互式查询，也就是我们常说的 Ad-Hoc Query，很多公司都...

2023-10-13

381

资源下载

更多资源

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。