Hadoop9 RPC介紹

RPC

轉(zhuǎn)載:http://blog.csdn.net/mindfloating/article/details/39474123

1.主要框架

近幾年的項(xiàng)目中,服務(wù)化和微服務(wù)化漸漸成為中大型分布式系統(tǒng)架構(gòu)的主流方式,而 RPC 在其中扮演著關(guān)鍵的作用。在平時的日常開發(fā)中我們都在隱式或顯式的使用 RPC,一些剛?cè)胄械某绦騿T會感覺 RPC 比較神秘洞翩,而一些有多年使用 RPC 經(jīng)驗(yàn)的程序員雖然使用經(jīng)驗(yàn)豐富检号,但有些對其原理也不甚了了赴肚。缺乏對原理層面的理解,往往也會造成開發(fā)中的一些誤用鸟整。

本文分上下兩篇《淺出篇》和《深入篇》引镊,其目標(biāo)就是想嘗試深入淺出的分析下 RPC 本質(zhì),我總是這么認(rèn)為理解了本質(zhì)才能更好的應(yīng)用篮条。

RPC 是什么弟头?

RPC 的全稱是 Remote Procedure Call 是一種進(jìn)程間通信方式。它允許程序調(diào)用另一個地址空間(通常是共享網(wǎng)絡(luò)的另一臺機(jī)器上)的過程或函數(shù)兑燥,而不用程序員顯式編碼這個遠(yuǎn)程調(diào)用的細(xì)節(jié)。即程序員無論是調(diào)用本地的還是遠(yuǎn)程的琴拧,本質(zhì)上編寫的調(diào)用代碼基本相同降瞳。

RPC 起源

RPC 這個概念術(shù)語在上世紀(jì) 80 年代由 Bruce Jay Nelson 提出。這里我們追溯下當(dāng)初開發(fā) RPC 的原動機(jī)是什么?在 Nelson 的論文 "Implementing Remote Procedure Calls" 中他提到了幾點(diǎn):

\1. 簡單:RPC 概念的語義十分清晰和簡單挣饥,這樣建立分布式計算就更容易除师。
\2. 高效:過程調(diào)用看起來十分簡單而且高效。
\3. 通用:在單機(jī)計算中過程往往是不同算法部分間最重要的通信機(jī)制扔枫。

通俗一點(diǎn)說汛聚,就是一般程序員對于本地的過程調(diào)用很熟悉,那么我們把 RPC 作成和本地調(diào)用完全類似短荐,那么就更容易被接受倚舀,使用起來毫無障礙。Nelson 的論文發(fā)表于 30 年前忍宋,其觀點(diǎn)今天看來確實(shí)高瞻遠(yuǎn)矚痕貌,今天我們使用的 RPC 框架基本就是按這個目標(biāo)來實(shí)現(xiàn)的。

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

Nelson 的論文中指出實(shí)現(xiàn) RPC 的程序包括 5 個部分:

\1. User
\2. User-stub
\3. RPCRuntime
\4. Server-stub
\5. Server

這 5 個部分的關(guān)系如下圖所示


img

這里 user 就是 client 端糠排,當(dāng) user 想發(fā)起一個遠(yuǎn)程調(diào)用時舵稠,它實(shí)際是通過本地調(diào)用 user-stub。user-stub 負(fù)責(zé)將調(diào)用的接口入宦、方法和參數(shù)通過約定的協(xié)議規(guī)范進(jìn)行編碼并通過本地的 RPCRuntime 實(shí)例傳輸?shù)竭h(yuǎn)端的實(shí)例哺徊。遠(yuǎn)端 RPCRuntime 實(shí)例收到請求后交給 server-stub 進(jìn)行解碼后發(fā)起本地端調(diào)用,調(diào)用結(jié)果再返回給 user 端乾闰。

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

Nelson 論文中給出的這個實(shí)現(xiàn)結(jié)構(gòu)也成為后來大家參考的標(biāo)準(zhǔn)范本落追。大約 10 年前,我最早接觸分布式計算時使用的 CORBAR 實(shí)現(xiàn)結(jié)構(gòu)基本與此類似汹忠。CORBAR 為了解決異構(gòu)平臺的 RPC淋硝,使用了 IDL(Interface Definition Language)來定義遠(yuǎn)程接口,并將其映射到特定的平臺語言中宽菜。后來大部分的跨語言平臺 RPC 基本都采用了此類方式谣膳,比如我們熟悉的 Web Service(SOAP),近年開源的 Thrift 等铅乡。他們大部分都通過 IDL 定義继谚,并提供工具來映射生成不同語言平臺的 user-stub 和 server-stub,并通過框架庫來提供 RPCRuntime 的支持阵幸。不過貌似每個不同的 RPC 框架都定義了各自不同的 IDL 格式花履,導(dǎo)致程序員的學(xué)習(xí)成本進(jìn)一步上升(苦逼啊)挚赊,Web Service 嘗試建立業(yè)界標(biāo)準(zhǔn)诡壁,無賴標(biāo)準(zhǔn)規(guī)范復(fù)雜而效率偏低,否則 Thrift 等更高效的 RPC 框架就沒必要出現(xiàn)了荠割。

