在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
开源软件名称:QSRPC-starter开源软件地址:https://gitee.com/sakaue/QSRPC-starter开源软件介绍:一个基于QSRPC, 结合 spring-boot 实现远程调用的轻量级高性能RPC框架
Maven<dependency> <groupId>com.github.tohodog</groupId> <artifactId>qsrpc-starter</artifactId> <version>1.1.1</version></dependency><!--导入如有问题,可尝试添加jitpack源--><repositories> <repository> <id>jitpack.io</id> <url>https://jitpack.io</url> </repository></repositories> Demo(4step)First configurednacos/zookeeper 1.application.properties(yml)#nacos qsrpc.nacos.addr=192.168.0.100:8848#zookeeper #qsrpc.zk.ips=127.0.0.1:2181#节点IPqsrpc.node.ip=192.168.0.100 (请配置为内(外)网IP,不配置自动获取)qsrpc.node.port=19980#option#请求权重(1-127) 默认平均1#qsrpc.node.weight=1#压缩,带宽不足可选#qsrpc.node.zip=snappy/gzip#全局请求超时时间#qsrpc.connect.timeout=60000 2.SpringBootApplication@EnableQSRpc//add this//@EnableQSRpc(qps = 100000) 限制整个服务qps@SpringBootApplicationpublic class RPCApplication { public static void main(String[] args) { SpringApplication.run(RPCApplication.class, args); }} 3.public apipublic interface IRPCServer { String hello(String name); RPCFuture<String> future(String name);//异步} 4.1 server@QSRpcService//@QSRpcService(value = "2.0", qps = 1f) 设置版本号及该服务qpspublic class RPCServer implements IRPCServer { @Override public String hello(String name) { return "hello:" + name; } @Override public RPCFuture<String> future(String name) { return RPCFuture.Ok(name); //服务端如需异步处理,可创建RPCFuture rpc=new RPCFuture(); //先行返回rpc,后续异步调用rpc.handleResult(t)返回结果 }} 4.2 client@QSRpcReference//@QSRpcReference(version = "2.0",timeout = 10000) 配置版本号及超时IRPCServer rpcServer;//同步调用@ResponseBody@GetMapping("/hello")public String hello() { return rpcServer.hello("QSPRC");}//异步调用@GetMapping("/future")public String future() { RPCFuture<String> future = rpcServer.future("QSPRC"); future.setCallback(new Callback<String>() { @Override public void handleResult(String result) { System.out.println("result:" + result); } @Override public void handleError(Throwable error) { System.err.println("error:" + error); } }); return "ok";} Future
Test4-core自发自收的情况下2.3万/秒的并发数,实际会更高 Test截图 截图2
QSRPC项目技术选型及简介1.TCP通信1.1 连接模式:本项目tcp通信使用长连接+全双工通信(两边可以同时收/发消息),可以保证更大的吞吐量/更少的连接数资源占用,理论上使用一个tcp连接即可满足通信(详见pool),如果使用http/1.1协议的请求-响应模式,同一个连接在同一个时刻只能有一个消息进行传输,如果有大量请求将会阻塞或者需要开更多tcp连接来解决 1.2 协议:
首先,使用长连接那就需要解决tcp粘包问题,常见的两种方式:
综上,本框架使用的是包头长度+特定包尾,结合了两者优点,避免了缺点,高效实用,检测到包错误会自动断开.没有使用校检码转码等,因为需要考虑实际情况,内网里出错概率非常低,出错了也能重连,对于RPC框架追求性能来说是合适的,即使是外网,后续有需求可以增加校验加密协议 其次,因为支持全双工那就需要解决消息回调问题,本协议使用了一个消息ID,由客户端生成,服务端返回消息带上;由于发送和接收是非连续的,所以客户端需要维护一个回调池,以ID为key,value为此次请求的context(callback),因为是异步的,请求有可能没有响应,所以池需要有超时机制 1.3 压缩/加密: 当出现带宽不足而CPU性能有余时,压缩就派上用场了,用时间换空间。目前支持了snappy/gzip两种压缩,snappy应用于google的rpc上,具有高速压缩速度和合理的压缩率,gzip速度次于snappy,但压缩率较高,根据实际情况配置,前提必须是带宽出现瓶颈/要求,否则不需要开启压缩 1.4 IO框架:网络IO目前是基于netty搭建的,支持nio,zero-copy等特性,由于本框架连接模式使用长连接,连接数固定且较少,所以本框架性能对于IO模式(BIO/NIO/AIO)并不是很敏感,netty对于http,iot服务这种有大量连接数的优势就很大了 2. Tcp pool 前面说了一个tcp连接即可支撑通信,为啥又用pool了呢,原因有两个:1. netty工作线程对于同一个连接使用同一个线程来处理的,所以如果客户端发送大量请求时,服务端只有一个线程在处理导致性能问题,起初是想服务端再把消息分发到线程池,但后续测试发现此操作在高并发下会导致延迟增大,因为又把消息放回线程池排队了。2. 相对于一条tcp链接,使用pool会更加灵活,且连接数也很少,并没有性能影响; 本框架还基于pool实现了一个[请求-响应]的通信模式* 3. 服务注册发现 分布式系统中都需要一个配置/服务中心,才能进行统一管理.本框架目前使用zookeeper(已支持nacos)进行服务注册,zookeeper是使用类似文件目录的结构,每个目录都可以存一个data Logv1.1.1(2021-11-25)
v1.0.3(2021-04-16)
v1.0.2(2020-11-26)
v1.0.1(2020-11-23)
v0.1.0(2020-11-16)
Other |
2022-08-15
2022-08-17
2022-09-23
2023-10-27
2022-08-18
请发表评论