国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

如何實現一個分布式RPC框架

Vultr / 682人閱讀

摘要:趁實習前的這段業余時間,我實現了一個輕量級的分布式框架,名字叫做,代碼量不大,但是麻雀雖小卻五臟俱全。目前支持和兩種序列化框架。使用實現服務注冊與發現功能。代碼實現是我學習驗證過程中誕生的一個輕量級分布式框架,代碼放在了。

遠程過程調用(Remote Procedure CallRPC)是一個計算機通信協議。該協議允許運行于一臺計算機的程序調用另一臺計算機的子程序,而程序員無需額外地為這個交互作用編程。RPC的主要目標是讓構建分布式應用更加容易,在提供強大的遠程調用能力的同時不損失本地調用的語義的簡潔性。

趁實習前的這段業余時間,我實現了一個輕量級的分布式RPC框架,名字叫做 buddha,代碼量不大,但是麻雀雖小卻五臟俱全。本篇文章將一步步闡明buddha的設計、框架組件的拆解以及需要考慮的因素。

序列化與反序列化

在網絡中,所有的數據都將會被轉化為字節進行傳送,所以在代碼層面上,一個RPC框架需要實現特定格式的數據與字節數組之間的相互轉化。像Java已經提供了默認的序列化方式,但是如果是在高并發的場景下,使用Java原生的序列化方式可能會遇到性能瓶頸。于是,出現了許多開源的、高效的序列化框架:如KryofastjsonProtobuf等。buddha目前支持Kryofastjson兩種序列化框架。

TCP拆包、粘包

由于TCP只關心字節流,并不知曉上層的數據格式。如果客戶端應用層一次要發送的數據過大時,TCP會將該數據進行分解傳送,因此在服務端需要進行粘包處理(由TCP來保證數據的有序性);如果客戶端一次要發送的數據量很小時,TCP并不會馬上把數據發送出去,而是將其存儲在緩沖區,當達到某個閾值的時候再發送出去,因此在服務端需要進行拆包的工作。

通過以上分析,我們了解了TCP粘包或者拆包的原因,解決這個問題的關鍵在于向數據包添加邊界信息,常用的方法有如下三個。

發送端給每個數據包添加包首部,首部中至少包含數據包的長度,這樣在接收端接收到數據時,通過讀取首部的長度信息得到該數據包有效數據的長度。

發送端將每個數據包封裝為固定長度(多余用0填充),這樣接收端在接收到數據后根據約定好的固定長度讀取每個數據包的數據。

使用特殊符號將每個數據包區分開來,接收端也是通過該特殊符號的劃分數據包的邊界。

buddha采用第一種方式來解決TCP拆包、粘包的問題。

BIO與NIO

BIO往往用于經典的每連接每線程模型,之所以使用多線程,是因為像accept()read()write()等函數都是同步阻塞的,這意味著當應用為單線程且進行IO操作時,如果線程阻塞那么該應用必然會進入掛死狀態,但是實際上此時CPU是處于空閑狀態的。開啟多線程,就可以讓CPU去為更多的線程服務,提高CPU的利用率。但是在活躍線程數較多的情況下,采用多線程模型回帶來如下幾個問題。

線程的創建和銷毀代價頗高,在Linux操作系統中,線程本質上就是一個進程,創建和銷毀線程屬于重量級的操作。

JVM中,每個線程會占用固定大小的棧空間,而JVM的內存空間是有限的,因此如果線程數量過多那么線程本身就會占據過多的資源。

線程的切換成本較高,每次線程切換需要涉及上下文的保存、恢復以及用戶態和內核態的切換。如果線程數過多,那么會有較大比例的CPU時間花費在線程切換上。

使用線程池的方式解決前兩個問題,但是線程切換帶來的開銷還是存在。所以在高并發的場景下,傳統的BIO是無能為力的。而NIO的重要特點是:讀、寫、注冊和接收函數,在等待就緒階段都是非阻塞的,可以立即返回,這就允許我們不使用多線程充分利用CPU。如果一個連接不能讀寫,可以把這個事件記錄下來,然后切換到別的就緒的連接進行數據讀寫。在buddha中,Netty被用來編寫結構更加清晰的NIO程序。

