[[179185]]

提到備戰(zhàn)，實(shí)際上不一定要到大型促銷時(shí)，工作應(yīng)該做到平時(shí)。京東已發(fā)展到了一個比較大的體量，無論是大促還是平時(shí)，都容不得出現(xiàn)大問題，我們的思路和方法是：積極預(yù)防、及時(shí)發(fā)現(xiàn)、快速處理，這正是本文前半部分要介紹的。但要做到這十二個字并不容易，本文后半部分會介紹背后的兩個要素：日漸成熟穩(wěn)定的團(tuán)隊(duì)、日趨完善的流程和規(guī)范。

下圖是對本文內(nèi)容的描繪：

1. 積極防預(yù)問題

在預(yù)防措施上，需要遵循PDCA方法：

P階段：

（1）分析系統(tǒng)職責(zé)，確立系統(tǒng)備戰(zhàn)的首要業(yè)務(wù)目標(biāo);

（2）依據(jù)業(yè)務(wù)量評估，對系統(tǒng)處理能力要求進(jìn)行評估，根據(jù)評估結(jié)果和系統(tǒng)運(yùn)行狀況，找出系統(tǒng)瓶頸。*特別地，如果是大促備戰(zhàn)，則要先給大促時(shí)的業(yè)務(wù)量評估。

D階段：

（3）針對系統(tǒng)瓶頸，進(jìn)行系統(tǒng)改造;

（4）梳理系統(tǒng)間的依賴關(guān)系，各系統(tǒng)之間達(dá)成SLA，以保證整體性能指標(biāo)。

C階段：

（5）對系統(tǒng)進(jìn)行壓力測試，驗(yàn)證處理能力，確保達(dá)標(biāo)。特別地，如果是大促備戰(zhàn)，則可以考慮在線上進(jìn)行跨系統(tǒng)軍演;

（6）特別地，如果是大促前夕，則要對系統(tǒng)進(jìn)行全面體檢。

A階段：

（7）如果系統(tǒng)改造達(dá)不到評估要求，則需要修正方案。

1.1. 確定每個系統(tǒng)的首要備戰(zhàn)目標(biāo)

每個系統(tǒng)都會有自己的邊界，各系統(tǒng)負(fù)責(zé)人應(yīng)該分析清楚系統(tǒng)的使命和職責(zé)是什么，分清主次，這同時(shí)也是制定應(yīng)急預(yù)案的最重要依據(jù)，舉例：

（1）訂單交易系統(tǒng)，其最重要的是保證下單，這是剛性的要求，其它的都是有彈性的，例如很多不影響下單的檢驗(yàn)邏輯，都可以放到下單之后來補(bǔ)償;

（2）OFC，其最重要的是保證訂單生產(chǎn)部門有訂單可生產(chǎn)，盡量不影響其產(chǎn)能，在這個前提下，可以采取各種靈活措施。例如，假設(shè)某個庫房的最高生產(chǎn)能力為10萬單，而當(dāng)時(shí)產(chǎn)生的訂單          有20萬，這時(shí)系統(tǒng)保障把10萬訂單送給這個庫房生產(chǎn)就能滿足生產(chǎn)要求了，此時(shí)可以把系統(tǒng)處理能力分配給POP訂單處理;

（3）物流生產(chǎn)系統(tǒng)，其最重要的是滿足工人的作業(yè)需求，保證生產(chǎn)效率，其它的邏輯，如生產(chǎn)數(shù)據(jù)跟蹤數(shù)據(jù)處理，可以異步處理。

1.2. 系統(tǒng)性能評估

總體思路：先進(jìn)行需求評估，然后進(jìn)行系統(tǒng)評估，找出差距。

1.2.1. 性能需求評估

總體思路：

