注：本文轉(zhuǎn)載自公眾號 infoQ，根據(jù)石佳寧在InfoQ舉辦的2016ArchSummit全球架構(gòu)師（深圳）峰會上的演講整理而成。

老司機(jī)簡介

石佳寧，餓了么后臺支撐研發(fā)部負(fù)責(zé)人，目前任職于餓了么,現(xiàn)任平臺研發(fā)中心-后臺支撐部門負(fù)責(zé)人,主要負(fù)責(zé)餓了么外賣訂單、統(tǒng)一客服系統(tǒng)、BD銷售以及管理工 具、代理商管理平臺等系統(tǒng)的設(shè)計(jì)和研發(fā)工作。

先自我介紹一下，我于2014年加入餓了么，那時(shí)正是餓了么飛速發(fā)展的起始點(diǎn)。我一直從事后臺領(lǐng)域的研發(fā)，比如BD系統(tǒng)、客服系統(tǒng)和訂單系統(tǒng)，現(xiàn)在專注交易架構(gòu)相關(guān)的工作。

今天要講的內(nèi)容主要分為兩大部分。第一部分是在高速增長和愈加復(fù)雜的交易場景下，餓了么訂單的服務(wù)架構(gòu)是如何演進(jìn)的，究竟是什么支撐我們的發(fā)展。

快速增長下的業(yè)務(wù)場景

具體講之前，我先介紹一下我們的場景，因?yàn)?strong>脫離具體的場景所有架構(gòu)演進(jìn)沒有任何意義。上面這兩個(gè)圖表不是餓了么的數(shù)據(jù)，是第三方分析整個(gè)外賣市場的數(shù)據(jù)圖。左邊的圖表是從2011年開始，整個(gè)O2O市場以及外賣的份額逐年增加。2013年和2014年的時(shí)候發(fā)生了比較大的飛躍，餓了么也是在這個(gè)時(shí)間段訂單量開始猛增。右邊的圖表是用戶注重外賣平臺的因素分布。

從圖中可以看到，用戶很在意配送速度，在意交易的時(shí)效性。對于O2O或者餓了么訂單，交易的要求比傳統(tǒng)電商的高，因?yàn)榻灰滓话阋粌蓚€(gè)小時(shí)就結(jié)束了。在2014年初，餓了么訂單量只有日均10萬單，到2014年底超過百萬，這是一個(gè)質(zhì)的飛躍，10萬訂單的量級和百萬訂單的量級的要求非常不一樣。在2015年突破了日均300萬，到今年5月單日峰值突破500萬。

快速發(fā)展涉及很多問題。我們是一家創(chuàng)業(yè)公司，業(yè)務(wù)發(fā)展非?？欤赡軠?zhǔn)備不是很充分，比如說監(jiān)控、日志、告警、框架、消息、數(shù)據(jù)庫，很多基礎(chǔ)設(shè)施還在建設(shè)之中。在這個(gè)過程中出現(xiàn)一些問題是在所難免的，對系統(tǒng)的要求不是不能掛、不能出問題，而是出了問題要第一時(shí)間能恢復(fù)。這是整個(gè)系統(tǒng)架構(gòu)的前提。

服務(wù)架構(gòu)的演進(jìn)

圖中所示是訂單的早期架構(gòu)圖，比較簡單。這個(gè)架構(gòu)在2014年的時(shí)候支撐了日均10萬的訂單，是一套很不錯(cuò)的架構(gòu)，依然在很多系統(tǒng)中完美運(yùn)行。但是對于后來發(fā)展的場景，它已經(jīng)曝露問題了，比如業(yè)務(wù)邏輯嚴(yán)重耦合、代碼管理很困難，因?yàn)閿?shù)據(jù)庫都在一起，操作變更很難追溯。

更進(jìn)一步的是，性能的瓶頸只能是靠服務(wù)器去硬抗，從物理架構(gòu)到邏輯架構(gòu)，都已經(jīng)成為業(yè)務(wù)發(fā)展的掣肘了。于是，為了業(yè)務(wù)的發(fā)展，我們做了一些演進(jìn)的工作。

