本文是京東智聯云云產品研發部專家架構師，雲數據庫研發負責人，《MariaDB原理與實現》作者張成遠爲大家分享的關於京東618大促前期技術人的“備戰”手冊。同時，內容中也提到了京東智聯雲在支持整個京東集團大促活動的成長之路。希望大家可以通過這篇內容，有所獲益。
從2012年畢業加入京東起，到現在已近8年。在這8年裏，見證了太多的變化：從最初各業務各自維護中間件、緩存到今天的雲上統一按需分配；從每逢上線就要求運維同學幫忙到現在研發可以自主一鍵上線；從用物理機線上部署業務到如今擁有全球最大的docker集羣；從當初的.net、SQL Server、Oracle切換到Java、MySQL時代。在這個過程中京東基礎設施系統從幾乎零基礎到如今涵蓋人工智能、雲計算、物聯網、大數據等多種前沿技術的京東智聯雲，承載了包括京東零售、京東物流等在內的數千個業務系統。
在剛剛落幕的第 17 個京東 618 大促中，京東智聯雲作爲京東 618 的技術基石，起到了極其重要的保障作用。618大促作爲京東創立的的電商活動，經歷過這些年的發展，已經變成整個電商領域的盛大節日。我們也在多次的大促備戰工作中，積累了豐富的經驗，本篇文章我就和大家聊一聊關於618大促備戰的支持工作。
早些年時候，考慮到採購機器需要一定週期，通常每年第一個季度就會開始評估當年618大促的業務量，等到四五月份機器到位以後，才能及時把機器上架到位，確保6.1開門大促之前機器資源是充足的。
自從2016年開始，京東智聯雲逐步開始發力，京東集團的業務也開始不斷遷移上雲。如今零售、物流等核心業務都已經部署到京東智聯雲上，大促期間需要的資源全都可以在雲上按需獲取，全集團資源也都可以輕鬆實現彈性可伸縮。有了雲的技術加持，大促備戰可以做到事半功倍。
每年的618 大促備戰都是全集團各個部門通力合作的結果，根據不同階段，我們可以把大促備戰分爲8 個步驟，從資源評估到模擬壓測、從預案整理到線上演練，直至最終的大促覆盤。每一次備戰都是一系列複雜的工作，大促成功的背後離不開一大羣可愛的技術人員無數個日夜的辛勤付出。
Step 1 識別保障範圍
所謂識別保障範圍就是爲大促活動確定大的邊界範圍，整個集團的業務線成千上萬條，哪些業務是這次大促核心鏈路上的業務，哪些是核心0級系統，哪些是核心1級系統？在大促備戰開始之前需要明確邊界範圍，明確要保障的業務優先級，才能更方便後面大促保障工作的展開。
Step 2 業務量預估及預檢查
例如一個業務訪問的網絡流量預估是10 Gbps、訪問QPS預估是100w/s或者訂單數預估每秒有多少萬單等，基於評估的業務量就可以去評估整個業務鏈路上需要的資源量。比如負載均衡器帶寬是否足夠，應用服務器部署的實例數是否足夠，緩存大小是否滿足需求，數據庫空間以及性能是否滿足需求等。如果不夠需要擴容的就可以提前進行擴容，如果整個資源池資源緊張，還需要發起採購的就需要提前發起採購，確保大促之前資源能夠到位。
Step 3 預案整理
各個上層業務團隊以及基礎系統團隊都需要提前整理好預案，尤其是核心預案。所謂核心預案就是大促期間可以快速保命的預案，預案的處理原則要求儘量簡單直接高效。如服務的高可用，在真正有異常時，預案可能就是主備切換。當然這種主備切換在很多系統中是自動的，如雲數據庫RDS。當系統檢測到主庫宕機時會在幾秒鐘時間內將從庫提升爲主庫，從而確保整個線上業務幾乎不受影響。除了這種自動切換外，我們還需要做好兜底方案，萬一主庫因爲某些特殊情況表現異常，希望可以主動做一下主從切換時也可以人工在控制檯一鍵切換。
在預案整理環節中，服務高可用是非常重要的部分。服務高可用可以分爲幾個級別：首先是Region級別的，如圖2所示京東智聯雲上有提供華北-北京、華南-廣州、華東-宿遷、華東-上海地域。Region級別指的就是一個地域，通常是城市級別的，Region下還會再分AZ(Availability Zone, 可用區)，可以簡單理解爲一個AZ約等於一個獨立的機房，比如京東智聯雲華北-北京這個Region下有可用區A、可用區B、可用區C三個獨立的可用區。
對於重要業務如果有需要可以把重要的數據從北京同步到上海。像物流很多庫房是分佈在全國各地的，資源部署上也會在就近的Region部署相應的服務。每個系統在同一個Region裏部署的時候都需要考慮跨AZ的情況，比如應用實例部署到雲主機的時候需要跨AZ部署，確保一個AZ異常時另一個AZ的應用可以正常對外服務。申請雲數據庫或者雲緩存等其他資源時，選擇跨AZ就可以直接創建出一個跨AZ的數據庫或者緩存實例，當某個AZ異常時，可以平滑地切換到另一個AZ，確保業務儘量不受影響。服務高可用一般是靠主備或者無狀態的服務部署多份(跨Region或者跨AZ)等來解決單點問題。根據場景不同，當出現異常時可以是自動切換的，也可以是人工在控制檯進行切換。
除了服務高可用，預案整理還有一個非常重要的部分是業務降級。所謂業務降級一般指當某個業務如果超過了其不能承受的範圍時，可以進行限定保護，犧牲掉一部分業務流量從而保證至少有一部分是可以成功訪問的。例如當某個用戶訪問請求非常大時，可以將用戶做一定的限制，超過閾值時訪問將會失敗，從而確保在整體資源有限的情況下其他正常請求的用戶可以訪問成功。甚至當正常的流量大到一定程度以後也是需要有能力放棄一部分流量來保證其餘大部分流量是正常的。降級思路實際是貫穿在整個業務鏈路中的，比如當應用實例部署很多時，每個應用實例的數據庫連接池也是需要做好控制的。如果連接池過大很可能造成數據庫壓力太大，而站在數據庫的角度自然也是需要做好最大鏈接數限制，確保即使應用實例的連接池配置得過大造成有數據庫壓力大的時候，數據庫自身還是有能力保護自己不被打趴下。這種貫穿整個鏈路的降級保護思路也可以理解爲系統間不信任原則的體現，即任意的A服務(模塊)去調用B服務(模塊)時，雖然在內部實際開發的過程中，A服務會盡量的去保護B服務，但B永遠是不信任A的，B需要根據自身的情況做好自己的保護工作。
除了降級保護以外，還有一類是彈性擴容預案，一般資源擴容在大促之前就會全部擴容完畢，坐等流量洪峯的到來。但是也不排除在大促中會出現少量業務的流量超過了預想值，或者依賴的資源因爲機器較老性能較差導致承接流量洪峯時壓力較大的情況。尤其是當上遊系統的生產流量已經往下游走的時候，下游壓力比較大，此時除了降級保護以外還需要能快速在線上擴容來滿足整個生產流量往下走。在大促業務壓力高峯時間點進行擴容在工程實踐上來講實際是一把雙刃劍，對各級系統的考驗還是非常大的。618大促這種有明確的時間點預期以及壓力預期的業務場景中，如果可以提前在業務低峯期做好合適的擴容準備纔是最理想的。
Step 4&5 監控及報警梳理
監控是我們看系統的眼睛，是線上系統的感知體系。如果監控沒有做到位的話，整個系統就是兩眼一抹黑的狀態，線上運行是否正常就全靠人品和運氣了，整個系統的運行就變成了玄學，所以做好系統監控是至關重要的。
監控和報警總是相輔相成的，監控是通過各種方式不斷去觀測整個系統的各種指標，報警則是發現指標有異常時可以及時通知到對應的值班人員及時介入處理。
監控可以分很多類別，最基本的是存活監控，我把它們稱爲如何活下來，也就是優先要保證能否活下來這個底線，存活監控一般包括IP存活、端口存活、服務存活等，一個服務是死是活是需要可以明確感知的，如果服務宕機了，需要第一時間可以檢測到併發出報警，除了這些機器及服務層面的存活，還有整個AZ(機房)的存活，如果整個AZ出問題了，對整個業務的影響是什麼，能否監控到能否發出報警等。
在活下來這個底線保住的情況下，第二類監控是解決如何活得更好的問題，比如TP99到了幾秒，CPU使用率是不是過高，內存佔用比例是不是過大，磁盤IO壓力是不是過高等。這類監控一般可以幫助你快速發現系統壓力，在系統真正故障或者不可用前及時介入處理，確保整個系統運行平穩。除了CPU、內存、磁盤等通用指標的監控，實際上還會有很多帶有較強業務屬性的監控。比如某個任務如果長期處於中間狀態，很可能是某個環節出現了沒有考慮到的異常，這種就需要有專門的監控用於發現這種長期處於中間狀態的任務。
Step 6 業務壓測及預案演練
當業務評估、監控報警、預案整理都梳理完，下一步重要的事情就是將整個業務鏈路完整串起來。例如某個業務預估訂單量是10w/s，那就需要採用壓測機器人模擬相當的業務量從源頭開始壓測，觀測整個鏈路在壓測過程中的監控指標變化情況。如果有異常要能及時報警，並按預案進行處理。這種完整的業務鏈路壓測代價其實是比較大的，各個上下游系統需要能夠處理識別出模擬壓測的訂單，確保壓測產生的訂單不會影響到線上生產的訂單。
除了業務全鏈路壓測以外，各個系統還需要根據各自系統的特點進行演練，比如雲數據庫RDS，在618大促之前會對線上核心業務構造主庫宕機等異常情況，觀測系統自動切換時間以及線上業務的表現等，保證即使數據庫發生異常也可以秒級自動切換，確保業務表現平穩。此外，數據庫還會單獨演練數據一鍵恢復等功能，雲數據庫除了每天會做一個全量備份外，還會實時將增量備份上傳到雲存儲(oss)，確保即使有異常，在雲上也是可以一鍵將數據還原，解除上層應用的後顧之憂。
Step 7 值班
京東618大促備戰的絕大部分工作，不論是業務評估、預案整理、監控報警、業務壓測還是預案演練都是前期準備工作，當這些前期準備工作做到位後，6.1開門大促開始時反倒是從容的，需要做的就是做好值班工作。值班同學24小時無縫銜接，確保線上報警可以第一時間響應，如有異常按預案處理即可。
Step 8 技術覆盤
大促結束後，還有一個重要工作是大促覆盤，團隊一起回顧大促備戰到大促結束的整個過程，審視哪些是後續需要改進完善的地方，哪些是未來需要進一步加強的，爲下一次大促做更長遠的準備。
以上就是京東618大促完整的技術備戰工作流程，這個過程看起來並不算複雜，但備戰是整個集團各個團隊共同協作一起完成的，這個過程中會涉及到多個事業部多個團隊非常多業務的很多細節，需要拉齊大家的信息以及認知，並確保動作的同步，在大規模工程上本身就是一件很有挑戰的事情。大促不是一個人、一個團隊或一個事業部就可以單獨搞定的事情，需要大家一起同心協力，共同努力。
更多精彩推薦
☞618 Tech Talk|400%存儲容量增長背後的成長之路
☞618 Tech Talk|高併發場景下的數據訪問速度如何保障？