公司層面首先要給出一個業(yè)務(wù)量的初估，然后各個團(tuán)隊(duì)可以根據(jù)此值來把總的業(yè)務(wù)量評估分解到自己的系統(tǒng)的吞吐量指標(biāo)上，接下來就是方案設(shè)計(jì)的問題了，目標(biāo)就是將吞吐量指標(biāo)提高到評估的水平，同時(shí)其它性能指標(biāo)仍能滿足業(yè)務(wù)要求。這樣兼顧了性能和成本。

吞吐能力評估：

吞吐能力，指的是單位時(shí)間內(nèi)處理請求的數(shù)量限制，一般用tps來衡量，指的是每秒處理請求的數(shù)量。

前面提到過要把總的業(yè)務(wù)量評估分解到自己的系統(tǒng)的吞吐量指標(biāo)，可以把系統(tǒng)看成一個黑桶，看這個桶上邊界輸入的量和下面輸出的量。假設(shè)一個系統(tǒng)是客戶訂單處理系統(tǒng)，每一個訂單向它輸入2條處理請求，并向外界輸出4條信息，如果一天的訂單量是1000萬，則這個系統(tǒng)要每天接收2000萬個請求，輸出4000萬條信息。對于直接面對客戶的系統(tǒng)，輸入的評估需要更多的維度(如促銷、推廣)，但也有簡單的評估辦法，那把上一次大促作為參照，按業(yè)務(wù)量同比擴(kuò)大。

當(dāng)然，實(shí)際評估時(shí)，不能只看一天的業(yè)務(wù)量，還要看峰值，而且要高度重視峰值。前端系統(tǒng)的峰值評估需要考慮比較多的維度(如促銷方式和力度等)，后端相對簡單，用于平均值乘以一個系數(shù)即可，這個系統(tǒng)可以根據(jù)系統(tǒng)以住大促時(shí)統(tǒng)計(jì)而來，如果是一個新系統(tǒng)，可以讓上游系統(tǒng)協(xié)助評估。

并不是所有系統(tǒng)都要承擔(dān)高峰值。如果一個業(yè)務(wù)處理流程比較長，則上游的系統(tǒng)可以平滑峰值，讓下游系統(tǒng)享受一個平滑得多的請求流，這樣可以大大減少系統(tǒng)的建設(shè)成本。例如，在訂單處理流程中，OFC扮演了這一個穩(wěn)壓器的作用，OFC把上游訂單和峰值進(jìn)行了平滑。所以吞吐能力的評估也需要團(tuán)隊(duì)合作。

容量規(guī)劃：

吞吐量的提升，往往伴隨著容量提升，需要做好容量規(guī)劃，主要考慮的因素有：

主業(yè)務(wù)對象的量(如訂單)以及到大促前的增長量

每個主業(yè)務(wù)對象會占用多少容量

數(shù)據(jù)要在線上主系統(tǒng)中存留的時(shí)間

出現(xiàn)高峰時(shí)，允許積壓的數(shù)據(jù)量和積壓時(shí)間

有了上面這幾個數(shù)據(jù)，就比較好評估了。特別是針對4進(jìn)行說明，有一些過程數(shù)據(jù)，處理完就不必要在主系統(tǒng)中存留了，所以在評估時(shí)不必考慮，但當(dāng)出現(xiàn)高峰值，且系統(tǒng)處理無法及時(shí)處理時(shí)，可以積壓一部分?jǐn)?shù)據(jù)慢慢處理。

流量規(guī)劃：

吞吐量的提升，也往往伴隨著流量的提升，需要做好容量規(guī)劃，這時(shí)主要考慮峰值時(shí)流量即可，評估時(shí)可以按峰值吞吐量同比擴(kuò)大。如果這個值比較大，應(yīng)該和運(yùn)維同事一起評估并尋求解決辦法。

響應(yīng)速度評估：

響應(yīng)速度，是衡量服務(wù)對請求響應(yīng)時(shí)間的指標(biāo)，一般用毫秒計(jì)量，通常用tp999，tp99,tp90這幾個指標(biāo)，其中tp999指99.9%的服務(wù)請求的響應(yīng)時(shí)間不會高于這個值。