服務注冊與發現

在實際應用中,RPC服務的提供者往往需要使用集群來保證服務的穩定性與可靠性。因此需要實現一個服務注冊中心,服務提供者將當前可用的服務地址信息注冊至注冊中心,而客戶端在進行遠程調用時,先通過服務注冊中心獲取當前可用的服務列表,然后獲取具體的服務提供者的地址信息(該階段可以進行負載均衡),根據地址信息向服務提供者發起調用。客戶端可以緩存可用服務列表,當注冊中心的服務列表發生變更時需要通知客戶端。同時,當服務提供者變為不可用狀態時也需要通知注冊中心服務不可用。buddha使用ZooKeeper實現服務注冊與發現功能。

代碼實現

buddha是我學習驗證RPC過程中誕生的一個輕量級分布式RPC框架,代碼放在了 GitHub。

參考

RPC 的概念模型與實現解析

NettyRpc

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/67289.html

相關文章

  • 布式下的遠程通信技術(RPC)的一些理解

    摘要:都是分開部署,單獨上線的。序列化畢竟是遠程通信,需要將對象轉化成二進制流進行傳輸。服務化架構的演進架構當業務規模很小時,將所有功能都不熟在同一個進程中,通過雙機或者負載均衡器實現負債分流此時,分離前后臺邏輯的架構是關鍵。 showImg(https://segmentfault.com/img/bVbiI2F?w=2250&h=1500); 前言 為什么需要RPC,而不是簡單的HTTP...

    EastWoodYang 評論0 收藏0
  • 布式服務框架之遠程通訊技術及原理分析

    摘要:微軟的雖然引入了事件機制,可以在隊列收到消息時觸發事件,通知訂閱者。由微軟作為主要貢獻者的,則對以及做了進一層包裝,并能夠很好地實現這一模式。 在分布式服務框架中,一個最基礎的問題就是遠程服務是怎么通訊的,在Java領域中有很多可實現遠程通訊的技術,例如:RMI、MINA、ESB、Burlap、Hessian、SOAP、EJB和JMS等,這些名詞之間到底是些什么關系呢,它們背后到底是基...

    sorra 評論0 收藏0
  • 布式服務框架之遠程通訊技術及原理分析

    摘要:微軟的雖然引入了事件機制,可以在隊列收到消息時觸發事件,通知訂閱者。由微軟作為主要貢獻者的,則對以及做了進一層包裝,并能夠很好地實現這一模式。 在分布式服務框架中,一個最基礎的問題就是遠程服務是怎么通訊的,在Java領域中有很多可實現遠程通訊的技術,例如:RMI、MINA、ESB、Burlap、Hessian、SOAP、EJB和JMS等,這些名詞之間到底是些什么關系呢,它們背后到底是基...

    0xE7A38A 評論0 收藏0
  • 后端必備——數據通信知識(RPC、消息隊列)一站式總結

    摘要:具體可以參考消息隊列之具體可以參考實戰之快速入門十分鐘入門阿里中間件團隊博客是一個分布式的可分區的可復制的基于發布訂閱的消息系統主要用于大數據領域當然在分布式系統中也有應用。目前市面上流行的消息隊列就是阿里借鑒的原理用開發而得。 我自己總結的Java學習的系統知識點以及面試問題,目前已經開源,會一直完善下去,歡迎建議和指導歡迎Star: https://github.com/Snail...

    Kahn 評論0 收藏0
  • SOA面向服務基礎

    摘要:面向服務面向服務的基礎面向服務的三層應用層,服務層,數據層應用層用于給用戶展示,,,,安卓。在服務器端,進程保持睡眠狀態直到調用信息到達為止。編譯完成,提示我們已經在下了。 面向服務 面向服務的基礎 面向服務的三層:應用層,服務層,數據層 * 應用層:用于給用戶展示,PC,H5,IOS,安卓。 * 服務層:業務邏輯,提供接口(商品,訂單,支付,用戶,物流)。 * 數據層:提供數據支持(...

    songze 評論0 收藏0

發表評論

0條評論

Vultr

|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<