訂單系統(tǒng):從0到1設(shè)計(jì)思路

訂單系統(tǒng):從0到1設(shè)計(jì)思路? (本文章為分享文章扒吁,原文來自人人都是產(chǎn)品作者)

本文主要講述了在傳統(tǒng)電商企業(yè)中,訂單系統(tǒng)應(yīng)承載的角色室囊,就訂單系統(tǒng)所包含的主要功能模塊梳理了設(shè)計(jì)思路雕崩,并對訂單系統(tǒng)未來的發(fā)展做了一些思考。

1融撞、訂單系統(tǒng)在企業(yè)中的角色

在搭建企業(yè)訂單系統(tǒng)之前盼铁,需要先梳理企業(yè)整體業(yè)務(wù)系統(tǒng)之間的關(guān)系和訂單系統(tǒng)上下游關(guān)系,只有劃分清業(yè)務(wù)系統(tǒng)邊界尝偎,才能確定訂單系統(tǒng)的職責(zé)與功能饶火,進(jìn)而保證各系統(tǒng)之間高效簡潔的工作。

2致扯、訂單系統(tǒng)與各業(yè)務(wù)系統(tǒng)的關(guān)系

image

(1)對外系統(tǒng):

所有給企業(yè)外部用戶使用的系統(tǒng)都在這一層肤寝,包括官網(wǎng)、普通用戶使用的C端抖僵,還包括給商戶使用的商家后臺(tái)和在各個(gè)銷售渠道進(jìn)行分銷的系統(tǒng)鲤看,比如與銀行信用卡中心合作、微信合作在合作商的平臺(tái)露出本企業(yè)的產(chǎn)品耍群。這類系統(tǒng)站在與客戶接觸的最前線义桂,是公司實(shí)現(xiàn)商業(yè)模式的橋頭堡。

(2)管理中后臺(tái):

每個(gè)C端的業(yè)務(wù)形態(tài)都會(huì)有一個(gè)對應(yīng)的系統(tǒng)模塊世吨,如負(fù)責(zé)管理平臺(tái)交易的訂單系統(tǒng)澡刹,管理優(yōu)惠信息的促銷系統(tǒng),管理平臺(tái)所有產(chǎn)品的產(chǎn)品系統(tǒng)耘婚,以及管理所有對外系統(tǒng)顯示內(nèi)容的內(nèi)容系統(tǒng)等罢浇。

(3)公共服務(wù)系統(tǒng):

隨著企業(yè)的發(fā)展,信息化建設(shè)到達(dá)一定程度后沐祷,企業(yè)需要將通用功能服務(wù)化嚷闭、平臺(tái)化,以保證應(yīng)用架構(gòu)的合理性赖临,提升服務(wù)效率胞锰。這類系統(tǒng)主要給其他應(yīng)用系統(tǒng)提供基礎(chǔ)服務(wù)能力支持。

3兢榨、訂單系統(tǒng)上下游關(guān)系

image

由此可見嗅榕,訂單系統(tǒng)對上接收用戶信息顺饮,將用戶信息轉(zhuǎn)化為產(chǎn)品訂單,同時(shí)管理并跟蹤訂單信息和數(shù)據(jù)凌那,承載了公司整個(gè)交易線的重要對客環(huán)節(jié)兼雄。對下則銜接產(chǎn)品系統(tǒng)、促銷系統(tǒng)帽蝶、倉儲(chǔ)系統(tǒng)赦肋、會(huì)員系統(tǒng)、支付系統(tǒng)等励稳,對整個(gè)電商平臺(tái)起著承上啟下的作用佃乘。

4、訂單系統(tǒng)的業(yè)務(wù)架構(gòu)

image

(1)訂單服務(wù)

該模塊的主要功能是用戶日常使用的服務(wù)和頁面驹尼,主要有訂單列表趣避、訂單詳情、在線下單等扶欣,還包括為公共業(yè)務(wù)模塊提供的多維度訂單數(shù)據(jù)服務(wù)鹅巍。

(2)訂單邏輯