演進(jìn)工作的核心就是一個(gè)字“拆”，跟“拆”對等的就是分治的思想。怎么拆分呢？面向服務(wù)有很多拆分原則。我將拆分過程中最具幫助和指導(dǎo)性的點(diǎn)羅列了以下幾條。

第一是明確的定義。之前也確實(shí)犯了一些錯(cuò)誤，為了拆而拆。其實(shí)我們需要更明確，什么才算是一個(gè)服務(wù)？服務(wù)一定具有非常獨(dú)立的技術(shù)能力或者業(yè)務(wù)能力，而且一定意義上能夠很抽象。

第二是松耦合。最基本的松耦合就是Customer的消費(fèi)不依賴于Provider的某一個(gè)特定實(shí)現(xiàn)，這樣服務(wù)器的內(nèi)部變更不會影響外部消費(fèi)，消費(fèi)者可以切換到其他服務(wù)能力的提供方，這是最基本的松耦合。還有時(shí)間上的松耦合或者位置上的松耦合，我們希望的松耦合是消費(fèi)方和服務(wù)方是可以分離的。

第三是基于領(lǐng)域的認(rèn)知，這對于整個(gè)產(chǎn)品起到非常大的作用。因?yàn)楫?dāng)時(shí)整個(gè)餓了么所有系統(tǒng)是在一起的，基于領(lǐng)域的認(rèn)知，在面向用戶的維度和面向商戶的維度做了切分，還有基于交易鏈路做了切分。

第四是單一職責(zé)和關(guān)注分離。簡單說，我們希望一個(gè)服務(wù)或者一個(gè)模塊擁有單一的能力，而不是承擔(dān)過多的職責(zé)，否則責(zé)任不清晰，導(dǎo)致能力也不清晰。

最后一點(diǎn)是可被驗(yàn)證的結(jié)果。在訂單拆分的過程中我們犯了一些錯(cuò)誤，當(dāng)時(shí)認(rèn)為這樣拆分是沒有問題的，但是過一、兩個(gè)月，并沒有帶來效率和能力的提升，反而是跨團(tuán)隊(duì)的要求越來越多，能力要求也越來越多。這時(shí)候可能是拆錯(cuò)了。如果是一個(gè)好的拆分一定有利于發(fā)展，拆分之后的發(fā)展是更迅速的。

基于這幾條原則，我們對餓了么的整體服務(wù)做拆分之后，如上圖所示，架構(gòu)就有了一些變化，看起來跟剛才架構(gòu)區(qū)別不大。把Order Service做了分離。當(dāng)時(shí)拆分雖然比較垂直，但是用戶、商戶、金融、訂單等還是有一些橫向交互。

一個(gè)接口有一個(gè)非常明確的Owner，一個(gè)表、一個(gè)庫也能保證僅有單一的操作方，讓我感受比較直接的是，為服務(wù)的治理奠定了基礎(chǔ)，以后可以針對某項(xiàng)特定業(yè)務(wù)做一些降級、熔斷，以及單獨(dú)的監(jiān)控。拆分實(shí)際上是讓各自模塊的掌控力變得更強(qiáng)了，對業(yè)務(wù)起到更好的支撐作用。

這時(shí)每個(gè)部門或者每個(gè)團(tuán)隊(duì)都負(fù)責(zé)自己獨(dú)立的領(lǐng)域，代碼和數(shù)據(jù)都拆分完畢是不是就可以了？但是后來發(fā)現(xiàn)好像還不對。因?yàn)殡m然大的領(lǐng)域上確實(shí)已經(jīng)干凈了，但是在小的領(lǐng)域上依然問題很多，訂單并不僅僅只有一張表，一個(gè)單一的模塊，其實(shí)還有很多復(fù)雜的內(nèi)容。

在一些技術(shù)工作上，這些問題曝露得并不是那么明顯，那時(shí)候大家對于一些領(lǐng)域認(rèn)知或者業(yè)務(wù)邊界的認(rèn)識還是模糊的，沒有人界定這些。但是當(dāng)更進(jìn)一步地去發(fā)展一個(gè)領(lǐng)域的時(shí)候，還是會有職責(zé)不清晰或者能力模糊的地方。我們思考，還要基于業(yè)務(wù)進(jìn)行更細(xì)膩的規(guī)劃。

