序 每年618或11.11大促都是一場技術團隊大練兵的時候。京麥平臺隨京東發展至今，已經歷了4次618，3次11.11，今年618備戰的場景還記憶猶新，11.11戰鼓聲卻已早早的敲響。那半年的時間里，京麥服務市場又有哪些蛻變呢？ 正文 京麥服務市場（fw.jd.com）是為第三方軟件服務商和京東商家提供服務的交易平臺。京麥服務市場是一個業務極度復雜的系統，在業務上涵蓋了服務類商品、促銷、計費、訂購、訂單、支付、結算、退款、發票等邏輯，幾乎涉及到電商所有元素。 京麥服務市場架構

大戰在即，要保障11.11的平穩度過。首先要整理自己的備戰思路，大致整理為幾個階段：梳理薄弱點，系統改造，上線和復盤。 詳細來說，備戰開始要對系統做一次全面的梳理診斷，其目的就是要找到系統薄弱點。而梳理方法可以從系統部署耦合、UMP 報警 & 日志、慢 SQL & 外部依賴等不同層面作為切入點進行。 在系統改造階段，通過對系統薄弱點的梳理，進行系統架構改造方案的設計，利用二八原理，集中精力到最重要的環節，即黃金流程的優化，最后制定計劃排期。當然，我們可以利用敏捷的思想，小步快跑，持續優化改進。 上線就是臨門一腳，臺上一分鐘，臺下十年功。為了保證上線成功，要進行充分的上線籌備。首先要整理上線計劃和切流方案，其中包括分階段上線、灰度上線等。計劃準備好之后就要進行反復的壓測和演練，包括極端情況的降級和預案的啟用等等。經驗來講，大多數上線失敗，反復回滾的案例，大多一無計劃，二無預案。 即使進行了周密的上線籌備，上線仍然出現意想不到的問題，所以我們要對每一次上線進行復盤總結，從教訓中成長，并總結出快速定位問題的技能，以及提升工具使用的能力。

我們以此為思路，通過京麥服務市場進行逐一介紹。 一、梳理薄弱點 找出薄弱點的方法有很多，服務市場作為一個前臺系統，我們從最影響用戶感知和體驗的角度進行梳理。

二、系統改造 通過梳理系統薄弱點，甄別出確認的改造點。 1. UMP 監控報警 & 日志 人常說，研發人員有兩只眼睛，一只是監控報警，另一只就是日志，所以無論什么情況監控報警日志一定不能少。本次11.11備戰通過采用AOP的方式，對工程所有層進行統一切面添加監控報警和日志。

特別要說的，設置了報警一定要即時處理和優化，無論是性能報警還是可用率報警，需專人跟進推動優化，如果改動量很大或風險很高，可調整報警閾值備注后期優化，警醒狼來了的故事。 2. 確認大流量頁面超時時間（少超時，多重試） 超時時間的設置采用少超時、多重試，這實際上是一種快速失敗策略，如第三方接口調用超時，如果設置過長，在訪問量大的時候，就會導致請求線程積壓、CPU飆高等問題。 超時設置一是全面檢查MySQL、JimDB、JSF等RPC調用的超時設置，尤其是大流量入口的調用鏈路，二是根據壓測結果結合具體業務場景進行設置調整。 3. 慢SQL 慢SQL問題大多數情況下都是沒有索引引起的，還有就是索引使用錯誤，如索引字段是varchar類型，但是程序中請求DB的時候傳的是long類型，造成索引失效等。 首先通過DBA找出慢SQL，其中重點關注調用次數高和響應速度慢的SQL，通過Query ID找到對應的SQL，然后通過EXPLAIN執行計劃查看SQL命中的索引。添加索引一定要結合MySQL執行計劃來判斷，同時添加Index要注意區分度，區分度=count(Distinct索引值)／總條數，區分度越接近1，說明區分度越高，查詢的時候就越會過濾掉更多的行數據。還有如果某些SQL操作有大量的JOIN操作，就要想辦法拆分SQL，修改代碼邏輯，這也是一種平衡的過程。

