❝

笔者在开发基于客户端/服务端模式通信的插件的时候，需要用到轻量级最小包依赖的RPC框架，而市面上的RPC框架份量过于庞大，最终打包下来都是几十兆甚至上百兆，而这里面大多数功能我都用不上，于是思来想去我决定写一款属于自己的轻量级RPC框架，简单易用快速接入。

关于技术选型

协议序列化/反序列化

网络通信基于TCP/IP为基础自定义应用层协议，常见的序列化/反序列化工具有java原生序列化，json,kryo,protobuf,fst,hessian等。

在不考虑跨语言的情况下，从序列化时长/序列化大小/易用性/扩展性这几方面考虑，综合性比较强的是kryo，但是kryo只支持java版本不能跨语言(据说能跨语言但是非常复杂，相当于不能跨语言了)，protobuf是性能最强的且支持跨语言，但是需要事先基于proto生成一个类，这会导致所有序列化和反序列化的时候只能用proto定义的类型。

最终选择kryo和protobuf两种序列化工具，使用的时候可选序列化类型，前者序列化几乎不受限制，后者支持跨语言，但是必须事先生成proto类型的类并使用其作为序列化工具。

通信框架使用

高性能异步非阻塞框架非Netty不可了，客户端和服务端基于Netty开发可事半功倍。

但是Netty打包完都需要20M左右，所以除了client和server端外，再开发一个client-mini模块，这个模块是client端基于nio开发的，性能虽然不如netty但是没有任何依赖，打包下来仅20kb。

服务注册和发现

注册中心选择zookeeper作为服务注册和服务发现，当然如果只用单点模式的话其实是不需要注册中心的，所以zookeeper是可选组件。

开发RPC框架

好了，有了上述这些技术就可以步入RPC框架的开发了，我这里分为了以下模块：

• base : 基础公共模块
• protocol : 协议层，包含应用层通信协议，以及序列化/反序列化，支持kryo和protobuf
• registry : 注册模块，基于zookeeper作为注册中心，包含注册服务和服务发现
• server : 服务端
• client : 客户端
• client-mini : 不依赖任何包的客户端，基于NIO

应用层协议

首先设计通信协议层，一个rpc框架通信的每一次请求主要包含服务名(serviceName)，函数名(methodName)，参数类型(paramTypes)和参数(params)等字段，当然再加上请求唯一id: traceId

ClientConfigconfig=newClientConfig();config.setSerializer(SerializerStrategy.KRYO.name());ModulePool.getModule(ClientModule.class).init(config);StringZK_URL="localhost:2181";ShadowClientGroupshadowClientGroup=newShadowClientGroup(ZK_URL);shadowClientGroup.init();IHellohelloService=shadowClientGroup.createRemoteProxy(IHello.class,"shadowrpc://DefaultGroup/helloservice");List<ShadowClient>shadowClientList=shadowClientGroup.getShadowClients("DefaultGroup");System.out.println("所有服务器:"+shadowClientList.stream().map(c->c.getRemoteIp()+":"+c.getRemotePort()).collect(Collectors.toList()));for(inti=0;i<shadowClientList.size()*5;i++){Stringhello=helloService.hello(i+"");System.out.println(hello);}

性能测试

目前Mac笔记本16G 4核测试的rpc调用hello逻辑，如果使用kryo序列化/反序列化，100w个请求耗时27秒，平均QPS为3.7w，如果使用protobuf序列化/反序列化耗时25秒, 平均QPS为4w，如果用M1芯片的Mac，平均QPS可以达到7W+，最高QPS可以达到10w+。

源码

篇幅有限，介绍的时候不够完整，有些遗漏，如需完成源码，可加我微信免费获取。目前仅供学习交流使用。