訂單系統(tǒng)的核心,起著至關(guān)重要的作用料祠,在訂單系統(tǒng)負(fù)責(zé)管理訂單創(chuàng)建骆捧、訂單支付、訂單生產(chǎn)髓绽、訂單確認(rèn)敛苇、訂單完成、取消訂單等訂單流程顺呕。還涉及到復(fù)雜的訂單狀態(tài)規(guī)則枫攀、訂單金額計(jì)算規(guī)則以及增減庫存規(guī)則等。在4節(jié)核心功能設(shè)計(jì)中會(huì)重點(diǎn)來說株茶。

(3)底層服務(wù)

信息化建設(shè)達(dá)到一定程度的企業(yè)来涨,一般會(huì)將公司公共服務(wù)模塊化,比如:產(chǎn)品启盛,會(huì)構(gòu)建對應(yīng)的產(chǎn)品系統(tǒng)蹦掐,代碼、數(shù)據(jù)庫僵闯,接口等相對獨(dú)立卧抗。但是,這也帶來了一個(gè)問題鳖粟,比如:訂單創(chuàng)建的場景下需要獲取的信息分散在各個(gè)系統(tǒng)社裆。

如果需要從各個(gè)公共服務(wù)系統(tǒng)調(diào)用:一是會(huì)花費(fèi)大量時(shí)間,二是代碼的維護(hù)成本非常高向图。因此泳秀,訂單系統(tǒng)接入所需的公共服務(wù)模塊接口标沪,在訂單系統(tǒng)即可完成對接公共系統(tǒng)的服務(wù)。

訂單系統(tǒng)核心功能

1嗜傅、訂單中所包含的內(nèi)容信息

image

為了使訂單系統(tǒng)能夠?qū)τ唵芜M(jìn)行高效谨娜、精準(zhǔn)的管理和跟蹤,訂單會(huì)儲(chǔ)存關(guān)于產(chǎn)品磺陡、優(yōu)惠、用戶漠畜、支付信息等一系列的訂單實(shí)時(shí)數(shù)據(jù)币他,來和下游系統(tǒng),如:促銷憔狞、倉儲(chǔ)蝴悉、物流進(jìn)行交互。

以一個(gè)通用B2C商城的訂單為例瘾敢,梳理其包含的信息如下:

這里要注意的是訂單類型拍冠,隨著平臺(tái)業(yè)務(wù)的不斷發(fā)展,品類豐富簇抵、交易方式豐富后庆杜,需要對訂單進(jìn)行多維度的分類管理,同時(shí)訂單類型利于訂單系統(tǒng)的擴(kuò)展性碟摆。每種訂單類型將會(huì)對應(yīng)一套流程及一套狀態(tài)晃财,便于對訂單進(jìn)行分類管理和復(fù)用。

2典蜕、流程引擎

流程是指從平臺(tái)角度出發(fā)断盛,將訂單從創(chuàng)建到完成的整個(gè)流轉(zhuǎn)過程進(jìn)行抽象,從而形成了一套標(biāo)準(zhǔn)流程規(guī)則愉舔。而不同的產(chǎn)品類型或交易類型在系統(tǒng)中的流程會(huì)千差萬別钢猛,因此為了方便對訂單流程進(jìn)行管理,會(huì)組建流程引擎模塊轩缤。

每套訂單流程中會(huì)包含正向流程及逆向流程命迈,正向流程可以比作一次順利的網(wǎng)購體驗(yàn)過程中,后臺(tái)系統(tǒng)之間的信息流轉(zhuǎn)典奉。逆向流程則是修改訂單躺翻、取消訂單、退款卫玖、退貨等各種動(dòng)作引起的后臺(tái)系統(tǒng)流程公你,同時(shí)每個(gè)流程觸發(fā)的條件又可分為系統(tǒng)觸發(fā)和人工觸發(fā)兩種場景。

(1)正向流程

以一個(gè)通用B2C商城的訂單系統(tǒng)為例假瞬,根據(jù)其實(shí)際業(yè)務(wù)場景陕靠,其訂單流程可抽象為5大步驟:訂單創(chuàng)建>訂單支付>訂單生產(chǎn)>訂單確認(rèn)>訂單完成迂尝。

而每個(gè)步驟的背后,訂單是如何在多系統(tǒng)之間交互流轉(zhuǎn)的剪芥,可概括如下圖:

image

訂單創(chuàng)建:

用戶下單后垄开,系統(tǒng)需要生成訂單,此時(shí)需要先獲取下單中涉及的商品信息税肪,然后獲取該商品所涉及到的優(yōu)惠信息溉躲,如果商品不參與優(yōu)惠信息,則無此環(huán)節(jié)益兄。

接著獲取該賬戶的會(huì)員權(quán)益锻梳,這里要注意的是:優(yōu)惠信息與會(huì)員權(quán)益的區(qū)別,比如:商品滿減是優(yōu)惠信息净捅,SUPER會(huì)員全場9.8折指的是會(huì)員權(quán)益疑枯,一個(gè)是針對商品,另一個(gè)是針對賬戶蛔六。其次就是優(yōu)惠活動(dòng)的疊加規(guī)則和優(yōu)先級規(guī)則等荆永。

增減庫存規(guī)則是指訂單中的商品,何時(shí)從倉儲(chǔ)系統(tǒng)中對相應(yīng)商品庫存進(jìn)行扣除国章,目前主流有兩種方式:

下單減庫存——即用戶下單成功時(shí)減少庫存數(shù)量

優(yōu)勢:用戶體驗(yàn)友好具钥,系統(tǒng)邏輯簡潔;

缺點(diǎn):會(huì)導(dǎo)致惡意下單或下單后卻不買液兽,使得真正有需求的用戶無法購買氓拼,影響真實(shí)銷量;

解決辦法:

設(shè)置訂單有效時(shí)間抵碟,若訂單創(chuàng)建成功N分鐘不付款桃漾,則訂單取消,庫存回滾拟逮;

限購撬统,用各種條件來限制買家的購買件數(shù),比如一個(gè)賬號敦迄、一個(gè)ip恋追,只能買一件;

風(fēng)控罚屋,從技術(shù)角度進(jìn)行判斷苦囱,屏蔽惡意賬號,禁止惡意賬號購買脾猛。

付款減庫存——即用戶支付完成并反饋給平臺(tái)后再減少庫存數(shù)量

優(yōu)勢:減少無效訂單帶來的資源損耗撕彤;

缺點(diǎn):因第三方支付返回結(jié)果存在時(shí)差,同一時(shí)間多個(gè)用戶同時(shí)付款成功,會(huì)導(dǎo)致下單數(shù)目超過庫存羹铅,商家?guī)齑娌蛔闳菀滓l(fā)斷貨和投訴蚀狰,成本增加。

解決辦法:

付款前再次校驗(yàn)庫存职员,如確認(rèn)訂單要付款時(shí)再驗(yàn)證一次麻蹋,并友好提示用戶庫存不足;

增加提示信息:在商品詳情頁焊切,訂單步驟頁面提示不及時(shí)付款扮授,不能保證有庫存等。

綜上所述专肪,兩種方式各有優(yōu)缺點(diǎn)糙箍,因此,需結(jié)合實(shí)際場景進(jìn)行考慮牵祟,如:秒殺、搶購抖格、促銷活動(dòng)等诺苹,可使用下單減庫存的方式。而對于產(chǎn)品庫存量大雹拄,并發(fā)流量沒有那么強(qiáng)的產(chǎn)品使用付款減庫存的方式收奔。

將兩種方式帶入到銷售場景中,關(guān)聯(lián)商品類型滓玖、促銷類型坪哄、供需關(guān)系等,靈活使用势篡,以充分發(fā)揮計(jì)算機(jī)系統(tǒng)的優(yōu)勢翩肌。

訂單支付:

用戶支付完訂單后,需要獲取訂單的支付信息禁悠,包括支付流水號念祭、支付時(shí)間等。支付完訂單接著就是等商家發(fā)貨碍侦,但在發(fā)貨過程中粱坤,根據(jù)平臺(tái)業(yè)務(wù)模式的不同,可能會(huì)涉及到訂單的拆分瓷产。

訂單拆分一般分兩種:

一種是用戶挑選的商品來自于不同渠道(自營與商家站玄,商家與商家);

另一種是在SKU層面上拆分訂單:不同倉庫濒旦,不同運(yùn)輸要求的SKU株旷,包裹重量體積限制等因素需要將訂單拆分。