4. 降級開關 降級開關可以防止實際情況發生的時候準備好的功能不可用。以下圖Solr降級開關為例，當so出問題時，我們可以關閉so的寫邏輯，sa和sb不影響繼續寫，同時將讀邏輯切換sa，做到平滑切換。當so恢復之后，開啟so的寫邏輯，將讀邏輯開關切換到so，也能做到平滑恢復。當然，要注意so故障時段可能出現的數據不一致問題。

5. 讀寫分離+多級緩存策略 緩存策略可以有效防止請求直達數據庫，造成數據庫壓力大問題。本次11.11備戰采用的緩存策略是JVM+JimDB+DB，緩存的數據主要是列表頁/頻道頁和單品頁的服務類目和服務信息。在啟動緩存策略的過程中，也要考慮緩存的穿透率，以此來調整緩存最優的過期時間。 不僅如此，我們還要將緩存JImDB中間件的不穩定因素的考慮放到備案中，如多機房的部署采用幾主幾從，主從之間是否支持自動切換等等。 服務信息多級緩存策略架構

在使用JimDB緩存一要注意大Key問題，否則量一上來很容易引起緩存集群的單片熱點問題，如服務信息可以根據SpuId的緯度來設置Key，但緩存服務信息會造成實時價格延遲，可以通過數據異構的方式同步價格數據。二要注意緩存過期的問題，不建議使用JimDB的過期設置，而是自定義timestamp由應用程序判斷是否過期，這樣可以解決DB宕機不確定恢復時間的情況下，可以仍從緩存獲取數據。三對于那些“尺寸較小”、“高頻的讀取操作”、“變更操作較少”的數據應全部由JimDB來抗量，如服務類目，每個類目ID作為緩存Key，可以通過雙寫或數據異構的方式。 6. Solr災備策略（列表頁/頻道頁） Solr的使用主要服務于搜索和列表頁多維度的檢索，但是Solr集群情況非常不樂觀，如果Solr宕機，不僅搜索不可用，更糟糕的事服務市場列表頁就完全不可用，所對Solr的災備成為當務之急。當然Solr的災備策略可以參考服務類目和服務信息的多級緩存策略，但是列表頁可能涉及到的熱點問題和分頁邏輯都將問題變得復雜。其實Solr的最優替換方案應該是ES，但一是限于資源問題，二是原檢索邏輯復雜，改造限于時間條件可能風險極大，所以11.11之前主要考慮用DB+JimDB進行容災。 Solr搜索切DB&JimDB拖底，如果Solr降級DB，DB是否有足夠的抗壓能力支持多維度的檢索，無論怎么想，這都不是一個好主意，而且經驗告訴我們，DB就不是用來抗量的。那如果Solr降級JimDB，如何針對多維度檢索設計JimDB的Key，過多的Key不僅會產生大量的數據，還會有相當的成本保證數據一致性，所以JimDB拖底作為一個過度方案，當Solr降級JimDB時，同時也進行了降緯，只保證通常檢索方式。 綜上，雖然Sorl可以降級JImDB，但Solr的單機問題是必須解決的問題，所以Solr集群部署采用二主一備的災備架構，當廊坊機房Solr主s0或馬駒橋的Solr主S1出問題，可以切換Solr備，如果此過程中，Solr備直接被流量擊垮，則直接降級切換對應機房的Jimdb從，如果還是扛不住，就啟動靜態頁托底。

7. 首頁分流加載 官網首頁是一個網站的門戶，如果首頁進不去，那作為一個交易平臺更不能進入列表頁、單品頁或結算頁了，所以特別需要注意首頁的加載性能和開天窗的問題，也正基于此，對首頁的加載采用異步分流加載，不同的區域調用不同的請求，不同的請求數據又是相互隔離，并通過分流加載提升加載速度，同時不把雞蛋都放在一個籃子里，保證頁面的容災和降級。

