本視頻時(shí)長(zhǎng)39分，建議在Wifi環(huán)境下觀看。

簡(jiǎn)單介紹一下外賣現(xiàn)在的情況：我們從2013年10月份做外賣的事情，是從餐飲外賣開(kāi)始的。經(jīng)過(guò)兩年多的發(fā)展，我們不光可以提供餐飲外賣，也可以提供水果、鮮花、蛋糕、下午茶甚至是超市和便利店一些外送的服務(wù)。我們做外賣過(guò)程中，我們發(fā)現(xiàn)用戶對(duì)外送的體驗(yàn)有兩個(gè)關(guān)注點(diǎn)：

1. 第一個(gè)是品質(zhì)，用戶對(duì)品質(zhì)要求非常高，送過(guò)來(lái)的飯不能涼了，不能不好看，送餐員身上臟兮兮也不行會(huì)影響食欲的；

2. 另外一個(gè)關(guān)注點(diǎn)要準(zhǔn)時(shí)，一定要按時(shí)間送到，比如我要求按12點(diǎn)送到就一定要按12點(diǎn)送到，不能早也不能晚，如果早為什么不好呢？11點(diǎn)40送到不行，我們正在跟老板開(kāi)會(huì)，一會(huì)一個(gè)電話太煩了；12點(diǎn)20送來(lái)也不行，太餓了，我都餓暈了，中午也有很多的安排，吃完飯可能要睡一會(huì)，中午不睡下午崩潰呀。

我們發(fā)現(xiàn)如果要把用戶體驗(yàn)做到極致的話，做得足夠好能保證用戶得到足夠好的體驗(yàn)，我們就要做專送的服務(wù)。所以我們正在做的是美團(tuán)外賣的平臺(tái)和我們自己的配送服務(wù)。

我們從2013年10月份確立做這個(gè)事情，到11月份正式上線，到14年底11月份時(shí)突破日訂單一百萬(wàn)單，15年的5月份大概突破了每天兩百萬(wàn)單，然后大概15年12月份做到每天三百萬(wàn)單，今年5月份的時(shí)候我們做到了四百萬(wàn)單每天。我們希望在響應(yīng)國(guó)家大的號(hào)召下，我們做供給側(cè)改革。我們希望給大家提供更多的、優(yōu)質(zhì)的、可選的外送服務(wù)，希望未來(lái)的某一天做到每天1000萬(wàn)單。

介紹一下我們的業(yè)務(wù)，也介紹一下在做這個(gè)業(yè)務(wù)過(guò)程中技術(shù)架構(gòu)的演進(jìn)的歷程。我們?cè)陂_(kāi)始做外賣的時(shí)候發(fā)現(xiàn)，那時(shí)候都是通過(guò)電話來(lái)點(diǎn)外賣的，小餐館的老板發(fā)傳單，我們用傳單上的電話給老板打電話下單。我們?cè)谒伎嘉覀兪遣皇强梢园央娫掽c(diǎn)餐的事情變成網(wǎng)絡(luò)點(diǎn)餐，讓用戶只需要在網(wǎng)絡(luò)上點(diǎn)點(diǎn)點(diǎn)就行了，不用打電話。

于是我們?cè)诠局車纳碳颐鬟@個(gè)事情，我們?cè)缟舷铝说罔F在地鐵口發(fā)傳單。我們?cè)趺茨軌蜃羁斓厝ヲ?yàn)證這個(gè)事情是否可行？

我們提供了一個(gè)非常簡(jiǎn)單的Web版本和Android的App，對(duì)于商家那一邊我們沒(méi)有提供任何軟件的服務(wù)，用戶在我們平臺(tái)里下單以后，我們?cè)俅螂娫捊o商家下單，有時(shí)候我們是發(fā)傳單的，有時(shí)候我們是接線員，用戶在我們平臺(tái)上下單，我們?cè)俅螂娫捊o商家下單，然后再去寫代碼。那時(shí)候基本上沒(méi)有太多架構(gòu)考慮，就是怎么快怎么來(lái)，以最快的速度去把我們的功能給變上去。 

這個(gè)事情我們驗(yàn)證之后發(fā)現(xiàn)確實(shí)可行，我們發(fā)現(xiàn)“懶”是極大的需求。因?yàn)閼械萌Q臺(tái)，所以發(fā)明了遙控器，懶得爬樓梯就發(fā)明了電梯，人都是很懶的，因?yàn)閼械么螂娫捰啿?，所以在網(wǎng)上點(diǎn)點(diǎn)點(diǎn)就好了。

我們發(fā)現(xiàn)這是極強(qiáng)的需求，于是我們就考慮規(guī)?；?，因?yàn)橹挥幸?guī)?；筮呺H的成本才可以變低，這套軟件在一個(gè)區(qū)域可以用，在一個(gè)城市可以用、在全國(guó)也可以用，我們的開(kāi)發(fā)成本就是這么多，所以我們?cè)趪L試在做規(guī)模化。

這個(gè)過(guò)程爆發(fā)性產(chǎn)生了非常多系統(tǒng)，我們?cè)谟脩暨@邊提供各種APP，商家這一邊我們也開(kāi)始提供服務(wù)。我們給商家提供PC的版本、App版本，還給商家提供打印機(jī)。

