你应该知道的 RPC 原理

在校期间大家都写过不少程序,比如写个hello world服务类,然后本地调用下,如下所示。这些程序的特点是服务消费方和服务提供方是本地调用关系。

而一旦踏入公司尤其是大型互联网公司就会发现,公司的系统都由成千上万大大小小的服务组成,各服务部署在不同的机器上,由不同的团队负责。这时就会遇到两个问题:1)要搭建一个新服务,免不了需要依赖他人的服务,而现在他人的服务都在远端,怎么调用?2)其它团队要使用我们的服务,我们的服务该怎么发布以便他人调用?下文我们将对这两个问题展开探讨。

1 如何调用他人的远程服务?

由于各服务部署在不同机器,服务间的调用免不了网络通信过程,服务消费方每调用一个服务都要写一坨网络通信相关的代码,不仅复杂而且极易出错。

如果有一种方式能让我们像调用本地服务一样调用远程服务,而让调用者对网络通信这些细节透明,那么将大大提高生产力,比如服务消费方在执行helloWorldService.sayHello(“test”)时,实质上调用的是远端的服务。这种方式其实就是RPC(Remote Procedure Call Protocol),在各大互联网公司中被广泛使用,如阿里巴巴的hsf、dubbo(开源)、Facebook的thrift(开源)、Google grpc(开源)、Twitter的finagle等。

要让网络通信细节对使用者透明,我们自然需要对通信细节进行封装,我们先看下一个RPC调用的流程:

  • 1)服务消费方(client)调用以本地调用方式调用服务;
  • 2)client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体;
  • 3)client stub找到服务地址,并将消息发送到服务端;
  • 4)server stub收到消息后进行解码;
  • 5)server stub根据解码结果调用本地的服务;
  • 6)本地服务执行并将结果返回给server stub;
  • 7)server stub将返回结果打包成消息并发送至消费方;
  • 8)client stub接收到消息,并进行解码;
  • 9)服务消费方得到最终结果。

RPC的目标就是要2~8这些步骤都封装起来,让用户对这些细节透明。

1.1 怎么做到透明化远程服务调用?

怎么封装通信细节才能让用户像以本地调用方式调用远程服务呢?对java来说就是使用代理!java代理有两种方式:1) jdk 动态代理;2)字节码生成。尽管字节码生成方式实现的代理更为强大和高效,但代码不易维护,大部分公司实现RPC框架时还是选择动态代理方式。

下面简单介绍下动态代理怎么实现我们的需求。我们需要实现RPCProxyClient代理类,代理类的invoke方法中封装了与远端服务通信的细节,消费方首先从RPCProxyClient获得服务提供方的接口,当执行helloWorldService.sayHello(“test”)方法时就会调用invoke方法。

1.2  怎么对消息进行编码和解码?

1.2.1 确定消息数据结构

上节讲了invoke里需要封装通信细节,而通信的第一步就是要确定客户端和服务端相互通信的消息结构。客户端的请求消息结构一般需要包括以下内容:

1)接口名称

在我们的例子里接口名是“HelloWorldService”,如果不传,服务端就不知道调用哪个接口了;

2)方法名

一个接口内可能有很多方法,如果不传方法名服务端也就不知道调用哪个方法;

3)参数类型&参数值

参数类型有很多,比如有bool、int、long、double、string、map、list,甚至如struct(class);

以及相应的参数值;

4)超时时间

5)requestID,标识唯一请求id,在下面一节会详细描述requestID的用处。

同理服务端返回的消息结构一般包括以下内容。

1)返回值

2)状态code

3)requestID

1.2.2 序列化

一旦确定了消息的数据结构后,下一步就是要考虑序列化与反序列化了。

什么是序列化?序列化就是将数据结构或对象转换成二进制串的过程,也就是编码的过程。

什么是反序列化?将在序列化过程中所生成的二进制串转换成数据结构或者对象的过程。

为什么需要序列化?转换为二进制串后才好进行网络传输嘛!为什么需要反序列化?将二进制转换为对象才好进行后续处理!

