perf[protocol]: 更新文档

This commit is contained in:
jaysunxiao
2022-05-25 22:24:15 +08:00
parent dbfad5abf5
commit c774bd7529
6 changed files with 52 additions and 49 deletions
+7 -1
View File
@@ -20,6 +20,13 @@
<br/>
-----------
Why is zfoo protocol ?
-----------
- 目前的Java二进制序列化和反序列化速度最快的框架,并且为序列化字节最少的框架
- 自定义协议格式的私有化序列化框架,同时能够前后兼容,更加安全,防止破解
- 协议目前原生支持 C++ Java Javascript C# Lua GDScript,可以轻易实现跨平台
- 单线程的Benchmark测试中,序列化和反序列化速度比Protobuf快50%,比Kryo快100%
. zfoo简介🚩
-----------
@@ -43,7 +50,6 @@
- 性能需求极高的项目,如网站和游戏服务器框架,单服滚服,全球服,直播聊天,IM系统,实时推送
- 节省研发成本的项目,如想节省,开发,部署,运维成本
- 适合作为 **GodotUnityCocosWebglH5** 的后端基础框架,网络通信协议支持 tcp udp websocket http
- 协议目前原生支持 **C++ Java Javascript C# Lua GDScript**,可以轻易实现跨平台
- 喜欢 [KISS法则](https://baike.baidu.com/item/KISS原则/3242383) 的项目 ,简单的配置,优雅的代码
Ⅲ. 详细的教程和完整的工程案例
Binary file not shown.

Before

Width:  |  Height:  |  Size: 59 KiB

After

Width:  |  Height:  |  Size: 58 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 60 KiB

After

Width:  |  Height:  |  Size: 58 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 56 KiB

After

Width:  |  Height:  |  Size: 56 KiB

+39 -39
View File
@@ -1,9 +1,9 @@
### . 简介
- [zfoo protocol](https://github.com/zfoo-project/zfoo/blob/main/protocol/README.md)
是目前的Java二进制序列化和反序列化最快的框架,并且为序列化字节最少的框架
是目前的Java二进制序列化和反序列化速度最快的框架,并且为序列化字节最少的框架
- 协议目前原生支持 **C++ Java Javascript C# Lua GDScript**,可以轻易实现跨平台
- 使用Javassist字节码增强动态生成顺序执行的序列化和反序列化函数,顺序执行的函数可以轻易的被JIT编译以达到极致的性能
- 协议可以自定义私有协议格式,让你的协议更加安全,支持增加字段和兼容前后版本协议
- 兼容protobuf,支持生成protobuf协议文件,提供从pojo到proto的生成方式
### Ⅱ. 快速使用
@@ -23,7 +23,7 @@ var packet = ProtocolManager.read(buffer);
### Ⅲ. 性能测试
- 单线程环境,在没有任何JVM参数调优的情况下速度比Protobuf快20%,比Kryo快40%[参见性能测试](src/test/java/com/zfoo/protocol/SpeedTest.java)
- 单线程环境,在没有任何JVM参数调优的情况下速度比Protobuf快50%,比Kryo快100%[参见性能测试](src/test/java/com/zfoo/protocol/SpeedTest.java)
- 线程安全,zfoo和Protobuf的性能不受任何影响,kryo因为线程不安全性能会有所损失,[参见性能测试](src/test/java/com/zfoo/protocol/SpeedTest.java)
@@ -42,43 +42,33 @@ cpu i9900k
### Ⅳ. 为什么快
- 轻量级实现,核心序列化和反序列化代码一千行左右
- 使用Javassist字节码增强动态生成顺序执行的序列化和反序列化函数,顺序化的函数可以轻易的被JIT编译以达到极致的性能
- 原生集成netty的高性能ByteBuf
- 没有装箱和拆箱,避免了无效GC
- 天生线程安全并且无锁化;kryo强制要求每条线程都有自己的一个Kryo实例,这是一个比较重的设计,特别是线程比较多的场景
- 没有反射,没有unsafe操作;对比kryo中使用objenesis导致大量unsafe,而且在Java11中运行会出现警告
- 优化了int和long的zigzag和varint编码的算法,避免了一些多余的方法调用和位操作
- 扁平化了方法栈的调用深度,数据结构嵌套没有任何性能损失,如List<Set<Map<>>>;对比kryo和protobuf数据结构嵌套会出现性能损失
- 使用Javassist字节码增强动态生成顺序执行的序列化和反序列化函数,顺序化的函数可以轻易的被JIT编译以达到极致的性能
- 其它优点
- 无漏洞注入风险,只有初始化时会进行字节码增强,后期不会再进行任何字节码的操作
```
无漏洞注入风险,只有初始化时会进行字节码增强,后期不会再进行任何字节码的操作
数据压缩体积小,压缩体积比kryo和protobuf都要小;比kryo小是因为kryo需要写入每个对象的注册号
智能语法分析,错误的协议定义将无法启动程序并给出错误警告
提升开发效率,完全支持POJO方式开发,使用非常简单
```
### . 待解决的问题
### . 为什么小
- 为了代码的优雅,zfoo protocol要求全部的协议类都要继承IPacket,但是可以保证不损失性能的情况下支持不继承IPacket的设计,这个有待继续讨论。
- 协议类修改
- 修改字段名称过后无法解析,内部使用字段的名称按照字符串的自然顺序来依次读写的,所以修改名称会导致读写顺序变化导致出现异常
- 减少字段无法解析,没必要一定要删除一个不需要的字段,所以不考虑这种情况
- 增加字段无法解析,可以考虑通过版本号去控制,或者增加新的协议类去解决(组合大于继承,协议类应该对扩展开放,对修改关闭)
- 轻量级实现,核心序列化和反序列化代码一千行左右
- 优化了int和long的zigzag和varint编码的算法,避免了一些多余的方法调用和位操作
- 数据压缩体积小,压缩体积比kryo和protobuf都要小;比kryo小是因为kryo需要写入每个对象的注册号
- 智能语法分析,错误的协议定义将无法启动程序并给出错误警告
- 提升开发效率,完全支持POJO方式开发,使用非常简单
```
设计模式六大原则中的开闭原则是对扩展开放,对修改关闭。协议的设计涉及到功能应该也要遵守这个原则。
目前的序列化过后对象的大小如下:
简单对象,zfoo包体大小8kryo包体大小5protobuf包体大小8
常规对象,zfoo包体大小547kryo包体大小594protobuf包体大小984
复杂对象,zfoo包体大小2214kryo包体大小2525protobuf包体大小5091
如果考虑支持修改协议类字段名称,必须让字段的读写顺序可控,这就需要注解来标识字段的顺序(protostuff就是这样做的),但是感觉这样不优雅。
如果考虑支持字段增加和减少,需要消耗5%左右的性能(预估),并且增加一倍的包体积大小(写入字段的顺序),感觉不是非常划算。
因为可以通过协议版本号来解决这个问题,所以去支持这样的增删操作动力并不是非常的大。
对于服务器来说协议一般有对内和对外的协议,对外protobuf用起来还行,但是服务器的内部调用protobuf用的就少了,用zfoo就可以统一对内和对外的协议。
常规对象,zfoo包体大小430kryo包体大小483protobuf包体大小793
复杂对象,zfoo包体大小2216kryo包体大小2528protobuf包体大小5091
```
### Ⅵ. 协议规范
@@ -88,22 +78,32 @@ cpu i9900k
- 协议类必须是简单的javabean,不能继承任何其它的类,但是可以继承接口
- 默认的数据格式支持,无需用户手动注册,[参考类定义](src/test/java/com/zfoo/protocol/packet/ComplexObject.java)
- booleanbyteshortintlongfloatdoublecharString
- BooleanByteShortIntegerLongFloatDoubleCharacter,序列化的时候如果null,会给个默认值0(Character默认值为Character.MIN_VALUE
- int[]Integer[],如果是null,则解析后的为一个长度为0的数组
- 原生泛型List,Set,Map,反序列化返回类型为HashSetArrayListHashMap,并且空指针安全(返回大小为0的集合)
- List<Integer>,必须指定泛型类,如果发送的是[1,1,null,1],接收到的是[1,1,0,1]
- List<XXXClass>,如果发送的是[obj,obj,null,obj],接收到的是[obj,obj,null,obj],即引用类型序列化之前为null,序列化之后同样为null
- booleanbyteshortintlongfloatdoublecharString
- BooleanByteShortIntegerLongFloatDoubleCharacter,序列化的时候如果null,会给个默认值0(Character默认值为Character.MIN_VALUE
- int[]Integer[],如果是null,则解析后的为一个长度为0的数组
- 原生泛型List,Set,Map,反序列化返回类型为HashSetArrayListHashMap,并且空指针安全(返回大小为0的集合)
- List<Integer>,必须指定泛型类,如果发送的是[1,1,null,1],接收到的是[1,1,0,1]
- List<XXXClass>,如果发送的是[obj,obj,null,obj],接收到的是[obj,obj,null,obj],即引用类型序列化之前为null,序列化之后同样为null
- 不支持的数据格式,因为zfoo会自动识别不支持的类型并且给出错误警告,所以用户不必太关心
- int[][],二维以上数组,考虑到不是所有语言都支持多维数组
- List<Integer>[]Map<Integer, Integer>[]Java语言本身就没有支持泛型类数组
- List<int[]>Map<Integer, Integer[]>,泛型里面套数组,这种写法看起来比较奇怪,实际使用的地方很少
- 枚举类,考虑到很多其他语言不支持枚举类,可以用int或者string在代码层面做替换
- 自定义泛型类XXXClass<T>,泛型类在很多框架中都极易出现性能上和解析上的问题,而且并不是所有语言都支持
- 循环引用,虽然底层支持循环引用,但是考虑到循环引用带来语义上难以理解,容易出现错误,所以就屏蔽了
- int[][],二维以上数组,考虑到不是所有语言都支持多维数组
- List<Integer>[]Map<Integer, Integer>[]Java语言本身就没有支持泛型类数组
- List<int[]>Map<Integer, Integer[]>,泛型里面套数组,这种写法看起来比较奇怪,实际使用的地方很少
- 枚举类,考虑到很多其他语言不支持枚举类,可以用int或者string在代码层面做替换
- 自定义泛型类XXXClass<T>,泛型类在很多框架中都极易出现性能上和解析上的问题,而且并不是所有语言都支持
- 循环引用,虽然底层支持循环引用,但是考虑到循环引用带来语义上难以理解,容易出现错误,所以就屏蔽了
### . 用途
### . 待解决的问题
- 通信协议
- 对象复制,深克隆
- 为了代码的优雅,zfoo protocol要求全部的协议类都要继承IPacket,但是可以保证不损失性能的情况下支持不继承IPacket的设计,这个有待继续讨论。
- 协议类修改
- 修改字段名称过后无法解析,内部默认使用字段的名称按照字符串的自然顺序来依次读写的(也可以自定义),所以修改名称会导致读写顺序变化导致出现异常
- 减少字段无法解析,没必要一定要删除一个不需要的字段,所以不考虑这种情况
- 增加字段,需要加上Compatible,order需要自然增大
```
设计模式六大原则中的开闭原则是对扩展开放,对修改关闭。协议的设计涉及到功能应该也要遵守这个原则,优先增加新的协议而不是修改现有协议。
协议类修改,可以考虑通过版本号去控制,或者增加新的协议类去解决(组合大于继承,协议类应该对扩展开放,对修改关闭)
```
@@ -15,10 +15,8 @@ package com.zfoo.protocol;
import com.esotericsoftware.kryo.Kryo;
import com.esotericsoftware.kryo.io.ByteBufferInput;
import com.esotericsoftware.kryo.io.ByteBufferOutput;
import com.esotericsoftware.kryo.io.Input;
import com.esotericsoftware.kryo.io.Output;
import com.esotericsoftware.kryo.unsafe.UnsafeInput;
import com.esotericsoftware.kryo.unsafe.UnsafeOutput;
import com.google.protobuf.ByteString;
import com.google.protobuf.CodedInputStream;
import com.google.protobuf.CodedOutputStream;
@@ -33,7 +31,6 @@ import io.netty.buffer.UnpooledUnsafeHeapByteBuf;
import org.junit.Ignore;
import org.junit.Test;
import java.nio.ByteBuffer;
import java.util.*;
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.ExecutorService;
@@ -54,8 +51,8 @@ public class SpeedTest {
* <p>
* 包体大小:
* 简单对象,zfoo包体大小8kryo包体大小5protobuf包体大小8
* 常规对象,zfoo包体大小547kryo包体大小594protobuf包体大小984
* 复杂对象,zfoo包体大小2214kryo包体大小2525protobuf包体大小5091
* 常规对象,zfoo包体大小430kryo包体大小483protobuf包体大小793
* 复杂对象,zfoo包体大小2216kryo包体大小2528protobuf包体大小5091
*/
@Ignore
@Test
@@ -140,8 +137,8 @@ public class SpeedTest {
public void kryoTest() {
var kryo = kryos.get();
var output = new Output(1024 * 8);
var input = new Input(output.getBuffer());
var output = new UnsafeOutput(1024 * 8);
var input = new UnsafeInput(output.getBuffer());
// 序列化和反序列化简单对象
long startTime = System.currentTimeMillis();