文經授權轉自公眾號：開濤的部落格（kaitao-1234567）

作者簡介：

林世洪

畢業於北京交通大學，2011年加入京東，先後負責京東訂單履約體系和零售平臺架構工作，連續兩屆架構委員會成員，此期間主導和參與了京東研發若干規範的制定。

著力推動電商核心系統架構升級，總結形成了大型促銷備戰方法論，保障了電商主流程系統的穩定性，降低了整體系統建設成本。個人技術方面更多關注根據業務特點和技術要求對系統進行可運營化改造和治理。

前言

提到備戰，實際上不一定要到大型促銷時，工作應該做到平時。京東已發展到了一個比較大的體量，無論是大促還是平時，都容不得出現大問題，我們的思路和方法是：積極預防、及時發現、快速處理，這正是本文前半部分要介紹的。但要做到這十二個字並不容易，本文後半部分會介紹背後的兩個要素：日漸成熟穩定的團隊、日趨完善的流程和規範。

下圖是對本文內容的描繪：

1. 積極防預問題

在預防措施上，需要遵循 PDCA 方法：

P階段：

1. 分析系統職責，確立系統備戰的首要業務目標；

2. 依據業務量評估，對系統處理能力要求進行評估，根據評估結果和系統執行狀況，找出系統瓶頸。*特別地，如果是大促備戰，則要先給大促時的業務量評估。

D階段：

3. 針對系統瓶頸，進行系統改造；

4. 梳理系統間的依賴關係，各系統之間達成 SLA，以保證整體效能指標。

C階段：

5. 對系統進行壓力測試，驗證處理能力，確保達標。特別地，如果是大促備戰，則可以考慮在線上進行跨系統軍演；

6. 特別地，如果是大促前夕，則要對系統進行全面體檢。

A階段：

7. 如果系統改造達不到評估要求，則需要修正方案。

1.1. 確定每個系統的首要備戰目標

每個系統都會有自己的邊界，各系統負責人應該分析清楚系統的使命和職責是什麼，分清主次，這同時也是制定應急預案的最重要依據，舉例：

1. 訂單交易系統，其最重要的是保證下單，這是剛性的要求，其它的都是有彈性的，例如很多不影響下單的檢驗邏輯，都可以放到下單之後來補償；
2. OFC，其最重要的是保證訂單生產部門有訂單可生產，儘量不影響其產能，在這個前提下，可以採取各種靈活措施。例如，假設某個庫房的最高生產能力為10萬單，而當時產生的訂單有20萬，這時系統保障把10萬訂單送給這個庫房生產就能滿足生產要求了，此時可以把系統處理能力分配給 POP 訂單處理；
3. 物流生產系統，其最重要的是滿足工人的作業需求，保證生產效率，其它的邏輯，如生產資料跟蹤資料處理，可以非同步處理。

1.2. 系統性能評估

總體思路：先進行需求評估，然後進行系統評估，找出差距。

1.2.1. 效能需求評估

總體思路：

公司層面首先要給出一個業務量的初估，然後各個團隊可以根據此值來把總的業務量評估分解到自己的系統的吞吐量指標上，接下來就是方案設計的問題了，目標就是將吞吐量指標提高到評估的水平，同時其它效能指標仍能滿足業務要求。這樣兼顧了效能和成本。

吞吐能力評估：

吞吐能力，指的是單位時間內處理請求的數量限制，一般用tps來衡量，指的是每秒處理請求的數量。

前面提到過要把總的業務量評估分解到自己的系統的吞吐量指標，可以把系統看成一個黑桶，看這個桶上邊界輸入的量和下面輸出的量。

假設一個系統是客戶訂單處理系統，每一個訂單向它輸入2條處理請求，並向外界輸出4條資訊，如果一天的訂單量是1000萬，則這個系統要每天接收2000萬個請求，輸出4000萬條資訊。

對於直接面對客戶的系統，輸入的評估需要更多的維度（如促銷、推廣），但也有簡單的評估辦法，那把上一次大促作為參照，按業務量同比擴大。

當然，實際評估時，不能只看一天的業務量，還要看峰值，而且要高度重視峰值。前端系統的峰值評估需要考慮比較多的維度（如促銷方式和力度等），後端相對簡單，用於平均值乘以一個係數即可，這個系統可以根據系統以住大促時統計而來，如果是一個新系統，可以讓上游系統協助評估。

並不是所有系統都要承擔高峰值。如果一個業務處理流程比較長，則上游的系統可以平滑峰值，讓下游系統享受一個平滑得多的請求流，這樣可以大大減少系統的建設成本。

例如，在訂單處理流程中，OFC 扮演了這一個穩壓器的作用，OFC 把上游訂單和峰值進行了平滑。所以吞吐能力的評估也需要團隊合作。

• 容量規劃：

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

