记一次在 mosn 对 dubbo、dubbo-go-hessian2 的性能优化

2020 年 6 月 07 日

记一次在 mosn 对 dubbo、dubbo-go-hessian2 的性能优化

背景

蚂蚁内部对 Service Mesh 的稳定性和性能要求是比较高的,内部 mosn 广泛用于生产环境。在云上和开源社区,RPC 领域 dubbo 和 spring cloud 同样广泛用于生产环境,我们在 mosn 基础上,支持了 dubbo 和 spring cloud 流量代理。我们发现在支持 dubbo 协议过程中,经过 Mesh 流量代理后,性能有非常大的性能损耗,在大商户落地 Mesh 中也对性能有较高要求,因此本文会重点描述在基于 Go 语言库 dubbo-go-hessian2 、dubbo 协议中对 mosn 所做的性能优化。

性能优化概述

根据实际业务部署场景,并没有选用高性能机器,使用普通 linux 机器,配置和压测参数如下:

  • Intel® Xeon® Platinum 8163 CPU @ 2.50GHz 4 核 16G 。
  • pod 配置 2c、1g,JVM 参数 -server -Xms1024m -Xmx1024m
  • 网络延迟 0.23 ms, 2 台 linux 机器,分别部署 server + mosn, 压测程序 rpc-perfomance

经过 3 轮性能优化后,使用优化版本 mosn 将会获得以下性能收益(框架随机 512 和 1k 字节压测):

  • 512 字节数据:mosn + dubbo 服务调用 TPS 整体提升 55-82.8%,RT 降低 45% 左右,内存占用 40M,
  • 1k 数据:mosn + dubbo 服务调用 TPS 整体提升 51.1-69.3%,RT 降低 41% 左右, 内存占用 41M。

性能优化工具 pprof

磨刀不误砍柴工,在性能优化前首先要找到性能卡点,找到性能卡点后,另一个难点就是如何用高效代码优化替代 slow code。因为蚂蚁 Service Mesh 是基于 go 语言实现的,我们首选 go 自带的 pprof 性能工具,我们简要介绍这个工具如何使用。如果我们 go 库自带 http.Server 时并且在 main 头部导入import _ "net/http/pprof",go 会帮我们挂载对应的 handler , 详细可以参考 godoc

因为 mosn 默认会在34902端口暴露 http 服务,通过以下命令轻松获取 mosn 的性能诊断文件:

复制代码
go tool pprof -seconds 60 http://benchmark-server-ip:34902/debug/pprof/profile
# 会生成类似以下文件,该命令采样 cpu 60 秒
# pprof.mosn.samples.cpu.001.pb.gz

然后继续用 pprof 打开诊断文件,方便在浏览器查看,在图 1-1 给出压测后 profiler 火焰图:

复制代码
# http=:8000 代表 pprof 打开 8000 端口然后用于 web 浏览器分析
# mosnd 代表 mosn 的二进制可执行文件,用于分析代码符号
# pprof.mosn.samples.cpu.001.pb.gz 是 cpu 诊断文件
go tool pprof -http=:8000 mosnd pprof.mosn.samples.cpu.001.pb.gz

)

图 1-1 mosn 性能压测火焰图

在获得诊断数据后,可以切到浏览器 Flame Graph(火焰图,go 1.11 以上版本自带),火焰图的 x 轴坐标代表 CPU 消耗情况, y 轴代码方法调用堆栈。在优化开始之前,我们借助 go 工具 pprof 可以诊断出大致的性能卡点在以下几个方面(直接压 server 端 mosn):

  • mosn 在接收 dubbo 请求,CPU 卡点在 streamConnection.Dispatch
  • mosn 在转发 dubbo 请求,CPU 卡点在 downStream.Receive

可以点击火焰图任意横条,进去查看长方块耗时和堆栈明细(请参考图 1-2 和 1-3 所示):

图 1-2 Dispatch 火焰图明细

图 1-3 Receive 火焰图明细

性能优化思路

本文重点记录优化了哪些 case 才能提升 50% 以上的吞吐量和降低 RT,因此后面直接分析当前优化了哪些 case。在此之前,我们以 Dispatch 为例,看下它为甚么那么吃性能 。在 terminal 中通过以下命令可以查看代码行耗费 CPU 数据(代码有删减):

