系統(tǒng)架構(gòu)模式

一、什么是架構(gòu)

架構(gòu)就是骨架
人類的身體的支撐是主要由骨架來承擔(dān)的囚衔,然后是其上面的肌肉挖腰、神經(jīng)、皮膚练湿。架構(gòu)對于軟件的重要性不亞于骨架對人類身體的重要性猴仑。

二、8種架構(gòu)模式

1肥哎、單庫單應(yīng)用模式

這是最簡單的一種設(shè)計模式辽俗,在初學(xué)和小項目中常見


image.png

如上圖所示,這種模式一般只有一個數(shù)據(jù)庫篡诽,一個業(yè)務(wù)應(yīng)用層崖飘,一個后臺管理系統(tǒng),所有的業(yè)務(wù)都是用業(yè)務(wù)層完成的霞捡,所有的數(shù)據(jù)也都是存儲在一個數(shù)據(jù)庫中坐漏。

優(yōu)點:結(jié)構(gòu)簡單、開發(fā)速度快碧信、實現(xiàn)簡單,可用于產(chǎn)品的第一版等有原型驗證需求街夭。

缺點:性能差砰碴、擴展性差,不適合用于大規(guī)模部署板丽、應(yīng)用等生產(chǎn)環(huán)境呈枉。

2、讀寫分離模式

這種模式主要解決單及數(shù)據(jù)庫壓力過大埃碱,從而導(dǎo)致業(yè)務(wù)緩慢甚至超時猖辫,查詢影響時間變長的問題,也包括需要大量數(shù)據(jù)庫服務(wù)器計算資源的查詢請求砚殿,這個可以說是單庫應(yīng)用模式的升級版本啃憎,也是技術(shù)架構(gòu)迭代演進過程中的必經(jīng)之路。


image.png

這種模式較單庫但應(yīng)用模式與內(nèi)容分發(fā)模式多了幾個部分似炎,一個是業(yè)務(wù)數(shù)據(jù)庫的主從分離辛萍,一個是引入ES悯姊,為什么要這樣?都解決的哪些痛點贩毕,下面具體結(jié)合業(yè)務(wù)需求場景進行敘述悯许。

場景一:關(guān)鍵詞檢索

這個需求在大部分的系統(tǒng)中都會存在,如果使用傳統(tǒng)的數(shù)據(jù)庫技術(shù)辉阶,大部分可能會使用like這種sql語句先壕。sql語句的性能問題與全表掃描機制導(dǎo)致了非常嚴(yán)重的性能問題,現(xiàn)在基本上很少見到谆甜。故采用ES作為搜索引擎启上。

場景二:大量的普通查詢

這個場景是指我們的業(yè)務(wù)中的大部分輔助性的查詢,如:取錢的時候先查詢一下余額店印,根據(jù)用戶的ID查詢用戶的記錄冈在,取得該用戶最新的一條取錢記錄等,我們肯定是要天天用到的按摘,而且用的還非常多包券。同時呢,我們的寫入請求也是非常多的炫贤,導(dǎo)致大量的寫入溅固、查詢操作壓向同一數(shù)據(jù)庫,然后兰珍,數(shù)據(jù)庫撐不住掛掉侍郭。

所以要求我們必須分散數(shù)據(jù)庫的壓力,一個業(yè)界較成熟的方案就是數(shù)據(jù)庫的讀寫分離掠河,寫的時候入主庫亮元,讀的時候讀分庫。這樣就把壓力分散到不同的數(shù)據(jù)庫了唠摹,如果一個讀庫性能不行爆捞,扛不住的話,可以一主多從勾拉,橫向擴展煮甥。

  • 請求數(shù)據(jù)庫存儲在主庫中
  • 數(shù)據(jù)同步或異步存入從庫中
  • 讀取數(shù)據(jù)時直接從讀庫讀取數(shù)據(jù)