1. 主業務物件的量（如訂單）以及到大促前的增長量
2. 每個主業務物件會佔用多少容量
3.  資料要在線上主系統中存留的時間
4. 出現高峰時，允許積壓的資料量和積壓時間

有了上面這幾個資料，就比較好評估了。特別是針對4進行說明，有一些過程資料，處理完就不必要在主系統中存留了，所以在評估時不必考慮，但當出現高峰值，且系統處理無法及時處理時，可以積壓一部分資料慢慢處理。

• 流量規劃：

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

• 響應速度評估：

響應速度，是衡量服務對請求響應時間的指標，一般用毫秒計量，通常用 tp999，tp99，tp90 這幾個指標，其中 tp999 指 99.9% 的服務請求的響應時間不會高於這個值。

提高響應速度，可以提高系統吞吐量。假設一個服務的響應時間為100ms，允許的併發數是500，則理論上這個服務的吞吐量上限為 5000（500*1000/100）tps；如果響應時間降低到50ms，則理論上的吞吐量上限會降為 10000tps。

但是提高響應速度會增加成本，一般說來可以採用類似下面的標準：

前端系統：

後端系統：

1.2.2. 系統性能評估與驗證

一般有如下方法：

1. 線上服務的效能一般可以通過 UMP 來檢視響應時間、吞吐量；
2. 對於 worker，則可以根據其實際輸入輸出的資料量來統計；
3. 線下壓力測試。梳理出所有開放的介面，進行介面壓力測試，線下進行。測試用的資料可以根據業務邏輯進行編制，也可以利用 TCP Copy等技術獲取；
4. 線上讀介面壓力測試；
5. 線上寫介面壓力測試。這種測試應該非常小心，注意不要產生垃圾資料，對業務造成影響。常用的避免影響業務的方法有：a) 給資料打上測試標籤，所有參與測試的系統都要根據此標籤識別出正式資料和測試資料；b) 設計好資料處理流程，在這個流程的最後一步才是真正地把資料提交到正式的主業務庫，而測試流程不執行這一步，或者結合標籤的方法，在這一步過慮掉測試資料；
6. 減少線上伺服器數量，讓更少的伺服器承擔不變的壓力，從而增大單臺伺服器的負載；
7. 如果面臨大促，則可以考慮跨系統主流程壓測：在上游積壓一定量的資料，以設計好的速度下發請求，驗證後面的流程在設計的併發請求量下是否暢通。這種方法不但需要跨研發團隊溝通，也需要和業務團隊進行溝通，因為可能會影響到生產時效，同時可能會影響團隊績效。

1.3. SLA確認

上下游系統之間進行 SLA 確認，是非常有必要的，如果被依賴的系統達不到效能需求，則依賴方的系統100%達不到性要求。因為問題影響首先會在依賴方顯現，所以依賴方更有動力去推動這項工作，如果沒有達成 SLA，則需要承擔責任。當然被依賴方也有義務配合，如果有分歧，則需要協商一個可以接受的 SLA。

這一個步驟，需要及早進行，只要指標確定，就可以開展了。下面是一個樣例：

其中，”是否可降級”，指的是當服務不可用或者效能下降，影響了呼叫方的可用性和響應時間到一定程度時，可以不呼叫或者有限呼叫。如果可降級，應該還要有具體的降級措施和補償措施。

“超時”指服務呼叫方的超時設定，超過這個時間將認為本次呼叫無效，呼叫方可以重試。如果存在多級依賴關係，如 A 呼叫 B，B 呼叫 C，則超時設定應該是 A>B>C，否則可能引起 DDOS 攻擊效果。

1.4. 系統改造

關於如何進行架構升級，不是本文的重點，建議大家去參考架構委員會的架構白皮書，白皮書系統地介紹了架構的原則和方法，非常有指導意義。這裡只強調下大促備戰最常用的內容，並且主要從應用角度來闡述。

1.4.1. 提高系統處理能力

在評估階段，我們強調過，最主要的系統改造目標是提高系統處理能力，對應的主要措施是：

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

第二，擴容。系統要擴容，首先要使系統具備水平擴充套件能力，應用的每一層都要能水平擴充套件，不能留有瓶頸。系統到了一定規模後，可以考慮以叢集為單位進行擴容，每一個標配的叢集的有定量處理能力。而且線上系統出現瓶頸時，可以擴容或者替換若干個叢集，這樣簡單高效。資料訪問層的擴充套件能力尤其重要，從京東系統現狀上來看，這一層往往是瓶頸，而且瓶頸一旦出現，解決起來時間比較長，建議大家引入公司內部的 JDAL 等中介軟體來實現。

第三，將系統進行拆分，從而將負載分攤，同時也降低問題影響面。可以按自頂向下，自業務到技術的線路去考慮對系統進行拆分，首先看是不是可以從業務域上切分，然後再從功能的相互依賴關係上分析，將相互依賴緊密但與其它應用互動很少的功能作為一個子系統拆分出來。當然，對於有使用者介面的系統，出於客戶體驗的考慮，系統拆分後，要注意儘量保持UI的統一。