打印機(jī)是跟我們后臺(tái)是聯(lián)網(wǎng)的，如果用戶在我們平臺(tái)上下單，我們會(huì)直接推送到這個(gè)打印機(jī)上，這個(gè)打印機(jī)可以直接打出單子，同時(shí)可以用林志玲或者郭德綱的聲音告訴你：“你有美團(tuán)外賣的訂單請(qǐng)及時(shí)處理”，這是對(duì)商家非常好的效率提升；同時(shí)我們給自身運(yùn)營(yíng)的系統(tǒng)加了很多功能，我們有上單、審核等各種各樣的系統(tǒng)等爆發(fā)性地產(chǎn)生了。

在這個(gè)階段我們業(yè)務(wù)發(fā)展特別快導(dǎo)致我們堆了特別多的系統(tǒng)，這個(gè)時(shí)候也并沒(méi)有做非常清晰的架構(gòu)，就是想把這個(gè)系統(tǒng)盡快地提供上線。這時(shí)候所有的表都在一個(gè)數(shù)據(jù)庫(kù)里，大家都對(duì)這件事情非常熟悉，我可以做訂單，也可以做管理系統(tǒng)。

但是這個(gè)事情在規(guī)?；?、用戶量迅速上升之后給我們帶來(lái)非常大的困擾，因?yàn)橹拔覀兪怯泻芏嗉夹g(shù)欠債的，在這個(gè)階段里面我們就做了重大的架構(gòu)調(diào)整，在這個(gè)調(diào)整里主要說(shuō)兩點(diǎn)：

1. 第一點(diǎn)就是拆 
   我們把很多耦合在一起的服務(wù)做服務(wù)化拆分，服務(wù)與服務(wù)之間通過(guò)接口來(lái)調(diào)用和訪問(wèn)，服務(wù)自己保護(hù)自己的庫(kù)：不能訪問(wèn)別人的庫(kù)，否則叫出軌；你的數(shù)據(jù)庫(kù)也不能被別人訪問(wèn)，否則叫綠帽子。

2. 第二點(diǎn)是中間件 
   我們?cè)谶@個(gè)階段引進(jìn)了很多中間件，包括了在開(kāi)源基礎(chǔ)上自研的KV系統(tǒng)，我們也引用了搜索Elasticsearch，我們通過(guò)Databus抓取數(shù)據(jù)庫(kù)的變更，把數(shù)據(jù)庫(kù)的實(shí)時(shí)變更刷到緩存和索引里，讓這個(gè)中間件做到穩(wěn)定可靠的服務(wù)。 

總結(jié)一下的話，我們的演進(jìn)大概分了這樣一個(gè)階段：整體上有一個(gè)多邏輯耦合在一起的情況按服務(wù)化拆分出來(lái)，每一個(gè)服務(wù)獨(dú)立專注地做一個(gè)事情，然后我們?cè)僮鰬?yīng)用級(jí)的容錯(cuò)，到現(xiàn)在我們?cè)谧龆鄼C(jī)房的容錯(cuò)。

在緩存上，我們?cè)缙谑褂昧薘edis，在Redis Cluster還沒(méi)發(fā)布之前我們用了他們的Alpha版本，當(dāng)然也踩了很多坑。后來(lái)我們用了自研的KV系統(tǒng)，最早的時(shí)候我們把所有業(yè)務(wù)的KV都是共用的，這個(gè)也有很大的問(wèn)題：如果所有的業(yè)務(wù)共用的KV集群，其中某一個(gè)業(yè)務(wù)導(dǎo)致這個(gè)KV集群有問(wèn)題的話，所有的業(yè)務(wù)都受影響。后來(lái)我們也做了每一個(gè)業(yè)務(wù)拆分自己專用的KV集群。

在數(shù)據(jù)庫(kù)這一層上，基本上是把一些大表的查詢、對(duì)數(shù)據(jù)庫(kù)有較大傷害的查詢變成了高級(jí)的搜索，在數(shù)據(jù)庫(kù)和應(yīng)用層之間加了中間件。

在360開(kāi)源的Atlas基礎(chǔ)上做了我們自己的定制，這個(gè)中間件有個(gè)好處：我們對(duì)數(shù)據(jù)庫(kù)的變更對(duì)于業(yè)務(wù)層是透明的，比如說(shuō)覺(jué)得能力不夠要擴(kuò)容，我們加幾臺(tái)從庫(kù)，業(yè)務(wù)方是無(wú)感知的，而且我們會(huì)做SQL的分組，即數(shù)據(jù)庫(kù)的分組，哪些SQL到哪個(gè)數(shù)據(jù)庫(kù)上，到主庫(kù)還是從庫(kù)上去，我們業(yè)務(wù)是不用關(guān)心的。 

下面介紹一下做外賣這個(gè)事情上遇到的挑戰(zhàn)：

1. 第一個(gè)挑戰(zhàn)，外賣這個(gè)事情具有一個(gè)典型的特點(diǎn)，就是聚集在中午和晚上兩個(gè)吃飯的高峰期，這天然就是非常集中的秒殺的場(chǎng)景，因?yàn)榇蠹視?huì)集中在11點(diǎn)10分到11點(diǎn)半去下單。我們?cè)诟叻迤诘臅r(shí)候，有一分鐘接進(jìn)2萬(wàn)單的巨大流量；

