作者 | 張松然，京東集團商家研發部技術專家

審校 | 王洪濤

每年的 618 大促都是一場技術團隊大練兵的時候。本文介紹了京東是如何備戰 618，保障系統穩定性的。

每年 618 的大促都是一場技術團隊大練兵的時候。作為技術研發人員，在這場戰斗中，加深了對線上系統的敬畏之心，通過系統的備戰，在技術上也得到了提升。大戰在即，如何保障系統穩定，我們的備戰思路是什么？

首先確定自己的備戰思路，梳理核心流程、找出薄弱點，對薄弱點進行優化，針對業務進行資源隔離，同時協調壓測對優化結果進行驗證，并針對場景準備預案，比如降級開關在什么場景下開啟，以及降級之后的影響有哪些等等，后面還要實際演練，防止實際情況發生時準備好的預案不可用。

我們知道，618 期間發生的問題都不是小問題，所以，如何做到更周密的籌備，我們可以秉承如下幾個原則：

? 墨菲定律：任何事都沒有表面看起來那么簡單；所有的事都會比你預計的時間長；會出錯的事總會出錯；如果你擔心某種情況發生，那么它就更有可能發生。
? 二八原則：19 世紀末意大利經濟學家巴萊多認為，在任何一組東西中，最重要的只占其中一小部分，約 20%，其余 80% 盡管是多數，卻是次要的，這就是二八法則。二八法則告訴我們，不要平均地分析、處理和看待問題，要把主要精力花在解決主要問題、抓主要項目上。

我們可以利用墨菲定律來梳理系統薄弱點，那些總是小問題不斷的地方，一定會在某天釀成大的災難，必須盡早解決。還可以利用二八原則梳理黃金流程，那些出了問題可能極大影響公司或影響用戶的地方，就是不容有失的黃金流程。

我們以此為思路，從四個方面進行逐一介紹。

梳理薄弱點

梳理系統架構

備戰第一步，就是要對系統做一次全面的梳理診斷，其目的就是要甄別出系統的薄弱點。而梳理的第一步，就是要梳理出系統架構。通過梳理系統架構，梳理系統的層次結構和調用關系，由此排查系統調用的瓶頸和薄弱點。如是否有服務節點是熱點或單點服務，是否有過長的調用鏈路，是否存在業務耦合相互影響等等。

以我現在負責的京東服務市場為例，服務市場采用 SOA 微服務化的架構設計理念，將服務市場設計為模塊化和層次化的架構風格，高層次模塊調用低層次模塊，低層次模塊通過接口向上提供服務。而復雜的調用鏈路，必然造成業務之間的相互影響，所以，通過對服務市場從部署、數據庫訪問、服務 PRC 調用、消息接收等進行了縱向垂直部署隔離，實現即使任一垂直域無論因為服務器還是數據庫問題，影響不會擴散到其他業務上。這我會在后面詳細講述如何實現縱向垂直部署隔離。

梳理系統薄弱點

無論系統架構是以哪種形式展示，我們都希望能夠通過梳理把系統的薄弱點甄別出來。那系統薄弱點都有哪些特征呢？通過哪些手段能檢查出系統薄弱點？

我們想一下，系統薄弱點可能引發哪些災難，嚴重的有系統宕機，服務不可用，性能下降，404，CPU 100%，OOM 等等，所以，可能產生上述隱患的點就是我們要關注的系統薄弱點。對于系統薄弱點，我們可以通過以下幾點進行排查：

