目錄
第1章 遠端過程/函數調用RPC概述
1.1 什麼是程式設計語言原生的函數調用
1.2 IPC:(Inter Process Communication )跨程序通信
1.4 什麼是本地過程(函數)調用LPC
1.5 什麼是遠端過程/函數調用RPC
第2章 遠端過程調動的網絡架構
2.1 去中心化的點對點架構(P2P架構)
2.2 用戶端-伺服器模式(二層C/S架構)
2.3 用戶端-伺服器模式(三層C/S架構)
2.4 MVC 架構
第3章 RPC主要架構
3.1 RPC架構的作用
3.2 RPC調用需要知道的資訊
3.3 比較典型RPC架構
第1章 遠端過程/函數調用RPC概述
1.1 什麼是程式設計語言原生的函數調用
計算機的函數,是一個固定的一個程式段,或稱其為一個子程式,它在可以實作固定運算功能的同時,還帶有一個入口和一個出口,所謂的入口,就是函數所帶的各個參數,我們可以通過這個入口,把函數的參數值代入子程式,供計算機處理;所謂出口,就是指函數的函數值,在計算機求得之後,由此口帶回給調用它的程式。

原生的函數調用的核心是:
(1)調用者首先給被調函數傳入參數,然後,等待被調函數的處理結果,直到被調函數獲得執行結果,并把傳回給調用者,最後,調用者繼續執行後續的代碼。
(2)函數執行鍊中的所有函數執行體,在同一個程序中。
1.2 IPC:(Inter Process Communication )跨程序通信
程序使用者空間是互相獨立的,一般而言是不能互相通路的。
但很多情況下程序間需要互相通信,來完成系統的某項功能。
程序通過與核心及其它程序之間的互相通信來協調它們的行為。
程序間通信是指兩個互相隔離的程序間的程式之間需要互相互動資料。
程序間通信可以有多種手段和方法:
- 虛拟檔案系統通信
- 無名管道:pipe 通信
- 信号量:semaphore
- 消息隊列: message queue
- 共享記憶體:shared memory
- 套接字:socket
- 信号: Signal
1.4 什麼是本地過程(函數)調用LPC
LPC是“本地過程調用(Local Procedure Call)”的縮寫。所謂“本地過程調用”是與“遠端過程調用”即RPC相對而言的。
RPC是廣義的,RPC可以發生在不同主機的程序之間,也可以發生在同一台主機的程序之間,發生在同一台主機的程序之間就是LPC,當然,如果發生在同一個程序内部,就是原生的函數調用。是以在Unix語境下就沒有LPC這一說,即使發生在同一台主機上也稱為RPC。
在曆史上,RPC是“開放軟體基金會(OSF)”設計和提出的一種用以實作“Unix分布計算環境(Unix DCE)”的标準。實際上,微軟的DCOM技術,就是建立在RPC基礎上的。Win2000的RPC可以采用TCP/IP、SPX、NetBIOS、命名管道、以及“本地”作為底層的通信手段,這“本地”就是LPC。
另一方面,Windows是一個帶有許多微核心系統特征的作業系統(盡管它的核心不是微核心),系統中有不少“系統級”的服務程序,例如大家已經熟知的csrss、管理使用者登入的“本地安全認證服務”程序LSASS等等,使用者程序以及微軟提供的系統工具軟體經常需要調用由這些服務程序提供的服務,這裡LPC就起着重要的作用。
LPC的基礎是一種稱為“端口(Port)”的程序間通信機制,類似于本地的(Unix域的)Socket。這種Port機制提供了面向封包傳遞(message passing)的程序間通信,而LPC則是建立在這個基礎上的高層機制,目的是提供跨程序的過程調用。注意這裡所謂“跨程序的過程調用”不同于以前所說的“跨程序操作”。前者是雙方有約定、遵循一定規程的、有控制的服務提供,被調用者在向外提供一些什麼服務、即提供哪些函數調用方面是自主的,而後者則可以是在不知不覺之間的被利用、被操縱。前者是良性的,而後者可以是惡性的。
1.5 什麼是遠端過程/函數調用RPC
隐藏了過程調用時實際通信細節的IPC方法。用戶端将調用一個本地方法,而這個本地方法則是負責透明的與遠端服務端進行過程間通信。這個本地方法會将相關參數順序打包到一個消息中,然後把這個消息發送給服務端提供的方法,服務端的方法會從消息中解出序列化發出來的參數,然後執行,最後仍以同樣的方式将方法的傳回值發送給用戶端。
遠端過程調用的角色劃分:
客戶程序:本地函數調動的應用程式。
伺服器程序:提供資料的遠端伺服器。
第2章 遠端過程調動的網絡架構
2.1 去中心化的點對點架構(P2P架構)
P2P架構中,沒有明顯的伺服器和伺服器,每個機器,既是用戶端也是伺服器。
這種架構對于一些去中心化的即時通信應用是有吸引力的。許多直接即時通訊社交應用涉及資訊管理和多使用者互動方面。一個用戶端主機可以同時作為 Client 或 Peer,這取決于該主機在應用程式的角色定義。
P2P 很适用于語音或視訊會議的場景。P2P 的很明顯的特征是功能的對稱性。适合資料面。
優點:降低了用戶端之間通信的延時,提升了用戶端到用戶端通信的效率。
缺點:如果一個用戶端與多終端同時通信,就會比較複雜。
2.2 用戶端-伺服器模式(二層C/S架構)
一切将服務提供者(伺服器)和服務消費者(用戶端)分開的分布式計算模式。
各個計算機之間以客戶機和伺服器的關系進行工作與交換資訊,客戶機首先向伺服器發送請求,然後伺服器完成請求的操作,并把結果傳回給客戶機。
C/S 應用程式 一部分是由以與用戶端或使用者互動為基礎的主機,另一部分主機則是專門用于管理大型資料存儲庫,處理應用特有的資料和邏輯的伺服器。
這給 C/S 架構引入了不對稱的功能性,用戶端需要向服務端發起請求,而服務端需要滿足(答複)用戶端的請求。
C/S 架構适合應用于在伺服器上釋出的資訊管理應用程式。
OLTP應用則是傳統的 C/S 架構中的良好示例。
On-Line Transaction Processing聯機事務處理過程(OLTP),也稱為面向交易的處理過程,其基本特征是前台接收的使用者資料可以立即傳送到計算中心進行處理,并在很短的時間内給出處理結果,是對使用者操作快速響應的方式之一。
2.3 用戶端-伺服器模式(三層C/S架構)
- 第一層:用戶端(使用者)。
- 第二層:服務端(用于存放應用程式的邏輯)。
- 第三層:資料庫(不同的應用程式所需要的共享資料)。
三層的 C/S 架構
這種3層架構的動機包括:
- 表現:專注于單個使用者
- 應用程式邏輯:支援多使用者,通過添加多台伺服器來支援更多使用者的成本是較低的。
- 關鍵共享資料:支援多個應用程式。
這三層的 C/S 架構中,每層之間都是
n…1
的關系。
顯然三層架構比兩層架構具備更高的擴充性,
向用戶端隐藏的異構資料庫支援以及提供了不同的通信協定的更好支援。
2.4 MVC 架構
模型 - 視圖 - 控制器(MVC)應用程式架構是用于分析分布式應用程式的功能的流行模型。
這種抽象有助于将應用程式分解成邏輯元件,以實作更容易/更清晰的分布式實作。
MVC 劃分在監視和處理資料中涉及的對象之間的功能,以便最小化這些對象之間的耦合度,并是以将這些對象映射在多層架構上。
最初 MVC 使用者解耦:輸入、資料處理、輸出 UI 界面。
但是,将此模型映射到多層網站或企業應用程式也很簡單。
- 模型(Model):操作資料。
當 Model 層資料變更時通知 View 。 它允許 Controller 通路 Model 封裝的方法。
- 視圖(View):将 Model 提供的内容渲染出來。
它可以查詢Model關于資料的模型并指定如何呈現它。
- 控制器(Controller):定義應用程式的行為。
它将使用者手勢映射到要由Model執行的操作。在标準的 GUI 用戶端,使用者手勢可以是按壓按鈕。在 Web 環境,它可以是發起一次 HTTP GET/POST 請求。通常一個Controller,表示一組相關的功能。
第3章 RPC主要架構
3.1 RPC架構的作用
RPC 是遠端過程調用的方式之一,涉及調用方和被調用方兩個程序的互動。
RPC(Remote Procedure Call)遠端過程調用是一種通過網絡從遠端計算機程式上請求服務,而不需要了解底層網絡技術的協定,簡單的了解是一個節點請求另一個節點提供的服務。
RPC隻是一套思想,基于這個思想來實作的架構都可以稱為 RPC 架構。
RPC架構是以庫的形式存在的。
RPC 提供類似于本地方法調用的形式,在有RPC架構的支援下,對于調用方來說,調用 RPC 方法和調用本地方法并沒有明顯差別。
3.2 RPC調用需要知道的資訊
對使用者來說,屏蔽了網絡通信的細節。
你隻需要知道調用這個方法傳回的結果,而無需關注底層邏輯。
從封裝的那個方法角度來看,調用之前我們需要知道什麼?
- 直接調用的語義,也可以了解為接口規範。(比如
)RESTful
- 中間的網絡傳輸協定 (比如
)HTTP或HTTP2
- 傳輸的資料序列化與反序列化規範(比如
ProtocolBuffers)。JSON、
有了這些約定,我就知道:
- 如何給你發資料
- 發什麼樣的資料
- 你傳回給我的又是什麼樣的資料。
3.3 比較典型RPC架構
(1)Dubbo
Dubbo(讀音[ˈdʌbəʊ])是阿裡巴巴公司開源的一個高性能優秀的服務架構,使得應用可通過高性能的 RPC 實作服務的輸出和輸入功能,可以和Spring架構無縫內建。
Dubbo是一款高性能、輕量級的開源Java RPC架構,它提供了三大核心能力:
- 面向接口的遠端方法調用,
- 智能容錯和負載均衡,
- 以及服務自動注冊和發現。
(2)Thrift
Thrift 是一個軟體架構(遠端過程調用架構),用來進行可擴充且跨語言的服務的開發。
它結合了功能強大的軟體堆棧和代碼生成引 擎,以建構在 C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, and OCaml 這些程式設計語言間無縫結合的、高效的服務。
thrift 最初由 facebook 開發,07 年四月開放源碼,08 年 5 月進入 apache 孵化器,現在是 Apache 基金會的頂級項目
thrift 允許你定義一個簡單的定義檔案中的資料類型和服務接口,以作為輸入檔案,編譯器生成代碼用來友善地生成 RPC 用戶端和伺服器通信的無縫跨程式設計語言。。
(3)gRPC
gRPC是由Google開發的一款語言中立、平台中立、高性能、通用的開源的開源
RPC
架構,主要用來解決性能損失的問題。
gRPC使用戶端和服務端應用程式可以透明地進行通信,并簡化了連接配接系統的建構。
它使用HTTP/2作為通信協定,使用ProtocolBuffers作為序列化協定。
HTTP/2協定:
從上圖可以看出,用戶端隻需要書寫http的文本,就可以實作遠端過程調用,從伺服器擷取資料。
當然,文本是有一定的協定格式的。
(4)Linux rpcgen