作為技術研發人員，我們常稱京東每年只幹兩件事

作為技術研發人員，我們常戲稱京東每年只幹兩件事，一個是618，另外一個是雙11！

確實每一次的大促都是一場全兵演練，技術人員在這場戰鬥中，從團隊合作、技術提升、使用者意識上都有一個立體的提高。實難想象還有比這樣規模的促銷再有更好的鍛鍊方式。

京麥平臺是目前京東所有商家唯一使用的一站式店鋪運營管理平臺，商家藉助京麥可以實現商品釋出、列印訂單、出庫、訂單訊息接收等等一系列的日常工作，京麥平臺更是集合了眾多ISV廠商為商家提供了更加豐富的功能，更好的賦能於商家。京麥平臺的技術架構也在隨著京東業務的飛速發展不斷演化著。從早期的簡單nginx+tomcat部署，到現在功能服務模組化，獨立部署，享受著微服務帶來的便利，但同時也給我們大促的備戰帶來了幾多挑戰。

首先確定自己的備戰思路，梳理核心流程、找出薄弱點，對薄弱點具體最佳化。

同時協調壓測對最佳化結果驗證，最佳化和壓測會有一個反覆的過程，後面我們還要實際演練，比如降級開關，防止實際情況發生的時候準備好的功能不可用。

最後我們要做一輪培訓，在工具使用，快速定位問題，歷來的教訓總結都過一遍，從心理層面上我們也要輔導，大促期間發生的問題都不是小問題，研發人員在這種壓力下處理問題有時候會變形，我們會在這方面做一次心理疏解。這中間我們可以利用幾個規則，二八法則，找出20%重要核心的功能，比如京麥的登入、交易、價格門訊息推送。在找薄弱點的時候我們可以試試墨菲定律的幾點規則，“可能出錯的事總會出錯”，“如果你擔心某種情況發生，那麼他就有可能發生”，我們還會找大家一起列出你心中最不可能出現問題的系統和功能點，那麼列出來重點對待，沒錯，是重點對待。

我們常用的備戰技術，肯定不是重啟，回滾，加機器，^_^。這裡面個人總結有分離技術，快取技術，SQL最佳化，快速失敗，降級限流，我們來逐一介紹。

分離技術

話說“天下大事，合久必分，分久必合”，但在軟體架構領域，一直是一個分的趨勢，比如京麥平臺有提供ISV的服務、提供京麥自有客戶端的服務、提供其他平臺的服務，同時還有監控服務，日誌服務，訊息服務等，需要將業務服務隔離部署，線下分析和線上執行隔離，同時還可以採取執行緒隔離，比如JSF裡面為每個不同重要的服務分別一個執行緒組的方式。資料庫層面上主從分離，京麥平臺的業務都是讀多寫少，可以充分利用分庫的資源。還可以再將資料庫細分，按照主要業務拆分不同的資料庫，結合RPC使用，更大降低資料庫層面的耦合程度。

快取技術

如果軟體裡面真的有一種銀彈的話，我認為就是快取，當你效能最佳化遇到瓶頸的時候，當你想抗量的時候，你都會想到快取。這裡有一個鐵律，那就是，對外暴露的介面一定不能直達資料庫。我們常用的快取是redis+jvmcache。計算redis穿透率的時候我們可以，透過UMP來實現，在一個方法的總入口埋點，比如統計出1分鐘呼叫M次，在請求redis的入口埋點，統計出1分鐘呼叫N次，計算命中率：N/M.。在使用redis的時候要注意含有大數值的key，常常量一上來會造成redis叢集的熱點訪問，直接將單一節點打死。這樣的情況下我們就要拆分這樣的大key。同時將快取DB化，就是不設定超時時間，這樣全部用redis來抗量。本地快取這塊我們常用的有Guava-cache，透過本地快取我們可以做三級防護，或者做託底資料等。如果資料“尺寸較小”、“高頻的讀取操作”、“變更操作較少”使用這種嵌入式快取將非常合適。

SQL最佳化

每次大促前我們都要將系統中效能慢的sql抓出來，而且這種工作投入產出比極高，也就是可以花費較小代價帶來極大的效能收益。sql效能問題，大多數情況下是沒有索引引起的，這可能是後續業務變化迅速，上線前程式碼review的遺漏，需要這個時候統一過一遍。還有就是索引使用錯誤，比如索引欄位是字串型別，但是程式中請求DB的時候傳的是long型別，索引失效，表中數量過多，做了一次全表掃描，效能會很差。還有時候我們新增索引的時候要看區分度，計算索引區分度的方法，不重複的索引值/總記錄數，值越接近1，說明區分度越高，查詢的時候mysql就會過濾掉更多的行資料。還有，新增索引最好結合mysql執行計劃來判斷。有時候做了過多的join操作，比如超過3張表以上，我們就要想著去拆解這些sql語句。在就是資料庫層面我可以把歷史資料轉出減少資料量來達到提高查詢速度的目的。

