专栏首页腾讯云原生团队深入了解服务网格数据平面性能和调优

深入了解服务网格数据平面性能和调优

关注【腾讯云原生】公众号,后台回复“TCM”

即可下载 KubeCon 大会演讲 PPT

彭磊,陈凌鹏,腾讯云高级软件工程师,目前负责TCM服务网格产品,致力于打造云原生服务网格。

在腾讯,已经有很多产品已使用或者正在尝试使用istio来作为其微服务治理的基础平台。不过在使用istio时,也有一些对通信性能要求较高的业务会对istio的性能有一些担忧。由于envoy sidecar的引入,使两个微服务之间的通信路径变长,导致服务延时受到了一些影响,istio社区一直以来也有这方面的声音。基于这类抱怨,我们希望能够对这一通信过程进行优化,以更好的满足更多客户的需求。

首先,我们看一下istio数据面的通信模型,来分析一下为什么会对延时有这么大的影响。可以看到,相比于服务之间直接通信,在引入istio 之后,通信路径会有明显增加,主要包括多出了两次本地进程之间的tcp连接通信和用户态网络代理envoy对数据的处理。所以我们的优化也分为了两部分进行。

内核态转发优化

那么对于本地进程之间的通信优化,我们能做些什么呢?其实在开源社区已经有了这方面的探索了。istio官方社区在2019年1月的时候已经有了这方面讨论,在文档里面提到了使用ebpf的技术来做socket转发的数据代理,使数据在socket层进行转发,而不需要再往下经过更底层的TCP/IP协议栈的一个处理,从而减少它在数据链路上的通信链路长度。

另外,网络开源项目cilium也在这方面有一个比较深入的实践,同样也是使用了ebpf的技术。不过在cilium中本地网络加速只是其中的一个模块,没有作为一个独立的服务进行开发实践,在腾讯云内部没法直接使用,这也促使了我们开发一个无依赖的解决方案。

当然在初期的时候,我们也对ebpf的技术进行了一个验证,从验证结果中可以看到,在使用了ebpf的技术之后,它的延时大概有20%到30%的提升,说明ebpf的技术应用在本地通讯上还是有一定优化能力的。

简单介绍一下ebpf,看一下它是怎么做到加速本地通讯的。首先ebpf可以看作是一个运行在内核里面的虚拟机,用户编写的ebpf程序可以被加载到内核里面进行执行。内核的一个verify组件会保证用户的ebpf程序不会引发内核的crash,也就是可以保证用户的ebpf程序是安全的。目前ebpf程序主要用来追踪内核的函数调用以及安全等方面。下图可以看到,ebpf可以用在很多内核子系统当中做很多的调用追踪。

另外一个比较重要的功能,就是我们在性能优化的时候使用到的在网络上的一个能力,也就是下面提到的sockhash。sockhash本身是一个ebpf特殊的一个kv存储结构,主要被用作内核的一个socket层的代理。它的key是用户自定义的,而value是比较特殊的,它存储的value是内核里面一个socket对象。存储在sockhash中的socket在发送数据的时候,如果能够通过我们挂在sockhash当中的一个ebpf当中的程序找到接收方的socket,那么内核就可以帮助我们把发送端的数据直接拷贝到接收端socket的一个接收队列当中,从而可以跳过数据在更底层的处理,比如TCP/IP协议栈的处理。

在sidecar中,socket是怎样被识别并存储在sockhash当中来完成一个数据拷贝的呢?我们需要分析一下数据链的本地通讯的流量特征。

首先从ingress来讲,ingress端的通信会比较简单一点,都是一个本地地址的通信。ingress端的envoy进程和用户服务进程之间通信,它的原地址和目的地址刚好是一一对应的。所以我们可以利用这个地址的四元组构造它的key,把它存储到sockhash当中。在发送数据的时候,根据这个地址信息反向构造这个key,从sockhash当中拿到接收端的socket返回给内核,这样内核就可以帮我们将这个数据直接拷贝给接收端的socket。

