整天跟微服務(wù)打交道怖竭,你不會(huì)連RPC都不知道吧锥债?

首先了解什么叫RPC,為什么要RPC痊臭,RPC是指遠(yuǎn)程過(guò)程調(diào)用哮肚,也就是說(shuō)兩臺(tái)服務(wù)器A,B广匙,一個(gè)應(yīng)用部署在A服務(wù)器上允趟,想要調(diào)用B服務(wù)器上應(yīng)用提供的函數(shù)/方法,由于不在一個(gè)內(nèi)存空間鸦致,不能直接調(diào)用潮剪,需要通過(guò)網(wǎng)絡(luò)來(lái)表達(dá)調(diào)用的語(yǔ)義和傳達(dá)調(diào)用的數(shù)據(jù)涣楷。

RPC 功能目標(biāo)

RPC 的主要功能目標(biāo)是讓構(gòu)建分布式計(jì)算(應(yīng)用)更容易,在提供強(qiáng)大的遠(yuǎn)程調(diào)用能力時(shí)不損失本地調(diào)用的語(yǔ)義簡(jiǎn)潔性抗碰。為實(shí)現(xiàn)該目標(biāo)狮斗,RPC 框架需提供一種透明調(diào)用機(jī)制讓使用者不必顯式的區(qū)分本地調(diào)用和遠(yuǎn)程調(diào)用,在前文《淺出篇》中給出了一種實(shí)現(xiàn)結(jié)構(gòu)弧蝇,基于 stub 的結(jié)構(gòu)來(lái)實(shí)現(xiàn)碳褒。下面我們將具體細(xì)化 stub 結(jié)構(gòu)的實(shí)現(xiàn)。

RPC 調(diào)用分類

RPC 調(diào)用分以下兩種:

1. 同步調(diào)用

客戶方等待調(diào)用執(zhí)行完成并返回結(jié)果看疗。

2. 異步調(diào)用

客戶方調(diào)用后不用等待執(zhí)行結(jié)果返回沙峻,但依然可以通過(guò)回調(diào)通知等方式獲取返回結(jié)果。

若客戶方不關(guān)心調(diào)用返回結(jié)果两芳,則變成單向異步調(diào)用专酗,單向調(diào)用不用返回結(jié)果。

異步和同步的區(qū)分在于是否等待服務(wù)端執(zhí)行完成并返回結(jié)果盗扇。

RPC 結(jié)構(gòu)拆解

《淺出篇》給出了一個(gè)比較粗粒度的 RPC 實(shí)現(xiàn)概念結(jié)構(gòu)祷肯,這里我們進(jìn)一步細(xì)化它應(yīng)該由哪些組件構(gòu)成,如下圖所示疗隶。

RPC 服務(wù)方通過(guò)RpcServer去導(dǎo)出(export)遠(yuǎn)程接口方法佑笋,而客戶方通過(guò)RpcClient去引入(import)遠(yuǎn)程接口方法“弑牵客戶方像調(diào)用本地方法一樣去調(diào)用遠(yuǎn)程接口方法蒋纬,RPC 框架提供接口的代理實(shí)現(xiàn),實(shí)際的調(diào)用將委托給代理RpcProxy坚弱。代理封裝調(diào)用信息并將調(diào)用轉(zhuǎn)交給RpcInvoker去實(shí)際執(zhí)行蜀备。在客戶端的RpcInvoker通過(guò)連接器RpcConnector去維持與服務(wù)端的通道RpcChannel,并使用RpcProtocol執(zhí)行協(xié)議編碼(encode)并將編碼后的請(qǐng)求消息通過(guò)通道發(fā)送給服務(wù)方荒叶。

RPC 服務(wù)端接收器RpcAcceptor接收客戶端的調(diào)用請(qǐng)求碾阁,同樣使用RpcProtocol執(zhí)行協(xié)議解碼(decode)。解碼后的調(diào)用信息傳遞給RpcProcessor去控制處理調(diào)用過(guò)程些楣,最后再委托調(diào)用給RpcInvoker去實(shí)際執(zhí)行并返回調(diào)用結(jié)果脂凶。

