SOFARPC 性能优化实践(上)| SOFAChannel#2 直播整理

本文涉及的产品
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
简介: 本次是 SOFAChannel 第二期,主要分享 SOFARPC 在性能上做的一些优化,这个系列会分成上下两部分进行分享,今天是 SOFARPC 性能优化(上),也会对本次分享中的一些结论,提供部分代码 Demo,供大家了解验证。
SOFA:Channel,有趣实用的分布式架构频道。

本次是 SOFAChannel 第二期,主要分享 SOFARPC 在性能上做的一些优化,这个系列会分成上下两部分进行分享,今天是 SOFARPC 性能优化(上),也会对本次分享中的一些结论,提供部分代码 Demo,供大家了解验证。
下期将在本月28号与大家见面, SOFARPC 性能优化(下),报名链接:https://tech.antfin.com/activities/245
欢迎加入直播互动钉钉群:23127468,不错过我们每场直播。

邮件配图.png

大家好,今天是我们 SOFAChannel 第二期。欢迎大家观看。

我是来自蚂蚁金服中间件的雷志远,花名碧远,目前在负责 SOFARPC 框架相关工作。
去年的时候,我们和外部的爱好者们一起,做了一个基于 SOFARPC 的源码解析系列,我同事已经发到群里了,大家可以保存,直播之后查看。
SOFARPC 源码解析系列:(点击【剖析 | SOFARPC 框架】即可查看)

今年,基于源码解析的基础,我们来多讲讲实践,如何应用到大家的业务,来帮助大家解决实际问题。在直播过程中有相关的问题想提问,可以在钉钉群互动。

前言

在上一期中,余淮分享了《从蚂蚁金服微服务实践谈起》。介绍了蚂蚁微服务的起源,以及之后服务化,单元化的情况。同时介绍了 SOFAStack 目前开源的情况。最后也分享了一下整个微服务中 SOFARPC 的设计与实现。

本期,我们主要分享 SOFARPC 在性能上做的一些优化。这个系列会分成上下两部分进行分享,今天是 SOFARPC 性能优化(上),也会对本次分享中的一些结论,提供部分代码 Demo,供大家了解验证。

我们先简要介绍一下 SOFARPC 的框架分层。这个在上次的分享中已经进行了介绍。

image.png

下层是网络传输层,依次是协议,序列化,服务发现和 Filter 等。
Transport 主要负责数据传输,可以是 Http2Transport,也可以是 BoltTransport,还有可能是其他。
Protocol 层是协议,是 Rest 还是 Bolt ,或者是 Dubbo 。
Serialization 是序列化,对于每种协议,可以是用不同的序列化方式,比如 hessian,pb,json 等。
Filter 是通用的过滤器层,主要是为了留出一些扩展,完成一些其他扩展功能,比如 Tracer 的埋点等。
Router 是路由层,主要是做寻址,这里可能是 Zk,也可能是 LVS,也可能是直连。
Cluster 是客户端集群方式的表示。

自定义通讯协议使用

首先我想介绍一下自定义通讯协议。

在说明自定义通讯协议之前,我先简单介绍一下通讯协议。在TCP之上,RPC框架通常还需要将请求和响应数据进行一定的封装,组装成 Packet,然后发送出去。这样,服务端收到之后,才能正确识别整个 TCP 发过来的字节流中,哪一部分是我们可以进行处理的一个完整单位。反之,客户端收到服务端的TCP 数据流也是如此。

有了上面的共识之后,我们要回答下面两个问题:

  1. 为什么要自定义,不使用 Http2/Dubbo/Rest/Grpc?
  2. 自定义之后,带来了什么好处呢?

Http2 虽然更为通用,但是一方面,出现较晚,迁移转换成本高,并且通用则意味着传输的辅助数据会变多,会有一些额外的信息需要传递或者判断。对于序列化反序列化的控制上,也不是很好扩展操作。

而 Dubbo,协议简单强大。但是一些元信息需要解析,Header 中传输的数据太少,很多都需要依赖 body 中的数据反序列化完成后才能使用,头部的信息太少。