2. 第二個(gè)挑戰(zhàn)，大家理解送外賣是一個(gè)很簡(jiǎn)單的事情，我點(diǎn)了餐，送過(guò)來(lái)，我愉快的把它吃掉就結(jié)束了，但是做外賣的事情上我們發(fā)現(xiàn)確實(shí)蠻復(fù)雜的，因?yàn)槲覀儼l(fā)現(xiàn)用戶要下單，要支付，我們還要調(diào)度一個(gè)配送員，我們找一個(gè)最快最合理的騎手，讓他到時(shí)間取餐送過(guò)去，同時(shí)還要給這個(gè)騎手最好的路徑規(guī)劃，告訴他走這條路是最快的。所以整個(gè)是一個(gè)非常復(fù)雜的過(guò)程，有非常非常多的服務(wù)；

3. 另外，外賣還是快速發(fā)展的階段，對(duì)我們的挑戰(zhàn)是迭代太快了，你可能要頻繁的發(fā)版，就有穩(wěn)定性的風(fēng)險(xiǎn)，可能有Bug，可能有測(cè)試不全的情況。另外是項(xiàng)目周期短，業(yè)務(wù)發(fā)展很快有很多業(yè)務(wù)需求正在排隊(duì)，架構(gòu)優(yōu)化的工作可能排不上去，甚至做技術(shù)架構(gòu)設(shè)計(jì)的時(shí)候可能有一些折中，這是極大的隱患，我們把它叫技術(shù)欠債。

   我們有一個(gè)列表記錄下來(lái)這些技術(shù)欠債，會(huì)記清楚說(shuō)這是一個(gè)什么樣的條件下做的方案，它在什么情況下可能會(huì)有哪些問(wèn)題，需要在什么時(shí)候必須去做哪些事情；另外一塊在監(jiān)控的壓力也很大，因?yàn)闃I(yè)務(wù)變化非常快，你今天是這樣設(shè)置監(jiān)控規(guī)則，明天業(yè)務(wù)又變了。 

如何保持穩(wěn)定性

介紹一下我們對(duì)于穩(wěn)定性的定義，我們也是拿四個(gè)“9”來(lái)衡量穩(wěn)定性，但是我們分別用于兩個(gè)指標(biāo)：系統(tǒng)可用性和訂單的可用性。

1. 系統(tǒng)可用性四個(gè)'9'意味著全年的宕機(jī)時(shí)間不超過(guò)52分鐘，我們是按季度考核的，相當(dāng)于一個(gè)季度系統(tǒng)宕機(jī)時(shí)間不超過(guò)13分鐘；

2. 另外一個(gè)維度訂單可用性也是四個(gè)'9'，意味著我們一個(gè)季度是一億單的話，這個(gè)季度的訂單損失不能超過(guò)1萬(wàn)單，而我們高峰期一分鐘就接近兩萬(wàn)單，因此只要這個(gè)系統(tǒng)有問(wèn)題，我們這個(gè)KPI就無(wú)法完成。

我們還是要保證四個(gè)'9'的可靠性，而我們?cè)趺慈プ觯何覀儚乃膫€(gè)階段來(lái)扎實(shí)地做這些事情：一個(gè)是日常運(yùn)行，二是事前預(yù)警，三是事故處理，四是事后總結(jié)，我會(huì)詳細(xì)地介紹這四個(gè)環(huán)節(jié)：

一、日常運(yùn)行 

首先在日常運(yùn)行里面，我們要做好穩(wěn)定性的架構(gòu)設(shè)計(jì)，這里有幾個(gè)原則：

第一個(gè)是大系統(tǒng)小做 

我們不希望做一個(gè)非常大的系統(tǒng)，它什么都能做，我們希望做小的系統(tǒng)，非常專注，功能相對(duì)獨(dú)立。我們先把功能相對(duì)獨(dú)立的系統(tǒng)拆開(kāi)，在早期發(fā)展過(guò)程中，你們看我們有一個(gè)系統(tǒng)它什么都能干，它其實(shí)是一個(gè)Web項(xiàng)目，還提供了Web的服務(wù)，同時(shí)還提供了App的API服務(wù)，它還消費(fèi)消息隊(duì)列，還是Job的執(zhí)行者，這就帶來(lái)一個(gè)問(wèn)題：你消費(fèi)消息的邏輯發(fā)生變化了，你就要去發(fā)版，其實(shí)別的功能是沒(méi)有變化的，發(fā)版就會(huì)影響到其他的功能。當(dāng)我們把幾個(gè)系統(tǒng)拆開(kāi)，它就是四個(gè)獨(dú)立的系統(tǒng)；

第二個(gè)原則是依賴穩(wěn)定性原則，你提供的服務(wù)一定是穩(wěn)定可靠的 

