京麥服務(wù)市場在哪里進(jìn)入？京東京麥網(wǎng)頁版登錄詳細(xì)教程分享

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

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

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

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

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

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

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

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

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

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

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

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