IDL 是為了跨平臺語言實(shí)現(xiàn) RPC 不得已的選擇妹卿,要解決更廣泛的問題自然導(dǎo)致了更復(fù)雜的方案旺矾。而對于同一平臺內(nèi)的 RPC 而言顯然沒必要搞個中間語言出來,例如 java 原生的 RMI夺克,這樣對于 java 程序員而言顯得更直接簡單箕宙,降低使用的學(xué)習(xí)成本。目前市面上提供的 RPC 框架已經(jīng)可算是五花八門铺纽,百家爭鳴了柬帕。需要根據(jù)實(shí)際使用場景謹(jǐn)慎選型,需要考慮的選型因素我覺得至少包括下面幾點(diǎn):
\1. 性能指標(biāo)
\2. 是否需要跨語言平臺
\3. 內(nèi)網(wǎng)開放還是公網(wǎng)開放
\4. 開源 RPC 框架本身的質(zhì)量狡门、社區(qū)活躍度

2.細(xì)節(jié)

RPC 功能目標(biāo)

RPC 的主要功能目標(biāo)是讓構(gòu)建分布式計算(應(yīng)用)更容易陷寝,在提供強(qiáng)大的遠(yuǎn)程調(diào)用能力時不損失本地調(diào)用的語義簡潔性。為實(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)來實(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é)果返回致扯,但依然可以通過回調(diào)通知等方式獲取返回結(jié)果肤寝。

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

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

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

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

img

RPC 服務(wù)方通過 RpcServer 去導(dǎo)出(export)遠(yuǎn)程接口方法蹈垢,而客戶方通過 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 通過連接器RpcConnector 去維持與服務(wù)端的通道RpcChannel堰酿,并使用RpcProtocol 執(zhí)行協(xié)議編碼(encode)并將編碼后的請求消息通過通道發(fā)送給服務(wù)方。

RPC 服務(wù)端接收器 RpcAcceptor 接收客戶端的調(diào)用請求张足,同樣使用RpcProtocol 執(zhí)行協(xié)議解碼(decode)触创。解碼后的調(diào)用信息傳遞給RpcProcessor 去控制處理調(diào)用過程,最后再委托調(diào)用給RpcInvoker 去實(shí)際執(zhí)行并返回調(diào)用結(jié)果为牍。

RPC 組件職責(zé)

上面我們進(jìn)一步拆解了 RPC 實(shí)現(xiàn)結(jié)構(gòu)的各個組件組成部分哼绑,下面我們詳細(xì)說明下每個組件的職責(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)用請求到服務(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é)接收客戶方請求并返回請求結(jié)果  
8. RpcProcessor  
   負(fù)責(zé)在服務(wù)方控制調(diào)用過程,包括管理調(diào)用線程池凌那、超時時間等  
9. RpcChannel  
   數(shù)據(jù)傳輸通道  

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

在進(jìn)一步拆解了組件并劃分了職責(zé)之后,這里以在 java 平臺實(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)出整個接口励稳,也可以更細(xì)粒度一點(diǎn)只導(dǎo)出接口中的某些方法,如:


// 只導(dǎo)出 DemoService 中簽名為 hi(String s) 的方法  
server.export(DemoService.class, demo, "hi", new Class<?>[] { String.class }, options); 