這里希望是將易變的和不變的地方拆開(kāi)。舉個(gè)例子，對(duì)于商家的服務(wù)，對(duì)于C端的用戶和服務(wù)來(lái)說(shuō)，用到最大的場(chǎng)景就是GetById，就是知道這個(gè)商家的信息就好了，但是我們還有很多對(duì)商家管理的服務(wù)需求，比如說(shuō)商家符合什么條件才能上線，需要什么過(guò)程才能改他的菜品，這些管理的功能是經(jīng)常變化的，對(duì)于讀取的信息是不變的，于是我們把這它拆開(kāi)，把它變?yōu)樽x的服務(wù)和管理的服務(wù)。管理的服務(wù)可以隨時(shí)發(fā)版，沒(méi)有關(guān)系，讀的服務(wù)是非常穩(wěn)定的，基本不發(fā)版；

最后一個(gè)原則是設(shè)計(jì)這個(gè)穩(wěn)定性的時(shí)候需要考慮用戶的體驗(yàn) 

需要考慮在系統(tǒng)出現(xiàn)問(wèn)題的時(shí)候用戶怎么辦？相信很多同學(xué)都有這個(gè)體驗(yàn)：可能APP上突然有提示失敗、服務(wù)器異常、空，不知道什么情況。我相信用戶遇到這種情況一定會(huì)不停刷新的，這時(shí)候如果后臺(tái)已經(jīng)有問(wèn)題的話其實(shí)是糟糕的事情，所以設(shè)計(jì)的時(shí)候要考慮到在異常情況下用戶的體驗(yàn)和用戶如何引導(dǎo)。 

日常運(yùn)行里面，另外一個(gè)工作是做例行的穩(wěn)定性巡檢

1、比如說(shuō)我們做專項(xiàng)的巡檢 

對(duì)DB來(lái)講，我們每個(gè)月要做DB容量的Review，我們看哪些表是大表、讀寫的QPS以及它的容量，以及未來(lái)某一天它能不能支持業(yè)務(wù)的發(fā)展；

2、我們會(huì)做靜態(tài)的梳理 

我們按場(chǎng)景梳理，例如首頁(yè)、Banner、列表頁(yè)，這些場(chǎng)景用到哪些服務(wù)，這些服務(wù)又用到了哪些服務(wù)，這些過(guò)程中，它們對(duì)下游的調(diào)用是否存在放大的情況。有一些情況是假的高并發(fā)。

比如說(shuō)有一個(gè)服務(wù)是說(shuō)告訴商家今天有幾個(gè)新訂單，這個(gè)功能很簡(jiǎn)單，就是在前端頁(yè)面去做輪詢，這個(gè)過(guò)程其實(shí)80%-90%的查詢是無(wú)效的，因?yàn)橐坏┯行掠唵挝覀兙蜁?huì)推送到商家，商家就會(huì)及時(shí)地處理掉，查這個(gè)請(qǐng)求其實(shí)是無(wú)效的，這么多無(wú)效的請(qǐng)求去查訂單的服務(wù)，最終還要落到數(shù)據(jù)庫(kù)上，這是假的高并發(fā)，這里我們?cè)谇懊婕右粚泳彺?，把到?shù)據(jù)庫(kù)的這一層假的高并發(fā)給干掉；

3、另外一個(gè)例行的工作是對(duì)指標(biāo)的巡檢

我們有許多的監(jiān)控指標(biāo)，尤其是關(guān)注它的尖刺，這些尖刺也不會(huì)放過(guò)。

對(duì)于平時(shí)來(lái)講，給我們?cè)鰪?qiáng)穩(wěn)定性最可靠的信心就是在線壓測(cè)，我們和其他大廠差不多，我們也在做在線壓測(cè)這個(gè)東西，我們有一個(gè)在線壓測(cè)的平臺(tái)。我們希望通過(guò)壓測(cè)來(lái)發(fā)現(xiàn)什么呢？首先發(fā)現(xiàn)系統(tǒng)里面的性能瓶頸，到底哪個(gè)系統(tǒng)是里面最弱的，以及我們要知道系統(tǒng)服務(wù)的上限和能力。

另外更關(guān)鍵的是，我們需要通過(guò)壓測(cè)來(lái)驗(yàn)證我們的監(jiān)控和報(bào)警機(jī)制是否生效的，可能很多時(shí)候大家都說(shuō)我們配置了非常完整的監(jiān)控方案，但是它可能不生效，一旦不生效就慘了。另外，我們要通過(guò)壓測(cè)指導(dǎo)我們報(bào)警的警戒線是怎么設(shè)置，到底CPU是設(shè)置是30%還是70%，什么時(shí)候該報(bào)警，我們就通過(guò)壓測(cè)來(lái)確立。

這個(gè)壓測(cè)告訴我們指導(dǎo)意見(jiàn)，警戒線設(shè)置到哪個(gè)位置是給你留有充足時(shí)間的，如果你的報(bào)警發(fā)生之后馬上掛了，其實(shí)報(bào)警是沒(méi)有用的。我們可以通過(guò)壓測(cè)來(lái)要設(shè)置警戒行動(dòng)線，到這個(gè)時(shí)候我們要考慮和關(guān)注這個(gè)問(wèn)題，留給穩(wěn)定性處理有足夠的時(shí)間。

我們?cè)趺醋瞿兀课覀儼丫€上的流量經(jīng)過(guò)日志錄取下來(lái)，把錄取的流量放到我們的壓測(cè)平臺(tái)里，這是對(duì)于讀請(qǐng)求的。對(duì)于寫請(qǐng)求的，我們做一些事務(wù)的模擬，我們有一些模擬的腳本偽造一些根據(jù)我們場(chǎng)景做的數(shù)據(jù)。