RPC 組件職責(zé)

上面我們進(jìn)一步拆解了 RPC 實(shí)現(xiàn)結(jié)構(gòu)的各個(gè)組件組成部分,下面我們?cè)敿?xì)說(shuō)明下每個(gè)組件的職責(zé)劃分愁茁。

1. RpcServer

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

2. RpcClient

負(fù)責(zé)導(dǎo)入(import)遠(yuǎn)程接口的代理實(shí)現(xiàn)

3. RpcProxy

遠(yuǎn)程接口的代理實(shí)現(xiàn)

4. RpcInvoker

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

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

5. RpcProtocol

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

6. RpcConnector

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

7. RpcAcceptor

負(fù)責(zé)接收客戶方請(qǐng)求并返回請(qǐng)求結(jié)果

8. RpcProcessor

負(fù)責(zé)在服務(wù)方控制調(diào)用過(guò)程蚕钦,包括管理調(diào)用線程池、超時(shí)時(shí)間等

9. RpcChannel

數(shù)據(jù)傳輸通道

RPC 實(shí)現(xiàn)分析

在進(jìn)一步拆解了組件并劃分了職責(zé)之后鹅很,這里以在 java 平臺(tái)實(shí)現(xiàn)該 RPC 框架概念模型為例嘶居,詳細(xì)分析下實(shí)現(xiàn)中需要考慮的因素。

導(dǎo)出遠(yuǎn)程接口

導(dǎo)出遠(yuǎn)程接口的意思是指只有導(dǎo)出的接口可以供遠(yuǎn)程調(diào)用促煮,而未導(dǎo)出的接口則不能邮屁。在 java 中導(dǎo)出接口的代碼片段可能如下:

DemoService demo ? =new...;

RpcServer ? server =new...;

server.export(DemoService.class, demo, options);

我們可以導(dǎo)出整個(gè)接口整袁,也可以更細(xì)粒度一點(diǎn)只導(dǎo)出接口中的某些方法,如:

// 只導(dǎo)出 DemoService 中簽名為 hi(String s) 的方法 ?

server.export(DemoService.class, demo,"hi",newClass[]{ String.class }, options);

java 中還有一種比較特殊的調(diào)用就是多態(tài)樱报,也就是一個(gè)接口可能有多個(gè)實(shí)現(xiàn)葬项,那么遠(yuǎn)程調(diào)用時(shí)到底調(diào)用哪個(gè)?這個(gè)本地調(diào)用的語(yǔ)義是通過(guò) jvm 提供的引用多態(tài)性隱式實(shí)現(xiàn)的迹蛤,那么對(duì)于 RPC 來(lái)說(shuō)跨進(jìn)程的調(diào)用就沒(méi)法隱式實(shí)現(xiàn)了民珍。如果前面DemoService?接口有 2 個(gè)實(shí)現(xiàn),那么在導(dǎo)出接口時(shí)就需要特殊標(biāo)記不同的實(shí)現(xiàn)盗飒,如:

DemoService demo ? =new...;

DemoService demo2 ?=new...;

RpcServer ? server =new...;

server.export(DemoService.class, demo, options);

server.export("demo2", DemoService.class, demo2, options);

上面 demo2 是另一個(gè)實(shí)現(xiàn)嚷量,我們標(biāo)記為 "demo2" 來(lái)導(dǎo)出,那么遠(yuǎn)程調(diào)用時(shí)也需要傳遞該標(biāo)記才能調(diào)用到正確的實(shí)現(xiàn)類逆趣,這樣就解決了多態(tài)調(diào)用的語(yǔ)義蝶溶。

導(dǎo)入遠(yuǎn)程接口與客戶端代理