? 檢查沒有脫庫的功能：我們知道大促時的流量可能是平時的 2～10 倍，所以一些平時性能還好的查詢接口，極有可能因調用量猛增，造成性能的極劇下降，如果其中的某些接口還是查詢數據庫的，那可能就會給數據庫產生極大的壓力，極端情況可能造成數據庫 CPU 100%，出現服務不可用，因為數據庫本身的架構設計就不是抗量的，所以對沒有必要查庫的功能進行脫庫改造，以保證數據庫的穩定，是非常重要的，尤其是那些嚴重依賴數據庫的系統。
? 檢查慢 sql：不是所有的功能都能實現脫庫的，所以慢 sql 的檢查就是為了保證數據庫的穩定，因為一個慢 sql 就有可能把數據庫的 CPU 打到 100%，一是由于慢 sql 最容易出現的是沒有索引，二是由于慢 sql 大多是關聯查詢、嵌套查詢，以及使用聚合函數等造成的，還有就是慢 sql 大多需要回源查詢，大量的請求會造成查詢能力特別慢，還會造成其他請求無法獲取連接，影響正常服務。所以，對于那些特別依賴數據庫的系統，要每日訂閱慢 sql，進行優化。優化就是優化數據庫索引，將慢 sql 變成快 sql。
? 檢查 ump 和 log：人常說，研發人員有兩只眼睛，一只是監控報警，另一只就是日志，所以無論什么情況監控報警日志一定不能少。因為有了監控就能做到即時發現問題，有了日志就能做到迅速定位問題。否則，出了問題，就是兩眼一抹黑，一通胡猜。我經常看到，當有些問題從客服那里投訴過來，才發現，要么該有的監控沒有，要么有監控卻沒有報警，以及在解決問題時總是找不到關鍵的日志，只能干著急。
? 檢查 jsf、mysql、jmq 等 timeout：設置 timeout 實際上是一種快速失敗策略，使系統具備自我保護的能力。檢查超時，一是檢查該有的設置有沒有，二是檢查設置的時間是否過長。沒有超時設置，則系統就沒有自我保護的能力，這自不必說，當大量請求連接因為長時間運行而無法得到釋放時，系統的資源很快就會被耗盡，從而造成了服務的不可用。而過長的設置，同樣在訪問量大的時候，就會導致請求連接積壓，這也會導致系統的 CPU 快速飆升。那超時應該設置多少合適，這需要具體情況具體分析，但一個查詢請求設置 10s 超時肯定是跟沒設置一樣的。
? 檢查 redis 熱 key、大 key、慢日志：熱 key 和 大 key 是不同的，熱 key 是某些 key 可能會被突然暴增的流量大量訪問，這些 key 又碰巧集中存儲在同一分片上，從而使得該分片的 IO、CPU 等資源吃緊，極端情況下迫使 redis 進行 failover 主從切換，但切換后的瞬時流量可能又一下子擊穿 redis，迫使 redis 再次 failover，如此反復，服務幾乎就是不可用的。而大 key 則是某些 key 存儲的 value 很大，或者結果集很多，也是在可能暴增的流量下，大 key 不合理的查詢，使得 value 在 IO 傳輸中阻塞，這情況和慢 sql 很像，又因為 redis 是單線程，所以大 key 查詢造成 IO 問題就會很容易凸顯出來。所以，如果檢查出熱 key 或大 key，就建議進行修改。
? 檢查 master-slave 同步延遲：master-slave 同步延遲很大可能造成數據不一致性，這有可能影響業務正常運營，如創建訂單寫到 master，然后從 slaver 查詢訂單，但由于延遲太大，就可能影響用戶查不到，你可能會說，這還好吧，慢 1～2s 不會有太大影響，但這個邏輯如果放在創建訂單之后馬上查詢訂單，根據查到的訂單創建結算，在這個場景下，如何查詢 slave 找不訂單，就是不可接受的，這可能導致流程代碼出錯。所以，需要評估這種延遲是否對業務產生影響。
? 檢查定時 worker 全量掃描任務：定時 worker 大多數是在運行數據訂正的任務，而數據訂正往往又需要查詢大量數據進行比對，其實，這都還好，不好的就是幾次深分頁的查詢，可能造成數據庫性能的極劇下降。所以，檢查定時 worker，尤其要避免慢 sql 和大數據集的查詢，否則會造成人為的流量洪峰。還有，檢查定時 worker 的執行頻率，檢查不同 worker 的執行時間，盡量避免不同 worker 同時執行，檢查定時 worker 執行的服務器是否單獨部署。

與運營溝通 618 運營節奏，應戰調用量高峰：提前與運營溝通運營節奏，可以做到知己知彼，并可以預知流量可能流向哪里，這可以有針對性的進行備戰。

梳理黃金流程

黃金流程也稱核心流程，什么是黃金流程，就是那些出了問題可能極大影響公司或影響用戶的地方，就是不容有失的黃金流程。以服務市場為例，服務市場包括服務發布、服務審核、服務訂購、服務結算、服務使用共五個環節，那其中哪些是重中之重的核心環節呢？服務市場是面向供需雙方的雙邊市場，以需求方為大頭，所以服務訂購和服務使用是服務市場的核心環節。

梳理黃金流程，我們要整理出它的大致流向和關鍵節點，通過系統流向和關鍵節點發現系統設計不合理的地方，以服務市場交易流程問題，我們看到在履約中心訂單完成后，通過觀察者模式發送消息、創建訂購、推送結算的設計是存在風險的，因為每個觀察者失敗了就失敗了，且每個觀察者的業務邏輯都不是冪等邏輯。這種設計的不合理，就必須通過梳理黃金流程來發現。

資源隔離

梳理依賴資源（docker、vip、mysql、jimdb、es、jsf、jmq），及目前資源的服務器狀況是否健康（cpu、memory、dish 等），進行縱向垂直部署隔離，實現即使任一垂直域無論因為服務器還是數據庫問題，影響不會擴散到其他業務上，而這也是所謂的分離技術。

