如何设计一个RPC框架

在大型项目中,系统间经常需要交互,一般就同步与异步两种,同步的话一般被称为RPC调用,网上有关RPC的开源框架有很多,当然也有很多公司没有使用网上的开源框架,而是公司自研。

设计

因为RPC用途广泛,明白其原理很重要,最好是自己实现一个简单的,结合我平时使用RPC的经验,来说说设计RPC的时候需要考虑的点。

服务注册与发现

系统很多的话,不可能让每个系统都知道其他系统的地址,服务啊什么的,肯定要找一个便捷的方式能够发现其他的服务。一般服务都会有自己的名字,这点和域名很像,纯碎记忆IP地址很难,人们队字符比较敏感,所以字符更容易记忆一些。

系统A如果想要调用B的话,肯定要知道B的地址,在系统很少的时候,我们还可以手工配置,但是想想系统成千上万的时候,手工将会非常的麻烦。

image-20190408194213902
  1. 系统增多,需要有专门的服务中心来管理所有的服务信息,现在系统A想要调用B的时候,首次会先去服务注册中心拿服务信息,然后再调用B
image-20190408194534084

注册中心只需要能存储服务信息即可,并且一定要保证高可用,不要服务中心挂掉了,所有的服务都用不了,常用的软件:

  • Zookeeper
  • Etcd
  • Consul
  • Nacos

像Zookeeper只提供存储,具体的如何发现,如何注册,还需要编码实现。服务注册与发现是RPC框架中一个很基础的部分,首先我们应该想到的就是它。

一般服务名称为:

  • 项目名.模块名.功能名.版本号

服务入口

在Java中,远程调用,我们不可能把每个服务接口都暴露在外面,而是一个入口接受参数,再由这个入口分发到系统内部的某个服务,调用后返回结果。

image-20190408195320439

序列化

因为涉及到网络传输,序列化反序列化也是必不可少的,组件,一般常用的序列化工具有

  • grpc
  • hession
  • java自带的序列化
  • json/xml

扩展点

一般服务器在部署的时候都是集群部署的,在发现服务的时候可能有多台机器,这个时候需要特定的负载均衡算法选择具体的服务器。常见的负载均衡算法

  • 轮询
  • 随机
  • 权重
  • 最少连接
  • ip_hash

也有可能在调用服务的时候发现某些服务不可用,那么要能保证自动的重试,可配置重试次数。在经过多次尝试之后,达到了最大的尝试次数还是不行,那么可进行服务降级,熔断处理。

最后

原本以为自己想的挺多的,梳理一下,发现暂时就这样了,如果等后面我看完了某个流行的开源RPC框架源码,再去设计这个框架,想必会比现在更详细

推荐阅读更多精彩内容