复制代码
go tool pprof mosnd pprof.mosn.samples.cpu.001.pb.gz
(pprof) list Dispatch
Total: 1.75mins
370ms 37.15s (flat, cum) 35.46% of Total
10ms 10ms 123:func (conn *streamConnection) Dispatch(buffer types.IoBuffer) {
40ms 630ms 125: log.DefaultLogger.Tracef("stream connection dispatch data string = %v", buffer.String())
. . 126:
. . 127: // get sub protocol codec
. 250ms 128: requestList := conn.codec.SplitFrame(buffer.Bytes())
20ms 20ms 129: for _, request := range requestList {
10ms 160ms 134: headers := make(map[string]string)
. . 135: // support dynamic route
50ms 920ms 136: headers[strings.ToLower(protocol.MosnHeaderHostKey)] = conn.connection.RemoteAddr().String()
. . 149:
. . 150: // get stream id
10ms 440ms 151: streamID := conn.codec.GetStreamID(request)
. . 156: // request route
. 50ms 157: requestRouteCodec, ok := conn.codec.(xprotocol.RequestRouting)
. . 158: if ok {
. 20.11s 159: routeHeaders := requestRouteCodec.GetMetas(request)
. . 165: }
. . 166:
. . 167: // tracing
10ms 80ms 168: tracingCodec, ok := conn.codec.(xprotocol.Tracing)
. . 169: var span types.Span
. . 170: if ok {
10ms 1.91s 171: serviceName := tracingCodec.GetServiceName(request)
. 2.17s 172: methodName := tracingCodec.GetMethodName(request)
. . 176:
. . 177: if trace.IsEnabled() {
. 50ms 179: tracer := trace.Tracer(protocol.Xprotocol)
. . 180: if tracer != nil {
20ms 1.66s 181: span = tracer.Start(conn.context, headers, time.Now())
. . 182: }
. . 183: }
. . 184: }
. . 185:
. 110ms 186: reqBuf := networkbuffer.NewIoBufferBytes(request)
. . 188: // append sub protocol header
10ms 950ms 189: headers[types.HeaderXprotocolSubProtocol] = string(conn.subProtocol)
10ms 4.96s 190: conn.OnReceive(ctx, streamID, protocol.CommonHeader(headers), reqBuf, span, isHearbeat)
30ms 60ms 191: buffer.Drain(requestLen)
. . 192: }
. . 193:}

通过上面 list Dispatch 命令,性能卡点主要分布在 159171172181 、和 190 等行,主要卡点在解码 dubbo 参数、重复解参数、tracer、发序列化和 log 等。

1. 优化 dubbo 解码 GetMetas

我们通过解码 dubbo 的 body 可以获得以下信息,调用的目标接口( interface )和调用方法的服务分组( group )等信息,但是需要跳过所有业务方法参数,目前使用开源的 dubbo-go-hessian2 库,解析 string 和 map 性能较差, 提升 hessian 库解码性能,会在本文后面讲解。

优化思路:

在 mosn 的 ingress 端( mosn 直接转发请求给本地 java server 进程), 我们根据请求的 path 和 version 窥探用户使用的 interface 和 group , 构建正确的 dataID 可以进行无脑转发,无需解码 body,榨取性能提升。

我们可以在服务注册时,构建服务发布的 path 、version 和 group 到 interface 、group 映射。在 mosn 转发 dubbo 请求时可以通过读锁查 cache + 跳过解码 body,加速 mosn 性能。

因此我们构建以下 cache 实现(数组 + 链表数据结构), 可参见 优化代码diff

复制代码
// metadata.go
// DubboPubMetadata dubbo pub cache metadata
var DubboPubMetadata = &Metadata{}
// DubboSubMetadata dubbo sub cache metadata
var DubboSubMetadata = &Metadata{}
// Metadata cache service pub or sub metadata.
// speed up for decode or encode dubbo peformance.
// please do not use outside of the dubbo framwork.
type Metadata struct {
data map[string]*Node
mu sync.RWMutex // protect data internal
}
// Find cached pub or sub metatada.
// caller should be check match is true
func (m *Metadata) Find(path, version string) (node *Node, matched bool) {
// we found nothing
if m.data == nil {
return nil, false
}
m.mu.RLocker().Lock()
// for performance
// m.mu.RLocker().Unlock() should be called.
// we check head node first
head := m.data[path]
if head == nil || head.count <= 0 {
m.mu.RLocker().Unlock()
return nil, false
}
node = head.Next
// just only once, just return
// for dubbo framwork, that's what we're expected.
if head.count == 1 {
m.mu.RLocker().Unlock()
return node, true
}
var count int
var found *Node
for ; node != nil; node = node.Next {
if node.Version == version {
if found == nil {
found = node
}
count++
}
}
m.mu.RLocker().Unlock()
return found, count == 1
}
// Register pub or sub metadata
func (m *Metadata) Register(path string, node *Node) {
m.mu.Lock()
// for performance
// m.mu.Unlock() should be called.
if m.data == nil {
m.data = make(map[string]*Node, 4)
}
// we check head node first
head := m.data[path]
if head == nil {
head = &Node{
count: 1,
}
// update head
m.data[path] = head
}
insert := &Node{
Service: node.Service,
Version: node.Version,
Group: node.Group,
}
next := head.Next
if next == nil {
// fist insert, just insert to head
head.Next = insert
// record last element
head.last = insert
m.mu.Unlock()
return
}
// we check already exist first
for ; next != nil; next = next.Next {
// we found it
if next.Version == node.Version && next.Group == node.Group {
// release lock and no nothing
m.mu.Unlock()
return
}
}
head.count++
// append node to the end of the list
head.last.Next = insert
// update last element
head.last = insert
m.mu.Unlock()
}