導(dǎo)入相對(duì)于導(dǎo)出遠(yuǎn)程接口,客戶端代碼為了能夠發(fā)起調(diào)用必須要獲得遠(yuǎn)程接口的方法或過(guò)程定義宣渗。目前抖所,大部分跨語(yǔ)言平臺(tái) RPC 框架采用根據(jù) IDL 定義通過(guò) code generator 去生成 stub 代碼,這種方式下實(shí)際導(dǎo)入的過(guò)程就是通過(guò)代碼生成器在編譯期完成的痕囱。我所使用過(guò)的一些跨語(yǔ)言平臺(tái) RPC 框架如 CORBAR田轧、WebService、ICE鞍恢、Thrift 均是此類方式傻粘。

代碼生成的方式對(duì)跨語(yǔ)言平臺(tái) RPC 框架而言是必然的選擇,而對(duì)于同一語(yǔ)言平臺(tái)的 RPC 則可以通過(guò)共享接口定義來(lái)實(shí)現(xiàn)帮掉。在 java 中導(dǎo)入接口的代碼片段可能如下:

RpcClient client =new...;

DemoService demo = client.refer(DemoService.class);

demo.hi("how are you?");

在 java 中 'import' 是關(guān)鍵字弦悉,所以代碼片段中我們用 refer 來(lái)表達(dá)導(dǎo)入接口的意思。這里的導(dǎo)入方式本質(zhì)也是一種代碼生成技術(shù)蟆炊,只不過(guò)是在運(yùn)行時(shí)生成稽莉,比靜態(tài)編譯期的代碼生成看起來(lái)更簡(jiǎn)潔些。java 里至少提供了兩種技術(shù)來(lái)提供動(dòng)態(tài)代碼生成盅称,一種是 jdk 動(dòng)態(tài)代理肩祥,另外一種是字節(jié)碼生成。動(dòng)態(tài)代理相比字節(jié)碼生成使用起來(lái)更方便缩膝,但動(dòng)態(tài)代理方式在性能上是要遜色于直接的字節(jié)碼生成的,而字節(jié)碼生成在代碼可讀性上要差很多岸霹。兩者權(quán)衡起來(lái)疾层,個(gè)人認(rèn)為犧牲一些性能來(lái)獲得代碼可讀性和可維護(hù)性顯得更重要。

協(xié)議編解碼

客戶端代理在發(fā)起調(diào)用前需要對(duì)調(diào)用信息進(jìn)行編碼贡避,這就要考慮需要編碼些什么信息并以什么格式傳輸?shù)椒?wù)端才能讓服務(wù)端完成調(diào)用痛黎。出于效率考慮予弧,編碼的信息越少越好(傳輸數(shù)據(jù)少),編碼的規(guī)則越簡(jiǎn)單越好(執(zhí)行效率高)湖饱。我們先看下需要編碼些什么信息:

-- 調(diào)用編碼 --

1. 接口方法

包括接口名掖蛤、方法名

2. 方法參數(shù)

包括參數(shù)類型、參數(shù)值

3. 調(diào)用屬性

包括調(diào)用屬性信息井厌,例如調(diào)用附件隱式參數(shù)蚓庭、調(diào)用超時(shí)時(shí)間等

-- 返回編碼 --

1. 返回結(jié)果

接口方法中定義的返回值

2. 返回碼

異常返回碼

3. 返回異常信息

調(diào)用異常信息

除了以上這些必須的調(diào)用信息,我們可能還需要一些元信息以方便程序編解碼以及未來(lái)可能的擴(kuò)展仅仆。這樣我們的編碼消息里面就分成了兩部分器赞,一部分是元信息、另一部分是調(diào)用的必要信息墓拜。如果設(shè)計(jì)一種 RPC 協(xié)議消息的話港柜,元信息我們把它放在協(xié)議消息頭中,而必要信息放在協(xié)議消息體中。下面給出一種概念上的 RPC 協(xié)議消息設(shè)計(jì)格式:

-- 消息頭 -- ?

magic ? ? ?: 協(xié)議魔數(shù),為解碼設(shè)計(jì)

header size: 協(xié)議頭長(zhǎng)度州刽,為擴(kuò)展設(shè)計(jì)

version ? ?: 協(xié)議版本唤殴,為兼容設(shè)計(jì)

st ? ? ? ? : 消息體序列化類型

hb ? ? ? ? : 心跳消息標(biāo)記,為長(zhǎng)連接傳輸層心跳設(shè)計(jì)

ow ? ? ? ? : 單向消息標(biāo)記澜驮,

rp ? ? ? ? : 響應(yīng)消息標(biāo)記,不置位默認(rèn)是請(qǐng)求消息

statuscode: 響應(yīng)消息狀態(tài)碼

reserved ? : 為字節(jié)對(duì)齊保留

message id : 消息 id

body size ?: 消息體長(zhǎng)度

-- 消息體 -- ?

采用序列化編碼,常見(jiàn)有以下格式

xml ? : 如 webservie soap

json ?: 如 JSON-RPC

binary: 如 thrift; hession; kryo 等

格式確定后編解碼就簡(jiǎn)單了释树,由于頭長(zhǎng)度一定所以我們比較關(guān)心的就是消息體的序列化方式。序列化我們關(guān)心三個(gè)方面:

1. 序列化和反序列化的效率擎淤,越快越好奢啥。

2. 序列化后的字節(jié)長(zhǎng)度,越小越好嘴拢。

3. 序列化和反序列化的兼容性桩盲,接口參數(shù)對(duì)象若增加了字段,是否兼容席吴。

上面這三點(diǎn)有時(shí)是魚(yú)與熊掌不可兼得赌结,這里面涉及到具體的序列化庫(kù)實(shí)現(xiàn)細(xì)節(jié),就不在本文進(jìn)一步展開(kāi)分析了孝冒。

傳輸服務(wù)

協(xié)議編碼之后柬姚,自然就是需要將編碼后的 RPC 請(qǐng)求消息傳輸?shù)椒?wù)方,服務(wù)方執(zhí)行后返回結(jié)果消息或確認(rèn)消息給客戶方庄涡。RPC 的應(yīng)用場(chǎng)景實(shí)質(zhì)是一種可靠的請(qǐng)求應(yīng)答消息流量承,和 HTTP 類似。因此選擇長(zhǎng)連接方式的 TCP 協(xié)議會(huì)更高效,與 HTTP 不同的是在協(xié)議層面我們定義了每個(gè)消息的唯一 id撕捍,因此可以更容易的復(fù)用連接拿穴。

既然使用長(zhǎng)連接,那么第一個(gè)問(wèn)題是到底 client 和 server 之間需要多少根連接忧风?實(shí)際上單連接和多連接在使用上沒(méi)有區(qū)別默色,對(duì)于數(shù)據(jù)傳輸量較小的應(yīng)用類型,單連接基本足夠狮腿。單連接和多連接最大的區(qū)別在于腿宰,每根連接都有自己私有的發(fā)送和接收緩沖區(qū),因此大數(shù)據(jù)量傳輸時(shí)分散在不同的連接緩沖區(qū)會(huì)得到更好的吞吐效率蚤霞。所以酗失,如果你的數(shù)據(jù)傳輸量不足以讓單連接的緩沖區(qū)一直處于飽和狀態(tài)的話,那么使用多連接并不會(huì)產(chǎn)生任何明顯的提升昧绣,反而會(huì)增加連接管理的開(kāi)銷规肴。