第四，提高響應速度。詳見保持響應速度一節。

第五，使用程式設計技巧。如序列變並行、單個處理變批量處理等。

1.4.2. 保持響應速度

大促備戰一般不會提出更高響應速度的要求，主要是能保持原來的響應速度，甚至允許有一定程度的下降。主要是因為系統負載增大後，處理過程中可能出現等待資源的情況，傳輸過程中也可能出現阻塞情況，從而增大了處理時長。提高響應速度的方法一般有：

第一，Review系統。對系統的每一層，甚至硬體都進行審查，低效能的程式碼和 SQL，低效能的中件間，有問題的硬體，都會影響效能，都需要改造或者替換。

第二，使用快取。首先描繪出從客戶端發請求到接到服務端應答的全路徑，然後分析這條路徑上的每一個節點，是否有必要增加快取。實際上，快取的本質就是把內容存到離客戶端更近、訪問速度更快的節點上；快取的內容可以整個網頁、一個完整的請求-應答、一個物件、一個變數值，等等。常用的快取技術有：

第三，優化依賴。如果一個系統服務對外有依賴，則有必要對其進行分析，看是否要以優化。首先要進行流程分析，識別出主流程，對不是主流程中的邏輯，通常有優化的餘地。常用的方法有：

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

1.4.3. 保持可用性

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

1.5. 處理能力確認

系統性能評估與驗證的方法同樣適用於本工作。

1.6.  大促前夕的系統體檢

就像運動員備戰運動會一樣，需要進行體檢，以保證系統以優良的狀態迎接大促。下表列出了重要的檢查項：

2.  及時發現問題

為一個網際網路企業，業務發展和變更速度比較快，系統很難一直保持穩定，出現問題在所難免。問題發現的越早，才能越早介入處理；更進一步，如果能在問題發生之前就發現問題的趨勢，並及時介入處理，就可能避免問題發生。

及時發現問題的主要手段是完善監控與報警體系，涵蓋從業務，到應用再到硬體、網路全方面的監控。本文主要涉及應用級別的監控。

3.  快速決策和處理

系統執行時可能遇到各種各樣的問題，如果有對應的應急預案，並演練到位，則可從容面對。當真的出現了緊急情況，最要緊並不是去尋找問題的根源，而是果斷採取措施控制住影響。越早決策，影響就越小。

3.1. 應急預案

3.1.1. 風險分析

系統執行時可能遇到各種各樣的問題，常見的有：

3.1.2. 預案重要元素

3.1.3. 常用預案和處理方法

3.2. 快速決策

• 做好分工
• 瞭解對業務的影響
• 檢查確認系統是否在正常工作；檢查日誌分析異常等資訊
• 檢查機器負載；檢查應用響應時長和吞吐量
• 關注報警
• 做好演練
• 演練操作的熟練程度
• 演練協調能力
• 注意總結，某些問題可以直接做出決策

3.3. 快速執行

• 提前開啟配置介面，配置好；提前收集好各類資訊
• 提前建好上線任務
• 進行培訓和實際操作

4. 成熟穩定的團隊

由於網際網路業務發展變化較快，系統變更也比較頻繁，不適合開發和運營分家的模式，而是自己建設的系統，自己負責運營。這樣，不但能提高運營效率，大家又可以在運營過程中發現問題，體驗問題帶來的痛苦，所以會想辦法改進設計，以避免問題發生。

這樣的團隊建設的系統會更易於運營，效能更加穩定，團隊的設計能力也會顯著提升，也就會趨於穩定和成熟，這樣就形成了良性迴圈。

5. 流程和規範

備戰大促，涉及到許多團隊，需要大家通力合作，也就需要遵循一定的制定和流程規範，下表列舉了其中一部分。

6. 總結

我們回顧一下備戰的思路和方法，這是平時就要認真做好的：

• 積極預防，遵循 PDCA 模型，在系統建設之初就注重非功能設計，注重如何方便日常運營，並持續改進系統
• 提高發現問題的能力，能及早發現問題，甚至在問題發生前就介入處理
• 提高問題決策和處理問題的速度，迅速控制住問題影響，並解決問題

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

• 用大促的業務量預估來對系統進行評估
• 採取更加嚴格的檢查措施，考慮進行跨系統的線上軍演；大促前夕對系統進行全面的健康體檢。
• 大促來臨時，執行嚴格的現場值班制度
• 建立統一的大促組織，統一指揮

要能很好地執行以上方法，應該具備兩個要素：

• 日漸成熟的團隊。開發團隊即運營團隊，團隊在運營過程中發現問題，並通過系統設計解決問題，設計和運營能力一起提升。
• 日趨完善的流程和規範，保障備戰措施的順利實施，促進團隊進步。