提高響應(yīng)速度，可以提高系統(tǒng)吞吐量。假設(shè)一個服務(wù)的響應(yīng)時(shí)間為100ms，允許的并發(fā)數(shù)是500，則理論上這個服務(wù)的吞吐量上限為 5000(500*1000/100)tps;如果響應(yīng)時(shí)間降低到50ms，則理論上的吞吐量上限會降為10000tps。

但是提高響應(yīng)速度會增加成本，一般說來可以采用類似下面的標(biāo)準(zhǔn)：

前端系統(tǒng)：

后端系統(tǒng)：

1.2.2. 系統(tǒng)性能評估與驗(yàn)證

一般有如下方法：

（1）線上服務(wù)的性能一般可以通過UMP來查看響應(yīng)時(shí)間、吞吐量;

（2）對于worker，則可以根據(jù)其實(shí)際輸入輸出的數(shù)據(jù)量來統(tǒng)計(jì);

（3）線下壓力測試。梳理出所有開放的接口，進(jìn)行接口壓力測試，線下進(jìn)行。測試用的數(shù)據(jù)可以根據(jù)業(yè)務(wù)邏輯進(jìn)行編制，也可以利用TCP Copy等技術(shù)獲取;

（4）線上讀接口壓力測試;

（5）線上寫接口壓力測試。這種測試應(yīng)該非常小心，注意不要產(chǎn)生垃圾數(shù)據(jù)，對業(yè)務(wù)造成影響。常用的避免影響業(yè)務(wù)的方法有：a) 給數(shù)據(jù)打上測試標(biāo)簽，所有參與測試的系統(tǒng)都要根據(jù)此標(biāo)          簽識別出正式數(shù)據(jù)和測試數(shù)據(jù);b) 設(shè)計(jì)好數(shù)據(jù)處理流程，在這個流程的最后一步才是真正地把數(shù)據(jù)提交到正式的主業(yè)務(wù)庫，而測試流程不執(zhí)行這一步，或者結(jié)合標(biāo)簽的方法，在這一步過          慮掉測試數(shù)據(jù);

（6）減少線上服務(wù)器數(shù)量，讓更少的服務(wù)器承擔(dān)不變的壓力，從而增大單臺服務(wù)器的負(fù)載;

（7）如果面臨大促，則可以考慮跨系統(tǒng)主流程壓測：在上游積壓一定量的數(shù)據(jù)，以設(shè)計(jì)好的速度下發(fā)請求，驗(yàn)證后面的流程在設(shè)計(jì)的并發(fā)請求量下是否暢通。這種方法不但需要跨研發(fā)團(tuán)隊(duì)          溝通，也需要和業(yè)務(wù)團(tuán)隊(duì)進(jìn)行溝通，因?yàn)榭赡軙绊懙缴a(chǎn)時(shí)效，同時(shí)可能會影響團(tuán)隊(duì)績效。

1.3. SLA確認(rèn)

上下游系統(tǒng)之間進(jìn)行SLA確認(rèn)，是非常有必要的，如果被依賴的系統(tǒng)達(dá)不到性能需求，則依賴方的系統(tǒng)100%達(dá)不到性要求。因?yàn)閱栴}影響首先會在依賴方顯現(xiàn)，所以依賴方更有動力去推動這項(xiàng)工作，如果沒有達(dá)成SLA，則需要承擔(dān)責(zé)任。當(dāng)然被依賴方也有義務(wù)配合，如果有分歧，則需要協(xié)商一個可以接受的SLA。

這一個步驟，需要及早進(jìn)行，只要指標(biāo)確定，就可以開展了。下面是一個樣例：