連接是由 client 端發(fā)起建立并維持。如果 client 和 server 之間是直連的夜畴,那么連接一般不會(huì)中斷(當(dāng)然物理鏈路故障除外)拖刃。如果 client 和 server 連接經(jīng)過(guò)一些負(fù)載中轉(zhuǎn)設(shè)備,有可能連接一段時(shí)間不活躍時(shí)會(huì)被這些中間設(shè)備中斷贪绘。為了保持連接有必要定時(shí)為每個(gè)連接發(fā)送心跳數(shù)據(jù)以維持連接不中斷兑牡。心跳消息是 RPC 框架庫(kù)使用的內(nèi)部消息,在前文協(xié)議頭結(jié)構(gòu)中也有一個(gè)專門的心跳位税灌,就是用來(lái)標(biāo)記心跳消息的均函,它對(duì)業(yè)務(wù)應(yīng)用透明。

執(zhí)行調(diào)用

client stub 所做的事情僅僅是編碼消息并傳輸給服務(wù)方菱涤,而真正調(diào)用過(guò)程發(fā)生在服務(wù)方苞也。server stub 從前文的結(jié)構(gòu)拆解中我們細(xì)分了RpcProcessor和RpcInvoker兩個(gè)組件,一個(gè)負(fù)責(zé)控制調(diào)用過(guò)程粘秆,一個(gè)負(fù)責(zé)真正調(diào)用如迟。這里我們還是以 java 中實(shí)現(xiàn)這兩個(gè)組件為例來(lái)分析下它們到底需要做什么?

java 中實(shí)現(xiàn)代碼的動(dòng)態(tài)接口調(diào)用目前一般通過(guò)反射調(diào)用攻走。除了原生的 jdk 自帶的反射殷勘,一些第三方庫(kù)也提供了性能更優(yōu)的反射調(diào)用,因此RpcInvoker就是封裝了反射調(diào)用的實(shí)現(xiàn)細(xì)節(jié)昔搂。

調(diào)用過(guò)程的控制需要考慮哪些因素玲销,RpcProcessor需要提供什么樣地調(diào)用控制服務(wù)呢?下面提出幾點(diǎn)以啟發(fā)思考:

1. 效率提升

每個(gè)請(qǐng)求應(yīng)該盡快被執(zhí)行摘符,因此我們不能每請(qǐng)求來(lái)再創(chuàng)建線程去執(zhí)行痒玩,需要提供線程池服務(wù)淳附。

2. 資源隔離

當(dāng)我們導(dǎo)出多個(gè)遠(yuǎn)程接口時(shí)议慰,如何避免單一接口調(diào)用占據(jù)所有線程資源蠢古,而引發(fā)其他接口執(zhí)行阻塞。

3. 超時(shí)控制

當(dāng)某個(gè)接口執(zhí)行緩慢别凹,而 client 端已經(jīng)超時(shí)放棄等待后草讶,server 端的線程繼續(xù)執(zhí)行此時(shí)顯得毫無(wú)意義。

RPC 異常處理

無(wú)論 RPC 怎樣努力把遠(yuǎn)程調(diào)用偽裝的像本地調(diào)用炉菲,但它們依然有很大的不同點(diǎn)堕战,而且有一些異常情況是在本地調(diào)用時(shí)絕對(duì)不會(huì)碰到的。在說(shuō)異常處理之前拍霜,我們先比較下本地調(diào)用和 RPC 調(diào)用的一些差異:

1. 本地調(diào)用一定會(huì)執(zhí)行嘱丢,而遠(yuǎn)程調(diào)用則不一定,調(diào)用消息可能因?yàn)榫W(wǎng)絡(luò)原因并未發(fā)送到服務(wù)方祠饺。

2. 本地調(diào)用只會(huì)拋出接口聲明的異常越驻,而遠(yuǎn)程調(diào)用還會(huì)跑出 RPC 框架運(yùn)行時(shí)的其他異常。

3. 本地調(diào)用和遠(yuǎn)程調(diào)用的性能可能差距很大道偷,這取決于 RPC 固有消耗所占的比重缀旁。