现如今序列化的方案越来越多,每种序列化方案都有优点和缺点,它们在设计之初有自己独特的应用场景,那到底选择哪种呢?从RPC的角度上看,主要看三点:1)通用性,比如是否能支持Map等复杂的数据结构;2)性能,包括时间复杂度和空间复杂度,由于RPC框架将会被公司几乎所有服务使用,如果序列化上能节约一点时间,对整个公司的收益都将非常可观,同理如果序列化上能节约一点内存,网络带宽也能省下不少;3)可扩展性,对互联网公司而言,业务变化快,如果序列化协议具有良好的可扩展性,支持自动增加新的业务字段,删除老的字段,而不影响老的服务,这将大大提供系统的健壮性。

目前国内各大互联网公司广泛使用hessian、protobuf、thrift、avro等成熟的序列化解决方案来搭建RPC框架,这些都是久经考验的解决方案。

1.3  通信

消息数据结构被序列化为二进制串后,下一步就要进行网络通信了。目前有两种IO通信模型:1)BIO;2)NIO。一般RPC框架需要支持这两种IO模型,原理可参考:《一个故事讲清楚 NIO》

如何实现RPC的IO通信框架?1)使用java nio方式自研,这种方式较为复杂,而且很有可能出现隐藏bug,见过一些互联网公司使用这种方式;2)基于mina,mina在早几年比较火热,不过这些年版本更新缓慢;3)基于netty,现在很多RPC框架都直接基于netty这一IO通信框架,比如阿里巴巴的HSF、dubbo,Twitter的finagle等。

1.4  消息里为什么要带有requestID?

如果使用netty的话,一般会用channel.writeAndFlush()方法来发送消息二进制串,这个方法调用后对于整个远程调用(从发出请求到接收到结果)来说是一个异步的,即对于当前线程来说,将请求发送出来后,线程就可以往后执行了,至于服务端的结果,是服务端处理完成后,再以消息的形式发送给客户端的。于是这里出现以下两个问题:

1)怎么让当前线程“暂停”,等结果回来后,再向后执行?

2)如果有多个线程同时进行远程方法调用,这时建立在client server之间的socket连接上会有很多双方发送的消息传递,前后顺序也可能是随机的,server处理完结果后,将结果消息发送给client,client收到很多消息,怎么知道哪个消息结果是原先哪个线程调用的?

如下图所示,线程A和线程B同时向client socket发送请求requestA和requestB,socket先后将requestB和requestA发送至server,而server可能将responseA先返回,尽管requestA请求到达时间更晚。我们需要一种机制保证responseA丢给ThreadA,responseB丢给ThreadB。

怎么解决呢?

1)client线程每次通过socket调用一次远程接口前,生成一个唯一的ID,即requestID(requestID必需保证在一个Socket连接里面是唯一的),一般常常使用AtomicLong从0开始累计数字生成唯一ID;

2)将处理结果的回调对象callback,存放到全局ConcurrentHashMap里面put(requestID, callback);

3)当线程调用channel.writeAndFlush()发送消息后,紧接着执行callback的get()方法试图获取远程返回的结果。在get()内部,则使用synchronized获取回调对象callback的锁,再先检测是否已经获取到结果,如果没有,然后调用callback的wait()方法,释放callback上的锁,让当前线程处于等待状态。

4)服务端接收到请求并处理后,将response结果(此结果中包含了前面的requestID)发送给客户端,客户端socket连接上专门监听消息的线程收到消息,分析结果,取到requestID,再从前面的ConcurrentHashMap里面get(requestID),从而找到callback对象,再用synchronized获取callback上的锁,将方法调用结果设置到callback对象里,再调用callback.notifyAll()唤醒前面处于等待状态的线程。

2 如何发布自己的服务?

如何让别人使用我们的服务呢?有同学说很简单嘛,告诉使用者服务的IP以及端口就可以了啊。确实是这样,这里问题的关键在于是自动告知还是人肉告知。