于是我們把訂單本身做了一些業(yè)務(wù)層次的拆分，拆分之前首先要確認(rèn)訂單到底在整個(gè)系統(tǒng)中，尤其是交易系統(tǒng)、O2O系統(tǒng)中承擔(dān)什么角色，擔(dān)負(fù)什么職責(zé)。

在這個(gè)思考過程中，我們的認(rèn)知大概是以下四點(diǎn)。

第一，訂單是整個(gè)交易鏈路的核心，圍繞了一些相關(guān)服務(wù)，比如金額計(jì)算服務(wù)、催單服務(wù)、售中異常服務(wù)等，我們希望這些服務(wù)之間有明確的區(qū)別。

第二，訂單實(shí)時(shí)處理是整個(gè)鏈路的中心，我們將這個(gè)過程定義得盡量簡潔。一筆交易中，訂單被推進(jìn)得越復(fù)雜，說明系統(tǒng)設(shè)計(jì)得越復(fù)雜，出問題的概率也會越高。所以我們希望訂單核心流程非常簡單、輕薄，把復(fù)雜的東西剝離出來，把簡單和復(fù)雜明確成兩個(gè)部分。

第三，考慮到交易的時(shí)效性和異常場景越來越復(fù)雜，將交易分成正向交易流程和逆向交易流程兩個(gè)部分。正向交易流程，99%的訂單會根據(jù)這個(gè)流程走完生命周期；逆向交易流程，比如說退單要求時(shí)效性比較低，處理會牽扯多方業(yè)務(wù)可能很復(fù)雜，所以通過一個(gè)逆向的交易流程來解決。

第四，能夠在功能和業(yè)務(wù)上獨(dú)立的部分，盡可能抽象為單獨(dú)的模塊或服務(wù)。簡單來說，比如催單的服務(wù)，它其實(shí)對交易鏈路無法起到推進(jìn)作用，它只是一個(gè)動作或者附帶服務(wù)，我們把它單獨(dú)抽象出來，為后面的發(fā)展做出鋪墊。

基于這些之后，我們對訂單進(jìn)行完整的認(rèn)知，對訂單的服務(wù)架構(gòu)和業(yè)務(wù)架構(gòu)做成圖中的樣子，大概是三層。下面一層是基本數(shù)據(jù)；中間層是正向逆向的流程、最核心的狀態(tài)和最關(guān)聯(lián)的交易鏈上耦合的服務(wù)；上層是用戶服務(wù)、商戶服務(wù)，包括跟交易鏈相關(guān)的，比如餓了么最近推出的“準(zhǔn)時(shí)達(dá)”的服務(wù)。

我們同時(shí)對其他服務(wù)模塊也做了演進(jìn)。一些是之前設(shè)計(jì)的不合理，如圖所示是當(dāng)時(shí)緩存服務(wù)的邏輯架構(gòu)，節(jié)點(diǎn)比較多。簡單解釋一下最初的做法:提交訂單的時(shí)候清除緩存，獲取訂單的時(shí)候如果沒有緩存的話，會通過消息機(jī)制來更新緩存。中間還有一個(gè)Replicator，起到重復(fù)合并的作用。

后來我們發(fā)現(xiàn)，本來可以輕量級實(shí)現(xiàn)的內(nèi)容，但是用了相對復(fù)雜的實(shí)現(xiàn)，鏈路長，組件多，受網(wǎng)絡(luò)影響非常大。一旦一個(gè)節(jié)點(diǎn)緩存數(shù)據(jù)不一致，感知會比較困難，尤其是業(yè)務(wù)體量大的時(shí)候。

業(yè)務(wù)體量小的時(shí)候同時(shí)處理的量并不多，問題曝露并不明顯，但是體量變大的時(shí)候，這個(gè)設(shè)計(jì)立刻帶來很多困擾。所以我們對緩存做了簡化，就是把不必要的內(nèi)容砍掉，做一個(gè)最基本的緩存服務(wù)。