正是這些區(qū)別決定了使用 RPC 時(shí)需要更多考量。當(dāng)調(diào)用遠(yuǎn)程接口拋出異常時(shí)勺鸦,異巢⑽。可能是一個(gè)業(yè)務(wù)異常,也可能是 RPC 框架拋出的運(yùn)行時(shí)異常(如:網(wǎng)絡(luò)中斷等)换途。業(yè)務(wù)異常表明服務(wù)方已經(jīng)執(zhí)行了調(diào)用懊渡,可能因?yàn)槟承┰驅(qū)е挛茨苷?zhí)行,而 RPC 運(yùn)行時(shí)異常則有可能服務(wù)方根本沒(méi)有執(zhí)行军拟,對(duì)調(diào)用方而言的異常處理策略自然需要區(qū)分剃执。

由于 RPC 固有的消耗相對(duì)本地調(diào)用高出幾個(gè)數(shù)量級(jí),本地調(diào)用的固有消耗是納秒級(jí)吻谋,而 RPC 的固有消耗是在毫秒級(jí)忠蝗。那么對(duì)于過(guò)于輕量的計(jì)算任務(wù)就并不合適導(dǎo)出遠(yuǎn)程接口由獨(dú)立的進(jìn)程提供服務(wù),只有花在計(jì)算任務(wù)上時(shí)間遠(yuǎn)遠(yuǎn)高于 RPC 的固有消耗才值得導(dǎo)出為遠(yuǎn)程接口提供服務(wù)漓拾。

總結(jié)