延遲問題?
如:數(shù)據(jù)還沒到從庫藕赞,我就馬上讀成肘,那么是讀不到的,會發(fā)生問題的斧蜕。對于這個問題双霍,各家公司解決的思路也是不一樣的,方法不盡相同,一個普遍的解決方案是:讀不到就讀主庫

優(yōu)點:減少數(shù)據(jù)庫的壓力店煞,理論上提供無限高的讀性能蟹演,提高業(yè)務(wù)(寫)的性能。

缺點:數(shù)據(jù)延遲顷蟀,數(shù)據(jù)一致性的保證酒请。

3、內(nèi)容分發(fā)模式

基本上所有的大型的網(wǎng)站都有或多或少的采用這一種設(shè)計模式鸣个,常見的應(yīng)用場景是采用CDN技術(shù)把網(wǎng)頁羞反、圖片、CSS囤萤、JS等這些靜態(tài)資源分發(fā)到離用戶最近的服務(wù)器


image.png

這種模式較單庫單應(yīng)用的模式多了一個CDN昼窗、一個云存儲OSS。一個經(jīng)典的應(yīng)用流程(以用戶上傳涛舍、查看圖片需求為例如下:)

1澄惊、上傳的時候,用戶選擇本地機器上的一個圖片進行上傳

2富雅、程序會把這個圖片上傳到云存儲OSS上掸驱,并返回該圖片的一個URL

3、程序把這個URL字符串存儲在業(yè)務(wù)數(shù)據(jù)庫中没佑,上傳完成

4毕贼、查看的時候,程序從業(yè)務(wù)數(shù)據(jù)庫得到該圖片的URL

5蛤奢、程序通過DNS查詢到這個URL的圖片服務(wù)器

6鬼癣、智能DNS會解析這個URL,得到于用戶最近的服務(wù)器(或集群)的地址A

7啤贩、然后把服務(wù)器A上的圖片返回給程序

8待秃、程序顯示該圖片,查看完成

由上可知瓜晤,這個模式的關(guān)鍵是智能DNS锥余,它能夠解析出離用戶最近的服務(wù)器,運行原理大致是:根據(jù)請求者的IP得到請求地點B痢掠,然后通過計算或者配置得到與B最近或通訊時間最短的服務(wù)器C,然后把C的IP地址返回給請求者嘲恍。這種模式的優(yōu)缺點如下:

優(yōu)點:資源下載快足画,無需過多的開發(fā)與配置,同時也減輕了后端服務(wù)器對資源的存儲壓力佃牛,減少帶寬的使用淹辞。

缺點:目前來說OSS、CDN的價格還是稍微有點貴的俘侠,只適用于中小規(guī)模的應(yīng)用象缀,另外由于網(wǎng)絡(luò)傳輸延遲蔬将、CDN的同步策略等,會有一些一致性央星、更新慢方面的問題霞怀。

4、微服務(wù)模式

為什么要使用微服務(wù)莉给?
1毙石、單及數(shù)據(jù)庫寫請求量大量增加,導(dǎo)致數(shù)據(jù)庫壓力變大
2颓遏、數(shù)據(jù)庫一旦掛了徐矩,那么整個業(yè)務(wù)都掛了
3、業(yè)務(wù)代碼越來越多叁幢,都在一個GIT里滤灯,越來越難以維護
4、代碼腐化嚴(yán)重曼玩,臭味越來越濃
5鳞骤、上線越來越頻繁,經(jīng)常是一個小功能的修改演训,就要整個大項目重新編譯
6弟孟、部門越來越多,該哪個部門改動大項目中的哪個東西样悟,撕逼的厲害
7拂募、其他一些外圍系統(tǒng)直接連數(shù)據(jù)庫,導(dǎo)致一旦數(shù)據(jù)庫結(jié)構(gòu)發(fā)生變化窟她,所有的相關(guān)系統(tǒng)都要通知陈症,甚至對修改不敏感的系統(tǒng)也要通知
8、每個應(yīng)用服務(wù)器需要開通所有權(quán)限震糖、網(wǎng)絡(luò)录肯、FTP、各種各樣的吊说,因為每個服務(wù)器部署的應(yīng)用都是一樣的论咏。


