成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

企業神奇中間件-RPC(總覽)

企業動態
RPC(Remote Procedure Call),遠程過程調用,從最簡單最抽象的模式來看,就是下面這個圖這樣。客戶端調用某個方法,然后中間經過一系列的過程,調用到服務端的某個方法。服務端進行處理之后,做出相應,然后逐層原路返回到客戶端。

 話說上個系列好像朋友們都表示有點難理解,難道是數學公式太多了?大數據計數原理1+0=1這你都不會算(十) 。希望這次可以寫簡單點,像大蕉這樣的小小白都可以理解那種。上一篇文章我們講到一些關于企業系統間交互,順便開了一下坑。企業神奇中間件-RPC

拷一段過來先,回顧一下。

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 再根據自己路由策略進行第二波路由。嗯,好像穩了。謹記喔,即使沒有注冊中心,上邊這套機制也是可以正常工作的喔,只要能以各種方式發現目標服務的存在。

未完待續。。。

【本文為51CTO專欄作者“大蕉”的原創稿件,轉載請通過作者微信公眾號“一名叫大蕉的程序員”獲取授權】

戳這里,看該作者更多好文

責任編輯:武曉燕 來源: 51CTO專欄
相關推薦

2018-05-02 16:23:24

中間件RPC容器

2018-06-12 15:10:49

RPCRM企業

2009-06-16 15:55:06

JBoss企業中間件

2012-11-01 15:16:22

金蝶中間件研究院院長

2013-07-30 16:29:24

中間件

2011-05-24 15:10:48

2021-02-11 08:21:02

中間件開發CRUD

2010-03-29 10:24:15

金蝶中間件Apusic企業架構

2016-11-11 21:00:46

中間件

2018-02-01 10:19:22

中間件服務器系統

2018-07-29 12:27:30

云中間件云計算API

2012-11-30 10:21:46

移動中間件

2023-06-29 10:10:06

Rocket MQ消息中間件

2023-10-24 07:50:18

消息中間件MQ

2013-08-25 23:57:31

中間件移動中間件選型企業移動信息化

2021-04-22 06:13:41

Express 中間件原理中間件函數

2015-02-07 21:52:45

PaaS中間件

2024-12-09 00:00:15

Gin框架中間件

2009-06-16 10:53:01

JBoss中間件JBoss架構

2020-08-19 08:39:05

中間件前端設計模式
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 9久久婷婷国产综合精品性色 | 日韩色综合 | 国产黄色大片 | 国产激情偷乱视频一区二区三区 | 日韩一区二区三区精品 | 久久久综合精品 | 最新超碰| 天天玩夜夜操 | 无人区国产成人久久三区 | 亚洲视频一区二区三区四区 | 久久高清免费视频 | 日本a在线 | 国产yw851.c免费观看网站 | 中文字幕国产 | 国产精品三级 | 国产精品成人品 | 久久久久久免费毛片精品 | 欧美激情精品久久久久久免费 | 欧美黄在线观看 | 国产精品一区久久久久 | 国产欧美精品 | 欧美日韩久久 | 91精品久久久久久综合五月天 | 91久久国产综合久久 | 伊人激情综合网 | 麻豆精品一区二区三区在线观看 | 精品国产一区二区三区久久 | 日韩精品一区中文字幕 | 成人日b视频 | 国产美女精品 | 中文字幕av一区二区三区 | 欧美一区二区成人 | 日韩一区二区三区视频 | 成人一区在线观看 | 国产欧美一级二级三级在线视频 | 一级毛片网 | 国产一在线观看 | 日韩一级欧美一级 | 久久精品一级 | 久久在线 | 成人精品鲁一区一区二区 |