訂單拆分也是一個(gè)相對獨(dú)立的模塊尔邓,這里就不詳細(xì)描述了灾常。

訂單生產(chǎn):訂單生產(chǎn)霎冯,是指產(chǎn)品從企業(yè)到用戶這一流程的概述。如電商平臺(tái)中钞瀑,商家發(fā)貨過程已有一個(gè)標(biāo)準(zhǔn)化的流程沈撞,訂單內(nèi)容會(huì)發(fā)送到倉庫,倉庫對商品進(jìn)行打單雕什、揀貨缠俺、包裝、交接快遞進(jìn)行配送贷岸。

訂單確認(rèn):收到貨后壹士,訂單系統(tǒng)需要在快遞被簽收后提醒用戶對商品做評價(jià)。這里要注意偿警,確認(rèn)收到貨不代表交易成功躏救,相反是售后服務(wù)的開始粉寞。

訂單完成:訂單完成是指在收到貨X天的狀態(tài)潘飘,此時(shí)訂單不在售后的支持時(shí)間范圍內(nèi)。到此吼驶,一個(gè)訂單的正向流程就算走完了七嫌。

(2)逆向流程

image

上面說到逆向流程是各種修改訂單少办、取消訂單、退款诵原、退貨等操作英妓,需要梳理清楚這些流程與正向流程的關(guān)系,才能理清訂單系統(tǒng)完整的訂單流程绍赛。

訂單修改:可梳理訂單內(nèi)信息蔓纠,根據(jù)信息關(guān)聯(lián)程度及業(yè)務(wù)訴求,設(shè)定訂單的可修改范圍是什么吗蚌,比如:客戶下單后贺纲,想修改收貨人地址及電話。此時(shí)只需對相應(yīng)數(shù)據(jù)進(jìn)行更新即可褪测。

訂單取消:用戶提交訂單后沒有進(jìn)行支付操作猴誊,此時(shí)用戶原則上屬于取消訂單,因?yàn)檫€未付款侮措,則比較簡單懈叹,只需要將原本提交訂單時(shí)扣減的庫存補(bǔ)回,促銷優(yōu)惠中使用的優(yōu)惠券分扎,權(quán)益等視平臺(tái)規(guī)則澄成,進(jìn)行相應(yīng)補(bǔ)回。

退款:用戶支付成功后,客戶發(fā)出退款的訴求后墨状,需商戶進(jìn)行退款審核卫漫,雙方達(dá)成一致后,系統(tǒng)應(yīng)以退款單的形式完成退款肾砂,關(guān)聯(lián)原訂單數(shù)據(jù)列赎。因商品無變化,所以不需考慮與庫存系統(tǒng)的交互镐确,僅需考慮促銷系統(tǒng)及支付系統(tǒng)交互即可包吝。

退貨:用戶支付成功后,客戶發(fā)出退貨的訴求后源葫,需商戶進(jìn)行退款審核诗越,雙方達(dá)成一致后,需對庫存系統(tǒng)進(jìn)行補(bǔ)回息堂,支付系統(tǒng)嚷狞、促銷系統(tǒng)以退款單形式完成退款。最后荣堰,在退款/退貨流程中床未,需結(jié)合平臺(tái)業(yè)務(wù)場景,考慮優(yōu)惠分?jǐn)偟倪壿嫵炙恚诎l(fā)生退款/退貨時(shí),優(yōu)惠該如何退回的處理規(guī)則和流程逃片。

(3)狀態(tài)機(jī)

狀態(tài)機(jī)是管理訂單狀態(tài)邏輯的工具屡拨。狀態(tài)機(jī)可歸納為3個(gè)要素,即現(xiàn)態(tài)褥实、動(dòng)作呀狼、次態(tài)。

現(xiàn)態(tài):是指當(dāng)前所處的狀態(tài)损离。

動(dòng)作:動(dòng)作執(zhí)行完畢后,可以遷移到新的狀態(tài)僻澎,也可以仍舊保持原狀態(tài)貌踏。

次態(tài):動(dòng)作滿足后要遷往的新狀態(tài)窟勃,“次態(tài)”是相對于“現(xiàn)態(tài)”而言的,“次態(tài)”一旦被激活秉氧,就轉(zhuǎn)變成新的“現(xiàn)態(tài)”了。