egress会稍微复杂一点,在一个egress端服务程序对外发出的请求被iptables规则重定向到了envoy监听的一个15001的端口。在这里,发起方的源地址和接收方的目的地址是一一对应的,但是发起方的目的地址和接收端的源地址有了一个变化,主要是由于iptables对地址有一个重写。所以我们在存储到sockhash中的时候,需要对这部分信息进行一个处理。由于istio的特殊性,直接可以把它改写成envoy所监听的一个本地服务地址。这样再存储到sockhash当中,它们的地址信息还是可以反向一一对应的。所以在查找的时候,还是可以根据一端的socket地址信息查找到另一端的socket,达到数据拷贝的目的。

经过对ebpf加速原理的分析,我们开发出来一个ebpf的插件,这个插件可以不依赖于集群本身的网络模式,使用daemonset方式部署到k8s集群的各个节点上。其中的通信效果如下图所示,本地进程的一个通信在socket层直接被ebpf拦截以后,就不会再往下发送到TCPIP协议栈了,直接在socket层就进行了一个数据拷贝,减少了数据链路上的一个处理流程

下面是对效果的一个测试,从整体来看,它的延时有大概5到8%的延时提升,其实提升的幅度不是很大,主要原因其实在整个通信的流程当中,内核态的一个处理占整个通信处理的时间,延时其实是比较少的一部分,所以它的提升不是特别明显。

另外ebpf还有一些缺陷,比如它对内核版本的要求是在4.18版本之后才有sockhash这个特性。另外sockhash本身还有一些bug,我们在测试当中也发现了一些bug,并且把它提交到社区进行解决。

Envoy 性能研究与优化

前面介绍了对istio数据面对流量在内核的处理所进行的一些优化。在istio数据面的性能问题上,社区注意到比较多的是在内核态有一个明显的转发流程比较长的问题,因此提出了使用eBPF进行优化的方案,但是在Envoy上面没有太多的声音。虽然Envoy本身是一个高性能的网络代理,但我们还是无法确认Envoy本身的损耗是否对性能造成了影响,所以我们就兵分两路,同时在Envoy上面进行了一些研究。

首先什么是Envoy?Envoy是为分布式环境而生的高性能网络代理,可以说基本上是作为服务网格的通用数据平面被设计出来的。Envoy提供不同层级的filter架构,如listenerFilter、networkFilter以及HTTPFilter,这使envoy具有非常好的可扩展性。Envoy还具有很好的可观察性,内置有stats、tracing、logging这些子系统,可以让我们更容易地对系统进行监控。

进行istio数据面优化的时候,我们面对的第一个问题是Envoy在istio数据面中给消息转发增加了多少延时?Envoy本身提供的内置指标是很难反映Envoy本身的性能。因此,我们通过修改Envoy源码,在Envoy处理消息的开始与结束的位置进行打点,记录时间戳,可以获得Envoy处理消息的延时数据。Envoy是多线程架构,在打点时我们考虑了性能和线程安全问题:如何高效而又准确地记录所有消息的处理延时,以方便后续的进行分析?这是通过如下方法做到的:

a. 给压测消息分配唯一数字ID;

b. 在Envoy中预分配一块内存用于保存打点数据,其数据类型是一个结构体数组,每个元素都是同一条消息的打点数据;

c. 提取消息中的数字ID当作时间戳记录的下标,将时间戳记录到预分配的内存的固定位置。通过这种方式,我们安全高效地实现了Envoy内的打点记录(缺点是需要修改Envoy以及压测工具)。

经过离线分析,我们发现了Envoy内消息处理延时的一些分布特征。左图是对Envoy处理延时与消息数量分布图,横轴是延时,纵轴是消息数量。可以看到在高延时部份,消息数量有异常增加的现象,这不是典型的幂率分布。进一步对高延时部份进行分析后发现,这些高延时消息均匀地分布于整个测试期间(如上图右所示)。根据我们的经验,这通常是Envoy内部转发消息的worker在周期性的执行一些消耗CPU的任务,导致有一部分消息没办法及时转发而引起的。