人肉告知的方式:如果你发现你的服务一台机器不够,要再添加一台,这个时候就要告诉调用者我现在有两个ip了,你们要轮询调用来实现负载均衡;调用者咬咬牙改了,结果某天一台机器挂了,调用者发现服务有一半不可用,他又只能手动修改代码来删除挂掉那台机器的ip。现实生产环境当然不会使用人肉方式。

有没有一种方法能实现自动告知,即机器的增添、剔除对调用方透明,调用者不再需要写死服务提供方地址?当然可以,现如今zookeeper被广泛用于实现服务自动注册与发现功能!

简单来讲,zookeeper可以充当一个服务注册表(Service Registry),让多个服务提供者形成一个集群,让服务消费者通过服务注册表获取具体的服务访问地址(ip+端口)去访问具体的服务提供者。如下图所示:

具体来说,zookeeper就是个分布式文件系统,每当一个服务提供者部署后都要将自己的服务注册到zookeeper的某一路径上: /{service}/{version}/{ip:port}, 比如我们的HelloWorldService部署到两台机器,那么zookeeper上就会创建两条目录:分别为/HelloWorldService/1.0.0/100.19.20.01:16888  /HelloWorldService/1.0.0/100.19.20.02:16888。

zookeeper提供了“心跳检测”功能,它会定时向各个服务提供者发送一个请求(实际上建立的是一个 socket 长连接),如果长期没有响应,服务中心就认为该服务提供者已经“挂了”,并将其剔除,比如100.19.20.02这台机器如果宕机了,那么zookeeper上的路径就会只剩/HelloWorldService/1.0.0/100.19.20.01:16888。

服务消费者会去监听相应路径(/HelloWorldService/1.0.0),一旦路径上的数据有任务变化(增加或减少),zookeeper都会通知服务消费方服务提供者地址列表已经发生改变,从而进行更新。

更为重要的是zookeeper 与生俱来的容错容灾能力(比如leader选举),可以确保服务注册表的高可用性。

3 小结

RPC几乎是每一个从学校进入互联网公司的同学都要首先学习的框架,之前面试过一个在大型互联网公司工作过两年的同学,对RPC还是停留在使用层面,这是不应该的。本文也仅是对RPC的一个比较粗糙的描述,希望对大家有所帮助,错误之处也请指出修正。

4 一些开源的RPC框架

https://github.com/alibaba/dubbo

http://thrift.apache.org/?cm_mc_uid=87762817217214314008006&cm_mc_sid_50200000=1444181090

打赏支持我写出更多好文章,谢谢!

打赏作者

打赏支持我写出更多好文章,谢谢!

7 71 收藏 24 评论

关于作者:占利军

阿里巴巴RDC长期招聘资深Java研发工程师&技术专家,有意者私信联系!一个专注于后端架构、算法的工程师 个人经历: 2015 至今 阿里巴巴; 2013-2015 美团; 2010-2013 中科院(硕士); 2006-2010 浙大(本科) 个人主页 · 我的文章 · 37 ·  

相关文章

可能感兴趣的话题