狀態(tài)機(jī)的設(shè)計(jì)需要結(jié)合平臺(tái)實(shí)際業(yè)務(wù)場景,將狀態(tài)間的切換細(xì)化成了執(zhí)行了某個(gè)動(dòng)作亚斋。

以一個(gè)B2C商城的訂單系統(tǒng)舉例如下:

image

訂單系統(tǒng)為了高效的對訂單進(jìn)行跟蹤和管理,會(huì)對訂單流程當(dāng)中的關(guān)鍵節(jié)點(diǎn)帅刊,抽象出訂單狀態(tài)纸泡。而訂單狀態(tài)從不同用戶的角度可分為,系統(tǒng)訂單狀態(tài)厚掷、商家訂單狀態(tài)弟灼、買家訂單狀態(tài)等。

對于訂單系統(tǒng)來說冒黑,訂單狀態(tài)細(xì)分的顆粒度越細(xì)田绑、越明確,訂單系統(tǒng)管理的精度和可靠性就越高抡爹,比如:在待付款和待發(fā)貨兩個(gè)狀態(tài)中掩驱,訂單系統(tǒng)后臺(tái)會(huì)細(xì)分為訂單超時(shí)取消、訂單支付失敗冬竟、訂單付款完成等欧穴。

因此,訂單狀態(tài)模塊中泵殴,通常會(huì)維護(hù)狀態(tài)映射表涮帘,以不同的用戶角色對系統(tǒng)訂單狀態(tài)進(jìn)行重新劃分,以滿足不同用戶的需求笑诅。

除此以外调缨,隨著電商平臺(tái)的不斷發(fā)展,不同的業(yè)務(wù)類型吆你,所對應(yīng)的訂單狀態(tài)都會(huì)有所區(qū)別弦叶。所以,訂單系統(tǒng)中一般會(huì)儲(chǔ)存多套狀態(tài)機(jī)妇多,以滿足不同的訂單類型來使用伤哺。

訂單系統(tǒng)的發(fā)展

訂單系統(tǒng)的主體框架,和主要業(yè)務(wù)模塊已基本講完者祖,那么隨著企業(yè)的發(fā)展立莉,業(yè)務(wù)量和業(yè)務(wù)形式不斷變化,企業(yè)有可能形成多個(gè)訂單系統(tǒng)并存以滿足不同的業(yè)務(wù)需要的情況七问。

業(yè)務(wù)系統(tǒng)架構(gòu)如下:

image

這種狀況的出現(xiàn)桃序,將會(huì)給平臺(tái)帶來非常大的發(fā)展瓶頸,如:

三個(gè)訂單系統(tǒng)烂瘫,每個(gè)訂單系統(tǒng)處理不同類型的訂單媒熊,沒有統(tǒng)一的訂單銷量奇适、訂單狀態(tài)信息,網(wǎng)站前臺(tái)對訂單的狀態(tài)展示與控制不統(tǒng)一芦鳍,只能是在網(wǎng)站前臺(tái)會(huì)員中心硬代碼維護(hù)一套面向會(huì)員的統(tǒng)一訂單明細(xì)與狀態(tài)數(shù)據(jù)嚷往。而無線側(cè)上線后,由于不了解前臺(tái)網(wǎng)站會(huì)員中心的訂單狀態(tài)管理邏輯柠衅,所以需要把前臺(tái)網(wǎng)站的訂單明細(xì)及狀態(tài)管理再在無線應(yīng)用側(cè)再實(shí)現(xiàn)一遍皮仁。

三套后臺(tái)訂單系統(tǒng)與公共業(yè)務(wù)系統(tǒng)如會(huì)員中心贷祈、支付與財(cái)務(wù)喝峦、促銷工具、客戶分單等系統(tǒng)都需要對接一遍粟耻,公共業(yè)務(wù)處理邏輯不統(tǒng)一挤忙,一旦邏輯變更多個(gè)系統(tǒng)統(tǒng)一個(gè)接口都要修改一遍谈喳,接口的重復(fù)維護(hù)開發(fā)工作量大。