深入研究Envoy在istio数据面的功能实现后,我们发现mixer遥测可能是导致这个问题的根本原因。Mixer是istio老版本(1.4及以前)实现遥测和策略检查功能的一个组件。在数据面的Envoy中,Mixer会提取所有消息的属性,然后批量压缩上报到mixer server,而属性的提取和压缩是一个高CPU的消耗的操作,这会引起延时数据分析中得到的结果:高延时消息转发异常增多。

在确定了原因之后,我们对Envoy的架构作了一些改进,给它增加了执行非关键任务的AsyncWorker线程,称为异步任务线程。通过把遥测的逻辑拆分出来放到了AsyncWorker线程中去执行,就解决了worker线程被阻塞的问题,进而可以降低envoy转发消息的延时。

进行架构优化之后,我们也做了对比测试,上图左测是延时与消息数量图,可以看到它高延时部分得到明显的改善。上图右可以看出Envoy整体的延时降低了40%以上。

优化Envoy架构给我们带来了第一手的经验,首先CPU是影响Istio数据面性能的关键资源,它的瓶颈主要出现在CPU上面,而不是网络IO操作。第二,我们对Envoy进行架构优化,可以降低延时,但是没有解决根本问题,因为CPU的使用没有降低,只是遥测逻辑转移到另外的线程中执行,降低Envoy转发消息的延时。优化CPU使用率才是数据面优化的核心。第三点,Envoy的不同组件当中,mixer消化掉了30%左右的CPU,而遥测是mixer的核心功能,因此后续遥测优化就变成了优化的重要方向。

怎么进行遥测优化呢?其实mixer实现遥测是非常复杂的一套架构,使用Istio mixer遥测的人都深有体会,幸好istio新版本中,不止对istio的控制面作了大的调整,在数据面mixer也同样被移除了,意味着Envoy中高消耗的遥测就不会存在了,我们是基于istio在做内部的service mesh,从社区得到这个消息之后,我们也快速跟进,引入适配新的架构。

没有Mixer之后,遥测是如何实现的。Envoy提供了使用wasm对其进行扩展的方式,以保持架构的灵活性。而istio社区基于Wasm的扩展开发了一个stats extension扩展,实现了一个新的遥测方案。与mixer遥测相比,这个stats extension不再上报全量数据到mixer server,只是在Envoy内的stats子系统中生成遥测指标。遥测系统拉取Envoy的指标,就可以获得整个遥测数据,会大大降低遥测在数据面的性能消耗。

然后我们对istio 1.5使用Wasm的遥测,做了一个性能的测试。发现整个Envoy代理在同样测试条件下,它的CPU降低10%,而使用mixer的遥测其实占用了30%的CPU,里面大部分逻辑是在执行遥测。按我们的理解,Envoy至少应该有20%的CPU下降,但是实际效果只有10%左右,这是为什么呢?

新架构下我们遇到了新的问题。我们对新架构进行了一些实现原理和技术细节上的分析,发现Envoy使用Wasm的扩展方式,虽然带来了灵活性和可扩展性,但是对性能有一定的影响。

首先,Wasm扩展机制跟Envoy host环境是通过内存拷贝的方式进行通信,这是Wasm虚拟机的隔离性机制决定的。Envoy为了保持架构灵活性的同时保证性能,使设计了一个非Wasm虚拟机运行扩展(如stats extension)的模式,即NullVM模式,它是一个假的Wasm虚拟机,实际上运行的扩展还是被编译在Envoy内部,但它也逃离不掉Wasm架构带来的内存拷贝影响。

其次,在实现extension与Envoy的通信时,一个属性的获取要经过多次的内存拷贝,是一个非常复杂的过程。如上图所示,获取request.url这个属性需要在Envoy的内存和Wasm虚拟机内存之间进行一个复杂的拷贝操作,这种方式的消耗远大于通过引用或指针提取属性。

第三,在实现遥测的时候,有大量的属性需要获取,通常有十几二十个属性,因此Wasm扩展带来的总体额外损耗非常可观。

