01?背景

????對于一個電商平臺而言，?往往涉及購物車，訂單，支付，商品等多個模塊，這就需要多個人員進行維護，如果采用單機系統(tǒng)，就會導致這樣的問題：

????1、某人在維護自己模塊代碼時，需要將所有代碼編譯打包，其余模塊可能需要回歸測試；

????2、其中一個模塊出問題，可能導致整個系統(tǒng)故障。

這就出現(xiàn)了遠程過程調(diào)用RPC，它使得我們可以像調(diào)用本地函數(shù)一樣調(diào)用遠程服務器的函數(shù)。

????RPC是分布式的基石。

????從單機走向分布式，產(chǎn)生了很多分布式的通信方式：

??? 1、TCP/UDP二進制傳輸：最古老，也是最有效的，事實上所有的通信方式歸根結(jié)底都是TCP/UDP；

??? 2、CORBA（Common Object Request Broker Architecture）：古老而復雜，支持面向?qū)ο蟮耐ㄐ艆f(xié)議；

??? 3、Web Service（SOA SOAP RDDI WSDL）：基于http+xml的標準化Web API；

??? 4、RestFul（Reprensentational State Transfer）：http+json；

??? 5、RMI（Remote Method Invocation）：Java內(nèi)部的分布式通信協(xié)議；

??? 6、JMS（Java Message Service）：JavaEE的消息框架標準，很多MQ支持；

??? 7、RPC（Remote Procedure Call）：遠程過程調(diào)用，這只是一個統(tǒng)稱，重點在于方法調(diào)用，具體實現(xiàn)甚至可以用RMI RestFul等去實現(xiàn)，但一般不用，因為RMI不能跨語言，而ResuFul效率太低。

????多用于服務器集群間的通信（分布式或微服務架構(gòu)），因此常使用更加高效、短小精悍的傳輸模式以提高效率。

02?概述

????RPC (Remote Procedure Call)即遠程過程調(diào)用，是分布式系統(tǒng)常見的一種通信方法。除RPC之外，常見的多系統(tǒng)數(shù)據(jù)交互方案還有分布式消息隊列、HTTP請求調(diào)用、數(shù)據(jù)庫和分布式緩存等。

????RPC是一種概念，HTTP也是RPC實現(xiàn)的一種方式。

????通過RPC能解耦服務，這才是使用RPC的真正目的。RPC的原理主要用到了動態(tài)代理模式，至于HTTP協(xié)議，只是傳輸協(xié)議而已。

2.1 RPC與HTTP

????和一般基于Message的分布式框架（如MPI）相比，RPC更加抽象，也更方便理解。不過在底層，無論是RPC還是MPI，終究還是要轉(zhuǎn)化成TCP/UDP包發(fā)來發(fā)去的。

????對比：

??? RPC適用于公司內(nèi)部使用，性能消耗低，傳輸效率高，服務治理方便，但是不建議傳輸較大的文本、視頻等。

??? HTTP適用于對外的技術(shù)，公司上下游的調(diào)用可以使用MQ。主要用于對外的異構(gòu)環(huán)境，瀏覽器接口調(diào)用，APP接口調(diào)用，第三方接口調(diào)用等。

2.2 RPC與IPC

????我們通常所說管道、FIFO等是同一機器的進程間通信方式（IPC），RPC是不同機器之間進程通信方式。

2.3 RPC與Socket

????RPC(Remote Procedure Call，遠程過程調(diào)用)是建立在Socket之上的，在一臺機器上運行的主程序，可以調(diào)用另一臺機器上準備好的子程序，就像LPC(本地過程調(diào)用)。RPC協(xié)議假定某些傳輸協(xié)議的存在，如TCP或UDP，為通信程序之間攜帶信息數(shù)據(jù)。在OSI網(wǎng)絡通信模型中，RPC跨越了傳輸層和應用層。RPC使得開發(fā)包括網(wǎng)絡分布式多程序在內(nèi)的應用程序更加容易。

????RPC作為普遍的C/S開發(fā)方法，開發(fā)效率高效，可靠。但RPC方法的基本原則是：以模塊調(diào)用的簡單性忽略通訊的具體細節(jié)，以便程序員不用關(guān)心C/S之間的通訊協(xié)議，集中精力對付實現(xiàn)過程。這就決定了RPC生成的通訊包不可能對每種應用都有最恰當?shù)奶幚磙k法，與Socket方法相比，傳輸相同的有效數(shù)據(jù)，RPC占用更多的網(wǎng)絡帶寬。

2.4 RPC與MQ

????區(qū)別：

??? 1、在架構(gòu)上，MQ有一個中間結(jié)點，可以把消息存儲。