docker 資源

梳理系統 docker 資源部署情況，設定 x 軸是各個業務線，y 軸是業務系統，整理出一張二維表，根據之前梳理的系統架構圖，可以清晰的看到各業務線下各個業務系統在不同機房的部署情況，如是否雙機房部署，是否有熱備機房，是否部署資源不合理等。機房 1 和機房 2 之間是兩個不同的地域部署，所以通過地域可以實現容災。還有，雖然系統都是一套代碼，但可以根據各業務線的具體情況，某些業務線不需要的某些系統就不部署，因為代碼走不到那里，并可根據業務調用量，合理配置資源情況。

梳理資源，一是梳理自己的資源部署情況，二是需要對上下游依賴系統，做到資源對齊（為了效率考慮，目前很多應用正常情況是同機房調用）譬如：如果上游部署在 3 個機房，機房 A、機房 B、機房 C，流量配比是 5.3.2，那我們也應該按照該比例部署。

數據僅為示例，不是真實數據；表格形式僅供參考

vip 資源

檢查 vip 配置，避免因為 docker 擴容或縮容，導致的 vip 配置錯誤，將擴容的 docker 加到 vip 中，將縮容的 docker 從 vip 中去掉。檢查運營商的 IP 解析情況，譬如，需要支持電信、聯通、移動、教育網等。當然，并不是所有業務系統都提供對外服務。熱備機房不掛 vip，否則就會有線上流量了。當主力機房出問題的時候，通過將問題機房的 vip 飄到熱備機房，從而實現流量切換。

數據僅為示例，不是真實數據；表格形式僅供參考

MySQL 隔離

在 docker 資源的部署背景下，我們繪制 mysql 資源的部署情況，其中，有些業務線下的機房雖然有部署系統，但該業務線的流程是已經脫庫的，所以就可以不配置數據庫。還有某些流程在某些業務線下只有讀操作，沒有寫操作的，所以，數據庫只配置讀庫，而不配置寫庫。以及最重要的，不同業務線的應該使用不同的從庫，并根據查詢數據庫的業務量，合理配置從庫資源規格。mysql 與 docker 盡可能在同機房部署，這也可以有效的實現系統容災。

數據僅為示例，不是真實數據；表格形式僅供參考

Redis / Solr / ES 隔離

繪制 redis、solr、es 部署情況與繪制 mysql 思路一樣。特別說下，服務市場部署 redis 與 mysql 不同之處在于，redis 是一主一從架構，各業務線共享同一 redis 集群，但不同系統之間使用不同的 redis 集群，所以，如果 redis 掛了，還是會影響所有業務線的，而避免 redis 宕機，則就要注意前面提到的，檢查 redis 的大 key 和熱 key。

標題

數據僅為示例，不是真實數據；表格形式僅供參考

JSF 業務隔離

梳理業務依賴關系，調整 jsf 調用鏈路，通過 jsf 分組進行業務隔離，這其實是最重要的，也是最難的，也只有把這個做好，才能實現各業務線出了問題不會相互影響。我們知道，一個系統里，既有 provider 也有 consumer，我們要做的就是保證在某一個業務線內，該業務線內 consumer 一定調用該業務線內的 provider 的，如服務市場的業務線 B，那一定是大前臺在業務線 B 下只能調用業務線 B 的商品中心、交易中心、服務引擎等，而這實現就是通過 jsf 的分組別名，這沒有啥技術含量，就是要了解業務依賴關系，認真仔細。由于系統是一套代碼，對于那些有部署系統，但不提供 jsf 的服務分組，我們可以設置為 disable，以此區分和隔離。

在進行 jsf 分組隔離時，因為工作量很大，很是耗神，還有就會想到一個問題，一個系統提供幾十個甚至上百個 jsf 接口出去，為什么分組命名會千奇百怪，幾乎是每個 jsf 分組都有自己的命名，但仔細想來 jsf 接口可以做到細粒度隔離，因為 jsf 可以實現進程隔離和線程隔離，這使得即使是同一系統的 provider，也可以實現進一步的細分業務，來隔離各業務間的相互影響。

數據僅為示例，不是真實數據；表格形式僅供參考

JMQ 業務隔離

jmq 大量應用在系統解耦的場景中，而 jmq 同樣有 provider 和 consumer，它不像 jsf 那樣靈活，可以支持多個分組，jmq 只能控制哪些系統生產消息，哪些系統可消費消息。因為 jmq 是通過 topic 進行消息傳遞的，我們不能給每個業務線申請一個 topic，所以 jmq 的隔離更多的是，梳理業務依賴關系，對那些不會生產或消費 jmq 的業務線，設置 topic 為 disable，確定消息會被哪些系統生產，又會被哪些系統消費。

