溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
在過去持續分享的幾十期阿里Java面試題中，幾乎每次都會問到Dubbo相關問題，比如：“如何從0到1設計一個Dubbo的RPC框架”，這個問題主要考察以下幾個方面：
你對RPC框架的底層原理掌握程度。
以及考驗你的整體RPC框架系統設計能力。
具體，我來為大家詳解。
即遠程過程調用, 主要解決遠程通信間的問題，不需要了解底層網絡的通信機制。
RPC框架負責屏蔽底層的傳輸方式（TCP或者UDP）、序列化方式、以及通信細節。
實際使用中，并不需要關心底層通信細節和調用過程，讓業務端專注于業務代碼的實現。
國內大家熟知的PRC框架，阿里的HSF和Dubbo(開源)。
比如早期一個應用Java War包，將所有功能都打包，部署在一個單機服務器，調用接口也比較方便，不涉及到任何分布式場景。
隨著業務的快速發展，業務越來越多、子系統也越來越多時。比如：淘寶的交易系統、商品系統、用戶系統、評價系統...上百個系統的出現。
系統變得越來越復雜，業務代碼依然耦合在一起。比如最早期的淘寶denali工程，包含所有業務系統的代碼，就僅打包部署都需要很長的時間。
并且，隨著每個業務線的快速發展，業務代碼耦合在一起，上線后出現問題急需要回滾代碼，拉分支、大量的代碼merge工作，這個過程極其痛苦。
這個時候，你會發現技術已經成了業務的瓶頸，急需把業務單獨抽離出來，各自單獨部署。
應用系統一旦涉及到拆分部署，問題就來了，急需一種高效的應用程序間的通訊手段來完成這種需求，這就會涉及到分布式遠程調用。
于是，淘寶就把denali按照業務為單位拆分成了類似這樣的系統：UM(UserManger)、SM(ShopManager)..等等幾十個工程代碼。
再按照業務為單位，把所有調用相關的接口以業務為單元進行拆分：UIC(用戶中心服務)、SIC(店鋪中心服務)...等等以業務為單位集群部署，按照業務提供服務。
所以，RPC的框架來了，阿里內部使用HSF，以及開源的RPC 框架：Dubbo。
RPC框架的核心設計
前面提到了RPC的核心目標：主要是解決分布式系統中服務之間的調用問題。
其實，走到這一步涉及的知識體系非常的多：要求對通信、遠程調用、消息機制等有深入的理解和掌握，要求的都是從理論、硬件級、操作系統級以及所采用的語言的實現都有清楚的理解。
1)服務提供者（Server）
對外提供后臺服務，將自己的服務信息，注冊到注冊中心。
2)注冊中心（Registry）
用于服務端注冊遠程服務以及客戶端發現服務。
目前主要的注冊中心可以借由 zookeeper，eureka，consul，etcd 等開源框架實現。
比如：阿里的Dubbo就是采用zookeeper實現注冊中心。
3)服務消費者（Client）
從注冊中心獲取遠程服務的注冊信息，然后進行遠程過程調用。
1）服務調用方（client）調用以本地調用方式調用服務；
2）client stub接收到調用后負責將方法、參數等組裝成能夠進行網絡傳輸的消息體；在Java里就是序列化的過程
3）client stub找到服務地址，并將消息通過網絡發送到服務端；
4）server stub收到消息后進行解碼,在Java里就是反序列化的過程；
5）server stub根據解碼結果調用本地的服務；
6）本地服務執行處理邏輯；
7）本地服務將結果返回給server stub；
8）server stub將返回結果打包成消息，Java里的序列化；
9）server stub將打包后的消息通過網絡并發送至消費方
10）client stub接收到消息，并進行解碼, Java里的反序列化；
11）服務調用方（client）得到最終結果。
RPC框架的目標就是要2~10這些步驟都封裝起來。
首先，要解決通訊的問題，主要是通過在客戶端和服務器之間建立TCP連接，遠程過程調用的所有交換的數據都在這個連接里傳輸。
1）服務注冊
首先需要把服務注冊到服務中心。其實就是在注冊中心進行一個登記，注冊中心存儲了該服務的IP、端口、調用方式(協議、序列化方式)等。在zookeeper中，進行服務注冊，實際上就是在zookeeper中創建了一個znode節點，該節點存儲了上面所說的服務信息。
2）服務發現
服務消費者在第一次調用服務時，會通過注冊中心找到相應的服務的IP地址列表，并緩存到本地，以供后續使用。當消費者調用服務時，不會再去請求注冊中心，而是直接通過負載均衡算法從IP列表中取一個服務提供者的服務器調用服務。
3）注冊服務
可靠的尋址方式（主要是提供服務的發現）是RPC的實現基石，比如可以zookeeper來實現注冊服務等等。
服務提供者啟動后主動向服務（注冊）中心注冊機器ip、端口以及提供的服務列表。
服務消費者啟動時向服務（注冊）中心獲取服務提供方地址列表，可實現軟負載均衡和Failover。
提供者需要定時向注冊中心發送心跳，一段時間未收到來自提供者的心跳后，認為提供者已經停止服務，從注冊中心上摘取掉對應的服務等等。
數據傳輸采用什么協議，數據該如何序列化和反序列化。
當前很多RPC框架都直接基于netty這一IO通信框架，比如阿里巴巴的HSF、dubbo，Hadoop Avro，推薦使用Netty 作為底層通信框架。
比如：B機器進行本地調用（通過代理Proxy）之后得到了返回值，此時還需要再把返回值發送回A機器，同樣也需要經過序列化操作，然后再經過網絡傳輸將二進制數據發送回A機器，而當A機器接收到這些返回值之后，則再次進行反序列化操作
總之，要實現一個RPC不算難，難的是實現一個高性能高可靠的RPC框架，后續將結合Dubbo的實現一起再探討。
以上就是RPC的介紹，更多Redis、Spring Cloud、MySQL數據庫分庫分表等高并發架構設計，關注我我會持續更新
針對于上面所涉及到的知識點我總結出了有1到5年開發經驗的程序員在面試中涉及到的絕大部分架構面試題及答案做成了文檔和架構視頻資料免費分享給大家（包括Dubbo、Redis、Netty、zookeeper、Spring cloud、分布式、高并發等架構技術資料），希望能幫助到您面試前的復習且找到一個好的工作，也節省大家在網上搜索資料的時間來學習，也可以關注我一下以后會有更多干貨分享。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
