RPC的相关资料收集/学习

本文最后更新于2018年3月17日,已超过 1 年没有更新,如果文章内容失效,还请反馈给我,谢谢!

=Start=

缘由:

想要系统性的学习一下分布式应用、微服务的基石之一的RPC的相关概念和原理。

正文:

参考解答:
#概念

RPC 的全称是 Remote Procedure Call 是一种进程间通信方式。 它允许程序调用另一个地址空间(通常是共享网络的另一台机器上)的过程或函数,而不用程序员显式编码这个远程调用的细节。即程序员无论是调用本地的还是远程的函数,本质上编写的调用代码基本相同。

#目标

RPC 的主要目标是让构建分布式计算(应用)更容易,在提供强大的远程调用能力时不损失本地调用的语义简洁性。为实现该目标,RPC 框架需提供一种透明调用机制让使用者不必显式的区分本地调用和远程调用。

#分类

RPC 调用分为以下两种:

  1. 同步调用:客户端等待调用执行完成并获取到执行结果。
  2. 异步调用:客户端调用后不用等待执行结果返回,但依然可以通过回调通知等方式获取返回结果。若客户端不关心调用返回结果,则变成单向异步调用,单向调用不用返回结果。

异步和同步的区分在于是否等待服务端执行完成并返回结果。