直接登录
最新评论
  • 吴煜 程序员 2015/10/06

    对zookeeper 技术不是太了解,不过心跳检测是一般检测是否断线的通用技术,服务器与服务器之间,客户端与客户端之间网络连接都是基于定期发送心跳包看是否收到回包进行判断是否连接

  • 泰乐橙   2015/10/06

    原理大致讲明白了,但是代码较少, 特别是通信那块,序列化和反序列化, 楼主能提供详细的带么?这样感觉还是太虚了,效果大打折扣, 毕竟程序员是拿代码说话的。

    • 占利军 研发 2015/10/07

      原理知道是很好的第一步,如果你想看源码,那推荐看dubbo或者thrift等开源的rpc框架,那里非常详细

  • feige1990   2015/10/07

    有没有github啥的 代码分享下呀

  • 占利军 研发 2015/10/07

    添加上dubbo、thrift相关源码链接,有兴趣的同学可以好好深入研究下

    • qualibaba   2015/10/07

      看dubbo的同学,不建议看他那个文档,简单的东西搞的很复杂,显得很NB似得...纯粹是为了增加理解的复杂度,直接看代码

      • 占利军 研发 2015/10/07

        哈哈,如果能直接看源码是最好的啦,RPC本质上的东西挺简单的,但是作为服务治理的框架,里面辅助性质的东西不少。现在有不少互联网公司都在直接使用dubbo,毕竟服务治理等做得还是不错的

  • dubbo 很久没有提交代码了,大家都是在默默地使用啊。Thrift 的序列化部分不能单独使用,所以和 Protobuf 并列当做序列化技术不合适。服务发布之后还涉及到服务查找和路由,可以通过服务地址直接调用,但如果服务很多,对于服务注册中心的压力比较大。另一种服务查找和路由的方式是使用 HAProxy 之类的负载均衡,是一种中心式的服务路由

    • 占利军 研发 2015/10/07

      1 虽然Thrift没有透出序列化与反序列化接口,但不妨碍单独拿出来用,都是开源的,有互联网公司就用thrift来做序列化但通信走的是http;
      2 用zookeeper做服务注册中心挺好的,本身就是分布式部署的,可以避免单点,而且每次请求一般走的是客户端缓存地址,只有发布等服务地址变化的时候压力会大些,所以一般不会有特别多的压力。

      • 我还没有遇到问题,没实践所以只说一些看法。因为 Zookeeper 是 CP 的,所以从 CAP 的角度看不是最适合做 Service Registry。因为对于 Service Registry 来说,AP 更合适。https://tech.knewton.com/blog/2014/12/eureka-shouldnt-use-zookeeper-service-discovery/ 这篇文章详细解释了这个问题。当然小规模的 ZK 还是没问题,但是有不少公司在服务注册方面用自己的技术而非 Zookeeper,我想主要就是出于 Zookeeper 不是很适合这个场景。不知道阿里巴巴在实际应用中也是自己实现的服务注册功能,而非使用 Zookeeper

        • 占利军 研发 2015/10/07

          嗯,阿里做得早,当时还没有zk可参考使用,所以自己实现了configserver。国外airbnb,国内美团等Java技术的互联网公司在用zk做注册,服务规模也很大了

          • 我发的链接里也有很多评论,关于如何解决文章里提到的问题。条条大路通罗马。这个话题算是具体实践的问题了,所以就不继续了 ^_^

  • 我是宅男小何   2015/10/21

    我的理解,其实一个http接口服务,也是一种rpc,对吗

    • 占利军 研发 2015/10/22

      可以这么理解,本质都是进行一次远程过程调用,只不过RPC更强调透明调用

      • 我是宅男小何   2015/10/30

        en,公司内部做一套中转的rpc系统,不知道有这个必要没,这样可以统一管理对接的模块,以及每一次rpc调用的耗时,异常等的监控,但是缺点就是每次的rpc会进行两次的网络传输。

  • 想问下,如果使用DUBBO服务式治理框架,可以满足100w用户访问量,10w用户同时在线访问的业务场景吗?

  • 你好  我一直对一些概念很模糊   你这篇文章讲的是服务间的调用,我知道的有httpclient、webservise、mq   你今天又提到了RPC  。 httpclient、webservise、mq、RPC 都把我搞混了,他们的区别以及在系统中的位置以及作用是什么呢??

  • liangck 三流程序猿 2016/09/23

    通俗易懂,娓娓道来,给大神赞一个!

  • 眼瞎   2016/12/28

    大哥,上面1.1小节的那段代码是不是缺了点儿东西啊?运行不通啊,类型转换异常。

  • 肖绪达 java开发 08/26

    讲的很透彻,领教了,多谢!

  • 老师你好,我对服务端是怎么找到客户端请求的服务还有些疑问,我目前用的wcf是要求给出契约和方法名,服务端要怎么找到接口的具体实现类呢?还有是不是要有个命名空间区分

  • zwjtech 软件工程师 09/21

    很好很仔细

  • 指尖上的榴莲   10/07

    1.1节

    getProxy方法的参数应该是HelloWorldService对象吧

跳到底部
返回顶部