這是一個(gè)最基本的緩存的套路，在數(shù)據(jù)庫更精準(zhǔn)的情況下更新緩存，如果從DB獲取不到就從緩存獲取。這個(gè)架構(gòu)雖然簡單了，但是效率比之前高很多，之前數(shù)據(jù)庫和緩存之間延遲在200毫秒左右，而這個(gè)簡單實(shí)現(xiàn)延遲控制在10毫秒以內(nèi)。

之前訂單最大的瓶頸是在數(shù)據(jù)庫，我們主要做了DAL中間層組件。圖中這個(gè)中間件對我們影響非常大，日均300萬單的時(shí)候數(shù)據(jù)庫量比較大，引入DAL中間件做什么呢？有幾個(gè)作用：數(shù)據(jù)庫管理和負(fù)載均衡以及讀寫分離，水平分表對用戶和商戶兩個(gè)維度做評估，為用戶存儲至少半年以上的數(shù)據(jù)。解決了數(shù)據(jù)庫的瓶頸，系統(tǒng)整體負(fù)載能力提升了很多。

這張圖說明了訂單具體改造的時(shí)候DAL中間件起的作用，有讀寫分離端口、綁定主庫端口、水平分表、限流削峰以及負(fù)載均衡等功能。

監(jiān)控和告警的峰值非常明顯，午間和晚間兩個(gè)高峰，其他時(shí)間流量相對平緩。下面主要講三個(gè)部分。

第一，對于訂單而言，吞吐量是最需要重點(diǎn)關(guān)注的指標(biāo)。一開始對業(yè)務(wù)指標(biāo)的感知并不是特別清晰，就在某一個(gè)接口耗費(fèi)了很多時(shí)間。后來發(fā)現(xiàn)一些很小BD的問題不太容易從小接口感知到，但是從業(yè)務(wù)方面感知就比較明顯，所以就更多關(guān)注業(yè)務(wù)指標(biāo)的控制。

第二，通常我們重視系統(tǒng)指標(biāo)，而容易忽視業(yè)務(wù)指標(biāo)，其實(shí)業(yè)務(wù)指標(biāo)更能反映出隱晦的問題。

第三，目前我們致力于基于監(jiān)控和數(shù)據(jù)學(xué)習(xí)的過載保護(hù)和業(yè)務(wù)自動降級。雖然現(xiàn)在還沒有完全做好，但是已經(jīng)能感覺到一些效果。如果商戶長時(shí)間不接單，用戶會自動取消訂單，自動取消功能的開關(guān)目前是人工控制的，我們更希望是系統(tǒng)來控制。

比如說有大量訂單取消了，有可能是接單功能出了問題，就需要臨時(shí)關(guān)閉這個(gè)功能，如果還是依靠人來做，往往已經(jīng)來不及，這時(shí)候就應(yīng)該基于數(shù)據(jù)的學(xué)習(xí)，讓系統(tǒng)自動降級這個(gè)功能。

當(dāng)做完這一切，訂單的架構(gòu)就變成了上面這個(gè)樣子。我們把整個(gè)Service集群做了分組，有面向用戶的、面向商戶的，還有物流和其他方面的。

Design for failure

就訂單系統(tǒng)而言主要有以下四個(gè)內(nèi)容。第一是消息廣播補(bǔ)償，第二是主流程補(bǔ)償，第三是災(zāi)備，第四是隨機(jī)故障測試系統(tǒng)。

首先是消息廣播補(bǔ)償。對于訂單來說，MQ是非常核心的基礎(chǔ)組件，如果它出現(xiàn)問題，一些訂單處理就會受影響。為了避免這種情況發(fā)生，我們做了一個(gè)補(bǔ)償?shù)膬?nèi)容，這個(gè)補(bǔ)償其實(shí)很簡單，就是在訂單狀態(tài)發(fā)生消息變化的時(shí)候，我們會同時(shí)落一份消息數(shù)據(jù)，目前會存儲最近一小時(shí)的消息。

如果MQ系統(tǒng)或者集群當(dāng)前有問題或者抖動，消息廣播補(bǔ)償可以起到一個(gè)備線的作用。消息廣播補(bǔ)償不能應(yīng)付所有問題，但是對于訂單系統(tǒng)的穩(wěn)定和健壯而言還是非常有用的。

