SOFA:Channel,有趣实用的分布式架构频道。本次是 SOFAChannel 第二期,主要分享 SOFARPC 在性能上做的一些优化,这个系列会分成上下两部分进行分享,今天是 SOFARPC 性能优化(上),也会对本次分享中的一些结论,提供部分代码 Demo,供大家了解验证。
下期将在本月28号与大家见面, SOFARPC 性能优化(下),报名链接:https://tech.antfin.com/activities/245
欢迎加入直播互动钉钉群:23127468,不错过我们每场直播。
大家好,今天是我们 SOFAChannel 第二期。欢迎大家观看。
我是来自蚂蚁金服中间件的雷志远,花名碧远,目前在负责 SOFARPC 框架相关工作。
去年的时候,我们和外部的爱好者们一起,做了一个基于 SOFARPC 的源码解析系列,我同事已经发到群里了,大家可以保存,直播之后查看。
SOFARPC 源码解析系列:(点击【剖析 | SOFARPC 框架】即可查看)
今年,基于源码解析的基础,我们来多讲讲实践,如何应用到大家的业务,来帮助大家解决实际问题。在直播过程中有相关的问题想提问,可以在钉钉群互动。
前言
在上一期中,余淮分享了《从蚂蚁金服微服务实践谈起》。介绍了蚂蚁微服务的起源,以及之后服务化,单元化的情况。同时介绍了 SOFAStack 目前开源的情况。最后也分享了一下整个微服务中 SOFARPC 的设计与实现。
本期,我们主要分享 SOFARPC 在性能上做的一些优化。这个系列会分成上下两部分进行分享,今天是 SOFARPC 性能优化(上),也会对本次分享中的一些结论,提供部分代码 Demo,供大家了解验证。
我们先简要介绍一下 SOFARPC 的框架分层。这个在上次的分享中已经进行了介绍。
下层是网络传输层,依次是协议,序列化,服务发现和 Filter 等。
Transport 主要负责数据传输,可以是 Http2Transport,也可以是 BoltTransport,还有可能是其他。
Protocol 层是协议,是 Rest 还是 Bolt ,或者是 Dubbo 。
Serialization 是序列化,对于每种协议,可以是用不同的序列化方式,比如 hessian,pb,json 等。
Filter 是通用的过滤器层,主要是为了留出一些扩展,完成一些其他扩展功能,比如 Tracer 的埋点等。
Router 是路由层,主要是做寻址,这里可能是 Zk,也可能是 LVS,也可能是直连。
Cluster 是客户端集群方式的表示。
自定义通讯协议使用
首先我想介绍一下自定义通讯协议。
在说明自定义通讯协议之前,我先简单介绍一下通讯协议。在TCP之上,RPC框架通常还需要将请求和响应数据进行一定的封装,组装成 Packet,然后发送出去。这样,服务端收到之后,才能正确识别整个 TCP 发过来的字节流中,哪一部分是我们可以进行处理的一个完整单位。反之,客户端收到服务端的TCP 数据流也是如此。
有了上面的共识之后,我们要回答下面两个问题:
- 为什么要自定义,不使用 Http2/Dubbo/Rest/Grpc?
- 自定义之后,带来了什么好处呢?
Http2 虽然更为通用,但是一方面,出现较晚,迁移转换成本高,并且通用则意味着传输的辅助数据会变多,会有一些额外的信息需要传递或者判断。对于序列化反序列化的控制上,也不是很好扩展操作。
而 Dubbo,协议简单强大。但是一些元信息需要解析,Header 中传输的数据太少,很多都需要依赖 body 中的数据反序列化完成后才能使用,头部的信息太少。
而使用了自研的协议之后,Header 中可自定义传输更多的元信息,序列化方式,Server Fail Fast,服务端线程隔离等也都成为可能。甚至蚂蚁在 ServiceMesh 的场景下,Mesh 本身也能利用 Bolt 的协议,进行部分数据的读取,而不依赖具体的序列化实现。
BOLT 协议图
经过我们的实践,大致来看,目前给我们带来的好处主要有以下的能力:
- Server Fast 的支持
- Header 和 Body 的分开序列化
- Crc 校验的支持
- 版本的支持,预防未来可能出现的更好的设计方案
- 多种序列化方式的支持
- 安全认证,Mesh 路由
如果你要自己设计一个通讯协议。可以考虑使用 BOLT 协议,或者参考进行更好的设计和优化。
关于 SOFABolt 相关的源码解析,也可以通过这个系列来了解。
SOFABolt 源码解析系列:(点击【剖析 | SOFABOLT 框架】即可查看)
Netty 性能参数优化
在介绍了自定义通讯协议之后,也就是确定好了怎么封包解包之后,还需要确定传输层的开发。一个 RPC 框架从现在的情况来看,一般不太可能完全基于 JAVA 的 NIO 或者其他 IO 进行直接的开发,主要是一些 NIO 原生的问题和使用难度,而成熟的,目前可选的不多。基本上,大家都会基于 Netty 进行开发,HSF/Dubbo/Motan 等都是这样。
直接使用是比较简单的。在 Netty 的 Bootstrap 的设置中,有一些可选的优化项,有必要跟大家分享一下。
1、SO_REUSEPORT/SO_REUSEADDR - 端口复用(允许多个 socket 监听同一个IP+端口)
SO_REUSEPORT 支持多个进程或者线程绑定到同一端口,提高服务器的接收链接的并发能力,由内核层面实现对端口数据的分发的负载均衡,在服务器 socket 上没有了锁的竞争。
同时 SO_REUSEADDR也要打开,这样针对 time-wait 链接 ,可以确保 server 重启成功。在一些服务端启动很快的情况下,可以防止启动失败。
2、TCP_FASTOPEN - 3次握手时也用来交换数据
三次握手的过程中,当用户首次访问服务端时,发送 syn 包,server 根据客户端 IP 生成 cookie ,并与 syn+ack 一同发回客户端;客户端再次访问服务端时,在 syn 包携带 TCP cookie;如果服务端校验合法,则在用户回复 ack 前就可以直接发送数据;否则按照正常三次握手进行。也就是说,如果客户端中途断开,再建联的时候,会同时发送数据,会有一定的性能提升。
TFO 提高性能的关键是省去了热请求的三次握手,这在小对象传输较多的移动应用场景中,能够极大提升性能。
Netty 中仅在 Epoll 的时候可用 Linux特性,不能在 Mac/Windows 上使用,SOFARPC 未开启。
3、TCP_NODELAY-关闭 (纳格) Nagle 算法,再小的包也发送,而不是等待
TCP/IP 协议中针对 TCP 默认开启了 Nagle 算法。Nagle 算法通过减少需要传输的数据包个数,来优化网络。但是现在的环境下,网络带宽足够,需要进行关闭。这样,对于传输数据量小的场景,能很好的提高性能,不至于出现数据包等待。
4、SO_KEEPALIVE –开启 TCP 层面的 Keep Alive 能力
这个不多说,开启一下 TCP 层面的 Keep Alive 的能力。
5、WRITE_BUFFER_WATER_MARK 设置
通过 WRITE_BUFFER_WATER_MARK 设置某个连接上可以暂存的最大最小 Buffer 之后,如果该连接的等待发送的数据量大于设置的值时,则 isWritable 会返回不可写。这样,客户端可以不再发送,防止这个量不断的积压,最终可能让客户端挂掉。如果发生这种情况,一般是服务端处理缓慢导致。这个值可以有效的保护客户端。此时数据并没有发送出去。
6、workerGroup
worker 线程数设置 处理器+1,Netty 默认是线程数*2,可以根据自己的压测情况来判断。Boss Group 用于服务端处理建立连接的请求,WorkGroup 用于处理I/O。为了避免线程上下文切换,只要能满足要求,这个值一般越少越好。
7、ioRadio 设置
EventLoop#ioRatio 的设置(默认50), 这是 EventLoop 执行 IO 任务和非 IO 任务的一个时间比例上的控制,BOLT 最佳实践是70,表示70%的时间在执行 IO 任务。
8、SO_BACKLOG 设置
在 Linux 系统内核中维护了两个队列:syns queue 和 accept queue。第一个是半连接队列,保存收到客户端 syn 之后,进入 syn_recv 状态的这些连接,默认 netty 中是128,io.netty.util.NetUtil#SOMAXCONN
,然后读取/proc/sys/net/core/somaxconn
来继续确定,之后还有一些系统级别的覆盖逻辑。
在一些场景下,如果客户端远远多余服务端,并发建联,可能不够。这个值也不能太大,否则会无法防止 SYN-Flood 攻击。Bolt 中目前这个值修改成了1024。通过设置之后,由于自己设置的和系统的取小,所以自己设置的值相当于设置了上限。如果 Linux 系统运维某些设置错误,也能通过代码层面进行避免。
目前我们的 Linux 层面,通常设置的是 128,最终经过计算会设置为 128。
SOFARPC 连接保持
Netty 设置基本 ok,协议也确定之后,连接的保持就比较重要,否则,第一次发送或者每次发送都要走一次建联的过程。虽然有 FAST OPEN 的加持,还是有一些损失。
说到这里, 可能有些同学有疑问:
- Keep Alive 不够吗?
- Bolt 的连接管理怎么做的?
- 如何解决初次建联的问题?
- 心跳是单向还是双向?
前面我们说过了,Keep Alive 已经打开了。不过,Keep Alive 还不够,主要是经过很多网络设备之后,Keep Alive可能失效,另外 Keep Alive 是一个 Linux 层面的设置,有时候整个系统并未打开。这些不可控的因素都会导致我们的连接管理失效。
Keep Alive 图
上面是 Keep Alive 的处理,主要是在没有读写事件一段时间后,进行数据包的发送来保活。
因为我们需要更通用的连接保持方案。连接管理核心的基于 Netty 的 Idle 事件来做。BOLT 的设置为单向心跳,客户端发,服务端收,减少心跳数据在网络上的传输量。有些 RPC 框架会使用双向心跳,同时,BOLT 在连接管理上,也允许一个地址,建立多个连接,这样可以在发送时,最大限度的利用网卡。默认为1,连接数在满足传输吞吐量的情况下越少越好。
但是这里要注意,如果你的场景是有大量的服务端,那么这个数据不建议进行扩大。因为 tcp 连接会成倍增长,反而带来性能下降。目前蚂蚁这边大部分也多为1。
RPC 连接管理
在 BOLT 连接管理的基础上,RPC 为了避免第一次用户请求,进行建联并发送的延迟,RPC 还有一个连接管理的线程,会异步的进行连接初始化。这样,当真正的请求发起的时候,连接已经准备好了,可以减少一次建联的耗时对业务的影响。
对于 LVS 和 VIP 的场景下,由于长连接的特性,即使后端有 100个 IP,对客户端来说,也只能和一个 IP 进行通信,因为这些设备是建联层面的,并非通信层面的。所以对这种情况。,一个 RPC 框架也要考虑支持定时断链和重连。
序列化选择
以上都准备好了之后,序列化方式的选择决定了业务传输对象能够有多小,也决定了在传输之前,序列化和反序列化的时候能有多快或者有多占用 CPU 。
序列化图
蚂蚁这边长期使用 hessian 作为序列化方式,在出现跨语言需求后,同时支持 pb 。如果你还有考虑其他的序列化方式,可以参考附录中的序列化框架性能测试套件来进行选择。
需要注意的是,在 RPC 场景的序列化中,一定要考虑接口变更,字段新增的兼容性。因为一旦一个接口被客户 A 和 B 引用,此时 C 要升级 facade 接口,能否兼容 A 和 B 的情况就很重要。
基于我们自己的情况,在序列化方式的选择上:
- 如果很长时间内,不存在跨语言的情况,hessian 是兼容性和性能的综合考虑
- 如果考虑跨语言,并且对性能要求很高,Pb 可作为跨语言的情况下的选择。
- 在选型时也要考虑序列化框架的社区情况。切勿选择看上去性能高,但是已经不再维护的库,或者用户量非常少的库,一旦出现问题,比较难解决。
IO 线程池批量解包
批量解包图
Netty 提供了一个方便的解码工具类 ByteToMessageDecoder ,如图上半部分所示,这个类具备 accumulate 批量解包能力,可以尽可能的从 socket 里读取字节,然后同步调用 decode 方法,解码出业务对象,并组成一个 List 。最后再循环遍历该 List ,依次提交到 ChannelPipeline 进行处理。改动后,如图下半部分所示,即将提交的内容从单个 command ,改为整个 List 一起提交,如此能减少 pipeline 的执行次数,同时提升吞吐量。这个模式在低并发场景下不明显,但是在高并发场景下对吞吐量有不小的性能提升。
这一段是我改成开关方式的,方便大家理解改动点。
if (batchSwitch) {
ArrayList<Object> ret = new ArrayList<Object>(size);
for (int i = 0; i < size; i++) {
ret.add(out.get(i));
}
ctx.fireChannelRead(ret);
}else{
for (int i = 0; i < size; i++) {
ctx.fireChannelRead(out.get(i));
}
}
我们的 DEMO 提供了一个验证的方式,如果有相关的压测环境,可以参考进行多并发的验证。
DEMO 链接:https://github.com/leizhiyuan/rpcchannel
客户端 Proxy 的性能优化
作为一个 RPC 框架,最后,我们还有给用户的接口生成代理。目前一般大家都是要用动态代理来做。动态代理的性能有不同,使用上也有一定的差别。各个版本之间,也会有一定的差异。在选择上,需要大家根据实际情况,进行测试验证。
我们自己的测试数据显示 Javassist Bytecode 的方式是除了 Asm 之外,性能最好的。Asm 由于使用写法非常反人类,所以我们目前还是使用的 Javassist Bytecode 的方式。
Benchmark | Mode | Cnt | Score | Error | Units |
---|---|---|---|---|---|
ProxyInvokeBenchmark.invokeByAsm | avgt | 10 | 7.865 | ±0.028 | ns/op |
ProxyInvokeBenchmark.invokeByBytebuddy | avgt | 10 | 14.318 | ± 0.41 | ns/op |
ProxyInvokeBenchmark.invokeByCglib | avgt | 10 | 8.231 | ± 0.221 | ns/op |
ProxyInvokeBenchmark.invokeByJavassist | avgt | 10 | 15.86 | ± 0.605 | ns/op |
ProxyInvokeBenchmark.invokeByJavassistByte | avgt | 10 | 8.075 | ± 0.267 | ns/op |
ProxyInvokeBenchmark.invokeByJdk | avgt | 10 | 12.774 | ± 0.806 | ns/op |
可优先选择 javassist bytecode,有一定的性能优势,性能测试可以根据自己的情况,使用 JMH 进行测试。测试代码和版本在 DEMO 中提供。
总结
得益于 Java 社区的发展以及前辈们的贡献,目前写一个 RPC 框架并不是很难。但是作为一个 RPC 框架,需要在可维护性的基础上,尽可能提高自身性能,将在实际过程中遇到的一些场景和异常情况进行修复和优化,并进行更好的代码设计和实现。对于性能上的数据,可以多使用 JMH 并结合实际业务场景,进行相应的测试。
最后感谢大家,今天的 SOFA Channel 直播到此结束。下期我们将在本月28号与大家见面, SOFARPC 性能优化(下),我们会带来关于线程池隔离,Server Fail Fast,内存操作优化,用户可调节参数等方面的介绍。
大家可以点击链接进行报名
https://tech.antfin.com/activities/245
相关链接
视频回放也给你准备好啦:
https://tech.antfin.com/activities/244
相关参考链接:
- DEMO 链接:https://github.com/leizhiyuan/rpcchannel
- SOFARPC:https://github.com/alipay/sofa-rpc
- FAST OPEN https://tools.ietf.org/html/rfc7413
- netty https://netty.io/news/2015/09/30/4-0-32-Final.html
- jvm-serializers https://github.com/eishay/jvm-serializers/wiki
- 半连接 https://www.cnxct.com/something-about-phpfpm-s-backlog/
- SYN Flood https://zh.wikipedia.org/wiki/SYN_flood