其中，”是否可降級”，指的是當(dāng)服務(wù)不可用或者性能下降，影響了調(diào)用方的可用性和響應(yīng)時(shí)間到一定程度時(shí)，可以不調(diào)用或者有限調(diào)用。如果可降級，應(yīng)該還要有具體的降級措施和補(bǔ)償措施。

“超時(shí)”指服務(wù)調(diào)用方的超時(shí)設(shè)置，超過這個時(shí)間將認(rèn)為本次調(diào)用無效，調(diào)用方可以重試。如果存在多級依賴關(guān)系，如A調(diào)用B，B調(diào)用C，則超時(shí)設(shè)置應(yīng)該是 A>B>C，否則可能引起DDOS攻擊效果。

1.4. 系統(tǒng)改造

關(guān)于如何進(jìn)行架構(gòu)升級，不是本文的重點(diǎn)，建議大家去參考架構(gòu)委員會的架構(gòu)白皮書，白皮書系統(tǒng)地介紹了架構(gòu)的原則和方法，非常有指導(dǎo)意義。這里只強(qiáng)調(diào)下大促備戰(zhàn)最常用的內(nèi)容，并且主要從應(yīng)用角度來闡述。

1.4.1. 提高系統(tǒng)處理能力

在評估階段，我們強(qiáng)調(diào)過，最主要的系統(tǒng)改造目標(biāo)是提高系統(tǒng)處理能力，對應(yīng)的主要措施是：

第一， 硬件升級，使用配置更高的硬件。但是，有的情況下即使硬件配置上去了，但分配給應(yīng)用本身的資源沒變，這樣處理能力沒有得到提升，資源利用率很低，這點(diǎn)尤其要注意。

第二，擴(kuò)容。系統(tǒng)要擴(kuò)容，首先要使系統(tǒng)具備水平擴(kuò)展能力，應(yīng)用的每一層都要能水平擴(kuò)展，不能留有瓶頸。系統(tǒng)到了一定規(guī)模后，可以考慮以集群為單位進(jìn)行擴(kuò)容，每一個標(biāo)配的集群的有定量處理能力。而且線上系統(tǒng)出現(xiàn)瓶頸時(shí)，可以擴(kuò)容或者替換若干個集群，這樣簡單高效。數(shù)據(jù)訪問層的擴(kuò)展能力尤其重要，從京東系統(tǒng)現(xiàn)狀上來看，這一層往往是瓶頸，而且瓶頸一旦出現(xiàn)，解決起來時(shí)間比較長，建議大家引入公司內(nèi)部的JDAL等中間件來實(shí)現(xiàn)。

第三，將系統(tǒng)進(jìn)行拆分，從而將負(fù)載分?jǐn)?，同時(shí)也降低問題影響面。可以按自頂向下，自業(yè)務(wù)到技術(shù)的線路去考慮對系統(tǒng)進(jìn)行拆分，首先看是不是可以從業(yè)務(wù)域上切分，然后再從功能的相互依賴關(guān)系上分析，將相互依賴緊密但與其它應(yīng)用交互很少的功能作為一個子系統(tǒng)拆分出來。當(dāng)然，對于有用戶界面的系統(tǒng)，出于客戶體驗(yàn)的考慮，系統(tǒng)拆分后，要注意盡量保持UI的統(tǒng)一。

第四，提高響應(yīng)速度。詳見保持響應(yīng)速度一節(jié)。

第五，使用編程技巧，如串行變并行、單個處理變批量處理等。

1.4.2. 保持響應(yīng)速度

大促備戰(zhàn)一般不會提出更高響應(yīng)速度的要求，主要是能保持原來的響應(yīng)速度，甚至允許有一定程度的下降。主要是因?yàn)橄到y(tǒng)負(fù)載增大后，處理過程中可能出現(xiàn)等待資源的情況，傳輸過程中也可能出現(xiàn)阻塞情況，從而增大了處理時(shí)長。提高響應(yīng)速度的方法一般有：