至此我們提出了一個(gè) RPC 實(shí)現(xiàn)的概念框架阁最,并詳細(xì)分析了需要考慮的一些實(shí)現(xiàn)細(xì)節(jié)。無(wú)論 RPC 的概念是如何優(yōu)雅骇两,但是“草叢中依然有幾條蛇隱藏著”速种,只有深刻理解了 RPC 的本質(zhì),才能更好地應(yīng)用低千。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 序言:七十年代末配阵,一起剝皮案震驚了整個(gè)濱河市馏颂,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌棋傍,老刑警劉巖救拉,帶你破解...
    沈念sama閱讀 223,002評(píng)論 6 519
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場(chǎng)離奇詭異瘫拣,居然都是意外死亡亿絮,警方通過(guò)查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 95,357評(píng)論 3 400
  • 文/潘曉璐 我一進(jìn)店門麸拄,熙熙樓的掌柜王于貴愁眉苦臉地迎上來(lái)派昧,“玉大人,你說(shuō)我怎么就攤上這事拢切〉傥” “怎么了?”我有些...
    開(kāi)封第一講書(shū)人閱讀 169,787評(píng)論 0 365
  • 文/不壞的土叔 我叫張陵淮椰,是天一觀的道長(zhǎng)五慈。 經(jīng)常有香客問(wèn)我,道長(zhǎng)实苞,這世上最難降的妖魔是什么豺撑? 我笑而不...
    開(kāi)封第一講書(shū)人閱讀 60,237評(píng)論 1 300
  • 正文 為了忘掉前任,我火速辦了婚禮黔牵,結(jié)果婚禮上聪轿,老公的妹妹穿的比我還像新娘。我一直安慰自己猾浦,他們只是感情好陆错,可當(dāng)我...
    茶點(diǎn)故事閱讀 69,237評(píng)論 6 398
  • 文/花漫 我一把揭開(kāi)白布。 她就那樣靜靜地躺著金赦,像睡著了一般音瓷。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上夹抗,一...
    開(kāi)封第一講書(shū)人閱讀 52,821評(píng)論 1 314
  • 那天绳慎,我揣著相機(jī)與錄音,去河邊找鬼漠烧。 笑死杏愤,一個(gè)胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的已脓。 我是一名探鬼主播珊楼,決...
    沈念sama閱讀 41,236評(píng)論 3 424
  • 文/蒼蘭香墨 我猛地睜開(kāi)眼,長(zhǎng)吁一口氣:“原來(lái)是場(chǎng)噩夢(mèng)啊……” “哼度液!你這毒婦竟也來(lái)了厕宗?” 一聲冷哼從身側(cè)響起画舌,我...
    開(kāi)封第一講書(shū)人閱讀 40,196評(píng)論 0 277
  • 序言:老撾萬(wàn)榮一對(duì)情侶失蹤,失蹤者是張志新(化名)和其女友劉穎已慢,沒(méi)想到半個(gè)月后曲聂,有當(dāng)?shù)厝嗽跇?shù)林里發(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 46,716評(píng)論 1 320
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡蛇受,尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 38,794評(píng)論 3 343
  • 正文 我和宋清朗相戀三年句葵,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片兢仰。...
    茶點(diǎn)故事閱讀 40,928評(píng)論 1 353
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡,死狀恐怖剂碴,靈堂內(nèi)的尸體忽然破棺而出把将,到底是詐尸還是另有隱情,我是刑警寧澤忆矛,帶...
    沈念sama閱讀 36,583評(píng)論 5 351
  • 正文 年R本政府宣布察蹲,位于F島的核電站,受9級(jí)特大地震影響催训,放射性物質(zhì)發(fā)生泄漏洽议。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 42,264評(píng)論 3 336
  • 文/蒙蒙 一漫拭、第九天 我趴在偏房一處隱蔽的房頂上張望亚兄。 院中可真熱鬧,春花似錦采驻、人聲如沸审胚。這莊子的主人今日做“春日...
    開(kāi)封第一講書(shū)人閱讀 32,755評(píng)論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽(yáng)膳叨。三九已至,卻和暖如春痘系,著一層夾襖步出監(jiān)牢的瞬間菲嘴,已是汗流浹背。 一陣腳步聲響...
    開(kāi)封第一講書(shū)人閱讀 33,869評(píng)論 1 274
  • 我被黑心中介騙來(lái)泰國(guó)打工汰翠, 沒(méi)想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留龄坪,地道東北人。 一個(gè)月前我還...
    沈念sama閱讀 49,378評(píng)論 3 379
  • 正文 我出身青樓奴璃,卻偏偏與公主長(zhǎng)得像悉默,于是被迫代替她去往敵國(guó)和親。 傳聞我的和親對(duì)象是個(gè)殘疾皇子苟穆,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 45,937評(píng)論 2 361

推薦閱讀更多精彩內(nèi)容

  • 今天分布式應(yīng)用抄课、云計(jì)算唱星、微服務(wù)大行其道,作為其技術(shù)基石之一的 RPC 你了解多少跟磨?一篇 RPC 的技術(shù)總結(jié)文章间聊,數(shù)...
    零一間閱讀 1,903評(píng)論 1 46
  • 原文地址:http://blog.csdn.net/mindfloating/article/details/39...
    hongyuan閱讀 2,451評(píng)論 0 19
  • 《深入篇》我們主要圍繞 RPC 的功能目標(biāo)和實(shí)現(xiàn)考量去展開(kāi),一個(gè)基本的 RPC 框架應(yīng)該提供什么功能抵拘,滿足什么要求...
    Yt_cc閱讀 237評(píng)論 0 0
  • 《深入篇》我們主要圍繞 RPC 的功能目標(biāo)和實(shí)現(xiàn)考量去展開(kāi)哎榴,一個(gè)基本的 RPC 框架應(yīng)該提供什么功能,滿足什么要求...
    Yt_cc閱讀 173評(píng)論 0 0
  • 深夜獨(dú)自彳亍總會(huì)不經(jīng)意回想起很多過(guò)往。無(wú)奈的是充尉,我的記憶力有點(diǎn)好飘言,總是能記住很多年前的細(xì)枝末節(jié)。而這些深刻的記憶中...
    USEEING閱讀 330評(píng)論 0 1