java 中還有一種比較特殊的調(diào)用就是多態(tài)囱井,也就是一個接口可能有多個實(shí)現(xiàn)驹尼,那么遠(yuǎn)程調(diào)用時到底調(diào)用哪個?這個本地調(diào)用的語義是通過 jvm 提供的引用多態(tài)性隱式實(shí)現(xiàn)的庞呕,那么對于 RPC 來說跨進(jìn)程的調(diào)用就沒法隱式實(shí)現(xiàn)了新翎。如果前面DemoService 接口有 2 個實(shí)現(xiàn),那么在導(dǎo)出接口時就需要特殊標(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 是另一個實(shí)現(xiàn)地啰,我們標(biāo)記為 "demo2" 來導(dǎo)出,那么遠(yuǎn)程調(diào)用時也需要傳遞該標(biāo)記才能調(diào)用到正確的實(shí)現(xiàn)類讲逛,這樣就解決了多態(tài)調(diào)用的語義亏吝。

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

導(dǎo)入相對于導(dǎo)出遠(yuǎn)程接口,客戶端代碼為了能夠發(fā)起調(diào)用必須要獲得遠(yuǎn)程接口的方法或過程定義盏混。目前蔚鸥,大部分跨語言平臺 RPC 框架采用根據(jù) IDL 定義通過 code generator 去生成 stub 代碼,這種方式下實(shí)際導(dǎo)入的過程就是通過代碼生成器在編譯期完成的许赃。我所使用過的一些跨語言平臺 RPC 框架如 CORBAR止喷、WebService、ICE图焰、Thrift 均是此類方式启盛。

代碼生成的方式對跨語言平臺 RPC 框架而言是必然的選擇,而對于同一語言平臺的 RPC 則可以通過共享接口定義來實(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 來表達(dá)導(dǎo)入接口的意思。這里的導(dǎo)入方式本質(zhì)也是一種代碼生成技術(shù)藤滥,只不過是在運(yùn)行時生成鳖粟,比靜態(tài)編譯期的代碼生成看起來更簡潔些。java 里至少提供了兩種技術(shù)來提供動態(tài)代碼生成拙绊,一種是 jdk 動態(tài)代理向图,另外一種是字節(jié)碼生成泳秀。動態(tài)代理相比字節(jié)碼生成使用起來更方便,但動態(tài)代理方式在性能上是要遜色于直接的字節(jié)碼生成的榄攀,而字節(jié)碼生成在代碼可讀性上要差很多嗜傅。兩者權(quán)衡起來,個人認(rèn)為犧牲一些性能來獲得代碼可讀性和可維護(hù)性顯得更重要檩赢。

協(xié)議編解碼

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

-- 調(diào)用編碼 --  
1. 接口方法  
   包括接口名军浆、方法名  
2. 方法參數(shù)  
   包括參數(shù)類型棕洋、參數(shù)值  
3. 調(diào)用屬性  
   包括調(diào)用屬性信息,例如調(diào)用附件隱式參數(shù)乒融、調(diào)用超時時間等  
  
-- 返回編碼 --  
1. 返回結(jié)果  
   接口方法中定義的返回值  
2. 返回碼  
   異常返回碼  
3. 返回異常信息  
   調(diào)用異常信息  

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

-- 消息頭 --  
magic      : 協(xié)議魔數(shù)典蜕,為解碼設(shè)計  
header size: 協(xié)議頭長度断盛,為擴(kuò)展設(shè)計  
version    : 協(xié)議版本,為兼容設(shè)計  
st         : 消息體序列化類型  
hb         : 心跳消息標(biāo)記愉舔,為長連接傳輸層心跳設(shè)計  
ow         : 單向消息標(biāo)記钢猛,  
rp         : 響應(yīng)消息標(biāo)記,不置位默認(rèn)是請求消息  
status code: 響應(yīng)消息狀態(tài)碼  
reserved   : 為字節(jié)對齊保留  
message id : 消息 id  
body size  : 消息體長度  
  
-- 消息體 --  
采用序列化編碼轩缤,常見有以下格式  
xml   : 如 webservie soap  
json  : 如 JSON-RPC  
binary: 如 thrift; hession; kryo 等  

格式確定后編解碼就簡單了命迈,由于頭長度一定所以我們比較關(guān)心的就是消息體的序列化方式。序列化我們關(guān)心三個方面:
\1. 序列化和反序列化的效率火的,越快越好壶愤。
\2. 序列化后的字節(jié)長度,越小越好馏鹤。
\3. 序列化和反序列化的兼容性征椒,接口參數(shù)對象若增加了字段,是否兼容湃累。
上面這三點(diǎn)有時是魚與熊掌不可兼得勃救,這里面涉及到具體的序列化庫實(shí)現(xiàn)細(xì)節(jié)碍讨,就不在本文進(jìn)一步展開分析了。

傳輸服務(wù)

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

既然使用長連接箭券,那么第一個問題是到底 client 和 server 之間需要多少根連接净捅?實(shí)際上單連接和多連接在使用上沒有區(qū)別,對于數(shù)據(jù)傳輸量較小的應(yīng)用類型辩块,單連接基本足夠蛔六。單連接和多連接最大的區(qū)別在于,每根連接都有自己私有的發(fā)送和接收緩沖區(qū)废亭,因此大數(shù)據(jù)量傳輸時分散在不同的連接緩沖區(qū)會得到更好的吞吐效率国章。所以,如果你的數(shù)據(jù)傳輸量不足以讓單連接的緩沖區(qū)一直處于飽和狀態(tài)的話豆村,那么使用多連接并不會產(chǎn)生任何明顯的提升液兽,反而會增加連接管理的開銷。

連接是由 client 端發(fā)起建立并維持掌动。如果 client 和 server 之間是直連的四啰,那么連接一般不會中斷(當(dāng)然物理鏈路故障除外)。如果 client 和 server 連接經(jīng)過一些負(fù)載中轉(zhuǎn)設(shè)備粗恢,有可能連接一段時間不活躍時會被這些中間設(shè)備中斷柑晒。為了保持連接有必要定時為每個連接發(fā)送心跳數(shù)據(jù)以維持連接不中斷。心跳消息是 RPC 框架庫使用的內(nèi)部消息眷射,在前文協(xié)議頭結(jié)構(gòu)中也有一個專門的心跳位匙赞,就是用來標(biāo)記心跳消息的,它對業(yè)務(wù)應(yīng)用透明妖碉。

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

client stub 所做的事情僅僅是編碼消息并傳輸給服務(wù)方涌庭,而真正調(diào)用過程發(fā)生在服務(wù)方。server stub 從前文的結(jié)構(gòu)拆解中我們細(xì)分了 RpcProcessorRpcInvoker 兩個組件欧宜,一個負(fù)責(zé)控制調(diào)用過程脾猛,一個負(fù)責(zé)真正調(diào)用。這里我們還是以 java 中實(shí)現(xiàn)這兩個組件為例來分析下它們到底需要做什么鱼鸠?

java 中實(shí)現(xiàn)代碼的動態(tài)接口調(diào)用目前一般通過反射調(diào)用猛拴。除了原生的 jdk 自帶的反射羹铅,一些第三方庫也提供了性能更優(yōu)的反射調(diào)用,因此 RpcInvoker 就是封裝了反射調(diào)用的實(shí)現(xiàn)細(xì)節(jié)愉昆。

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

1. 效率提升  
   每個請求應(yīng)該盡快被執(zhí)行跛溉,因此我們不能每請求來再創(chuàng)建線程去執(zhí)行焊切,需要提供線程池服務(wù)。  
2. 資源隔離  
   當(dāng)我們導(dǎo)出多個遠(yuǎn)程接口時芳室,如何避免單一接口調(diào)用占據(jù)所有線程資源专肪,而引發(fā)其他接口執(zhí)行阻塞。  
3. 超時控制  
   當(dāng)某個接口執(zhí)行緩慢堪侯,而 client 端已經(jīng)超時放棄等待后嚎尤,server 端的線程繼續(xù)執(zhí)行此時顯得毫無意義。

RPC 異常處理

無論 RPC 怎樣努力把遠(yuǎn)程調(diào)用偽裝的像本地調(diào)用伍宦,但它們依然有很大的不同點(diǎn)芽死,而且有一些異常情況是在本地調(diào)用時絕對不會碰到的。在說異常處理之前次洼,我們先比較下本地調(diào)用和 RPC 調(diào)用的一些差異:
\1. 本地調(diào)用一定會執(zhí)行关贵,而遠(yuǎn)程調(diào)用則不一定,調(diào)用消息可能因?yàn)榫W(wǎng)絡(luò)原因并未發(fā)送到服務(wù)方卖毁。
\2. 本地調(diào)用只會拋出接口聲明的異常揖曾,而遠(yuǎn)程調(diào)用還會跑出 RPC 框架運(yùn)行時的其他異常。
\3. 本地調(diào)用和遠(yuǎn)程調(diào)用的性能可能差距很大亥啦,這取決于 RPC 固有消耗所占的比重翩肌。
正是這些區(qū)別決定了使用 RPC 時需要更多考量。當(dāng)調(diào)用遠(yuǎn)程接口拋出異常時禁悠,異衬罴溃可能是一個業(yè)務(wù)異常,也可能是 RPC 框架拋出的運(yùn)行時異常(如:網(wǎng)絡(luò)中斷等)碍侦。業(yè)務(wù)異常表明服務(wù)方已經(jīng)執(zhí)行了調(diào)用粱坤,可能因?yàn)槟承┰驅(qū)е挛茨苷?zhí)行,而 RPC 運(yùn)行時異常則有可能服務(wù)方根本沒有執(zhí)行瓷产,對調(diào)用方而言的異常處理策略自然需要區(qū)分站玄。

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