??? 2、同步調(diào)用：對于要立即等待返回處理結(jié)果的場景，RPC是首選。

??? 3、MQ的使用，一方面是基于性能的考慮，比如服務端不能快速的響應客戶端（或客戶端也不要求實時響應），需要在隊列里緩存。另外一方面，它更側(cè)重數(shù)據(jù)的傳輸，因此方式更加多樣化，除了點對點外，還有訂閱發(fā)布等功能。

??? 4、隨著業(yè)務增長，處理端出現(xiàn)性能瓶頸，此時會進行同步調(diào)用改造為異步調(diào)用，可以考慮使用MQ。

????由此可知，二者最大的區(qū)別是，RPC沒有broker, 而消息隊列是需要管理消息的存儲的，RPC沒有存儲，只有通信。

????總結(jié)：

? ? 異步MQ，同步RPC。

03?分類

????常見的RPC技術(shù)有Cobra、RMI、.NET Remoting、WebService、JSON-RPC、XML-RPC、Hessian、Thrift、Protocol Buffer、gRPC等等。

????按照序列化機制的特點，我們可以把RPC技術(shù)分為文本的（WebService、JSON-RPC、XML-RPC等）和二進制的（RMI、Hessian、Thrift、Protocol Buffer等）。

????按照常見的通信協(xié)議來看，我們又可以分為基于HTTP的（WebService、Hessian等）和基于TCP的（RMI、.NET Remoting等）。

????按照是否可以用于多個不同平臺，又可以分為平臺特定的（RMI是Java平臺特定的、.NET Remoting是.NET平臺特定的）和平臺無關(guān)的（比如WebService、JSON-RPC、Hessian等）。

04?模式

????按照調(diào)用方式來看，RPC有四種模式：

????RR（Request-Response）模式，又叫請求響應模式，指每個調(diào)用都要有具體的返回結(jié)果信息。

????Oneway模式，又叫單向調(diào)用模式，調(diào)用即返回，沒有響應的信息。

????Future模式，又叫異步模式，返回拿到一個Future對象，然后執(zhí)行完獲取到返回結(jié)果信息。

????Callback模式，又叫回調(diào)模式，處理完請求以后，將處理結(jié)果信息作為參數(shù)傳遞給回調(diào)函數(shù)進行處理。

????這四種調(diào)用模式中，RR和Oneway最常見。

????從本質(zhì)上看，RPC一般對于客戶端的來說是一種同步的遠程服務調(diào)用技術(shù)。與其相對應的，一般來說MQ是一種異步的調(diào)用技術(shù)。

????而對于MQ，根據(jù)消息處理的特點，我們又可以總結(jié)兩種消息模式：

????點對點模式（Point to Point，PTP），一個生產(chǎn)者發(fā)送的每一個消息，都只能有一個消費者能消費，看起來消息就像從一個點傳遞到了另外一個點。

????發(fā)布訂閱模式，（Publish-Subscribe，PubSub），一個生產(chǎn)者發(fā)送的每一個消息，都會發(fā)送到所有訂閱了此隊列的消費者。

05?原理

????RPC的一般需要經(jīng)歷4個步驟：

? ??1、建立通信

??? A機器想要調(diào)用B機器，首先得在客戶端和服務器之間建立TCP連接。

? ??2、服務尋址

????要解決尋址的問題，A服務器上如何連接到B服務器（如主機或IP地址）以及特定的端口，方法的名稱是什么。

????3、網(wǎng)絡傳輸

????1）序列化

????當A服務器上的應用發(fā)起一個RPC調(diào)用時，調(diào)用方法和參數(shù)數(shù)據(jù)都需要先進行序列化。

? ??2）反序列化

????當B服務器接收到A服務器的請求之后，又需要對接收到的參數(shù)等信息進行反序列化操作。

????4、服務調(diào)用

??? B服務器進行本地調(diào)用（通過代理Proxy）之后得到了返回值，此時還需要再把返回值發(fā)送回A服務器，同樣也需要經(jīng)過序列化操作，然后再經(jīng)過網(wǎng)絡傳輸將二進制數(shù)據(jù)發(fā)送回A服務器。

????通常，一次完整的PRC調(diào)用需要經(jīng)歷如上4個步驟。

5.1 組件

????一個RPC框架一般包含以下幾個組件：

??? RPC Server：負責導出（export）遠程接口

??? RPC Client：負責導入（import）遠程接口的代理實現(xiàn)

??? RPC Proxy：遠程接口的代理實現(xiàn)

??? RPC Invoker：

????客戶方實現(xiàn)：負責編碼調(diào)用信息和發(fā)送調(diào)用請求到服務方并等待調(diào)用結(jié)果返回；