image.png

如上圖所示,把業(yè)務(wù)分塊颁井,做了垂直切分厅贪,切成一個個獨立的系統(tǒng),每個系統(tǒng)各自衍化雅宾,有自己的庫养涮、緩存、ES等輔助系統(tǒng),系統(tǒng)之間的實時交互通過RPC/Rest API贯吓,異步交互通過MQ懈凹,通過這種組合,共同完成整個系統(tǒng)功能悄谐。

那么介评,這么做是否真的能解決上述問題了呢?不玩虛的尊沸,一個一個來說威沫。

對于問題一,由于拆分成多個子系統(tǒng)洼专,系統(tǒng)的壓力被分散了棒掠,而各個子系統(tǒng)都有自己的數(shù)據(jù)庫實例,所以數(shù)據(jù)庫的壓力變小屁商。

對于問題二烟很,一個子系統(tǒng)A的數(shù)據(jù)庫掛了,只是影響到系統(tǒng)A和使用系統(tǒng)A的那些功能蜡镶,不會所有的功能不可用雾袱,從而解決一個數(shù)據(jù)庫掛了,導(dǎo)致所有的功能都不可用的情況官还。

對于問題三芹橡、四,也因為拆分得到了解決望伦,各個子系統(tǒng)都有自己獨立的GIT代碼庫林说,不會相互影響。通用的模塊可通過庫屯伞、服務(wù)腿箩、平臺的形式解決。

對于問題五劣摇,子系統(tǒng)A發(fā)生改變珠移,需要上線,那么我們只需要編譯A末融,然后上線就可以了钧惧,不需要其他系統(tǒng)做通向的事情。

對于問題六勾习,順應(yīng)了康威定律垢乙,我部門該干什么事,輸出什么语卤,也通過服務(wù)的形式暴露出來,我部門只管把我部的職責(zé)、軟件功能做好就可以粹舵。

對于問題七钮孵,所有需要我部數(shù)據(jù)的需求,都通過接口的形式發(fā)布出去眼滤,客戶通過接口獲取數(shù)據(jù)巴席,從而屏蔽了底層數(shù)據(jù)庫結(jié)構(gòu),甚至數(shù)據(jù)來源诅需,我部只需保證我部的接口契約沒有發(fā)生變化即可漾唉,新的需求增加新的接口,不會影響老的接口堰塌。

對于問題八赵刑,不同的子系統(tǒng)需要不同的權(quán)限,這個問題也優(yōu)雅的解決了场刑。

優(yōu)點:相對高性能般此,可擴展性強,高可用牵现,適用于中等以上規(guī)模公司架構(gòu)铐懊。

缺點:復(fù)雜、度不好把握瞎疼。指不僅需要一個能在高層把控大方向科乎、大流程、總體技術(shù)的人贼急,還需要能夠針對各個子系統(tǒng)有針對性的開發(fā)茅茂。把握不好度或者濫用的話,這個模式適得其反竿裂!

5玉吁、多級緩存模式

這個模式可以說是應(yīng)對超高查詢壓力的一種普遍采用的策略,基本的思想就是在所有鏈路的地方腻异,能加緩存的就加緩存进副,如下圖所示:


image.png

如上圖所示,一般在三個地方加入緩存悔常,一個是客戶端處影斑,一個是API網(wǎng)關(guān)處,一個是具體的后端業(yè)務(wù)處机打,下面分別介紹:

客戶端處緩存:這個地方加緩存可以說是效果最好的一個——無延遲矫户。因為不用經(jīng)過長長的網(wǎng)絡(luò)鏈條去后端業(yè)務(wù)處獲取數(shù)據(jù),從而導(dǎo)致加載時間過長残邀,客戶流失等損失皆辽,雖然有CDN的支持柑蛇,但是從客戶端到CDN還是有網(wǎng)絡(luò)延遲的,雖然不大驱闷,具體的技術(shù)依據(jù)不同的客戶端而定耻台,對于WEB來講,有瀏覽器本地緩存空另、Cookie盆耽、Storage、緩存策略等技術(shù)扼菠;對于APP來講摄杂,有本地數(shù)據(jù)庫,本地文件循榆,本地內(nèi)存析恢,進程內(nèi)緩存支持,以上提到的各種技術(shù)有興趣的同學(xué)可以繼續(xù)展開學(xué)習(xí)冯痢,如果客戶端緩存沒有命中氮昧,那么會去后端業(yè)務(wù)拿數(shù)據(jù),一般來講浦楣,就會有個API網(wǎng)關(guān)袖肥,在這里加緩存也是非常重要的。

后端業(yè)務(wù)處理:這個我就不用多說了振劳,大家應(yīng)該差不多都知道椎组,什么Redis、Memcache历恐、Jvm等等寸癌,不贅述了。

實踐中弱贼,要結(jié)合具體的實際情況蒸苇,綜合利用各級緩存技術(shù),使得各種請求最大程度的在到達后端業(yè)務(wù)之前就被解決掉吮旅,從而減少后端服務(wù)器壓力溪烤、減少占用帶寬、增強用戶體驗庇勃。至于是否只有這三個地方加緩存檬嘀,我覺得要活學(xué)活用,心法比劍法重要责嚷!總結(jié)一下這個模式的優(yōu)缺點:

優(yōu)點:抗住大量讀請求鸳兽,減少后端壓力。

缺點:數(shù)據(jù)一致性問題較為突出罕拂,容易發(fā)生雪崩揍异,即:如果客戶端緩存失效全陨、API網(wǎng)關(guān)緩存失效,那么所有的大量請求瞬間壓向后端業(yè)務(wù)系統(tǒng)蒿秦,后果可想而知烤镐。

6、分庫分表模式

這種模式主要解決單表寫入棍鳖、讀取 、存儲壓力過大碗旅,從而導(dǎo)致業(yè)務(wù)緩慢甚至超時渡处,交易失敗,容量不夠的問題祟辟。一般有水平切分和垂直切分兩種医瘫,這里主要介紹水平切分。這個模式也是技術(shù)架構(gòu)迭代演進的必經(jīng)之路旧困。


image.png

如上圖所示紅色部分醇份,把一張表分到了幾個不同的庫中,從而分擔(dān)壓力吼具。是不是很籠統(tǒng)僚纷?哈哈,那我們接下來就詳細(xì)的講解一下拗盒,首先澄清幾個概念怖竭,如下:

主機:硬件,指一臺物理機陡蝇,或虛擬機痊臭,有自己的CPU,內(nèi)存登夫,硬盤等广匙。

實例:數(shù)據(jù)庫實例,如一個MySql服務(wù)進程恼策,一個主機可以有多個實例裤唠,不同的實例有不同的進程嗅虏,監(jiān)聽不同的端口。

庫:指表的集合,如學(xué)校庫溅呢,可能包含教師表、學(xué)生表廷臼、食堂表等等蝗柔,這些表在一個庫中。一個實例中可以有多個庫情龄,庫與庫之間用庫名來區(qū)分迄汛。

表:庫中的表捍壤,不必多說,不懂的就不用往下看了鞍爱,不解釋鹃觉。

那么怎么把單表分散呢?到底怎么個分發(fā)呢睹逃?分發(fā)到哪里呢盗扇?以下是幾個工作中的實踐,分享一下:

主機:這是最主要的也是最重要的點沉填,本質(zhì)上分庫分表是因為計算與存儲資源不夠?qū)е碌牧屏ィ@種資源主要由物理機,主機提供的翼闹,畢竟沒有可用的計算資源斑鼻,怎么分效果都不是太好。

實例:實例控制著連接數(shù)猎荠,同時受OS限制坚弱,CPU、內(nèi)存关摇、硬盤荒叶、網(wǎng)絡(luò)IO也會受間接影響。會出現(xiàn)熱實例的現(xiàn)象拒垃,即:有些實例特別忙停撞,有些實例非常的空閑。一個典型的現(xiàn)象是:由于單表反應(yīng)慢悼瓮,導(dǎo)致連接池被拉滿戈毒,所以其他的業(yè)務(wù)都受影響了。這時候横堡,把表分到不同的實例是有一些效果的埋市。

庫:一般是由于單庫中最大單表數(shù)量的限制,才采取分庫命贴。

表:單表壓力過大道宅,索引量大,容量大胸蛛,單表的鎖污茵。據(jù)以上,把單表水平切分成不同的表葬项。

大型應(yīng)用中泞当,都是一臺主機上只有一個實例,一個實例中只有一個庫民珍,庫==實例==主機襟士,所以才有了分庫分表這個簡稱盗飒。

既然知道了這個基本理論,那么具體是怎么做的呢陋桂?邏輯是怎么跑的呢逆趣?接下來以一個例子來講解一下。

這個需求很簡單嗜历,用戶表(user)宣渗,單表數(shù)據(jù)量1億,查詢秸脱、插入落包、存儲都出現(xiàn)了問題,怎么辦呢摊唇?

首先,分析問題涯鲁,這個明顯是由于數(shù)據(jù)量太大了而導(dǎo)致的問題巷查。

其次,設(shè)計方案抹腿,可以分為10個庫岛请,這樣每個庫的數(shù)據(jù)量就降到了1KW,單表1KW數(shù)據(jù)量還是有些大警绩,而且不利于以后量的增長崇败,所以每個庫再分100個表,這樣每個單表數(shù)據(jù)量就為10W了肩祥,對于查詢后室、索引更新、單表文件大小混狠、打開速度岸霹,都有一些溢出。接下來将饺,給IT部門打電話贡避,要10臺物理機,擴展數(shù)據(jù)庫……

最后予弧,邏輯實現(xiàn)刮吧,這里應(yīng)該是最有學(xué)問的地方。首先是寫入數(shù)據(jù)掖蛤,需要知道寫到哪個分庫分表中杀捻,讀也是一樣的,所以坠七,需要有個請求路由曾水醋,負(fù)責(zé)把請求分發(fā)旗笔、轉(zhuǎn)換到不同的庫表中,一般有路由規(guī)則的概念拄踪。

怎么樣蝇恶,簡單吧?哈哈惶桐。說說這個模式的問題撮弧,主要是帶來了事務(wù)上的問題,因為分庫分表姚糊,事務(wù)完成不了贿衍,而分布式事務(wù)又太笨重,所以這里需要有一定的策略救恨,保證在這種情況下事務(wù)能夠完成贸辈。采取的策略如:最終一致性、復(fù)制肠槽、特殊設(shè)計等擎淤。再有就是業(yè)務(wù)代碼的改造,一些關(guān)聯(lián)查詢要改造秸仙,一些單表orderBy的問題需要特殊處理嘴拢,也包括groupBy語句,如何解決這些副作用不是一句兩句能夠說清楚的寂纪,以后有時間席吴,我單獨講講這些。

該總結(jié)一下這種模式的優(yōu)缺點了捞蛋,如下:

優(yōu)點:減少數(shù)據(jù)庫單表的壓力孝冒。

缺點:事務(wù)保證困難、業(yè)務(wù)邏輯需要做大量改造襟交。

7迈倍、彈性伸縮模式

