引言

以前在做一個(gè)規(guī)模不大的系統(tǒng)的時(shí)候，用的是單體架構(gòu)，一臺(tái)服務(wù)器部署上一個(gè)應(yīng)用和數(shù)據(jù)庫(kù)也就夠了。

但是現(xiàn)代化互聯(lián)網(wǎng)公司業(yè)務(wù)逐漸擴(kuò)大，服務(wù)逐漸細(xì)分，很多服務(wù)之間需要通過(guò)遠(yuǎn)程分布式接口調(diào)用通訊，即不同的服務(wù)不是部署在同一個(gè)服務(wù)器上，比如訂單服務(wù)在 A 服務(wù)上，付款服務(wù)在另一個(gè)服務(wù)上，有同步調(diào)用、也有異步調(diào)用，這個(gè)時(shí)候我們就需要遠(yuǎn)程調(diào)用不同的服務(wù)，使用的時(shí)候調(diào)用遠(yuǎn)程服務(wù)就像調(diào)用本地服務(wù)一樣，引入一個(gè) jar 包，就能通過(guò) this.xxx( ) 一樣調(diào)用遠(yuǎn)程服務(wù)，這背后的機(jī)制就是通過(guò) RPC 技術(shù)。

重點(diǎn)：RPC 技術(shù)一定是今后工作必備基礎(chǔ)，熟練掌握其中一種，知道原理，閱讀源碼，甚至自己手寫(xiě)一個(gè)。

1、面試官：

公司使用什么 RPC 框架？，可以介紹一下 RPC 的工作原理嗎？

問(wèn)題分析： 面試官想了解基礎(chǔ)設(shè)施是否和我們項(xiàng)目用的一樣，一樣最好了，能直接上手，不一樣了解其它一個(gè)別的應(yīng)該也問(wèn)題不大，畢竟原理技術(shù)都大同小異，說(shuō)你最熟悉的一個(gè)。

答：RPC 是一個(gè)分布式計(jì)算的 CS 模式，總是由 Client 向 Server 發(fā)出一個(gè)執(zhí)行若干過(guò)程請(qǐng)求，Server 接受請(qǐng)求，使用者客戶端提供的參數(shù)，計(jì)算完成之后將結(jié)果返回給客戶端。

使用最廣泛的 Spring Cloud，基于 Spring Boot 特性整合了開(kāi)源行業(yè)中優(yōu)秀的組件，整體對(duì)外提供了一套在微服務(wù)架構(gòu)中服務(wù)治理的解決方案。

國(guó)內(nèi)開(kāi)源的框架中，使用比較廣泛的有阿里的 Dubbo，后來(lái)捐獻(xiàn)給了 Apache。還有騰訊的 Tars 框架，還有 Thrift 框架，也有基于 Thrift 二次開(kāi)發(fā)的 RPC 框架，比如美團(tuán)的 Mtthrift。

這些 RPC 大致原理基本都是一樣的。（這個(gè)時(shí)候，跟面試官要紙和筆，畫(huà)圖解釋 RPC 原理）

 這個(gè)圖既不顯得太過(guò)復(fù)雜給自己挖坑，也不會(huì)顯得簡(jiǎn)單潦草。

1-5 逐行解釋：

• 服務(wù)集成 RPC 后，服務(wù)（這里的服務(wù)就是圖中的 Provider，服務(wù)提供者）啟動(dòng)后會(huì)通過(guò) Register（注冊(cè)）模塊，把服務(wù)的唯一 ID 和 IP 地址，端口信息等注冊(cè)到 RPC 框架注冊(cè)中心（圖中的 Registry 部分）。
• 當(dāng)調(diào)用者（Consumer）想要調(diào)用服務(wù)的時(shí)候，通過(guò) Provider 注冊(cè)時(shí)的的服務(wù)唯一 ID 去注冊(cè)中心查找在線可供調(diào)用的服務(wù)，返回一個(gè) IP 列表（3.notify 部分）。
• 第三步 Consumer 根據(jù)一定的策略，比如隨機(jī) or 輪訓(xùn)從 Registry 返回的可用 IP 列表真正調(diào)用服務(wù)（4.invoke）。
• 最后是統(tǒng)計(jì)功能，RPC 框架都提供監(jiān)控功能，監(jiān)控服務(wù)健康狀況，控制服務(wù)線上擴(kuò)展和上下線（5.count）

 有清晰的流程圖，有每一步的解釋，面試官表示很滿意，繼續(xù)追加提問(wèn)。

2、面試官：

服務(wù)啟動(dòng)的時(shí)候服務(wù)基本信息被注冊(cè)到注冊(cè)中心，如果服務(wù)提供者掛了，注冊(cè)中心如何知道服務(wù)不可用了呢？

 答：服務(wù)掉線分為主動(dòng)下線和心跳檢測(cè)

比如服務(wù)由于發(fā)版時(shí)，在重啟之前先主動(dòng)通知注冊(cè)中心：我要重啟了，有流量進(jìn)來(lái)先不要分給我，讓別的機(jī)器服務(wù)，等我重啟成功后在放流量進(jìn)來(lái)，或者是在管理后臺(tái)手動(dòng)直接摘掉機(jī)器，這個(gè)是主動(dòng)下線。

