企业神奇中间件-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 条评论
登录 后参与评论

相关文章

来自专栏互联网研发闲思录

实时监控系统设计

  随着系统业务复杂度的提升,系统复杂度提升,需要对整个系统的功能、性能、可用性,以及服务、 web、webservice、网页等等多个角度进行监控。     ...

6005
来自专栏编程微刊

[慕课笔记] node+mongodb建站攻略

2325
来自专栏喔家ArchiSelf

从连接池到内存池

AI赋能万物,老码农的伙伴们也曾经开发了一个基于图数据库的知识问答系统,在压力测试的时候发现随着并发数的增加,响应的时延明显变长,看时延分布,是应用程序与图数据...

1171
来自专栏FreeBuf

ossec入侵检测日志行为分析

上次说写的ossec连载,不幸因为工作太忙夭折了,最近缓过神来决定补上第2篇,言归正传,ossec的功能主要是为了防御及抓坏人,但因为攻防之间本来就信息不对称所...

42110
来自专栏编程

Python的黑客技能:快速提取Windows密码和Wi-Fi密钥凭证!

LaZagne比较适合黑客和安全管理员,可以在Linux,Windows和MacOS上运行,而且几乎适用于每一个目标。Lazagne是后期开发模块,包含在远程访...

3997
来自专栏优启梦

使用Referer Meta标签控制referer 来源

本文描述了一个关于 http 协议中 referer 的 metadata 参数的提议,使用这个 metadata 参数,html 文档可以控制 http 请求...

2395
来自专栏iOS122-移动混合开发研究院

【树莓派自动化应用实例】整点提醒自己休息五分钟

背景介绍 ? 我有一个习惯,定闹钟每隔60分钟左右,提醒自己休息一次。我发现自己有时候长时间思考,很容易拘泥于细节之中。适当的简单休息过后,往往会对正在解决和处...

2399
来自专栏耕耘实录

实现登录概要监控的BashShell脚本

版权声明:本文为耕耘实录原创文章,各大自媒体平台同步更新。欢迎转载,转载请注明出处,谢谢。

802
来自专栏aoho求索

consul配置与实战

上一篇提到,项目用的分布式服务发现与注册组件是consul,这篇文章主要来讲下consul组件在项目中的应用以及相关介绍。本文以官方文档为主要参考consul文...

6925
来自专栏FreeBuf

当DNS泄漏让VPN不再安全,我们该怎么办?

当你想要匿名上网时,用VPN是最简单的解决方案——你的IP地址,服务提供商和位置都会隐藏起来。但是,DNS泄漏完全可以让藏在VPN之后的你原形毕露。 FreeB...

6977

扫码关注云+社区