這種模式主要解決突發(fā)流量的到來,導(dǎo)致無法橫向擴展或者橫向擴展太慢捣域,進而影響業(yè)務(wù)啼染,全站崩潰的問題。這個模式是一種相對來說比較高級的技術(shù)焕梅,也是各大公司目前都在研究迹鹅、試用的技術(shù)。


image.png

如上圖所示贞言,多了一個彈性伸縮服務(wù)斜棚,用來動態(tài)的增加、減少實例。原理上非常簡單弟蚀,但是這個模式到底解決了什么問題呢蚤霞?先說說由來和意義。

每年的雙11义钉、618或者一些大促銷到來之前昧绣,我們都會為大流量的到來做以下幾個方面的工作:提前準(zhǔn)備10倍甚至更多的機器,即便用不上也要放在那里備著捶闸,以防萬一夜畴,這樣浪費了大量的資源。每臺機器配置删壮、調(diào)試贪绘、引流,以便讓所有的機器都可用央碟,這樣浪費了大量的人力税灌、物力,更容易出錯亿虽。如果機器準(zhǔn)備不充分垄琐,那么還要加班加點的重復(fù)上面的工作,這樣特別容易出錯经柴,引來領(lǐng)導(dǎo)的不滿,沒時間回家陪老婆墩朦,然后你老婆就……哈哈

在雙十一之后坯认,我們還要人工做縮容,非常的辛苦氓涣。一般一年中會有多次促銷牛哺,那么我們就會一直這樣,實在是煩劳吠!

最嚴(yán)重的引润,突然間的大流量爆發(fā),會讓我們猝不及防痒玩,半夜起來擴容是正常不過的事情淳附,為此,我們偷懶起來蠢古,要更多的機器備著奴曙,也就出現(xiàn)了大量CPU利用率為1%的機器。

相信我草讶,如果你是老板一定很震驚吧洽糟!

哈哈,那么如何改變這種情況呢?請接著看

為此坤溃,首先把所有的計算資源整合成資源池的概念拍霜,然后通過一些策略、監(jiān)控薪介、服務(wù)祠饺,動態(tài)的從資源池中獲取資源,用完后再放回到池子中昭灵,供其他系統(tǒng)使用吠裆。具體實現(xiàn)上比較成熟的兩種資源池方案是VM、docker烂完,每個都有著自己強大的生態(tài)试疙。監(jiān)控點有CPU、內(nèi)存抠蚣、硬盤祝旷、網(wǎng)絡(luò)IO、服務(wù)質(zhì)量等嘶窄,根據(jù)這些怀跛,再配合一些預(yù)留、擴張柄冲、收縮策略吻谋,就可以簡單的實現(xiàn)自動收縮。怎么樣现横?是不是很神奇漓拾?深入的內(nèi)容我會在后面的文章中詳細(xì)的講述,該總結(jié)以下這種模式的優(yōu)缺點了戒祠。如下:

優(yōu)點:彈性骇两、隨需計算,充分優(yōu)化企業(yè)計算資源姜盈。

缺點:應(yīng)用要從架構(gòu)層做到可橫向擴展化改造低千、依賴的底層配套比較多,對技術(shù)水平馏颂、實力示血、應(yīng)用規(guī)模要求比較高。

8饱亮、多機房模式

這種模式主要解決不同地區(qū)高性能矾芙、高可用的問題

隨著應(yīng)用用戶的不斷增加,用戶群體分布在全球各地近上,如果把服務(wù)器都部署在一個地方剔宪,一個地方,比如北京,那么美國的用戶使用應(yīng)用的時候會特別慢葱绒,因為每個請求都需要通過海底光纜走上那么一秒鐘左右感帅,這樣對用戶體檢及其不好,怎么辦地淀?使用多機房部署失球。

用戶請求一個連接A

通過DNS智能解析到離用戶最近的機房B

使用B機房服務(wù)連接A

是不是覺得很簡單,沒啥帮毁?其實這里面的問題沒有表面這么簡單实苞,下面一一道來,

