如何分析原理及應(yīng)用

本篇文章為大家展示了如何分析原理及應(yīng)用，內(nèi)容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細(xì)介紹希望你能有所收獲。

01 背景

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

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

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

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

    RPC是分布式的基石。

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

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

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

    3、Web Service（SOA SOAP RDDI WSDL）：基于http+xml的標(biāo)準(zhǔn)化Web API；

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

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

    6、JMS（Java Message Service）：JavaEE的消息框架標(biāo)準(zhǔn)，很多MQ支持；

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

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

02 概述

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

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

    通過RPC能解耦服務(wù)，這才是使用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)部使用，性能消耗低，傳輸效率高，服務(wù)治理方便，但是不建議傳輸較大的文本、視頻等。

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

2.2 RPC與IPC

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

2.3 RPC與Socket

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

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

2.4 RPC與MQ

    區(qū)別：

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

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

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

    4、隨著業(yè)務(wù)增長，處理端出現(xiàn)性能瓶頸，此時會進(jì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等）和二進(jìn)制的（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）模式，又叫請求響應(yīng)模式，指每個調(diào)用都要有具體的返回結(jié)果信息。

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

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

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

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

    從本質(zhì)上看，RPC一般對于客戶端的來說是一種同步的遠(yuǎn)程服務(wù)調(diào)用技術(shù)。與其相對應(yīng)的，一般來說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機器，首先得在客戶端和服務(wù)器之間建立TCP連接。

    2、服務(wù)尋址

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

    3、網(wǎng)絡(luò)傳輸

    1）序列化

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

    2）反序列化

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

    4、服務(wù)調(diào)用

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

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

5.1 組件

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

    RPC Server：負(fù)責(zé)導(dǎo)出（export）遠(yuǎn)程接口

    RPC Client：負(fù)責(zé)導(dǎo)入（import）遠(yuǎn)程接口的代理實現(xiàn)

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

    RPC Invoker：

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

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

    RPC Protocol：負(fù)責(zé)協(xié)議編/解碼

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

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

    RPC Processor：負(fù)責(zé)在服務(wù)方控制調(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(jìn)制。可以采用JDK（僅適用于Java），JSON（跨語言，文本化，比二進(jìn)制包大，性能稍差），Hessian，Protobuf（使用IDL文件，對數(shù)據(jù)類型做了約定，跨語言能力強）。

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

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

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

    3、用戶定義白名單

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

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

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

    健康檢查：

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

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

5.4 負(fù)載方式

    負(fù)載均衡：

    負(fù)載方式：

    1、隨機負(fù)載

    2、一致性hash負(fù)載

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

    集群策略：

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

5.5 流量控制

    服務(wù)端流量控制：

    流量控制方案：

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

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

    3、集群限流

5.6 分組部署

5.7 安全認(rèn)證

06 特點

    優(yōu)點：

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

    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)絡(luò)狀況；

    3、調(diào)用遠(yuǎn)程方法對初學(xué)者來說難度大。

07 框架

    Dubbo

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

    Montan

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

    Spring Cloud

    rpcx

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

    gRPC

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

    gsaop

    gsoap更適合C/C++程序，重量級應(yīng)用。

    Thrift

    適合Java程序，中量級應(yīng)用。

    rest

    適合腳本語言，輕量級應(yīng)用。

    對比

08 應(yīng)用

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

8.1 Nginx與RPC

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

8.2 Hadoop與RPC

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

8.3 TensorFlow與RPC

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

上述內(nèi)容就是如何分析原理及應(yīng)用，你們學(xué)到知識或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識儲備，歡迎關(guān)注億速云行業(yè)資訊頻道。