快速失敗

快速失敗策略實際上是一種自我保護措施，比如呼叫第三方介面超時，如果超時時間設定過長，訪問量大的時候，就會導致請求執行緒積壓，如果此時有執行緒隔離還好，若剛好沒有，那麼訪問量一上來就會迅速導致cpu飆高。京麥平臺的特點之一，會大量呼叫第三方介面服務，我們會對每個方法動態的設定超時時間，如果UMP報警再結合JVM效能資料，我們會將這個介面的超時時間閾值調小。透過zookeeper下發到每一個服務節點上。在大促前，我們會重點檢查mysql、redis、jsf等rpc呼叫的超時設定，確保每一次rpc呼叫都要有上限閾值。關於RPC呼叫超時，這裡多說一下，有時候我們會發現呼叫端效能比如超過500ms，但是服務端確是在100ms上線徘徊。這裡面我們除了檢查閘道器延時，tcp重傳，還要注意一點，就是任何一個成熟的rpc框架都不會讓業務執行緒直接參與網路請求，rpc會提供一個訊息佇列，呼叫端直接跟訊息佇列打交道。此時，我們就要想到佇列這塊是否有問題了。

降級限流

這種技術實際上是保命的措施。降級一般有屛蔽降級和容錯降級兩種，對一些非核心的功能，比如京麥的麥圈，服務號，論壇等功能，而他們恰恰又請求著mysql，redis等公共資源，為了減少這種競爭我們就會對這些功能進行屛蔽降級，直接切斷RPC呼叫，不再發起遠端呼叫，返回空或者其它異常提示，減少公共資源的訪問。降級開關，目前京麥是採用統一配置中心來使用。同樣，限流技術在京麥平臺中也是異常重要的一個措施，尤其是對京麥閘道器的呼叫。我們目前是採用令牌桶的方法，實現方式是Guava RateLimter，簡單有效，再結合統一配置中心，我們可以動態調整限流閾值。不用重啟伺服器即可實現快速限流策略調整。我們在閘道器裡面還有一個設定，就是併發度，這個是方法粒度的，對每一個呼叫第三方的介面都有一個併發度數值設定，而且是動態設定，也是透過zookeeper下發到每一個服務節點上。併發度的具體實現是透過jdk的Semaphore。

監控配置和效能壓測

監控配置是一定不能缺少，我們要求自己一定要第一時間早於使用者發現問題。平時開發在上線的時候我們都應該有統一要求每一個RPC呼叫都要有監控和錯誤棧的輸出。在備戰期間實際是對監控配置的一個治理過程，監控配置key要規則化，比如***.mysql.***,***.redis.***等讓我們一眼便知到是操作的哪一個資源。京麥平臺這次備戰的過程中透過採用AOP的方式，把所有類似的呼叫統一規範化處理，後續結合Python指令碼對監控閾值進行統一調整。這樣走下來一方面把我們平時可能漏掉的監控給補全，另外一方面我們的監控配置按照統一的規則來生成。

效能壓測這一塊，可以很好的檢驗我們最佳化的結果，壓測的過程中我們關注qps的同時，還要結合伺服器的cpu、io、記憶體等機器效能指標來定位我們的效能瓶頸。最後來預估我們系統的承載能力，提供資料支撐來申請伺服器或者docker資源。壓測工具研發可以自己寫指令碼，藉助jmeter、loadrunner等工具，也可以有計劃的聯絡效能壓測組他們協助執行。最困難的還是產生真實的壓力。

還有一個備戰點，返璞歸真，回到程式碼，重點核心功能檢查一遍，把壞味道的程式碼查出來。比如join了很多張表的sql語句，日誌輸出沒有采用條件方式或者佔位符的方式，日誌重複列印，try程式碼塊放到了事務中，迴圈體中含有低效能的語句，鎖程式碼塊中進行RPC呼叫，等等。

最後，我們可以想一下備戰備的是什麼，總結歷次的大促，我認為主要在工具、知識、經驗三個方面的備戰。工欲善其事，必先利其器，我們要有一些個好的工具輔助我們解決問題，比如MDC(裡面含有CPU，網路等監控)、UMP(京東自研方法效能，可用率等監控平臺)、CAP(容器的總體監控，也含有cpu負載等資訊檢視)。知識層面，是我們歷來的積累，我們的認識的提高，使用工具時候的指導。經驗是我們以往的大大小小的教訓的總結，前車之鑑，防止我們再次發生類似的事情。

以“結硬寨，打呆賬”這句話結束此次618備戰的總結，最重要的一點，還是要求我們備戰在平時。