首先是數(shù)據(jù)同步問題烈疚,在中國產(chǎn)生的數(shù)據(jù)要同步到美國黔牵,美國的也一樣,數(shù)據(jù)同步就會涉及數(shù)據(jù)版本爷肝、一致性猾浦、更新丟棄、刪除等問題灯抛。

其次是一地多機房的請求路由問題金赦,典型的是如上圖,中國的北京機房和杭州機房对嚼,如果北京機房掛了夹抗,那么要能夠通過路由把所有發(fā)往北京機房的請求轉(zhuǎn)發(fā)到杭州機房,異地也存在這個問題纵竖。

友情鏈接
http://www.reibang.com/p/4046165b0387

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末兔朦,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子磨确,更是在濱河造成了極大的恐慌,老刑警劉巖声邦,帶你破解...
    沈念sama閱讀 222,946評論 6 518
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件乏奥,死亡現(xiàn)場離奇詭異,居然都是意外死亡亥曹,警方通過查閱死者的電腦和手機邓了,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 95,336評論 3 399
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來媳瞪,“玉大人骗炉,你說我怎么就攤上這事∩呤埽” “怎么了句葵?”我有些...
    開封第一講書人閱讀 169,716評論 0 364
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經(jīng)常有香客問我乍丈,道長剂碴,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 60,222評論 1 300
  • 正文 為了忘掉前任轻专,我火速辦了婚禮忆矛,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘请垛。我一直安慰自己催训,他們只是感情好,可當(dāng)我...
    茶點故事閱讀 69,223評論 6 398
  • 文/花漫 我一把揭開白布宗收。 她就那樣靜靜地躺著漫拭,像睡著了一般。 火紅的嫁衣襯著肌膚如雪镜雨。 梳的紋絲不亂的頭發(fā)上嫂侍,一...
    開封第一講書人閱讀 52,807評論 1 314
  • 那天,我揣著相機與錄音荚坞,去河邊找鬼挑宠。 笑死,一個胖子當(dāng)著我的面吹牛颓影,可吹牛的內(nèi)容都是我干的各淀。 我是一名探鬼主播,決...
    沈念sama閱讀 41,235評論 3 424
  • 文/蒼蘭香墨 我猛地睜開眼诡挂,長吁一口氣:“原來是場噩夢啊……” “哼碎浇!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起璃俗,我...
    開封第一講書人閱讀 40,189評論 0 277
  • 序言:老撾萬榮一對情侶失蹤奴璃,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后城豁,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體苟穆,經(jīng)...
    沈念sama閱讀 46,712評論 1 320
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 38,775評論 3 343
  • 正文 我和宋清朗相戀三年唱星,在試婚紗的時候發(fā)現(xiàn)自己被綠了雳旅。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 40,926評論 1 353
  • 序言:一個原本活蹦亂跳的男人離奇死亡间聊,死狀恐怖攒盈,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情哎榴,我是刑警寧澤型豁,帶...
    沈念sama閱讀 36,580評論 5 351
  • 正文 年R本政府宣布僵蛛,位于F島的核電站,受9級特大地震影響偷遗,放射性物質(zhì)發(fā)生泄漏墩瞳。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 42,259評論 3 336
  • 文/蒙蒙 一氏豌、第九天 我趴在偏房一處隱蔽的房頂上張望喉酌。 院中可真熱鬧,春花似錦泵喘、人聲如沸泪电。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,750評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽相速。三九已至,卻和暖如春鲜锚,著一層夾襖步出監(jiān)牢的瞬間突诬,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 33,867評論 1 274
  • 我被黑心中介騙來泰國打工芜繁, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留旺隙,地道東北人。 一個月前我還...
    沈念sama閱讀 49,368評論 3 379
  • 正文 我出身青樓骏令,卻偏偏與公主長得像蔬捷,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子榔袋,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 45,930評論 2 361

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