這些數(shù)據(jù)再經(jīng)過(guò)一次染色，把真實(shí)數(shù)據(jù)和測(cè)試數(shù)據(jù)隔離開(kāi)，經(jīng)過(guò)我們異步階梯加壓的模塊，我們先通過(guò)異步的方式把它迅速打起來(lái)，我們可以把量打地非常高；另外我們是通過(guò)階梯性地打，我們不是一次打到2萬(wàn)，我們可能先到5000，然后再到9000，然后打到15000，然后再持續(xù)10分鐘。

我們對(duì)這個(gè)監(jiān)控的流量施壓過(guò)程和跟我們監(jiān)控指標(biāo)關(guān)聯(lián)起來(lái)，我們做壓測(cè)之前先看和哪幾個(gè)指標(biāo)關(guān)聯(lián)，哪幾個(gè)指標(biāo)到了什么閾值就自動(dòng)中止壓測(cè)，畢竟我們是在線上做這些事情，不能對(duì)真實(shí)線上的情況產(chǎn)生影響。對(duì)于其他依賴的服務(wù)，比如說(shuō)支付，這些真的不能壓到銀行去，外部的服務(wù)我們做了一些Mock。 

二、事前預(yù)警 

對(duì)于事前預(yù)警階段，如果真的有事故發(fā)生我們希望更早曝露出來(lái)，觸發(fā)報(bào)警，然后有充足的時(shí)間去應(yīng)對(duì)這些事情，我們?cè)谶@個(gè)地方在事前預(yù)警階段我們有一些監(jiān)控心得：

首先是有分層的監(jiān)控：有系統(tǒng)級(jí)的監(jiān)控，例如性能指標(biāo)的監(jiān)控，還有業(yè)務(wù)監(jiān)控，我們還有平時(shí)健康度的分析，我們的應(yīng)用是不是健康的。

我們分享一下在業(yè)務(wù)監(jiān)控的想法，業(yè)務(wù)監(jiān)控其實(shí)是最讓你放心的，你有一個(gè)業(yè)務(wù)大盤，這個(gè)大盤如果有一個(gè)波動(dòng)你就立馬發(fā)現(xiàn)了，說(shuō)明現(xiàn)在可能會(huì)有影響，你可能會(huì)收到報(bào)警，例如什么CPU的報(bào)警，你去看大盤，大盤可能說(shuō)沒(méi)有什么影響，這樣你不會(huì)那么慌。

另外，我們系統(tǒng)里面把訂單相關(guān)的所有信息和重要節(jié)點(diǎn)做了日志的輸出，日志通過(guò)flume收集到Kafka再到Storm里，我們?cè)赟torm里對(duì)這些日志進(jìn)行匯聚，匯聚的結(jié)果放在HBase里，在這些結(jié)果里我們有幾個(gè)非常好的應(yīng)用：

1. 例如首先只要告訴我一個(gè)訂單號(hào)或者手機(jī)號(hào)，我可以查到這個(gè)訂單走到了哪個(gè)環(huán)節(jié)，到了哪個(gè)服務(wù)的哪個(gè)服務(wù)器掛掉了，解決這類問(wèn)題非常的方便；

2. 另外我們還可以把這些指標(biāo)做成監(jiān)控曲線，比如說(shuō)你要下單，下單量是這么高，到了接單的環(huán)節(jié)它出現(xiàn)了下降，接單這個(gè)服務(wù)可能關(guān)聯(lián)的ABC三個(gè)服務(wù)：可能有商家、PC、打印機(jī)的接單，到底是哪個(gè)服務(wù)出了問(wèn)題導(dǎo)致了大盤的下降，我們的曲線可以非常方便地看出來(lái)。 

三、事故處理 

還有可能有一些意想不到的事情發(fā)生，真的出現(xiàn)了事故怎么辦？第一原則就是及時(shí)止損。我們知道發(fā)版是導(dǎo)致穩(wěn)定性變化的第一因素，如果立馬確定是由發(fā)版引起的這次事故，最快速最有效的方法就是回滾。另外可能還有一些流量異常，對(duì)于流量異常我們有限流的模塊，我們提供了三種限流的策略：

1. 第一種是防刷的，防止用戶頻繁刷新導(dǎo)致后臺(tái)的流量繼續(xù)放大；

2. 另外一個(gè)策略是等待 限時(shí)的服務(wù)，用戶其實(shí)在用我們平臺(tái)的時(shí)候，用戶確實(shí)是需要選的，可能要選來(lái)選去才能下單，對(duì)于這些服務(wù)，我們希望說(shuō)你愿意等一段時(shí)間我們可以提供，比如說(shuō)你愿意等10秒鐘，我給你提供20分鐘的服務(wù)，這段時(shí)間應(yīng)該是可以下完單的；

3. 還有一種策略是對(duì)單機(jī)的QPS保護(hù)：我們壓測(cè)驗(yàn)證的時(shí)候這個(gè)服務(wù)單機(jī)能達(dá)到500QPS是穩(wěn)定可靠的，再往高有問(wèn)題的話，我可以啟動(dòng)這樣一個(gè)保護(hù)，確保你能夠以最大的服務(wù)能力提供服務(wù)而不至于掛掉。另外在單機(jī)QPS保護(hù)中我們需要把關(guān)鍵的路徑去放過(guò)，你真的不希望用戶在下單、支付的這些路徑把它干掉或流空掉，這些服務(wù)我們就用白名單的方式放過(guò)。 