另外,Wasm实现的遥测功能还需要另外一个叫做metadata_exchange扩展的支持。metadata_exchange用来获得调用对端的一些节点信息,而metadata_exchange扩展运行在另外一个虚拟机当中,通过Envoy的Filter state机制与stats 扩展进行通信,进一步增加了遥测的额外消耗。

那么如何去优化呢?简单对Wasm插件优化是没有太大帮助,因为它的底层Wasm机制已经决定了它有不少的性能损耗,所以我们就开发了一个新的遥测插件tstats。tstats使用Envoy原生的扩展方式开发。在tstats扩展内部,实现了遥测和metadata_exchange的结合,消除了Wasm带来的性能弊端。Tstats遥测与社区遥测兼容,生成相同的指标,tstats基于istio控制面的EnvoyFilter CRD进行部署,用户可以平滑升级,当用户发现tstats的功能没有满足需求或者出现一些问题时,也可以切换使用到社区提供的遥测扩展。

在tstats扩展还优化了遥测指标的计算过程。在计算指标的时候有许多维度信息需要填充,(目前大指标有二十几个维度的填充),这其实是一个比较复杂的操作,其实,有很多指标的维度都是节点信息,就是发起服务调用的客户端和服务端的一些信息,如服务名、版本等等。其实我们可以将它进行一些缓存,加速这些指标的计算。

经过优化之后,对比tstats遥测和官方的基于Wasm的遥测的性能,我们发现CPU降低了10到20%,相对于老版本的mixer来说降低了20%以上,符合了我们对envoy性能调研的一个预期。上图右可以看到在延时上有一个明显的降低,即使在P99在不同的QPS下,也会有20%到40%的总体降低(这个延时是使用echo service做End-to-End压测得到的)。

使用火焰图重新观察一下Envoy内部的CPU使用分布,我们发现tstats遥测插件占用CPU的比例明显更少,而使用wasm的遥测插件有一个明显的CPU占用来实现遥测,这也证明了tstats优化是有效果的。

总结

前面我们分享了在优化istio数据面过程当中,在内核态和Envoy内探索的一些经验。这是我们优化的主要内容,当然还有一些其它的优化点,例如:

  • 使用XDP进行加速,因为由于istio proxy的引入,Pod和Pod之间的访问实际上是不需要经过主机上的iptables规则处理。基于这一点,我们可以利用XDP的快速转发能力直接将包发送到对应的网卡,完成快速转发。
  • 链路跟踪在Envoy中消耗的CPU也比较可观,即使在1%的采样率下也消耗了8%的CPU,是可以进行优化的,所以我们也在做这部分的工作。
  • Envoy内部有非常多的内置统计,Istio的一些指标与Envoy内置的指标有一部分重复,可以考虑进行一些裁剪优化,或者增加一些特性开关,当不需要使用的时候对它进行关闭。

总体来说,Istio数据面性能的损耗分布在各个环节,并不是单独的内核态消息转发或者用户态Envoy就消耗特别多。在使用Mixer架构的Istio版本中,Envoy内一个明显的性能热点, mixer遥测,这也在版本迭代中逐步解决了。

最后,在进行Istio数据面优化的时候需要综合考虑各个环节,这也是我们目前总体上对Istio数据面性能的一个认识,通过这次分享,希望社区和大家都会在更注重Istio数据面的性能,帮助ServiceMesh更好地落地。腾讯云基于Istio提供了云上ServiceMesh产品TCM,大家有兴趣可以来体验。