????服務方實現(xiàn)：負責調(diào)用服務端接口的具體實現(xiàn)并返回調(diào)用結(jié)果

??? RPC Protocol：負責協(xié)議編/解碼

??? RPC Connector：負責維持客戶方和服務方的連接通道和發(fā)送數(shù)據(jù)到服務方

??? RPC Acceptor：負責接收客戶方請求并返回請求結(jié)果

??? RPC Processor：負責在服務方控制調(diào)用過程，包括管理調(diào)用線程池、超時時間等

??? RPC Channel：數(shù)據(jù)傳輸通道

5.2 序列化

????RPC實現(xiàn)另一臺機器的調(diào)用通信，本質(zhì)上是借助底層TCP/IP協(xié)議，通過序列化和反序列化實現(xiàn)的。

????序列化把對象轉(zhuǎn)換為可傳輸?shù)亩M制。可以采用JDK（僅適用于Java），JSON（跨語言，文本化，比二進制包大，性能稍差），Hessian，Protobuf（使用IDL文件，對數(shù)據(jù)類型做了約定，跨語言能力強）。

????反序列化安全問題，采用白名單：

????1、掃描接口類聲明的類型

????2、系統(tǒng)內(nèi)置白名單

????3、用戶定義白名單

5.3 服務發(fā)現(xiàn)

? ? 服務發(fā)現(xiàn)：

????調(diào)用方和提供方通過注冊中心實現(xiàn)函數(shù)（地址）的發(fā)布和訂閱，提供方將自己的函數(shù)注冊到注冊中心，調(diào)用方到注冊中心訂閱相應的函數(shù)。

????健康檢查：

? ? 通過狀態(tài)機實現(xiàn)節(jié)點假死的轉(zhuǎn)移。

????通過心跳機制將亞健康的節(jié)點轉(zhuǎn)換為死亡狀態(tài)，然后還可以通過探活機制實現(xiàn)節(jié)點狀態(tài)的檢查。

5.4 負載方式

????負載均衡：

????負載方式：

????1、隨機負載

????2、一致性hash負載

????3、自適應負載（計算TPS，利用率等計算出權(quán)重）

????集群策略：

????集群策略：快速失敗，失敗重試，定點調(diào)用

5.5 流量控制

????服務端流量控制：

????流量控制方案：

????1、識別調(diào)用來源

??? 2、單節(jié)點限流：平滑限流算法

????3、集群限流

5.6?分組部署

5.7 安全認證

06?特點

????優(yōu)點：

??? 1、長鏈接，不必每次通信都要像http一樣去3次握手什么的，減少了網(wǎng)絡開銷；

??? 2、RPC框架一般都有注冊中心，有豐富的監(jiān)控管理；發(fā)布、下線接口、動態(tài)擴展等，對調(diào)用方來說是無感知、統(tǒng)一化的操作；

??? 3、提升系統(tǒng)可擴展性；

??? 4、提升系統(tǒng)可維護性和持續(xù)交付能力；

??? 5、實現(xiàn)系統(tǒng)高可用。

????缺點：

??? 1、一個完善的RPC框架開發(fā)難度大；

??? 2、RPC框架調(diào)用成功率受限于網(wǎng)絡狀況；

??? 3、調(diào)用遠程方法對初學者來說難度大。

07?框架

????Dubbo

??? Dubbo是阿里巴巴開源的一個Java高性能優(yōu)秀的服務框架，可以和Spring框架無縫集成。

????Montan

??? Montana是新浪微博開源的一個Java框架。

????Spring?Cloud

????rpcx

??? rpcx是go語言生態(tài)圈的Dubbo。

????gRPC

??? gRPC是Google開發(fā)的高性能、通用的開源RPC框架。

????gsaop

??? gsoap更適合C/C++程序，重量級應用。

????Thrift

????適合Java程序，中量級應用。

????rest

????適合腳本語言，輕量級應用。

????對比

08?應用

??? RPC在我們熟悉的各種中間件中都有它的身影。我們這里說的RPC指的是廣義的RPC，即分布式系統(tǒng)的通信技術(shù)。

8.1 Nginx與RPC

Nginx和后端服務之間的交互在本質(zhì)上也可以理解為RPC數(shù)據(jù)交互。

8.2 Hadoop與RPC

??? Hadoop文件系統(tǒng)HDFS，一般包括一個NameNode和多個DataNode，NameNode和DataNode之間就是通過一種稱為Hadoop RPC的二進制協(xié)議進行通訊。

8.3 TensorFlow與RPC

??? Tensorflow Cluster的RPC通訊框架使用了Google內(nèi)部自研的gRPC框架。