第一，Review系統(tǒng)。對系統(tǒng)的每一層，甚至硬件都進(jìn)行審查，低性能的代碼和SQL，低性能的中件間，有問題的硬件，都會影響性能，都需要改造或者替換。

第二，使用緩存。首先描繪出從客戶端發(fā)請求到接到服務(wù)端應(yīng)答的全路徑，然后分析這條路徑上的每一個節(jié)點(diǎn)，是否有必要增加緩存。實(shí)際上，緩存的本質(zhì)就是把內(nèi)容存到離客戶端更近、訪問速度更快的節(jié)點(diǎn)上;緩存的內(nèi)容可以整個網(wǎng)頁、一個完整的請求-應(yīng)答、一個對象、一個變量值，等等。常用的緩存技術(shù)有：

第三，優(yōu)化依賴。如果一個系統(tǒng)服務(wù)對外有依賴，則有必要對其進(jìn)行分析，看是否要以優(yōu)化。首先要進(jìn)行流程分析，識別出主流程，對不是主流程中的邏輯，通常有優(yōu)化的余地。常用的方法有：

第四，系統(tǒng)分解。涉及到的方法有很多，例如：

1.4.3. 保持可用性

為保持可用性，一般可以采取如下措施：

1.5. 處理能力確認(rèn)

系統(tǒng)性能評估與驗(yàn)證的方法同樣適用于本工作。

1.6. 大促前夕的系統(tǒng)體檢

就像運(yùn)動員備戰(zhàn)運(yùn)動會一樣，需要進(jìn)行體檢，以保證系統(tǒng)以優(yōu)良的狀態(tài)迎接大促。下表列出了重要的檢查項(xiàng)：

2. 及時(shí)發(fā)現(xiàn)問題

為一個互聯(lián)網(wǎng)企業(yè)，業(yè)務(wù)發(fā)展和變更速度比較快，系統(tǒng)很難一直保持穩(wěn)定，出現(xiàn)問題在所難免。問題發(fā)現(xiàn)的越早，才能越早介入處理;更進(jìn)一步，如果能在問題發(fā)生之前就發(fā)現(xiàn)問題的趨勢，并及時(shí)介入處理，就可能避免問題發(fā)生。

及時(shí)發(fā)現(xiàn)問題的主要手段是完善監(jiān)控與報(bào)警體系，涵蓋從業(yè)務(wù)，到應(yīng)用再到硬件、網(wǎng)絡(luò)全方面的監(jiān)控。本文主要涉及應(yīng)用級別的監(jiān)控。

3. 快速決策和處理

系統(tǒng)運(yùn)行時(shí)可能遇到各種各樣的問題，如果有對應(yīng)的應(yīng)急預(yù)案，并演練到位，則可從容面對。當(dāng)真的出現(xiàn)了緊急情況，最要緊并不是去尋找問題的根源，而是果斷采取措施控制住影響。越早決策，影響就越小。

3.1. 應(yīng)急預(yù)案

3.1.1. 風(fēng)險(xiǎn)分析

系統(tǒng)運(yùn)行時(shí)可能遇到各種各樣的問題，常見的有：

3.1.2. 預(yù)案重要元素

3.1.3. 常用預(yù)案和處理方法

3.2. 快速決策

• 做好分工
• 了解對業(yè)務(wù)的影響
• 檢查確認(rèn)系統(tǒng)是否在正常工作;檢查日志分析異常等信息
• 檢查機(jī)器負(fù)載;檢查應(yīng)用響應(yīng)時(shí)長和吞吐量
• 關(guān)注報(bào)警
• 做好演練
• 演練操作的熟練程度
• 演練協(xié)調(diào)能力
• 注意總結(jié)，某些問題可以直接做出決策

3.3. 快速執(zhí)行

• 提前打開配置界面，配置好;提前收集好各類信息
• 提前建好上線任務(wù)
• 進(jìn)行培訓(xùn)和實(shí)際操作