问题

  • 怎么判断项目需要使用服务网格? 服务网格解决的最直接的场景就是你的服务需要进行微服务治理,但是你们之前可能有多个技术栈,没有一个统一的技术框架,比如没有使用SpringCloud等。缺少微服务治理能力,但是又想最低成本获得链路跟踪、监控、流量管理、熔断等这样的能力,这个时候可以使用服务网格实现。
  • 这次优化有没有考虑到回归到社区? 其实我们也考虑过这个问题,我们在进行mixer优化的时候,当时考虑到需要对Envoy做比较多的改动,并且了解到社区规划从架构中去掉mixer,所以这个并没有回归到社区,异步任务线程架构的方案目前保留在内部。对于第二点开发的tstats扩展,它的功能和社区的遥测是一样的,如果提交到社区我们觉得功能会有重叠,所以没有提交给社区。
  • 服务网格数据调优给现在腾讯的业务带来了哪些改变? 我想这里主要还是可观测性上面吧,之前很多的服务和开发,他们的监控和调用面的上面做得都是差强人意的,但是他们在业务的压力之下,其实是没有很完善的方式、没有很大的动力快速实现这些服务治理的功能,使用istio之后,有不少团队都获得了这样的能力,他们给我们的反馈都是比较好的。
  • 在减少延迟方面,腾讯做了哪些调整,服务网格现在是否已经成熟,对开发者是否友好? 在延迟方面,我们对性能的主要探索就是今天分享的内容,我们最开始就注意到延时比较高,然后在内核做了相应的优化,并且研究了在Envoy内为什么会有这些延迟。所以我们得出的结论,CPU是核心的资源,需要尽量降低数据面Proxy代理对CPU的使用,这是我们做所有优化最核心的出发点,当CPU降下来,延时就会降低。服务网格现在是否已经成熟。我觉得不同的人有不同答案,因为对一些团队,目前他们使用服务网格使用得很好的,因为他们有多个技术栈,没有统一的框架。他们用了之后,获得这些流量的管理和监控等等能力,其实已经满足了他们的需求。但是对一些成熟的比较大的服务,数据面性能上面可能会有一些影响,这个需要相应的团队进行仔细的评估才能决定,并没办法说它一定就是能在任何场景下可以直接替换现有的各个团队的服务治理的方式。
  • 为什么不直接考虑1.6? 因为我们做产品化的时候,周期还是比较长的。istio社区发版本的速度还是比较快的,我们还在做1.5产品化的时候,可能做着做着,istio1.6版本就发出来了,所以我们也在不停更新跟迭代,一直在跟随社区,目前主要还是在1.5版本上。其实我们在1.4的时候就开始做现在的产品了。
  • 公司在引入多种云原生架构,包括SpringCloud和Dubbo,作为运维,有必要用Istio做服务治理吗?另外SpringCloud和Dubbo这种架构迁移到Istio,如何调整? 目前SpringCloud和Dubbo都有不错的服务治理功能,如果没有非常紧迫的需求,比如你们又需要引入新的服务并且用别的语言实现,我觉得继续使用这样的框架,可能引入istio没有太大的优势。但是如果考虑进行更大规模的服务治理,包括融合SpringCloud和Dubbo,则可以考虑使用istio进行一个合并的,但是这个落地会比较复杂。那么SpringCloud和Dubbo迁移到Istio如何调整?目前最复杂的就是他们的服务注册机制不一样,服务注册模型不一样。我们之前内部也有在预研如何提供一个统一的服务注册模型,以综合Istio和其它技术框架如SpringCloud的服务注册和服务发现,以及SpringCloud如何迁移进来。这个比较复杂,需要对SDK做一些改动,我觉得可以下来再进行交流。
文章分享自微信公众号:
腾讯云原生

本文参与 腾讯云自媒体分享计划 ,欢迎热爱写作的你一起参与!

如有侵权,请联系 yunjia_community@tencent.com 删除。
登录 后参与评论
0 条评论