image.png

而使用了自研的协议之后,Header 中可自定义传输更多的元信息,序列化方式,Server Fail Fast,服务端线程隔离等也都成为可能。甚至蚂蚁在 ServiceMesh 的场景下,Mesh 本身也能利用 Bolt 的协议,进行部分数据的读取,而不依赖具体的序列化实现。


BOLT 协议图

经过我们的实践,大致来看,目前给我们带来的好处主要有以下的能力:

  1. Server Fast 的支持
  2. Header 和 Body 的分开序列化
  3. Crc 校验的支持
  4. 版本的支持,预防未来可能出现的更好的设计方案
  5. 多种序列化方式的支持
  6. 安全认证,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 的加持,还是有一些损失。

说到这里, 可能有些同学有疑问:

  1. Keep Alive 不够吗?
  2. Bolt 的连接管理怎么做的?
  3. 如何解决初次建联的问题?
  4. 心跳是单向还是双向?

前面我们说过了,Keep Alive 已经打开了。不过,Keep Alive 还不够,主要是经过很多网络设备之后,Keep Alive可能失效,另外 Keep Alive 是一个 Linux 层面的设置,有时候整个系统并未打开。这些不可控的因素都会导致我们的连接管理失效。

image.png
Keep Alive 图

上面是 Keep Alive 的处理,主要是在没有读写事件一段时间后,进行数据包的发送来保活。

因为我们需要更通用的连接保持方案。连接管理核心的基于 Netty 的 Idle 事件来做。BOLT 的设置为单向心跳,客户端发,服务端收,减少心跳数据在网络上的传输量。有些 RPC 框架会使用双向心跳,同时,BOLT 在连接管理上,也允许一个地址,建立多个连接,这样可以在发送时,最大限度的利用网卡。默认为1,连接数在满足传输吞吐量的情况下越少越好。

但是这里要注意,如果你的场景是有大量的服务端,那么这个数据不建议进行扩大。因为 tcp 连接会成倍增长,反而带来性能下降。目前蚂蚁这边大部分也多为1。

image.png
RPC 连接管理

在 BOLT 连接管理的基础上,RPC 为了避免第一次用户请求,进行建联并发送的延迟,RPC 还有一个连接管理的线程,会异步的进行连接初始化。这样,当真正的请求发起的时候,连接已经准备好了,可以减少一次建联的耗时对业务的影响。

对于 LVS 和 VIP 的场景下,由于长连接的特性,即使后端有 100个 IP,对客户端来说,也只能和一个 IP 进行通信,因为这些设备是建联层面的,并非通信层面的。所以对这种情况。,一个 RPC 框架也要考虑支持定时断链和重连。

序列化选择

以上都准备好了之后,序列化方式的选择决定了业务传输对象能够有多小,也决定了在传输之前,序列化和反序列化的时候能有多快或者有多占用 CPU 。

image.png
序列化图

蚂蚁这边长期使用 hessian 作为序列化方式,在出现跨语言需求后,同时支持 pb 。如果你还有考虑其他的序列化方式,可以参考附录中的序列化框架性能测试套件来进行选择。
需要注意的是,在 RPC 场景的序列化中,一定要考虑接口变更,字段新增的兼容性。因为一旦一个接口被客户 A 和 B 引用,此时 C 要升级 facade 接口,能否兼容 A 和 B 的情况就很重要。
基于我们自己的情况,在序列化方式的选择上:

  1. 如果很长时间内,不存在跨语言的情况,hessian 是兼容性和性能的综合考虑
  2. 如果考虑跨语言,并且对性能要求很高,Pb 可作为跨语言的情况下的选择。
  3. 在选型时也要考虑序列化框架的社区情况。切勿选择看上去性能高,但是已经不再维护的库,或者用户量非常少的库,一旦出现问题,比较难解决。

IO 线程池批量解包

image.png
批量解包图

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

相关参考链接:

讲师观点

channel#2金句海报.jpg