四、事故總結(jié) 

事故發(fā)生之后，我們需要對(duì)事故做一個(gè)非常深刻的總結(jié)。這里面有幾個(gè)非常強(qiáng)的要求，第一是必須找到根源，根源我們采用5whys的分析方法，一定要追蹤到最根本的原因，從現(xiàn)象開(kāi)始追蹤。另外要去核算清楚這次造成多少損失，因?yàn)槲覀円阄覀兊姆€(wěn)定性。還有一個(gè)方面，你要對(duì)這次系統(tǒng)出現(xiàn)問(wèn)題的過(guò)程、你處理的過(guò)程和中間的流程進(jìn)行總結(jié)，看哪些地方可以優(yōu)化。

我建議的做法是：我們需要把這次事故處理的過(guò)程詳細(xì)記錄下來(lái)，它可能是需要精確到分鐘的，比如說(shuō)某一分鐘誰(shuí)跟誰(shuí)做了什么動(dòng)作，這對(duì)我們總結(jié)很有幫助。因?yàn)橛锌赡苁鹿侍幚磉^(guò)程本身是有問(wèn)題的，比如說(shuō)你去擴(kuò)容花了30分鐘時(shí)間，這是有問(wèn)題的；比說(shuō)你在處理過(guò)程中做了錯(cuò)誤的決定也是有問(wèn)題的，所以我們把過(guò)程中做了詳細(xì)的記錄。

我們對(duì)于這個(gè)事故的總結(jié)和Review，我們希望能看到什么？在這個(gè)總結(jié)里面，我們希望看到到底哪里出了問(wèn)題，我們能不能更快的發(fā)現(xiàn)它，將來(lái)如果再發(fā)現(xiàn)，能不能比現(xiàn)在處理的更快一點(diǎn)。

講完這些處理原則，再介紹一下我們做這個(gè)事情的實(shí)踐。我們對(duì)穩(wěn)定性的要求是極高的，每一個(gè)訂單的損失我們非常敏感，我們就有一個(gè)實(shí)踐的動(dòng)作：就是力保關(guān)鍵路徑不掛，我們要保住訂單，那要保住和訂單交易相關(guān)的所有路徑不能掛。

所以平時(shí)我們就梳理出了和訂單交易的關(guān)鍵路徑，從用戶下單、從用戶開(kāi)始選門店，然后開(kāi)始選菜，然后下單，然后到配送完成，這個(gè)過(guò)程里邊每一個(gè)環(huán)節(jié)關(guān)聯(lián)了哪些服務(wù)，這些服務(wù)都應(yīng)該具備有降級(jí)的功能。

比如說(shuō)Rank服務(wù)，用戶首先打開(kāi)我們App的時(shí)候，我們就會(huì)給他最附近的、可以配送到的一些商家，這些服務(wù)會(huì)給用戶之前的購(gòu)買記錄來(lái)做推薦，我們會(huì)給他更好的排序。

如果我們Rank的服務(wù)出現(xiàn)問(wèn)題了，我們可以迅速地將這個(gè)Rank的服務(wù)給降級(jí)掉，改成默認(rèn)按銷量去排序，這樣用戶也是可以選餐的。所以這個(gè)環(huán)節(jié)里面的每一步我們都可以降級(jí)的，從而保證在下單這個(gè)關(guān)鍵路徑上服務(wù)都OK，其他服務(wù)可以接受它的掛掉。 

另外，預(yù)案的建設(shè)，你永遠(yuǎn)需要想一下你將來(lái)可能發(fā)生什么，如果發(fā)生這些事情的話，我們?cè)撛趺崔k？所以你在做這個(gè)事情之前就要去考慮，我們認(rèn)為性能是功能的一部分，穩(wěn)定也是功能的一部分，而不是大家做這一次技術(shù)方案設(shè)計(jì)，做完之后再來(lái)優(yōu)化性能和穩(wěn)定性。

我們需要在做這個(gè)架構(gòu)設(shè)計(jì)的時(shí)候考慮到性能和穩(wěn)定，它們是產(chǎn)品功能的一部分，同時(shí)也要考慮到如果性能穩(wěn)定性出現(xiàn)問(wèn)題，用戶體驗(yàn)是怎樣的，用戶不希望看到很傻的提示。

所以我們?cè)诠δ茉O(shè)計(jì)的時(shí)候，就考慮到了出現(xiàn)這樣的情況我們可能要降級(jí)，這個(gè)降級(jí)的方案可能是一個(gè)開(kāi)關(guān)，就會(huì)有非常多降級(jí)開(kāi)關(guān)，有些情況下是更復(fù)雜的場(chǎng)景：如果這個(gè)情況發(fā)生了，我們可能把這個(gè)開(kāi)關(guān)和那個(gè)開(kāi)關(guān)給關(guān)掉，這是我們的降級(jí)管理平臺(tái)，我們真的把一個(gè)降級(jí)開(kāi)關(guān)給做成了一個(gè)開(kāi)關(guān)，就是開(kāi)啟和關(guān)閉，同時(shí)我告訴你開(kāi)啟意味著什么、影響著什么。