數據僅為示例，不是真實數據；表格形式僅供參考

? ?壓測? ?

壓測不是為了把系統壓掛，是否需要測出峰值，需按照業務場景決定。很多業務，可能就需要知道自己的峰值。壓測一定是根據當前調用量進行評估，以 2～10 倍為預期值進行壓測，壓測還要選在掉用量少的時間，并逐步加量。壓測盡量做到服務器及依賴資源的隔離，如果無法做到，需要控制好量。尤其當壓測會查詢數據庫的服務，一定不要把數據庫壓出問題來，如果壓出問題，就違背了壓測的初衷，壓測是為了把系統的瓶頸壓出來，而不是把系統壓出問題來。即使是完全讀取緩存的服務，也會因壓測造成系統性能的下降，因為數據在傳輸過程中的序列化和反序列化，以及對多線程的切換，都會造成 CPU 的飆升，還有注意磁盤空間是否會被日志打滿，諸如以上等等問題，不要因為壓測造成一場線上事故。

壓測我們要關注哪些是結果指標，有并發數、TPS、TP99、成功率，這些結果指標能有效反應服務的好壞，以及關注被壓測服務的 docker 的 CPU、內存、load 等系統性能。所以，壓測策略一定是逐步加量，從并發 10 - 50 - 100 - 200 - 500，觀察服務的 TPS、TP99、成功率是否有降低，還有被壓測機從 1 - 5 容器數增加，對比單機服務性能是否有所提升。所以，壓測的目的是為了能檢驗服務能力是否支持可水平擴展，即加機器就可以抵抗洪峰。

最后，壓測一定要制定計劃，今天壓什么，明天壓什么，還有跟兄弟團隊打好招呼，因為別的團隊也會壓測，如果他的服務會調用到你這里，而這是你也在壓測這個接口，結果超出預期的流量就可能造成意想不到的麻煩。

? ?預案? ?

預案準備至關重要，它能保證系統在出問題時，進行及時止損，避免大出血。止損主要以降級開關來實現有損降級，以保證核心黃金流程不受到影響。因為系統業務演進多是混沌的，所以需要對系統的降級開關進行有效的梳理，哪些是有用的，那些是無效的，還要協調兄弟團隊，一起溝通 618 備戰方案，確定演練方案，聯合備戰。

對降級開關的梳理，不能只停留在知道有這個開關的基礎上，還要知道這個降級開關在什么場景下開啟，以及降級之后的影響有哪些等等，降級邏輯必須場景化，否則出了問題，開關開還是不開，都沒有一個準則。

? ?總結? ?

當然，在備戰 618 的過程中，有很多事要做，不僅僅是業務隔離和壓測，還要在梳理系統薄弱點過程中發現潛藏的問題，進行針對性的優化改造。這里有個題外話要說，備戰過程中，我偶爾會聽到一些聲音，讓我非常生氣。

一是說，”之前沒出問題，所以覺得就沒問題“。我見過多少次線上事故，就是因為思想上的怠慢，問題并不是不知道，就是本著僥幸的思想，覺得之前沒問題，覺得現在就沒有問題。這種想法我認為就是錯的，之前沒問題，不代表它不是問題，是問題就是問題。我犯過錯一個錯誤，就是大上周上線報警出一個問題，排查有個慢 sql 查庫，然后進行了修改，不急不慢改一周準備第二天晚上上線，結果第二天早上就被人刷了，數據庫 CPU 直接干到 80%，好在這個功能有降級，且業務之間進行隔離部署，沒有造成很大的影響。所以，發現問題一定要即時修改。

二是說，”之前的邏輯不是我寫的，我就改了這些，那些代碼我不太清楚“。這種說辭更不可接受，你連你改的代碼上下文都不了解，你改什么代碼，你能不改錯么。所以，我要求大家，之前的代碼不管誰寫的，我不管了，但現在代碼在你手上，你就必須負責把它寫好，不能總是個臨時方案，開個分支出去，最后代碼一團漿糊。舉個例子，上線新代碼為了能實現快速降級，通常使用開關進行切換，這時系統里就會有新老兩套代碼，那老代碼什么時候刪除，如果當時寫代碼的人不負起責任，代碼就那么放著，也不刪，那后面不僅系統代碼會越來越臃腫，而且代碼的可讀性也會越來越差。甚至不小心弄錯了開關，還會出現意外的彩蛋什么的。

來到京東，今年（2019）是我的第 6 個 618，和往年一樣，必須保障系統穩定，最后，以曾國藩的一句話作為文本的總結，”結硬寨，打呆仗“。

總結

以上是生活随笔為你收集整理的备战618，京东如何保障系统稳定性？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。