相关实践学习
通过性能测试PTS对云服务器ECS进行规格选择与性能压测
本文为您介绍如何利用性能测试PTS对云服务器ECS进行规格选择与性能压测。
目录
相关文章
|
1月前
|
缓存 监控 Java
大厂性能优化的10大顶级方案 (万字图文史上最全)
本文详细介绍了大厂性能优化的10大顶奢方案,涵盖代码优化、缓存优化、异步优化、多线程优化、前端优化、微服务架构优化、硬件升级、数据库优化、过载保护优化以及度量与监控系统等方面。每部分不仅提供了理论知识,还结合实际案例和代码示例,帮助读者全面理解和应用这些优化策略。文章还特别强调了架构设计的重要性,指出架构师需要具备多方面的知识和技能,包括硬件、软件、网络协议、分布式知识等,以应对复杂的技术挑战。最后,作者尼恩分享了自己多年的经验,提供了丰富的技术资源和实战指导,助力读者在面试和工作中取得成功。
大厂性能优化的10大顶级方案 (万字图文史上最全)
|
1月前
|
Web App开发 编解码 视频直播
视频直播技术干货(十二):从入门到放弃,快速学习Android端直播技术
本文详细介绍了Android端直播技术的全貌,涵盖了从实时音视频采集、编码、传输到解码与播放的各个环节。文章还探讨了直播中音视频同步、编解码器选择、传输协议以及直播延迟优化等关键问题。希望本文能为你提供有关Andriod端直播技术的深入理解和实践指导。
45 0
阿里为了双十一,整理亿级JVM性能优化文档,竟被GitHub“抢开”
“随着云计算和微服务大行其道,现代 Java 程序需要适配的计算环境日益多样化。如何在云时代充分发挥Java的性能优势是所有 Java 程序员都必然要面对的挑战。
|
SQL 缓存 负载均衡
项目高并发问题解决方案合集
这道题是比较典型的题吧,也是我第一个公司入职的时候,面试官问我的,当时我回答只能说是星星之火,还不能燎原那种,差点被面试官给浇灭。
110 0
|
设计模式 缓存 Java
好家伙!阿里新产Java性能优化(终极版),涵盖性能优化所有操作
上月公司来了一位大佬,入职不到一周就把公司现有项目的性能优化了一遍,直接给公司节省了一半的成本。 一问情况,才知道这位仁兄也是一路被虐过来的。去年年底被裁,本以为自己技术还行,看了一段时间面经,复习了基础知识,就开始投大厂简历。阿里最先给他面试机会,结果没能扛过三面,然后是各种大大小小的公司,在实际面试中被碾压得翻不了身。整整一个半月,一个offer都没拿到,最后针对性的恶补,才入职了我司。
|
SQL 存储 分布式计算
Presto 架构原理与优化介绍 | 青训营笔记
MapReduce代表了抽象的物理执行模型,使用]槛较高。 与Mapreduce Job相比,OLAP引擎常通过SQL的形式,为数据分析、数据开发人员提供统的逻辑描述语言,实际的物理执行由具体的引|擎进行转换和优化。
580 0
Presto 架构原理与优化介绍 | 青训营笔记
|
SQL 移动开发 网络协议
【优化技术专题】「系统性能调优实战」终极关注应用系统性能调优及原理剖析(上册)
【优化技术专题】「系统性能调优实战」终极关注应用系统性能调优及原理剖析(上册)
153 0
|
SQL 缓存 监控
【优化技术专题】「系统性能调优实战」终极关注应用系统性能调优及原理剖析(下册)
【优化技术专题】「系统性能调优实战」终极关注应用系统性能调优及原理剖析(下册)
140 0
|
数据采集 开发工具 流计算
项目中直播实现的原理解析
最近项目中涉及到了直播这快的内容,所以针对平时开发中的问题以及采用的技术做一波分享,希望对大家有所帮助。
325 0
|
Serverless 开发者
报名中 | Serverless 技术进阶研读班,碎片时间提升技术新方式
工作太忙没时间学习?Serverless 专家为你盘点知识干货,每天碎片时间,带你快速跃迁 Serverless 技术。
报名中 | Serverless 技术进阶研读班,碎片时间提升技术新方式