再介紹一下這個(gè)平臺(tái)里面我們有對(duì)灰度的管理，有對(duì)壓測(cè)的管理，有對(duì)健康度的分析。另外有一塊我們稱為核按鈕，即如果事情發(fā)生之后你要保住的底線，如果我們的系統(tǒng)出現(xiàn)問(wèn)題，商家不能接單或者配送無(wú)法送出的話，用戶下的這些單子都會(huì)被取消掉，這個(gè)體驗(yàn)是很糟的。

我下了單，然后5分鐘你告訴我商家不能接單這個(gè)訂單被取消掉了，我忍了我換了一家，結(jié)果又被取消了，這會(huì)罵人的。如果商家不能接單，就不要讓用戶下單，如果這些情況發(fā)生，我們就迅速啟動(dòng)核按鈕，把我們篩選的這些不能接單的商家迅速變?yōu)樾菹?，可以保證用戶向可以服務(wù)的商家去下單。 

在整個(gè)實(shí)踐的過(guò)程中，與穩(wěn)定性斗智斗勇的過(guò)程中，我們總結(jié)了非常多的流程，我們叫做標(biāo)準(zhǔn)操作流程SOP，這些流程涵蓋了從需求、開(kāi)發(fā)、測(cè)試、上線、監(jiān)控、故障處理的每個(gè)環(huán)節(jié)，每一個(gè)環(huán)節(jié)都是標(biāo)準(zhǔn)的、非常嚴(yán)格的、經(jīng)過(guò)認(rèn)真思考的流程來(lái)供大家參考的，一定要按照流程來(lái)操作。為什么這樣做？

給大家舉個(gè)例子，按照這個(gè)步驟走是值得信賴的，每一步都有非常好的預(yù)案與系統(tǒng)的配合。比如說(shuō)出現(xiàn)事故，大家是很慌的，因?yàn)槟敲炊嗳嗽谕对V、那么多人在等著說(shuō)不能點(diǎn)餐了，為什么，美團(tuán)外賣怎么了？然后我們處理事故的同學(xué)說(shuō)：你不要慌。怎么可能呢？那么多用戶在投訴，老板還在后面問(wèn)你怎么樣了，什么時(shí)候才能處理好，怎么可能不慌呢，臣妾做不到呀。

這個(gè)時(shí)候你肯定很慌的，這個(gè)時(shí)候你還要把很多問(wèn)題考慮清楚幾乎是不可能的，有些同學(xué)說(shuō)我這里需要這么做、我需要寫條SQL，結(jié)果忘了Where的語(yǔ)句，所以你在非常緊張的情況下根本想不全這件事情的，那怎么辦？我們只能提前想好，如果會(huì)出現(xiàn)這種情況我們就執(zhí)行這條SQL，然后放在那里經(jīng)過(guò)無(wú)數(shù)人的Review和實(shí)驗(yàn)，它是可靠和可以被執(zhí)行的。所以，我們?cè)谡麄€(gè)過(guò)程里面收集了非常非常多的操作流程，每一步都有非常嚴(yán)格的要求。 

我們梳理完了這些流程，希望把這些流程變成自動(dòng)化的，否則人工操作的話，我們是可以要求大家嚴(yán)格執(zhí)行，但是畢竟也是效率低下的，我們需要把很多的操作變成自動(dòng)化。

舉個(gè)例子，下圖是我們發(fā)版的流程，看上去還蠻復(fù)雜的，一共有10步，我們有非常多的要求，你在發(fā)版之前需要驗(yàn)證哪些事情，發(fā)完版之后要驗(yàn)證哪些功能，最重要的是你要去評(píng)估，你要去評(píng)估有什么影響，你對(duì)下游有什么影響。

更重要的是，我們對(duì)每次發(fā)版都一定要有回滾措施，就是應(yīng)急預(yù)案，你要回滾到哪個(gè)版本，如果是一個(gè)大的項(xiàng)目，大家一起聯(lián)合發(fā)布的，是怎樣的回滾過(guò)程，誰(shuí)先操作誰(shuí)后操作。對(duì)于每一次發(fā)版，沒(méi)有預(yù)案是不允許發(fā)布的。

大家可能會(huì)說(shuō)，我要改庫(kù)、我要改表，我已經(jīng)把表結(jié)構(gòu)變了，還要寫數(shù)據(jù)，這時(shí)候無(wú)法回滾，回不去了。那不行，那是不可能的，你一定有辦法把它回退過(guò)去。另外，我們有每一次的降級(jí)方案和灰度的策略，如果是這一次發(fā)版引發(fā)的故障的，發(fā)版之后整個(gè)過(guò)程做一次非常詳細(xì)的整理，到底哪些地方出了什么問(wèn)題。 

在處理的過(guò)程中有幾句總結(jié)的話跟大家分享：

第一句話：你要想穩(wěn)定性做的非常可靠，灰度、灰度、還是灰度，沒(méi)有別的方法 ；你不要把所有的量去驗(yàn)證這個(gè)事情。我們對(duì)于灰度，可以做到按照城市、按某個(gè)功能、按URL某個(gè)參數(shù)來(lái)進(jìn)行灰度，也可以按照一定流量的比例，比如說(shuō)先灰度1%，然后到50%，然后到100%。 