第二是主流程的補(bǔ)償。什么是主流程？就是交易的正向流程。99%的交易都會是正向的，就是下單、付款，順利吃飯。在這個(gè)過程中，只要用戶有通過餓了么吃飯的意向，就盡全力一定讓他完成最終的交易，不要因?yàn)橄到y(tǒng)的原因影響到他。

主流程主要是針對鏈路本身出問題的情況，以最大程度保證交易的進(jìn)行，也是對主要鏈路的保護(hù)。

比如有一次出現(xiàn)這個(gè)問題：用戶已經(jīng)支付過了，但訂單沒有感受到這個(gè)結(jié)果，訂單顯示還在待支付，當(dāng)時(shí)支付服務(wù)本應(yīng)該把結(jié)果推送過來，訂單就可以繼續(xù)往前走，但是系統(tǒng)在那里卡住了，這對用戶就是比較差的體驗(yàn)。

所以后來我們做了主流程的補(bǔ)償，以確保交易的信息鏈路一直完整。我們的原則是，對訂單的各個(gè)狀態(tài)變更進(jìn)行推送或拉取，保證最終的一致性，鏈路和介質(zhì)要獨(dú)立于原流程。我們從兩個(gè)方面來解決這個(gè)問題。

在部署方面，把提供補(bǔ)償功能的服務(wù)和主服務(wù)分開部署，依賴的服務(wù)也需要使用獨(dú)立實(shí)例，以保證高可用性。在效果方面，用戶支付成功前的所有信息都應(yīng)該盡量入庫，可以對支付、待接單、接單等一系列環(huán)節(jié)都可以做補(bǔ)償。

這是主流程補(bǔ)償?shù)膱D，最大的關(guān)聯(lián)方就是支付和商戶，支付就是代表用戶。商戶有推送訂單信息，支付也有推送訂單信息，如果出現(xiàn)問題，補(bǔ)償服務(wù)可以拉取結(jié)果，訂單甚至可以自動接單。這個(gè)補(bǔ)償經(jīng)過多次的演變，目前依然在運(yùn)作，對于一些比較特殊的情況還是很有用的，可以在第一時(shí)間處理問題，保證交易的完成。

第三是災(zāi)備。目前訂單系統(tǒng)做了一個(gè)比較簡單的災(zāi)備，就是兩個(gè)機(jī)房的切換。切換的時(shí)候是全流量切換的，我們會把流量從A機(jī)房切到B機(jī)房。訂單的主要操作是在切換的過程中要進(jìn)行修復(fù)數(shù)據(jù)。

比如，一些訂單開始是在A機(jī)房，被切換到B機(jī)房去操作，這就可能會造成兩個(gè)機(jī)群數(shù)據(jù)不一致的情況，所以會專門對信息做補(bǔ)全，當(dāng)一筆交易切換到另一個(gè)機(jī)房后，我們要確保短時(shí)間內(nèi)將數(shù)據(jù)對比并修復(fù)完成，當(dāng)然主要還是確保數(shù)據(jù)最終一致。

第四是隨機(jī)故障測試系統(tǒng)。左圖是Netflix的猴子家族，右圖是我們做的Kennel系統(tǒng)，一個(gè)是猴子窩，一個(gè)是狗窩。大家對猴子家族了解嗎？Netflix現(xiàn)在幾乎把所有內(nèi)容都部署在云上，對系統(tǒng)和架構(gòu)的要求很高，他們可以隨時(shí)破壞一些節(jié)點(diǎn)，以測試是否能依然為用戶提供服務(wù)。

我們也參考他們的做法，有很大的啟發(fā)，避免失敗最好的辦法就是經(jīng)常失敗。餓了么的發(fā)展速度比非常快，技術(shù)還不完善，設(shè)計(jì)也會有缺口。我個(gè)人覺得，一個(gè)好的系統(tǒng)或者好的設(shè)計(jì)不是一開始被大牛設(shè)計(jì)出來的，一定是隨著發(fā)展和演進(jìn)逐漸被迭代出來的。