通过服务注册时构建好的 cache,可以在 mosn 的 stream 做解码时命中 cache , 无需解码参数获取接口和 group 信息,可参见优化代码 diff :

复制代码
// decoder.go
// for better performance.
// If the ingress scenario is not using group,
// we can skip parsing attachment to improve performance
if listener == IngressDubbo {
if node, matched = DubboPubMetadata.Find(path, version); matched {
meta[ServiceNameHeader] = node.Service
meta[GroupNameHeader] = node.Group
}
} else if listener == EgressDubbo {
// for better performance.
// If the egress scenario is not using group,
// we can skip parsing attachment to improve performance
if node, matched = DubboSubMetadata.Find(path, version); matched {
meta[ServiceNameHeader] = node.Service
meta[GroupNameHeader] = node.Group
}
}

在 mosn 的 egress 端( mosn 直接转发请求给本地 java client 进程), 我们采用类似的思路, 我们根据请求的 path 和 version 去窥探用户使用的 interface 和 group , 构建正确的 dataID 可以进行无脑转发,无需解码 body,榨取性能提升。

2. 优化 dubbo 解码参数

在 dubbo 解码参数值的时候 ,mosn 采用的是 hessian 的正则表达式查找,非常耗费性能。我们先看下优化前后 benchmark 对比, 性能提升 50 倍。

复制代码
go test -bench=BenchmarkCountArgCount -run=^$ -benchmem
BenchmarkCountArgCountByRegex-12 200000 6236 ns/op 1472 B/op 24 allocs/op
BenchmarkCountArgCountOptimized-12 10000000 124 ns/op 0 B/op 0 allocs/op

优化思路:

