企业神奇中间件-RPC(总览) No.97

话说上个系列好像朋友们都表示有点难理解,难道是数学公式太多了?大数据计数原理1+0=1这你都不会算(十)No.77 。希望这次可以写简单点,像大蕉这样的小小白都可以理解那种。上一篇文章我们讲到一些关于企业系统间交互,顺便开了一下坑。企业神奇中间件-RPC No.96

拷一段过来先,回顾一下。

RPC(Remote Procedure Call),远程过程调用,从最简单最抽象的模式来看,就是下面这个图这样。客户端调用某个方法,然后中间经过一系列的过程,调用到服务端的某个方法。服务端进行处理之后,做出相应,然后逐层原路返回到客户端。

是不是很简单,一般来说,开发者只需要关注蓝色( functions )部分,而至于红色部分( stub句柄 ) 和黄色部分(socket 网络)部分呢,框架层面会把它解决掉。蓝色部分,服务端开发者要做的事情就是定义某个接口,客户端开发者要做的事情就是调用某个接口,一切开发模式都跟本地调用无差别。

RPC 在企业内部有三个非常非常重要的作用。

1、抛弃厚重的 HTTP 头,减少网络带宽消耗。

2、默认使用信任的 TCP 长连接,减少各种身份确认以及网络握手消耗。

3、面向开发者友好,开发者可以跟开发本地程序一样调用别人的服务。


HTTP请求交互:

一次 HTTP 请求

客户端:你准备好我要发送了啊。

服务端:好吧你发送吧。

客户端:你真的准备好我真的要发送了啊。

客户端:发送请求。

服务端:响应请求。

客户端:你准备好我要关闭了啊。

服务端:好吧你关闭吧。

服务端:我关闭连接了。

客户端:好的我知道你关闭了。

ps:

HTTP 1.0 默认不打开长连接,客户端想持有长连接要加上"Connection:keep-alive"的 header。

HTTP 1.1 默认打开长连接,服务端返回报文有 "Connection:keep-alive" 表示是一个长连接。

HTTP 2.0 默认打开长连接支持多路复用,即在一个连接中可发起多次请求和响应。


RPC交互过程:

客户端:你准备好我要发送了啊。

服务端:好吧你发送吧。

客户端:你真的准备好我真的要发送了啊。

客户端:发送请求。

服务端:响应请求。

客户端:发送请求。

服务端:响应请求。

客户端:发送请求。

服务端:响应请求。

连接永远不会有连接关闭的一天,除非目标机器挂了通道崩了之类的。


连接的打开和关闭是一个成本,虽然 HTTP 已经支持了长连接,但是抛去这些不讲,繁重的 HTTP 头也是会把网络搞崩。HTTP 全名 HyperText Transfer Protocol - 超文本传输协议,顾名思义,这个应该是用来完成一些请求很少但是响应文本比较多的协议,而对于高效率高并发的企业级应用来说,还是需要使用一些私有化的协议来进行系统间的交互,以减少一大堆在这个场景没有用处的头信息浪费带宽。

好目光继续回到 RPC 本身,先来讲讲现在各种 RPC 框架的套路。根据我的观察,现在各种 RPC 框架无论支持多少协议,无论是用什么语言实现的,一般都离不开下面这种套路。先明确一个观念,在 RPC 中我们把调用方叫 Consumer 消费者,服务端叫 Provider 生产者。

套路是这样的。

关于 RPC 的调用路径

1、Consumer 调用代理 Proxy,无论是主动调用还是被动调用,都是调用。

2、对请求进行序列化 Serializer。

3、序列化完再转成二进制,交给 Socket 或者 其他网络 IO 层。

4、将二进制写入 Channal 通道中。

5、Channal 直接飞到 服务端。

6、服务端 Socket 读取 Channal 获得二进制体。

7、对请求进行 Deserializer 反序列化,还原原始请求。

8、然后将请求交给服务端的代理 Proxy。

9、代理调用到真正的 Provider 。

10、Provider 对请求做出相应。

然后再依次 9.8.7.6.5.4.3.2.1 原路返回。

综上所述,所以完整的是交互这样的,蓝色是请求,红色是响应。

关于注册中心

当然,类似 Dubbo 这类框架呢,还会提供一小部分服务治理的能力,比如搞一个注册中心,Provider 在启动的时候向注册中心暴露自己的ip和端口和各种服务的地址。然后 Consumer 在调用的时候,先问一下 Register 注册中心有哪些机器是我能调用的,这个时候会有一层路由策略或者 HA 的策略。获取到地址列表之后呢,Consumer 再根据自己路由策略进行第二波路由。嗯,好像稳了。谨记喔,即使没有注册中心,上边这套机制也是可以正常工作的喔,只要能以各种方式发现目标服务的存在。

未完待续。。。

五一快乐突然不想写了,就先写到这吧,吃饭去了再见。

原文发布于微信公众号 - 一名叫大蕉的程序员(DaBananaTalk)

原文发表时间:2018-05-01

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏程序猿DD

使用Spring StateMachine框架实现状态机

Spring StateMachine框架可能对于大部分使用Spring的开发者来说还比较生僻,该框架目前差不多也才刚满一岁多。它的主要功能是帮助开发者简化状态...

3749
来自专栏Timhbw博客

iOS学习巩固笔记-Socket

2016-05-0922:18:41 发表评论 665℃热度 下面是一些个人学习笔记,查缺补漏,巩固知识,希望大家能有所收获。 ? Socket又称"套接字”...

2608
来自专栏Python中文社区

使用python实现RESTful API服务器端的思路

最近这些年,REST已经成为web services和APIs的标准架构,很多APP的架构基本上是使用RESTful的形式了。 REST的六个特性 Client...

3848
来自专栏大内老A

使命必达: 深入剖析WCF的可靠会话[共8篇]

作为一个通信基础平台,WCF必须保证通信的可靠性。由于消息交换是WCF采用的通信手段,通信可靠性的保障体现在确保消息的可靠传输。WCF本质上是一个消息处理框架,...

1775
来自专栏猿天地

房价网是怎么使用分布式作业框架elastic-job

Elastic-Job是一个分布式调度解决方案,由两个相互独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成。

1072
来自专栏最高权限比特流

HTTP协议(三):状态码

1453
来自专栏WeTest质量开放平台团队的专栏

HTTP/2之服务器推送(Server Push)最佳实践

商业转载请联系腾讯WeTest获得授权,非商业转载请注明出处。

3780
来自专栏CSDN技术头条

NoSQL数据库的主主备份

Tarantool DBMS的高性能应该很多人都听说过,包括其丰富的工具套件和某些特定功能。比如,它拥有一个非常强大的on-disk存储引擎Vinyl,并且知道...

19210
来自专栏肖洒的博客

SSM简单介绍

SSM:Struts、Spring、Mybatis SSM三层集成框架系统总体设计:模块划分、数据库表,存储过程

743
来自专栏土豆专栏

计算机网络基础知识整理--运输层

从IP层来说,通信的两端是两个主机。IP数据报的首部明确地标志了这两个主机的IP地址。我们需要知道,真正进行通信的实体是在主机中的进程,是这个主机中的一个进程和...

60912

扫码关注云+社区