參考了Netflix的猴子家族，我們研發(fā)了自己的Kennel系統(tǒng)。猴子家族主要是針對節(jié)點(diǎn)的攻擊，我們的Kennel主要是對網(wǎng)絡(luò)、內(nèi)存等做了調(diào)整，還結(jié)合自己的服務(wù)，對應(yīng)用和接口也做了一些攻擊。攻擊分兩部分。

第一部分是物理層面的，我們可以對指定節(jié)點(diǎn)IO做攻擊，或者把CPU打到很高；對于服務(wù)和接口而言，可以把某個(gè)接口固定增加500毫秒或者更要的響應(yīng)延遲，這樣做的目的是什么？在整個(gè)鏈路中，我們希望架構(gòu)設(shè)計(jì)或者節(jié)點(diǎn)都是高可用的，高可用就需要被測試，通過大量的測試人為攻擊節(jié)點(diǎn)或者服務(wù)，來看預(yù)先設(shè)計(jì)好的那些措施或者補(bǔ)償?shù)哪芰κ遣皇钦娴挠杏谩?/p>

整個(gè)Kennel的設(shè)計(jì)是，首先會有一個(gè)控制中心來做總的調(diào)度，配置模塊可以配置各種計(jì)劃，可以控制CPU或者網(wǎng)絡(luò)丟包等，可以設(shè)置在每周六8-10am的某個(gè)時(shí)間點(diǎn)攻擊系統(tǒng)十五分鐘。它還有一些操作模塊，比如執(zhí)行計(jì)劃模塊、任務(wù)執(zhí)行模塊、節(jié)點(diǎn)管理模塊、執(zhí)行記錄模塊等。

Kennel有四個(gè)主要的作用。

首先，幫助我們發(fā)現(xiàn)鏈路中隱蔽的缺陷，將小概率事件放大。比如說緩存不一致的問題，之前極少出現(xiàn)，一旦出現(xiàn)之后，處理手段比較缺乏，那就可以通過Kennel來模擬。網(wǎng)絡(luò)的抖動是很隨機(jī)的，那么Kennel可以在某個(gè)時(shí)間段專門進(jìn)行模擬，把小概率事件放大。如果懷疑某個(gè)地方出了問題，可以通過它來測試是不是真的能查出問題。

第二，重大功能可以在發(fā)布之前通過其進(jìn)行測試，迫使你更深入地設(shè)計(jì)和編碼。通過模擬流量或者線上流量回放，來檢驗(yàn)系統(tǒng)運(yùn)行是否如你設(shè)計(jì)那樣工作，比如監(jiān)控的曲線或者告警以及相關(guān)服務(wù)之間的依賴等。

第三，我們做了很多失敗的準(zhǔn)備和設(shè)計(jì)，要看到底會不會起作用、起多大作用。可以通過Kennel進(jìn)行校驗(yàn)，在某個(gè)時(shí)間通過隨機(jī)手段攻擊相關(guān)服務(wù)，服務(wù)方不知道具體的攻擊內(nèi)容，這時(shí)原本設(shè)定的監(jiān)控告警，降級熔斷等措施有沒有及時(shí)起作用就是一個(gè)很好的校驗(yàn)。同時(shí)還可以檢驗(yàn)之前準(zhǔn)備的容錯(cuò)或者補(bǔ)償措施是否能按照預(yù)期工作。

第四，需要驗(yàn)證FailOver的設(shè)計(jì)，只有驗(yàn)證通過才可以依靠。所有的設(shè)計(jì)都是經(jīng)歷了一次一次的失敗，一些設(shè)計(jì)原以為有用，但是真實(shí)問題發(fā)生時(shí)并沒有起到作用。真正有意義的FailOver設(shè)計(jì)一定是經(jīng)過驗(yàn)證的。

生成海報(bào)

免責(zé)聲明：此文內(nèi)容為第三方自媒體作者發(fā)布的觀察或評論性文章，所有文字和圖片版權(quán)歸作者所有，且僅代表作者個(gè)人觀點(diǎn)，與極客網(wǎng)無關(guān)。文章僅供讀者參考，并請自行核實(shí)相關(guān)內(nèi)容。投訴郵箱：editor@fromgeek.com。

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實(shí)，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。