心跳檢測(cè)是處理服務(wù)非正常下線（如斷電斷網(wǎng)）的情況，這個(gè)時(shí)候如果注冊(cè)中心不知道該服務(wù)已經(jīng)掉線，一旦被其調(diào)用就會(huì)帶來(lái)問(wèn)題。為了避免出現(xiàn)這樣的情況，注冊(cè)中心增加一個(gè)心跳檢測(cè)功能，它會(huì)對(duì)服務(wù)提供者（Provider）進(jìn)行心跳檢測(cè)，比如每隔 30s 發(fā)送一個(gè)心跳，如果三次心跳結(jié)果都沒(méi)有返回值，就認(rèn)為該服務(wù)已下線，趕緊更新 Consumer 的服務(wù)列表，告訴 Consumer 調(diào)用別的機(jī)器。

問(wèn)題分析： 闡述了服務(wù)端掛了注冊(cè)中心如何感知的問(wèn)題，你以為此問(wèn)題已經(jīng)完事兒了？還沒(méi)有，你成功給自己挖了個(gè)坑，面試官可能繼續(xù)深挖，服務(wù)提供者（Provider）掛了注冊(cè)中心能解決，那注冊(cè)中心自己就不掛了嗎？三連問(wèn)繼續(xù)。

3、面試官：

如果注冊(cè)中心掛了，比如你用的是 Zookeeper，如果 Zookeeper 掛了，那服務(wù)之間還能相互調(diào)用嗎？

 答：首先注冊(cè)中心掛掉也要分兩種情況，如果數(shù)據(jù)庫(kù)掛了，ZK 還是能用的，因?yàn)?ZK 會(huì)緩存注冊(cè)機(jī)列表在緩存里。

其次 ZK 本身就是一個(gè)集群的，一臺(tái)機(jī)器掛了，ZK 會(huì)選舉出集群中的其他機(jī)器作為 Master 繼續(xù)提供服務(wù)，如果整個(gè)集群都掛了也沒(méi)問(wèn)題，因?yàn)檎{(diào)用者本地會(huì)緩存注冊(cè)中心獲取的服務(wù)列表。省略和注冊(cè)中心的交互，Consumer 和 Provider 采用直連方式，這些策略都是可配置的。

問(wèn)題分析： 面試是一個(gè)自由交流時(shí)間，任何一個(gè)點(diǎn)都可能被發(fā)散繼續(xù)深入挖掘，刨根問(wèn)題，總有你覆蓋不到的知識(shí)盲區(qū)，目的不是為難你，是想了解你的技術(shù)沉淀深度。

4、面試官：

你對(duì) RPC 了解的很透徹，那你能否自己寫(xiě)一個(gè) RPC 框架？可以簡(jiǎn)答描述下思路也行。

答：這個(gè)問(wèn)題，雖然沒(méi)有自己動(dòng)手寫(xiě)過(guò)，但是我閱讀過(guò)源碼，大致實(shí)現(xiàn)思路是這樣的。（畫(huà)圖給面試官）

1. 客戶端 invoke 方法編寫(xiě)，使用 JDK 的動(dòng)態(tài)代理技術(shù)，客戶端調(diào)用遠(yuǎn)程服務(wù)方法時(shí)調(diào)用的是 InvocationHandler 的 invoke 方法。
2. 客戶端 Filter 方法編寫(xiě)，完善的 RPC 框架少不了監(jiān)控、路由、降級(jí)、鑒權(quán)等功能。
3. 創(chuàng)建 Socket，在 Filter 方法中實(shí)現(xiàn) Client.write 方法，其邏輯為從連接池（ChannelPool）中獲取連接，然后將數(shù)據(jù)寫(xiě)進(jìn) Channel。
4. 實(shí)現(xiàn)數(shù)據(jù)序列化、壓縮，目的減少網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)量，向服務(wù)端發(fā)送 request 數(shù)據(jù)，這里可以使用 Netty 異步通訊框架。
5. 服務(wù)端收到客戶端發(fā)過(guò)的消息后，從 Channel 中將消息讀出來(lái)之前，也會(huì)先經(jīng)反序列化解壓。
6. 請(qǐng)求就到了服務(wù)端 Filter 中。請(qǐng)求依次經(jīng)過(guò)監(jiān)控、鑒權(quán)方法。
7. 根據(jù)客戶端傳遞來(lái)的服務(wù)信息和參數(shù)，通過(guò)反射調(diào)用相應(yīng)的業(yè)務(wù)服務(wù)并拿到業(yè)務(wù)處理結(jié)果。然后在 ResponseFilter 中將返回結(jié)果寫(xiě)入 Channel。
8. 服務(wù)端序列化、壓縮等，發(fā)送給客戶端。
9. 客戶端收到消息后，經(jīng)過(guò)客戶端反序列化、解壓縮，后交給 ResponseThreadPoolProcessor 線程池處理。
10. ResponseThreadPoolProcessor 收到消息后，就將結(jié)果返回給之前的方法調(diào)用，整個(gè)調(diào)用請(qǐng)求就結(jié)束了。