可以消除正则表达式,采用简单字符串解析识别参数类型个数, dubbo 编码参数个数字符串实现 并不复杂, 主要给对象加 L 前缀、数组加 [、primitive 类型有单字符代替。采用 go 可以实现同等解析, 可以参考优化代码 diff

复制代码
func getArgumentCount(desc string) int {
len := len(desc)
if len == 0 {
return 0
}
var args, next = 0, false
for _, ch := range desc {
// is array ?
if ch == '[' {
continue
}
// is object ?
if next && ch != ';' {
continue
}
switch ch {
case 'V', // void
'Z', // boolean
'B', // byte
'C', // char
'D', // double
'F', // float
'I', // int
'J', // long
'S': // short
args++
default:
// we found object
if ch == 'L' {
args++
next = true
// end of object ?
} else if ch == ';' {
next = false
}
}
}
return args
}

3. 优化 dubbo hessian go 解码 string 性能

在图 1-2 中可以看到 dubbo hessian go 在解码 string 占比 CPU 采样较高,我们在解码 dubbo 请求时,会解析 dubbo 框架版本、调用 path 、接口版本和方法名,这些都是 string 类型,dubbo hessian go 解析 string 会影响 RPC 性能。

我们首先跑一下 benchmar k 前后解码 string 性能对比,性能提升 56.11%, 对应到 RPC 中有 5% 左右提升。

复制代码
BenchmarkDecodeStringOriginal-12 1967202 613 ns/op 272 B/op 6 allocs/op
BenchmarkDecodeStringOptimized-12 4477216 269 ns/op 224 B/op 5 allocs/op

优化思路:

直接使用 UTF-8 byte 解码,性能最高,之前先解码 byte 成 rune , 对 rune 解码成 string ,及其耗费性能。增加批量 string chunk copy ,降低 read 调用,并且使用 unsafe 转换 string (避免一些校验),因为代码优化 diff 较多,这里给出优化代码 PR

go SDK 代码runtime/string.go#slicerunetostring( rune 转换成 string ), 同样是把 rune 转成 byte 数组,这里给了我优化思路启发。

4. 优化 hessian 库编解码对象

虽然消除了 dubbo 的 body 解码部分,但是 mosn 在处理 dubbo 请求时,必须要借助 hessian 去 decode 请求头部的框架版本、请求 path 和接口版本值。但是每次在解码的时候都会创建序列化对象,开销非常高,因为 hessian 每次在创建 reader 的时候会 allocate 4k 数据并 reset。

复制代码
10ms 10ms 75:func unSerialize(serializeId int, data []byte, parseCtl unserializeCtl) *dubboAttr {
10ms 140ms 82: attr := &dubboAttr{}
80ms 2.56s 83: decoder := hessian.NewDecoderWithSkip(data[:])
ROUTINE ======================== bufio.NewReaderSize in /usr/local/go/src/bufio/bufio.go
50ms 2.44s (flat, cum) 2.33% of Total
. 220ms 55: r := new(Reader)
50ms 2.22s 56: r.reset(make([]byte, size), rd)
. . 57: return r
. . 58:}

我们可以写个池化内存前后性能对比, 性能提升 85.4% , benchmark 用例

复制代码
BenchmarkNewDecoder-12 1487685 803 ns/op 4528 B/op 9 allocs/op
BenchmarkNewDecoderOptimized-12 10564024 117 ns/op 128 B/op 3 allocs/op

优化思路:

在每次编解码时,池化 hessian 的 decoder 对象,新增 NewCheapDecoderWithSkip 并支持 reset 复用 decoder 。

复制代码
var decodePool = &sync.Pool{
New: func() interface{} {
return hessian.NewCheapDecoderWithSkip([]byte{})
},
}
// 在解码时按照如下方法调用
decoder := decodePool.Get().(*hessian.Decoder)
// fill decode data
decoder.Reset(data[:])
hessianPool.Put(decoder)

5. 优化重复解码 service 和 methodName 值

xprotocol 在实现 xprotocol.Tracing 获取服务名称和方法时,会触发调用并解析 2 次,调用开销比较大。

复制代码
10ms 1.91s 171: serviceName := tracingCodec.GetServiceName(request)
. 2.17s 172: methodName := tracingCodec.GetMethodName(request)

优化思路:

因为在 GetMetas 里面已经解析过一次了,可以把解析过的 headers 传进去,如果 headers 有了就不用再去解析了,并且重构接口名称为一个,返回值为二元组,消除一次调用。

6. 优化 streamID 类型转换

在 go 中将 byte 数组和 streamID 进行互转的时候,比较费性能。

优化思路:

生产代码中, 尽量不要使用 fmt.Sprintf 和 fmt.Printf 去做类型转换和打印信息。可以使用 strconv 去转换。

复制代码
. 430ms 147: reqIDStr := fmt.Sprintf("%d", reqID)
60ms 4.10s 168: fmt.Printf("src=%s, len=%d, reqid:%v\n", streamID, reqIDStrLen, reqIDStr)

7. 优化昂贵的系统调用

mosn 在解码 dubbo 的请求时,会在 header 中塞一份远程 host 的地址,并且在 for 循环中获取 remote IP,系统调用开销比较高。

优化思路:

复制代码
50ms 920ms 136: headers[strings.ToLower(protocol.MosnHeaderHostKey)] = conn.connection.RemoteAddr().String()

在获取远程地址时,尽可能在 streamConnection 中 cache 远程 IP 值,不要每次都去调用 RemoteAddr。

8. 优化 slice 和 map 触发扩容和 rehash

在 mosn 处理 dubbo 请求时,会根据接口、版本和分组去构建 dataID ,然后匹配 cluster , 会创建默认 slice 和 map 对象,经过性能诊断,导致不断 allocate slice 和 grow map 容量比较费性能。

优化思路:

使用 slice 和 map 时,尽可能预估容量大小,使用 make(type, capacity) 去指定初始大小。

9. 优化 trace 日志级别输出

mosn 中不少代码在处理逻辑时,会打很多 trace 级别的日志,并且会传递不少参数值。

优化思路:

调用 trace 输出前,尽量判断一下日志级别,如果有多个 trace 调用,尽可能把所有字符串写到 buf 中,然后把 buf 内容写到日志中,并且尽可能少的调用 trace 日志方法。

10. 优化 tracer、log 和 metrics

在大促期间,对机器的性能要求较高,经过性能诊断,tracer、mosn log 和 cloud metrics 写日志( IO 操作)非常耗费性能。

优化思路:

通过配置中心下发配置或者增加大促开关,允许 API 调用这些 feature 的开关。

复制代码
/api/v1/downgrade/on
/api/v1/downgrade/off

11. 优化 route header 解析

mosn 中在做路由前,需要做大量的 header 的 map 访问,比如 IDC、antvip 等逻辑判断,商业版或者开源 mosn 不需要这些逻辑,这些也会占用一些开销。

优化思路:

如果是云上逻辑,主站的逻辑都不走。

12. 优化 featuregate 调用

在 mosn 中处理请求时,为了区分主站和商业版路由逻辑,会通过 featuregate 判断逻辑走哪部分。通过 featuregate 调用开销较大,需要频繁的做类型转换和多层 map 去获取。

优化思路:

通过一个 bool 变量记录 featuregate 对应开关,如果没有初始化过,就主动调用一下 featuregate。

未来性能优化思考

经过几轮性能优化 ,目前看火焰图,卡点都在 connection 的 read 和 write ,可以优化的空间比较小了。但是可能从以下场景中获得收益:

  • 减少 connection 的 read 和 write 次数 (syscall) 。
  • 优化 IO 线程模型,减少携程和上下文切换等。

作为结束,给出了最终优化后的火焰图 ,大部分卡点都在系统调用和网络读写, 请参考图 1-4。

图 1-4 优化版本 mosn + dubbo 火线图

其他

pprof 工具异常强大,可以诊断 CPU、memory、go 协程、tracer 和死锁等,该工具可以参考 godoc ,性能优化参考:

关于作者

诣极,github ID zonghaishang,Apache Dubbo PMC,目前就职于蚂蚁金服中间件团队,主攻 RPC 和 Service Mesh 方向。 《深入理解 Apache Dubbo 与实战》一书作者。

2020 年 6 月 07 日 14:07 1663

评论

发布
暂无评论
发现更多内容

谈谈对分布式事务的一点理解和解决方案

Throwable

分布式 分布式事务 架构设计

使用 Generic Webhook Trigger 触发 Jenkins 多分支流水线自动化构建

jerry.mei

DevOps 持续集成 jenkins CI/CD 持续交付

[译] 图说前端-图解 React

梦见君笑

前端 前端框架 React 框架 前端训练

看动画学算法之:排序-冒泡排序

程序那些事

算法 动画 排序算法 轻松学

架构师训练营第六周学习总结

张明森

U盘+grub2安装centos8实战

昌安古城

如何使用预测性指标衡量敏捷转型的成功?

Atlassian速递

敏捷开发 开发工具 Atlassian Jira

SpringBoot2.x入门:应用打包与启动

Throwable

springboot

3W字干货深入分析基于Micrometer和Prometheus实现度量和监控的方案

Throwable

Java 监控 Grafana Prometheus springboot

关于架构的几件小事:架构概述(1)

北风

架构 架构设计 架构师 架构设计原则

要不要做一个gif动态图玩一下?

诸葛小猿

GIF ScreenToGif 动态图

修炼我们的智慧之眼

Jeff.Spring

认知提升

如何不写一行代码就做出一款游戏来

Lawliet

Vue 游戏开发 游戏制作 游戏开源 前端进阶训练营

AOP有几种实现方式?

八苦-瞿昙

技术 随笔杂谈 aop 代理 框架

SpringBoot 入门:02 - 实现 MVC

封不羁

Java spring springboot

了不起的 Webpack Scope Hoisting 学习指南

pingan8787

JavaScript 前端 webpack

iOS - CollectionViewCell对应不同flow layout的实例

teoking

ios

工程规约 - maven统一管理

Man

maven DevOps 工程规约

如何在 Go 中写出高效的单元测试

_why先生

go testing slideshare

玛雅密码社区不忘初心 共筑未来通证新经济

Geek_116789

大话设计模式 | 4. 装饰模式

Puran

C# 设计模式

阿里花500万年薪招天才黑客?官方回应:这种人得交给警察

程序员生活志

黑客 阿里

如何编写可怕的 Java 代码?

武培轩

Java 编程 程序员 后端

帮助小团队实现大梦想 | Atlassian 云产品免费使用

Atlassian速递

百万级别数据Excel导出优化

Throwable

架构设计 springboot

list vs tupple

Leetao

Python 数据结构 Python基础知识

如何搭建Hive 环境

Rayjun

大数据 hive

架构师训练营第六周作业

talen

并行流ParallelStream中隐藏的陷阱

Throwable

JAVA stream

ARST Week7

时之虫

ARTS 打卡计划

创业使人成长系列 (3)- 如何取个好名字

石云升

创业 成长 取名

记一次在 mosn 对 dubbo、dubbo-go-hessian2 的性能优化-InfoQ