#组件
  1. RpcServer
    负责导出(export)远程接口
  2. RpcClient
    负责导入(import)远程接口的代理实现
  3. RpcProxy
    远程接口的代理实现
  4. RpcInvoker
    客户端:负责编码调用信息和发送调用请求到服务端并等待调用结果返回
    服务端:负责调用服务端接口的具体实现并返回调用结果
  5. RpcProtocol
    负责协议编/解码
  6. RpcConnector
    负责维持客户端和服务端的连接通道和发送数据到服务端
  7. RpcAcceptor
    负责接收客户端请求并返回请求结果
  8. RpcProcessor`
    负责在服务端控制调用过程,包括管理调用线程池、超时时间等
  9. RpcChannel
    数据传输通道
#一些RPC框架

 

  • 国内
    Dubbo。来自阿里巴巴
    Motan。新浪微博自用
    Dubbox。当当基于 Dubbo 修改的
    rpcx。基于 Golang 的 
  • 国外
    Thrift from facebook
    Avro from hadoop
    Finagle from twitter
    gRPC from Google(Google inside use Stuppy)
    Hessian from cuacho

RPC框架的职责是要向【调用方】和【服务提供方】屏蔽各种复杂性

  • 让调用方感觉就像调用本地函数一样;
  • 让服务提供方感觉就像实现一个本地函数一样来实现服务。
参考链接:

=END=

声明: 除非注明,ixyzero.com文章均为原创,转载请以链接形式标明本文地址,谢谢!
https://ixyzero.com/blog/archives/3827.html

《RPC的相关资料收集/学习》上有21条评论

  1. Linux下进程间通信的六种机制详解
    https://www.cnblogs.com/melons/p/5791796.html

    1.管道(Pipe)及有名管道(named pipe):管道可用于具有亲缘关系进程间的通信,有名管道克服了管道没有名字的限制,因此,除具有管道所具有的功能外,它还允许无亲缘关系进程间的通信;

    2.信号(Signal):信号是比较复杂的通信方式,用于通知接受进程有某种事件生,除了用于进程间通信外,进程还可以发送信号给进程本身;linux除了支持Unix早期信号语义函数sigal外,还支持语义符合Posix.1标准的信号函数sigaction(实际上,该函数是基于BSD的,BSD为了实现可靠信号机制,又能够统一对外接口,sigaction函数重新实现了signal函数);

    3.报文(Message)队列(消息队列):消息队列是消息的链接表,包括Posix消息队列system V消息队列。有足够权限的进程可以向队列中添加消息,被赋予读权限的进程则可以读走队列中的消息。消息队列克服了信号承载信息量少,管道只能承载无格式字节流以及缓冲区大小受限等缺点。

    4.共享内存:使得多个进程可以访问同一块内存空间,是最快的可用IPC形式。是针其他通信机制运行效率较低设计的。往往与其它通信机制,如信号量结合使用, 来达到进程间的同步及互斥。

    5.信号量(semaphore):主要作为进程间以及同一进程不同线程之间的同步手段。

    6.套接字(Socket):更为一般的进程间通信机制,可用于不同机器之间的进程间通信。起初是由Unix系统的BSD分支开发出来的,但现在一般可以移植到其它类Unix 系统上:Linux和System V的变种都支持套接字。

  2. Linux下的进程间通信-详解
    http://blog.csdn.net/eroswang/article/details/1772350

    Linux进程间通信总结
    https://www.cnblogs.com/yangang92/p/5679641.html

    Linux下进程间通信–共享内存:最快的进程间通信方式
    https://www.cnblogs.com/melons/p/5791787.html
    Linux共享内存编程实例
    http://blog.csdn.net/pcliuguangtao/article/details/6526119

    深刻理解Linux进程间通信(IPC)
    https://www.ibm.com/developerworks/cn/linux/l-ipc/

  3. 企业神奇中间件-RPC No.96
    https://mp.weixin.qq.com/s/_PTwXCORi-Gk602sgrVt6w

    在企业的业务发展到一定程度的时候,企业内部的系统总会进行这样或者那样的系统切分。那么这会导致一个什么问题呢?原来直接通过直接本地调用方式的功能,已经无法正常工作了,因为物理上或者逻辑上已经隔离了。切分应用分别部署一般来说有四种方式。
    1、同一主机不同端口。
    2、同一主机跨虚拟机或者跨 Docker 容器。
    3、跨主机同一内网
    4、跨主机跨网络。

    这就使得不论是从逻辑还是从物理上隔离,都使得远程调用尤为重要。现在最常用的就四大类。
    1、SpringCloud系列,以 RESTful API 为首的 HTTP 类交互。
    2、消息队列系列。
    3、WebSocket系列。
    4、RPC系列,远程过程调用。

  4. Apache Thrift学习之一(入门及Java实例演示)
    https://www.cnblogs.com/duanxz/p/5516558.html

    服务端编码基本步骤:
    实现服务处理接口Impl
    创建TProcessor
    创建TServerTransport
    创建TProtocol
    创建TServer
    启动Server

    客户端编码基本步骤:
    创建Transport
    创建TProtocol
    基于TTransport和TProtocol创建 Client
    调用Client的相应方法

    数据传输协议:
    TBinaryProtocol : 二进制格式
    TCompactProtocol : 压缩格式
    TJSONProtocol : JSON格式
    TSimpleJSONProtocol : 提供JSON只写协议,生成的文件很容易通过脚本语言解析

    注意事项:客户端和服务端的协议要一致!!!

    Thrift的网络栈如下所示:

    Server (single threaded, event driven etc)
    |
    Processor (compiler generated) Processor层封装了从输入数据流中读数据和向数据数据流中写数据的操作。读写数据流用Protocol对象表示。
    |
    Protocol (JSON, compact etc) Protocol层定义了一种将内存中数据结构映射成可传输格式的机制。换句话说,Protocol定义了datatype怎样使用底层的Transport对自己进行编解码。因此,Protocol的实现要给出编码机制并负责对数据进行序列化。
    |
    Transport (raw TCP, HTTP etc) Transport层提供了一个简单的网络读写抽象层,这使得thrift底层的transport从系统其它部分(比如:序列化/反序列化)中解耦出来。

    Server将以上所有特性集成在一起:
    (1) 创建一个transport对象
    (2) 为transport对象创建输入输出protocol
    (3) 基于输入输出protocol创建processor
    (4) 等待连接请求并将之交给processor处理

  5. 抓包gRPC的细节及分析
    https://jingwei.link/2018/10/02/grpc-wireshark-analysis.html

    ”抓包gRPC调用并分析具体抓包数据加深对gRPC的理解“

    写在前面
    工具及源码
    抓包细节
      一次gRPC调用总览
      Settings
      Headers
      Data
      再一次的Settings
      Window_update, Ping
      ping(pong)
      headers,data,headers
      window_update,ping
      再一次ping(pong)
    gRPC中的context数据
    小结
    参考

  6. RPC负载均衡策略学习
    http://blog.soliloquize.org/2019/10/01/RPC%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1%E7%AD%96%E7%95%A5%E5%AD%A6%E4%B9%A0/

    负载均衡策略对于RPC的请求吞吐来说影响重大,因此尝试了解了一下一些开源PRC框架中的负载均衡策略。

    简单看了三个项目的实现:dubbo、sofa-rpc、brpc-java。首先还是直接清单展示对比一下三个项目中的负载均衡策略,随后再来分析下每种策略的实现。

    Random - 随机
    RoundRobin - 轮询
    ConsistentHash - 一致性哈希
    LeastActive - 最小活跃连接策略。每一次分发请求时,选择当前活跃连接数最小的节点进行随机加权分配。
    Weight - 基于权重进行分配,但权重值的计算可以有多种方式。

    现实中可能基于最小活跃连接去改造会更为方便,拿到更好结果。不过上述三个框架中的策略基本都只是客户端维度上的处理,基于最简单的统计维度。实际项目中的情况可能更为复杂,例如服务端业务逻辑进行了限流快速熔断等处理,这种适合节点处理请求快延迟小并不代表节点更优。这种场景下,单纯的客户端维度统计可能并不足够,或许是要更细的去识别请求结果内容来进行判定。

发表评论

电子邮件地址不会被公开。 必填项已用*标注