面試官： 可以可以，確實(shí)是看了，這個(gè)問(wèn)題就到這。（面試官心理：雖然目前項(xiàng)目里不會(huì)讓你真正去寫(xiě)一個(gè) RPC 框架，知其然知其所以然，遇到這類 RPC 相關(guān)問(wèn)題一定能搞定了，項(xiàng)目組正好缺一個(gè)這樣的人）

深入分析

已經(jīng)有 http 協(xié)議接口，或者說(shuō) RestFul 接口，為什么還要使用 RPC 技術(shù)？

在接?不多的情況下，使用 http 確實(shí)是一個(gè)明智的選擇，比如在初創(chuàng)企業(yè)，我們不確定業(yè)務(wù)能順利開(kāi)展下去，可能面臨隨時(shí)倒閉，開(kāi)發(fā)人員也不足，這個(gè)時(shí)候使用簡(jiǎn)潔高效的技術(shù)，先把東西做出來(lái)是最明智的選擇，無(wú)需一步登天。

系統(tǒng)與系統(tǒng)交互較少的情況下，使用 http 協(xié)議優(yōu)點(diǎn)顯而易見(jiàn)：開(kāi)發(fā)簡(jiǎn)單、測(cè)試也比較直接、部署方便，利用現(xiàn)成的 http 協(xié)議進(jìn)行系統(tǒng)間通訊，如果業(yè)務(wù)真的慢慢做大，系統(tǒng)也慢慢擴(kuò)大，RPC 框架的好處就顯示出來(lái) 了，?先 RPC 支持長(zhǎng)鏈接，通信不必每次都要像 http 一樣去重復(fù) 3 次握?，減少了網(wǎng)絡(luò)開(kāi)銷。

其次就是 RPC 框架一般都有注冊(cè)中心模塊，有完善的監(jiān)控管理功能，服務(wù)注冊(cè)發(fā)現(xiàn)、服務(wù)下線、服務(wù)動(dòng)態(tài)擴(kuò)展等都方便操作，服務(wù)化治理效率大大提高。

基于 TCP 協(xié)議實(shí)現(xiàn)的 RPC，能更靈活地對(duì)協(xié)議字段進(jìn)行定制，相比 http 能減少網(wǎng)絡(luò)傳輸字節(jié)數(shù)，降低網(wǎng)絡(luò)開(kāi)銷（握手）提高性能。實(shí)現(xiàn)更大的吞吐量和并發(fā)數(shù)，但是需要更多的關(guān)注底層復(fù)雜的細(xì)節(jié)， 對(duì)開(kāi)發(fā)人員的要求也高，增加開(kāi)發(fā)成本。

總結(jié)

在面試官奪命三連問(wèn)的攻擊下，前三個(gè)題目一定要掌握，最后一個(gè)加分項(xiàng)徒手寫(xiě) RPC 深入分析，可以大大拉升面試官對(duì)你的好感，只要有亮點(diǎn)，即使其他問(wèn)題答得不好，那么問(wèn)題也不大。

RPC 工作原理總結(jié)：

Provider：服務(wù)提供方，CS 模型中的 Server。

Consumer： 調(diào)用遠(yuǎn)程服務(wù)服務(wù)消費(fèi)方，CS 模型中的 Client。

Registry：服務(wù)注冊(cè)與發(fā)現(xiàn)的服務(wù)管理中心。

Monitor：統(tǒng)計(jì)服務(wù)的調(diào)用次數(shù)和調(diào)用時(shí)間的監(jiān)控中心。

Container：服務(wù)運(yùn)行容器，如 jetty。

RPC 執(zhí)行過(guò)程總結(jié)：

1. 服務(wù)容器負(fù)責(zé)啟動(dòng)，加載，運(yùn)行服務(wù)提供者。
2. 服務(wù)提供者在啟動(dòng)時(shí)，向注冊(cè)中心注冊(cè)自己提供的服務(wù)，暴露自己的 IP 和端口信息。
3. 服務(wù)消費(fèi)者在啟動(dòng)時(shí)，向注冊(cè)中心訂閱自己所需的服務(wù)。
4. 注冊(cè)中心返回服務(wù)提供者列表給消費(fèi)者，如果有變更，注冊(cè)中心將基于長(zhǎng)連接推送給數(shù)據(jù)消費(fèi)者。
5. 服務(wù)消費(fèi)者，從提供這地址列表中，基于軟負(fù)載均衡算法，選一臺(tái)提供者進(jìn)行調(diào)用，如果調(diào)用失敗，再選另外一臺(tái)服務(wù)調(diào)用。
6. 服務(wù)消費(fèi)者和提供者，在內(nèi)存中累計(jì)調(diào)用次數(shù)和調(diào)用時(shí)間，定時(shí)發(fā)送一次統(tǒng)計(jì)數(shù)據(jù)到監(jiān)控中心。

以上就是公司一般使用的分布式RPC框架及其原理的詳細(xì)內(nèi)容，更多關(guān)于分布式RPC框架原理的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論