訂單開發(fā)目前分到事業(yè)部赏僧,各個(gè)事業(yè)部只會(huì)考慮自己的邏輯,不會(huì)考慮公共架構(gòu)次哈,只會(huì)越走越遠(yuǎn)吆录。碰到像無線這樣的項(xiàng)目恢筝,需要對接各個(gè)事業(yè)部巨坊,無線側(cè)應(yīng)用上線進(jìn)展慢。

因此未來的訂單系統(tǒng)可拆分為訂單中心與業(yè)務(wù)訂單系統(tǒng)兩個(gè)模塊侄柔,以管理公司所有訂單數(shù)據(jù),并為各個(gè)模塊提供統(tǒng)一服務(wù)移剪。

業(yè)務(wù)系統(tǒng)架構(gòu)如下:

image

最后

對于企業(yè)訂單系統(tǒng)的搭建纵苛,并不是要做的大而全言津、也不是要小而精。而需要結(jié)合市場悬槽、公司陷谱、業(yè)務(wù)的實(shí)際情況來最終制定系統(tǒng)設(shè)計(jì)方案和產(chǎn)品迭代計(jì)劃。

最終渣窜,和公司整體發(fā)展相互協(xié)調(diào)宪躯,相輔相成。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末详瑞,一起剝皮案震驚了整個(gè)濱河市坝橡,隨后出現(xiàn)的幾起案子计寇,更是在濱河造成了極大的恐慌脂倦,老刑警劉巖,帶你破解...
    沈念sama閱讀 216,372評論 6 498
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件蝶押,死亡現(xiàn)場離奇詭異棋电,居然都是意外死亡,警方通過查閱死者的電腦和手機(jī)稼虎,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,368評論 3 392
  • 文/潘曉璐 我一進(jìn)店門霎俩,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人打却,你說我怎么就攤上這事柳击。” “怎么了捌肴?”我有些...
    開封第一講書人閱讀 162,415評論 0 353
  • 文/不壞的土叔 我叫張陵状知,是天一觀的道長孽查。 經(jīng)常有香客問我,道長西设,這世上最難降的妖魔是什么答朋? 我笑而不...
    開封第一講書人閱讀 58,157評論 1 292
  • 正文 為了忘掉前任梦碗,我火速辦了婚禮,結(jié)果婚禮上叉弦,老公的妹妹穿的比我還像新娘淹冰。我一直安慰自己巨柒,他們只是感情好柠衍,可當(dāng)我...
    茶點(diǎn)故事閱讀 67,171評論 6 388
  • 文/花漫 我一把揭開白布珍坊。 她就那樣靜靜地躺著阵漏,像睡著了一般翻具。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上裆泳,一...
    開封第一講書人閱讀 51,125評論 1 297
  • 那天运提,我揣著相機(jī)與錄音闻葵,去河邊找鬼。 笑死洪灯,一個(gè)胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的签钩。 我是一名探鬼主播铅檩,決...
    沈念sama閱讀 40,028評論 3 417
  • 文/蒼蘭香墨 我猛地睜開眼昧旨,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了兔沃?” 一聲冷哼從身側(cè)響起乒疏,我...
    開封第一講書人閱讀 38,887評論 0 274
  • 序言:老撾萬榮一對情侶失蹤怕吴,失蹤者是張志新(化名)和其女友劉穎,沒想到半個(gè)月后伟件,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 45,310評論 1 310
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡斧账,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 37,533評論 2 332
  • 正文 我和宋清朗相戀三年,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了扯旷。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 39,690評論 1 348
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡毯炮,死狀恐怖耸黑,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情为迈,我是刑警寧澤,帶...
    沈念sama閱讀 35,411評論 5 343
  • 正文 年R本政府宣布葫辐,位于F島的核電站耿战,受9級特大地震影響焊傅,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜鸭栖,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 41,004評論 3 325
  • 文/蒙蒙 一晕鹊、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦肉渴、人聲如沸同规。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,659評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽关炼。三九已至儒拂,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間社痛,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 32,812評論 1 268
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留撵儿,地道東北人。 一個(gè)月前我還...
    沈念sama閱讀 47,693評論 2 368
  • 正文 我出身青樓,卻偏偏與公主長得像房匆,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個(gè)殘疾皇子浴鸿,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 44,577評論 2 353