另外我們對(duì)于發(fā)版是有很強(qiáng)要求的，我們有一個(gè)發(fā)版的時(shí)間窗，周一到周四的下午兩點(diǎn)到四點(diǎn)，其他時(shí)間是不允許發(fā)版的，如果你要發(fā)版你要提申請(qǐng)和審批。

為什么這么做呢？因?yàn)槲覀兺赓u特點(diǎn)就是中午流量非常高，晚上流量偏低。我們之前發(fā)現(xiàn)其實(shí)兄弟們很辛苦，非常辛苦的寫代碼，寫到晚上八點(diǎn)，終于寫完了開(kāi)始發(fā)版，然后測(cè)試，到十點(diǎn)多又有十幾臺(tái)服務(wù)器要發(fā)布上去，還要回歸這些功能，到11點(diǎn)終于發(fā)完了，一身疲憊終于可以回家了，然后回去休息。第二天早上十點(diǎn)鐘一個(gè)電話打過(guò)來(lái)，出問(wèn)題了，怎么辦？到底去公司還是不去呢？別去了，趕緊在家看吧。

因?yàn)榈诙熘形缡欠浅８叩母叻?，我們不希望用中午這么大的量來(lái)驗(yàn)證，我們希望晚上來(lái)驗(yàn)證，晚高峰雖然比中午的高峰低很多，但是也是一個(gè)非常大的高峰，我們用這個(gè)流量來(lái)驗(yàn)證，所以我們把發(fā)版的時(shí)間調(diào)到下午，不要在晚上發(fā)版，這樣很累可能想不清楚，和你關(guān)聯(lián)的其他同事都不在，很多事情也無(wú)法處理。

所以我們下午來(lái)發(fā)版，這樣會(huì)很穩(wěn)妥，大家都在，通過(guò)晚上的高峰來(lái)驗(yàn)證，如果沒(méi)有問(wèn)題，第二天也很穩(wěn)妥很安心的，如果有問(wèn)題則晚上進(jìn)行壓測(cè)；

第二句話：慢查詢往往闖大禍。慢查詢是非常討厭的事情，而且它的出現(xiàn)可能會(huì)有非常大的危害，慢查詢把一個(gè)庫(kù)打掛的話，我們負(fù)載均衡會(huì)跑到其他庫(kù)也繼續(xù)打掛，然后所有都掛了，解決數(shù)據(jù)庫(kù)掛了的問(wèn)題是非常耗時(shí)的，所以對(duì)SQL有極高的要求，在我們的實(shí)踐里面我們不允許寫join，不允許寫like，每一次SQL都有Review，上線的流程里面會(huì)記錄這次上線這次SQL是誰(shuí)Review的；

第三句話：防御式編程，不要相信任何人和服務(wù)。別相信你的下游說(shuō)，我就調(diào)你三次，你放心吧，沒(méi)事的。別信，肯定有鬼，你要做好對(duì)自身的保護(hù)，也不要相信下游說(shuō)別人的提供的服務(wù)放心地使，哥向你保證五個(gè)9的可靠性，沒(méi)有一個(gè)服務(wù)能做到100%的可靠的，這是必然的，即使是5個(gè)9，也有損失的時(shí)候，別相信他，要做好對(duì)下游的依賴和熔斷；

第四句話：SOP保平安。我們把所有的流程都變成標(biāo)準(zhǔn)化流程，這比拜大仙還管用，有時(shí)候開(kāi)玩笑說(shuō)發(fā)版之前沒(méi)有拜一拜所以掛了，其實(shí)不是，而是因?yàn)槟銢](méi)有按照標(biāo)準(zhǔn)流程來(lái)操作所以掛了，如果每一步都嚴(yán)格按照標(biāo)準(zhǔn)流程來(lái)做，它是可信賴的，是不遺不漏的，保證做到方方面面；

最后一句話：你所擔(dān)心的事一定會(huì)發(fā)生，而且可能馬上會(huì)發(fā)生。最近上了一些功能，你說(shuō)好像這個(gè)地方可能會(huì)有問(wèn)題，你最好趕緊看，也許馬上就會(huì)有問(wèn)題。所以我們建議做例行的巡檢，定期地對(duì)你的服務(wù)、服務(wù)的指標(biāo)、依賴的情況，有一天你去看發(fā)現(xiàn)突然多了一個(gè)服務(wù)，可能你還不知道。另外對(duì)DB、KV這樣一些中間件做例行的巡檢，及時(shí)的發(fā)現(xiàn)這些里面可能存在的問(wèn)題。

怎么樣？這樣的分享看了是不是覺(jué)得干貨滿滿、誠(chéng)意十足？那小Q我告訴你，這樣的良心分享，我們一次 ArchSummit 大會(huì)就有十幾個(gè)專題幾十場(chǎng)，就問(wèn)你怕不怕！

ArchSummit 全球架構(gòu)師峰會(huì) 2016 北京站火熱報(bào)名中！二次傳播的拾人牙慧，總是不及講師現(xiàn)場(chǎng)的面授機(jī)宜。