總結(jié)

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

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末循头,一起剝皮案震驚了整個濱河市绵估,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌卡骂,老刑警劉巖国裳,帶你破解...
    沈念sama閱讀 223,126評論 6 520
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異全跨,居然都是意外死亡缝左,警方通過查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 95,421評論 3 400
  • 文/潘曉璐 我一進(jìn)店門螟蒸,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人崩掘,你說我怎么就攤上這事七嫌。” “怎么了苞慢?”我有些...
    開封第一講書人閱讀 169,941評論 0 366
  • 文/不壞的土叔 我叫張陵诵原,是天一觀的道長。 經(jīng)常有香客問我挽放,道長绍赛,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 60,294評論 1 300
  • 正文 為了忘掉前任辑畦,我火速辦了婚禮吗蚌,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘纯出。我一直安慰自己蚯妇,他們只是感情好,可當(dāng)我...
    茶點(diǎn)故事閱讀 69,295評論 6 398
  • 文/花漫 我一把揭開白布暂筝。 她就那樣靜靜地躺著箩言,像睡著了一般。 火紅的嫁衣襯著肌膚如雪焕襟。 梳的紋絲不亂的頭發(fā)上陨收,一...
    開封第一講書人閱讀 52,874評論 1 314
  • 那天,我揣著相機(jī)與錄音鸵赖,去河邊找鬼务漩。 笑死拄衰,一個胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的菲饼。 我是一名探鬼主播肾砂,決...
    沈念sama閱讀 41,285評論 3 424
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼宏悦!你這毒婦竟也來了镐确?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 40,249評論 0 277
  • 序言:老撾萬榮一對情侶失蹤饼煞,失蹤者是張志新(化名)和其女友劉穎源葫,沒想到半個月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體砖瞧,經(jīng)...
    沈念sama閱讀 46,760評論 1 321
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡息堂,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 38,840評論 3 343
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了块促。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片荣堰。...
    茶點(diǎn)故事閱讀 40,973評論 1 354
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖竭翠,靈堂內(nèi)的尸體忽然破棺而出振坚,到底是詐尸還是另有隱情,我是刑警寧澤斋扰,帶...
    沈念sama閱讀 36,631評論 5 351
  • 正文 年R本政府宣布渡八,位于F島的核電站,受9級特大地震影響传货,放射性物質(zhì)發(fā)生泄漏屎鳍。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 42,315評論 3 336
  • 文/蒙蒙 一问裕、第九天 我趴在偏房一處隱蔽的房頂上張望逮壁。 院中可真熱鬧,春花似錦粮宛、人聲如沸貌踏。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,797評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽祖乳。三九已至,卻和暖如春秉氧,著一層夾襖步出監(jiān)牢的瞬間眷昆,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 33,926評論 1 275
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留亚斋,地道東北人作媚。 一個月前我還...
    沈念sama閱讀 49,431評論 3 379
  • 正文 我出身青樓,卻偏偏與公主長得像帅刊,于是被迫代替她去往敵國和親纸泡。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 45,982評論 2 361

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

  • Spring Cloud為開發(fā)人員提供了快速構(gòu)建分布式系統(tǒng)中一些常見模式的工具(例如配置管理赖瞒,服務(wù)發(fā)現(xiàn)女揭,斷路器,智...
    卡卡羅2017閱讀 134,720評論 18 139
  • 今天分布式應(yīng)用栏饮、云計算吧兔、微服務(wù)大行其道,作為其技術(shù)基石之一的 RPC 你了解多少袍嬉?一篇 RPC 的技術(shù)總結(jié)文章境蔼,數(shù)...
    零一間閱讀 1,903評論 1 46
  • 轉(zhuǎn)自http://mp.weixin.qq.com/s?__biz=MzAxMTEyOTQ5OQ==&mid=26...
    文刂德光軍閱讀 1,125評論 0 11
  • 今天分布式應(yīng)用、云計算伺通、微服務(wù)大行其道箍土,作為其技術(shù)基石之一的 RPC 你了解多少?一篇 RPC 的技術(shù)總結(jié)文章罐监,數(shù)...
    mindwind閱讀 1,878評論 1 38
  • 其實(shí)那是一個沒有背景的故事吴藻, 但是陰差陽錯的成為了所有故事的起點(diǎn), 我給他取了個名字叫追尋笑诅,后來又改成了平凡之路调缨,...
    二井三川閱讀 716評論 0 0