8. 單品頁加載優化 分流加載的思想也可以應用在單品頁中，以保證可以細粒度的降級。單品頁的特殊性在于實時價格，直接采用緩存可能會造成價格延遲，導致在單品頁看到的價格與結算頁不一致，所以對單品頁添加緩存時處理實時價格需要進行雙寫操作，以此保證單品頁價格的實時性。 發布服務更新價格，寫MySQL，通過異步任務更新主JimDB價格數據。服務信息讀取主JimDB中價格，無過期則直接返回，過期或未命中則訪問主MySQL，獲取最新數據返回用戶，同時異步更新主JImDB價格。

三、上線 1. 壓測 通過梳理系統薄弱點并進行系統改造部署上線之后，我們就要對線上真正能承載能力進行壓測，通過壓測知道系統的極限值是多大，當系統承受不住訪問時，就會再暴露出瓶頸，如服務器CPU、數據庫、內存、響應速度等，從而促使我們再進行優化。線上壓測是在凌晨一兩點，從線上剝離出一小部分集群，所有服務器和配置使用的都是線上真實的場景進行壓測，壓測場景分為讀業務和寫業務。 首先，我們進行了兩次壓測，在未優化前進行了一次壓測，通過對壓測結果的分析，看看系統瓶頸主要出現在哪里。第一次壓測結果發現大量請求穿透直接調用DB，造成DB的性能急劇下降，數據庫服務器的CPU多次飆高，這成為我們備戰優化的重點，優化慢SQL，進行數據庫讀寫分離，添加多級緩存，優化系統調用等。

根據第一次壓測結果結果進行優化后，第二次壓測性能有了很大的提升。 2. 演練 在壓測演練過程中，也暴露出很多問題，如數據配置錯誤未校驗、服務器內存未調整、使用新擴容機器壓測等，這導致出現了一連串的問題。壓測開始服務器CPU90%，數據庫無任何響應，因為數據庫配置錯誤導致服務器根本沒有連接到數據庫。服務器內存1G造成頻繁Full GC，性能總是提升不上去。新服務器造成很多配置未同步、權限未申請，花費很多時間解決，影響壓測主流程。 3. 預案 預案的執行包括發現問題、定位問題和解決問題。發現問題要結合軟硬件問題能夠即時發現問題，定位問題包括監控報警和日志分析，這就要看之前添加監控的粒度和日志是否打的有用，最后就是解決問題。 11.11零時大促，京東主站迎來流量洪峰，而到8時才是商家的主戰場，接口調用量是平時的3~10倍，系統性能負載也略有飄高，UMP報警也接踵而至，通過監控和日志迅速排查線上隱患和風險，共不同程度啟用降級預案。 四、復盤 11.11服務市場還是非常平穩的度過了。而在整個過程中也暴露出了很多問題，有一點是上述沒有提到的，那就是心理因素的培訓。如在壓測演練時，前期時由于遇到各種問題導致結果遲遲不能到達預期效果，整體團隊開始出現急躁，處理操作開始變形，出現質疑聲音進行自我否定等問題，還好后期即時調整，過程逐漸進入正軌，大家開始慢慢恢復常態。所以，11.11真正開始前我們就開始進行了小復盤，針對心理心態進行了調整和培訓，并完善了預案等內容。 在11.11當前出現的問題，團隊保持很好的心態處理線上的問題，而整個系統也非常給力的穩定運行。 總結 最后，總結歷次的大促，無論是今天給大家介紹的京麥服務市場，還是后期會給大家介紹京麥網關，所面臨的技術難點，最重要的還是服務治理。因為我們要打造的不是一個系統，也不是一堆系統，而是一個平臺生態，能夠持續地提高系統的運營能力。