相关文章

  • KubeCon 2021|使用 eBPF 代替 iptables 优化服务网格数据面性能

    刘旭,腾讯云高级工程师,专注容器云原生领域,有多年大规模 Kubernetes 集群管理及微服务治理经验,现负责腾讯云服务网格 TCM 数据面产品架构设计和研...

    腾讯云原生
  • 技术集锦 | 服务网格 & Istio 技术原理及最佳实践系列

    前言 作为 CNCF 定义的云原生关键技术之一,服务网格发展至今已经有五个年头了,其发展目前正处于大规模落地及生态发展阶段。 服务网格是一个专门处理服务通讯的基...

    腾讯云原生
  • “久仰大名,幸会幸会”:SDWAN的江湖门派

    作为在网络设备江湖打滚多年的老牌厂商,“SDWAN少林派弟子”充分发挥优势,依靠积累多年的行业经验拓展自身业务,推出了基于路由器交换机的SDWAN方案。

    SDNLAB
  • 微博深度学习平台架构和实践

    用户1737318
  • 看阿里首席架构师是如何选择并落地架构方案的

    如何针对当前需求,选择合适的应用架构,如何面向未来,保证架构平滑过渡,这个是软件开发者,特别是架构师,都需要深入思考的问题。

    技术zhai
  • 围观 KubeCon China 2020 之服务网格

    由CNCF与全球开源志愿者共同发起的“Cloud Native + Open Source Virtual Summit China 2020中国线上峰会”(...

    CNCF
  • 直播倒计时 |腾讯云服务网格实现全托管的架构演进

    作为云原生服务网格领域的热门开源项目,Istio 可以为微服务提供无侵入的流量管理、安全通信、服务可见性等服务治理能力。目前越来越多的微服务项目开始考虑将自己...

    腾讯云原生
  • 扫盲 : 图片的深度认知

    图片是互联网的重要元素之一,各应用各网站基本上都离不开它,以图片作为关键场景的产品一直层出不穷。十年海量请求的技术锤炼,从基础服务到业务深度合作,从基础架构到精...

    TEG云端专业号
  • 未来你将这样养老:看智慧养老如何破解人口老龄化?

    随着中国跑步进入老年化社会,如何养老已成为不得不面对的严峻问题。在5月27日中共中央政治局就我国人口老龄化的形势和对策举行的集体学习会上,总书记强调:要努力挖掘...

    腾讯研究院
  • 工信部《“十四五”信息通信行业发展规划》:建设新型数字基础设施、拓展数字化发展空间、 构建新型行业管理体系等

    2021年11月16日,工业和信息化部印发“十四五”信息通信行业发展规划。 “十四五”信息通信行业发展规划 “十四五”时期是我国全面建成小康社会之后,乘势而上...

    云头条
  • 腾讯重磅发布全栈机器学习平台Angel 3.0

    腾讯首个AI开源项目Angel,正式发布一个里程碑式的版本:Angel 3.0。这是一个全栈的机器学习平台,功能特性涵盖了机器学习的各个阶段,超过50万行代码,...

    腾讯技术工程官方号
  • 【科技事知一点】太平洋保险与阿里签署战略合作协议;「宾通智能」获6000万元A轮融资

    12月14日,中国太平洋保险集团与阿里巴巴集团在上海签署全面战略合作协议,在前期云计算、安全、专属钉钉等合作基础上,双方将进一步开展包括集团级数据中台建设、核心...

    庞九公子
  • 实现全托管,腾讯云服务网格的架构演进

    |导语 腾讯云服务网格(TCM)作为一个兼容 isito 的服务网格平台,已经在腾讯内外部有诸多落地案例。本文深度解析服务网格架构演进和发展趋势。 一、 ist...

    腾讯大讲堂
  • 超50万行代码、GitHub 4200星:腾讯重磅发布全栈机器学习平台Angel 3.0

    【导读】腾讯首个AI开源项目Angel,正式发布一个里程碑式的版本:Angel 3.0。这是一个全栈机器学习平台,功能特性涵盖了机器学习的各个阶段,超过50万行...

    腾讯大数据
  • “十四五”数字经济发展规划发布

    来源:中华人民共和国中央人民政府官网本文约12000字,建议阅读15+分钟带你浏览国务院发布的《“十四五”数字经济发展规划》。 数字经济是继农业经济、工业经济之...

    数据派THU
  • 国家发布《“十四五”数字经济发展规划》:加快推动数字产业化、增强关键技术创新能力、提升核心产业竞争力、增强网络安全防护能力等

    2022年1月12日,国务院关于印发“十四五”数字经济发展规划的通知。 “十四五”数字经济发展规划 数字经济是继农业经济、工业经济之后的主要经济形态,是以数据...

    云头条

扫码关注云+社区

领取腾讯云代金券