4. 成熟穩(wěn)定的團(tuán)隊(duì)

由于互聯(lián)網(wǎng)業(yè)務(wù)發(fā)展變化較快，系統(tǒng)變更也比較頻繁，不適合開發(fā)和運(yùn)營分家的模式，而是自己建設(shè)的系統(tǒng)，自己負(fù)責(zé)運(yùn)營。這樣，不但能提高運(yùn)營效率，大家又可以在運(yùn)營過程中發(fā)現(xiàn)問題，體驗(yàn)問題帶來的痛苦，所以會想辦法改進(jìn)設(shè)計(jì)，以避免問題發(fā)生。這樣的團(tuán)隊(duì)建設(shè)的系統(tǒng)會更易于運(yùn)營，性能更加穩(wěn)定，團(tuán)隊(duì)的設(shè)計(jì)能力也會顯著提升，也就會趨于穩(wěn)定和成熟，這樣就形成了良性循環(huán)。

5. 流程和規(guī)范

備戰(zhàn)大促，涉及到許多團(tuán)隊(duì)，需要大家通力合作，也就需要遵循一定的制定和流程規(guī)范，下表列舉了其中一部分。

6. 總結(jié)

我們回顧一下備戰(zhàn)的思路和方法，這是平時(shí)就要認(rèn)真做好的：

• 積極預(yù)防，遵循PDCA模型，在系統(tǒng)建設(shè)之初就注重非功能設(shè)計(jì)，注重如何方便日常運(yùn)營，并持續(xù)改進(jìn)系統(tǒng)
• 提高發(fā)現(xiàn)問題的能力，能及早發(fā)現(xiàn)問題，甚至在問題發(fā)生前就介入處理
• 提高問題決策和處理問題的速度，迅速控制住問題影響，并解決問題

如果面臨大促，則有必要采取的措施有：

• 用大促的業(yè)務(wù)量預(yù)估來對系統(tǒng)進(jìn)行評估
• 采取更加嚴(yán)格的檢查措施，考慮進(jìn)行跨系統(tǒng)的線上軍演;大促前夕對系統(tǒng)進(jìn)行全面的健康體檢。
• 大促來臨時(shí)，執(zhí)行嚴(yán)格的現(xiàn)場值班制度
• 建立統(tǒng)一的大促組織，統(tǒng)一指揮

要能很好地執(zhí)行以上方法，應(yīng)該具備兩個要素：

• 日漸成熟的團(tuán)隊(duì)。開發(fā)團(tuán)隊(duì)即運(yùn)營團(tuán)隊(duì)，團(tuán)隊(duì)在運(yùn)營過程中發(fā)現(xiàn)問題，并通過系統(tǒng)設(shè)計(jì)解決問題，設(shè)計(jì)和運(yùn)營能力一起提升。
• 日趨完善的流程和規(guī)范，保障備戰(zhàn)措施的順利實(shí)施，促進(jìn)團(tuán)隊(duì)進(jìn)步。

作者：林世洪，畢業(yè)于北京交通大學(xué)，2011年加入京東，先后負(fù)責(zé)京東訂單履約體系和零售平臺架構(gòu)工作，連續(xù)兩屆架構(gòu)委員會成員，此期間主導(dǎo)和參與了京東研發(fā)若干規(guī)范的制定，著力推動電商核心系統(tǒng)架構(gòu)升級，總結(jié)形成了大型促銷備戰(zhàn)方法論，保障了電商主流程系統(tǒng)的穩(wěn)定性，降低了整體系統(tǒng)建設(shè)成本。個人技術(shù)方面更多關(guān)注根據(jù)業(yè)務(wù)特點(diǎn)和技術(shù)要求對系統(tǒng)進(jìn)行可運(yùn)營化改造和治理。

 【本文來自51CTO專欄作者張開濤的微信公眾號(開濤的博客)，公眾號id: kaitao-1234567】