《大促訂單、PV雙線破億，解密京東商城交易系統(tǒng)的演進(jìn)之路》要點(diǎn)：
本文介紹了大促訂單、PV雙線破億，解密京東商城交易系統(tǒng)的演進(jìn)之路，希望對(duì)您有用。如果有疑問，可以聯(lián)系我們。

本文根據(jù)京東商城交易平臺(tái)的楊超在“第一期蝴蝶沙龍：揭秘618電商大促背后的高并發(fā)架構(gòu)”會(huì)議上的演講整理而成.

大家好!我是來自京東商城交易平臺(tái)的楊超,今天特別高興能夠來給大家做這個(gè)分享.我是 2011 年加入京東,5 年中我經(jīng)歷了不少技術(shù)架構(gòu)的演進(jìn),也看到了不少變化.這次分享首先介紹京東商城的服務(wù)、京東交易結(jié)構(gòu),然后介紹針對(duì)618備戰(zhàn),我們做的一些事情,以及從2011年到現(xiàn)在,京東交易平臺(tái)經(jīng)歷的變化.

如圖所示是京東交易平臺(tái)的一張大的漁網(wǎng)圖.從主頁面網(wǎng)站開始,到后面提交訂單、購物車、結(jié)算頁、訂單中心等的整個(gè)生產(chǎn)過程,大體可分為三個(gè)部分.第一部分是訂單提交前,就是俗稱的購物車,結(jié)算頁.第二部分是訂單預(yù)處理部分,生成訂單之后、到物流之前,還會(huì)有一些預(yù)處理過程,比如生鮮、大家電、奢侈品、易碎品等商品.第三部分是訂單履約部分.今天我講的主要內(nèi)容是,交易平臺(tái)的提交以前和預(yù)處理部分.

京東交易平臺(tái),包括單品頁的價(jià)格、庫存,購物車、促銷,結(jié)算頁的下單,再到訂單中心線.

如下圖所示,2011年京東的訂單量是30萬,2015年訂單量就已經(jīng)到了3000多萬,京東的流量每年不斷地翻倍.訂單從30萬到100萬是三倍增長,實(shí)際上訪問流量的翻番,可能是10倍、50倍,甚至上百倍.

比如,用戶購買東西從單品頁進(jìn)入,然后查詢很多信息,包括價(jià)格、評(píng)價(jià).商品加入購物車后,用戶會(huì)不停地比對(duì)各類商品.刷新購物車,從前端到后端所有的服務(wù)基本上都會(huì)刷新.那么,當(dāng)你刷新一次,調(diào)動(dòng)服務(wù)就會(huì)承受一次動(dòng)態(tài)的調(diào)用.當(dāng)訂單量翻三倍的時(shí)候,實(shí)際服務(wù)訪問量最少是要翻20倍.

我見過的京東目前最大的前端流量是,一分鐘幾千萬,一個(gè)正常前端服務(wù)訪問量是在幾千萬,幾億、幾十億,一天的PV.

那為了應(yīng)對(duì)如此大的調(diào)動(dòng)量,每年的618、雙11,京東都做了什么?

下面我會(huì)詳細(xì)講618、雙11備戰(zhàn)后面,每一年所做的不同改變.這是一個(gè)整體的大概分析,我們從哪些方面做優(yōu)化,去提高系統(tǒng)的容災(zāi)性,提高系統(tǒng)應(yīng)對(duì)峰值流量的能力.

實(shí)際上每年京東內(nèi)部的正常情況是,領(lǐng)導(dǎo)層會(huì)給出一個(gè)大概的預(yù)期值,就是希望當(dāng)年的大促中,需要達(dá)到幾百億,或者幾十億的預(yù)期銷售額.那么,根據(jù)這個(gè)銷售額,根據(jù)客單價(jià)(電商的訂單的平均價(jià)格,稱為客單價(jià))換算成訂單量.

另外在以往的618、雙11中,我們都會(huì)統(tǒng)計(jì)出訂單量和調(diào)用量,即前端價(jià)格需要訪問多少次,購物車需要訪問多少次,促銷引擎需要訪問多少次,整個(gè)流程需要多大的量.有了大概的方向之后,就會(huì)把具體系統(tǒng)的量換算出來.第一輪會(huì)做壓測,壓測分為線上壓測和線下壓測兩部分.這些都是準(zhǔn)備工作,根據(jù)一些指標(biāo)往年的增長量估算出一個(gè)預(yù)期值.

壓測

這是真正進(jìn)入第一波.首先,每年的大促前,都會(huì)經(jīng)歷半年業(yè)務(wù)迭代期,整個(gè)系統(tǒng)會(huì)有很多變更.我們會(huì)進(jìn)行第一輪的壓測系統(tǒng),壓測之后會(huì)知道當(dāng)前線上真正能夠承載的訪問量有多大,距離預(yù)期有多遠(yuǎn).壓測分為線上壓測跟線下壓測.壓測場景分為讀業(yè)務(wù)和寫業(yè)務(wù),壓測方案有集群縮減服務(wù)、模擬流量、流量泄洪.

講到壓測,先說說壓測的來歷吧.2011年時(shí)候沒有線上壓測,線下壓測也不是很全.真正引入線上壓測是在2014年,訂單量已經(jīng)接近2000萬.之前的大促備戰(zhàn),是通過組織架構(gòu)師、優(yōu)秀的管理人員,優(yōu)秀的技術(shù)人員,一起去評(píng)估優(yōu)化系統(tǒng),因?yàn)樵诘a的同時(shí),我們會(huì)知道系統(tǒng)哪里容易出現(xiàn)問題,然后對(duì)數(shù)據(jù)庫、Web或者業(yè)務(wù)服務(wù)做一堆優(yōu)化.

在2014年,訂單量到了上千萬,換算成為訪問量,每天的PV大漲,集群也更大偏大,如果還是只依靠技術(shù)人員去優(yōu)化,可能會(huì)不足.于是就衍生出壓測,我們想知道系統(tǒng)的極限值.這樣,當(dāng)系統(tǒng)承受不住訪問請(qǐng)求的時(shí)候,我們就會(huì)知道哪里出現(xiàn)瓶頸,比如,服務(wù)器的CPU、內(nèi)存、連接速度等.我們通過第一輪壓測找到第一波的優(yōu)化點(diǎn),開始了線上的壓測.

當(dāng)時(shí)第一波做線上壓測是在凌晨一兩點(diǎn),把整個(gè)線上的流量剝離小部分機(jī)器上.把集群剝離出來,然后再做壓測.所有的服務(wù)器、所有的配置就是用線上完全真實(shí)的場景去做壓測,就能夠得到線上服務(wù)器在真實(shí)情況,再優(yōu)化.

曾經(jīng)做redis壓測,把進(jìn)程綁定到單核CPU,redis是單進(jìn)程程序,當(dāng)時(shí)集群的性能就提升了5%.因?yàn)闄C(jī)器的每次CPU切換,都需要損耗資源,當(dāng)時(shí)把進(jìn)程直接綁定到固定的CPU上,讓它高壓下不頻繁地切換CPU進(jìn)程.就這樣一個(gè)改變,性能提升了5%.當(dāng)量很大的時(shí)候,真正底層細(xì)節(jié)的小改變,整個(gè)性能就會(huì)有很大的改進(jìn).這是我們從2014年引進(jìn)線上壓測和線下壓測之后的一個(gè)真實(shí)感受.

壓測完之后得到容量,得到交易系統(tǒng)的購物車、結(jié)算頁大概承受值,之后會(huì)進(jìn)行一輪優(yōu)化,包括對(duì)NoSQL緩存的優(yōu)化.京東在2012年的時(shí)候自建CDN網(wǎng)絡(luò),Nginx層做了很多模塊加Nginx+lua的改造.應(yīng)用程序?qū)右矔?huì)做很多緩存,把數(shù)據(jù)存在Java虛擬器里面.數(shù)據(jù)層的緩存,主要有redis、?NoSQL的使用,另外會(huì)剝離出一些獨(dú)立的數(shù)據(jù)存儲(chǔ).

緩存壓縮

CDN域名切換的問題,原來外部CDN切換IP,需要15-20分鐘,整個(gè)CDN才能生效.我們的運(yùn)維做了很多的改進(jìn),自建了CDN,內(nèi)網(wǎng)VIP等等進(jìn)行緩存壓縮.Nginx本身就有介質(zhì)層的緩存和GZIP壓縮功能,把靜態(tài)js、CSS文件在Nginx層直接攔掉返回,這樣就節(jié)省了后面服務(wù)的服務(wù)器資源.

GZIP壓縮能壓縮傳輸?shù)奈募约皵?shù)據(jù),節(jié)省了網(wǎng)絡(luò)資源的開銷(GZIP壓縮主力損耗CPU,機(jī)器內(nèi)部資源的平衡).前面就直接壓縮返回圖片、文件系統(tǒng)等靜態(tài)資源.流量到部署集群系統(tǒng)時(shí),只需要處理動(dòng)態(tài)資源的計(jì)算,這樣就將動(dòng)態(tài)靜態(tài)分離集中處理這些專向優(yōu)化.

真正的計(jì)算邏輯,服務(wù)自身的組裝、如購物車的促銷商品、服務(wù)用戶,基本上所有資源都耗費(fèi)在此.比如,連接數(shù)都會(huì)耗費(fèi)在跟促銷,商品,用戶服務(wù)之間調(diào)用,這是真實(shí)的數(shù)據(jù)服務(wù).如果不分離,你用DOS攻擊直接訪問JS,然后傳一個(gè)大的包,就會(huì)完全占用帶寬,連接和訪問速度就會(huì)非常慢.這也是一種防護(hù)措施,在大促中會(huì)做很多緩存、壓縮這些防護(hù).

購物車從2010年就開始Java改造,整體結(jié)構(gòu)的劃分主體有,促銷引擎、商品、用戶.系統(tǒng)結(jié)構(gòu)在2012年已經(jīng)成型.到13年,加入了購物車服務(wù)的存儲(chǔ).原來購物車存儲(chǔ)的商品是在瀏覽器端的Cookie里的,用戶更換一臺(tái)設(shè)備,之前加入的商品就會(huì)丟失掉.為了解決這個(gè)需求,我們做了購物車服務(wù)端存儲(chǔ),只要登錄,購物車存儲(chǔ)就會(huì)從服務(wù)端拿取.然后通過購車服務(wù)端存儲(chǔ)打通了手機(jī)端與PC端等的存儲(chǔ)結(jié)構(gòu),讓用戶在A設(shè)備加入商品,在另外一個(gè)設(shè)備也能結(jié)算,提高用戶體驗(yàn).

異步異構(gòu)

2013年之后,接入了很多其他業(yè)務(wù),如跟騰訊合作,有微信渠道,我們會(huì)把存儲(chǔ)分為幾份,容量就會(huì)逐步地放大.這是異步的存儲(chǔ),手機(jī)端會(huì)部署一套服務(wù),PC端會(huì)部署一套服務(wù),微信端會(huì)部署一套服務(wù).就會(huì)隔離開來,互不影響.

購物車就是這么做的.購物車整個(gè)數(shù)據(jù)異步寫的時(shí)候都是全量寫的.上一次操作可能異步?jīng)]寫成功,下一次操作就會(huì)傳導(dǎo)都寫成功了.不會(huì)寫丟,但是可能會(huì)有一下延時(shí),這些數(shù)據(jù)還是會(huì)同步過來.比如,從PC端加入商品之后沒有立即同步到移動(dòng)端,再勾選下購物車,購物車的存儲(chǔ)又會(huì)發(fā)生變更,就會(huì)直接把全部數(shù)據(jù)同步到移動(dòng)端.這樣,我們的數(shù)據(jù)很少會(huì)出現(xiàn)丟失的情況.

異步寫的數(shù)據(jù)是進(jìn)行了很多的壓縮的.第一層壓縮從前端開始,整個(gè)前端是一個(gè)接口串,到后面購物車服務(wù),先把它壓縮為單個(gè)字母的接口串,后面又會(huì)壓縮成字節(jié)碼,使字節(jié)流真正存儲(chǔ)到redis層里面.當(dāng)存儲(chǔ)壓縮得很小的時(shí)候,性能也會(huì)提高.

緩存壓縮只是為提升縱向性能做的改進(jìn).后面還會(huì)進(jìn)行橫向異步異構(gòu)的改進(jìn),購物車把移動(dòng)端存儲(chǔ)剝離出去,移動(dòng)端的存儲(chǔ)在一組redis上,PC端的存儲(chǔ)在另外一組上.PC端和移動(dòng)端是異步去寫,這樣相互不影響,雖然它們的數(shù)據(jù)是同步的.這是針對(duì)多中心用戶所做的一些改進(jìn).

外層的異步,是做一些不重要的服務(wù)的異步,就從購物車前端看到的地址服務(wù)、庫存狀態(tài)服務(wù).庫存狀態(tài)服務(wù)在購物車只是一些展示,它不會(huì)影響主流層、用戶下單.真正到用戶提交的時(shí)候,庫存數(shù)據(jù)才是最準(zhǔn)確的.這樣,我們會(huì)優(yōu)先保證下單流程.

接下來講講接單的異步.提交訂單,提交一次訂單原來需要寫10多張表.當(dāng)訂單量提高到一分鐘10萬的時(shí)候,系統(tǒng)就無法承受.我們就把整個(gè)提交訂單轉(zhuǎn)成XML,這樣只寫一張表,后面再去做異步.接單的第一步,先是把整個(gè)訂單所有信息存儲(chǔ)下來,然后再通過狀態(tài)機(jī)異步寫原來的10多張表數(shù)據(jù).

關(guān)于訂單中心的異步異構(gòu),訂單中心原來都是從訂單表直接調(diào)出的.隨著體量增大,系統(tǒng)無法承載訪問,我們異構(gòu)出訂單中心的存儲(chǔ),支付臺(tái)帳存儲(chǔ)等. 異構(gòu)出來數(shù)據(jù)都具有業(yè)務(wù)針對(duì)性存儲(chǔ).數(shù)據(jù)體量會(huì)變小,這樣對(duì)整體的優(yōu)化提升提供很好的基礎(chǔ).

這樣的存儲(chǔ)隔離,對(duì)訂單狀態(tài)更新壓力也會(huì)減小,對(duì)支付的臺(tái)帳、對(duì)外部展示的性能也會(huì)提升.大家會(huì)疑問,這些數(shù)據(jù)可能會(huì)寫丟.我們從第一項(xiàng)提交開始,直接異步寫到訂單中心存儲(chǔ),到后面訂單狀態(tài)機(jī)會(huì)補(bǔ)全.如果拆分不出來,后面就生產(chǎn)不了.也就是說,到不了訂單中心,數(shù)據(jù)生產(chǎn)不了,一些異步?jīng)]成功的數(shù)據(jù)就會(huì)在這個(gè)環(huán)節(jié)補(bǔ)全.

然后是商品的異步異構(gòu).2013年,商品團(tuán)隊(duì)面臨的訪問量,已經(jīng)是幾十億.如何去應(yīng)對(duì)這個(gè)情況呢?很多商品數(shù)據(jù)貫穿了整個(gè)交易,包括交易的分析、各個(gè)訂單的系統(tǒng)都會(huì)調(diào)商品系統(tǒng).我們會(huì)針對(duì)系統(tǒng)優(yōu)化.

比如,針對(duì)促銷系統(tǒng)調(diào)用,促銷系統(tǒng)主要調(diào)用特殊屬性,我們把這些屬性存到促銷系統(tǒng)的特有存儲(chǔ).庫存系統(tǒng)也類推.調(diào)用的特殊屬性的方法也不一樣.譬如大家電的長寬高這些特有屬性,不像前端商品頁里只是基本屬性.這樣就把所有的屬性異構(gòu)處理,針對(duì)商品緯度、商品ID等所有數(shù)據(jù)會(huì)異構(gòu)一份到庫存、促銷、單品頁,后面進(jìn)行改造的時(shí)候,又將數(shù)據(jù)分A包、B包、C包.

京東的業(yè)務(wù)很復(fù)雜,有自營,又有平臺(tái)數(shù)據(jù),A包可能是基礎(chǔ)數(shù)據(jù),B包可能是擴(kuò)展數(shù)據(jù),C包可能是更加偏的擴(kuò)展數(shù)據(jù).這樣,促銷系統(tǒng)可能調(diào)用的是B包的擴(kuò)展屬性,也有可能調(diào)用的是A包的基礎(chǔ)屬性.單品頁訪問A包、B包,調(diào)的集群是不一樣的.這樣存儲(chǔ)的容量就可以提高兩倍,系統(tǒng)的容災(zāi)承載力也會(huì)提高.

商品原來是一個(gè)單表,后來慢慢發(fā)展成為了一個(gè)全量的商品系統(tǒng),包括前端、后端整個(gè)一套的流程.異步異構(gòu)完了之后,系統(tǒng)可進(jìn)行各方面的優(yōu)化,這樣系統(tǒng)的容量也會(huì)慢慢接近預(yù)期值.然后找到系統(tǒng)容量的最大值,如果超過這個(gè)值,整個(gè)系統(tǒng)就會(huì)宕機(jī).那么,我們會(huì)做分流和限流,來保證系統(tǒng)的可用性.否則,這種大流量系統(tǒng)一旦倒下去,需要很長的時(shí)間才能恢復(fù)正常,會(huì)帶來很大的損失.

分流限流

在618、雙11時(shí)候,手機(jī)、筆記本會(huì)有很大力度的促銷,很多人都會(huì)去搶去刷.有很多商販利用系統(tǒng)去刷,系統(tǒng)流量就不像用戶一秒鐘點(diǎn)三四次,而是一分鐘可以刷到一兩百萬.怎樣預(yù)防這部分流量?我們會(huì)優(yōu)先限掉系統(tǒng)刷的流量.

• Nginx層： 通過用戶IP、Pin,等一下隨機(jī)的key進(jìn)行防刷.
• Web 層： 第一層,Java應(yīng)用實(shí)列中單個(gè)實(shí)列每分鐘,每秒只能訪問多少次；第二層 ,業(yè)務(wù)規(guī)則防刷,每秒單用戶只能提交多少次,促銷規(guī)則令牌防刷.

從Nginx,到Web層、業(yè)務(wù)邏輯層、數(shù)據(jù)邏輯層,就會(huì)分流限流,真正落到實(shí)際上的流量是很小的,這樣就會(huì)起到保護(hù)作用,不會(huì)讓后端的存儲(chǔ)出現(xiàn)崩潰.從前面開始,可能訪問價(jià)格或者購物車的時(shí)間是10毫秒,保證20臺(tái)的機(jī)器一分鐘的流量是一百萬、兩百萬.

如果是40臺(tái)機(jī)器的話,承載能力會(huì)很強(qiáng),會(huì)透過Java的服務(wù),壓倒存儲(chǔ),這樣會(huì)引發(fā)更大的問題,龐大存儲(chǔ)一旦出現(xiàn)問題很難一下恢復(fù).如果從前面開始一層一層往下限,就可以起到保護(hù)底層的作用.中間層出問題比較容易處理,如Web層,限流會(huì)消耗很多CPU,會(huì)一步步加入更多機(jī)器,這樣就能夠解決這個(gè)問題.

我們需要降級(jí)分流限流.

下面結(jié)合秒殺系統(tǒng)來講講如何限流分流.2014年才產(chǎn)生秒殺系統(tǒng).當(dāng)時(shí),在同一時(shí)刻可能有1500萬人預(yù)約搶一件商品,搶到系統(tǒng)不能訪問.后端服務(wù)都沒有出現(xiàn)這些問題,有的服務(wù)費(fèi)不能正常展現(xiàn).后來就專為搶購設(shè)計(jì)了一個(gè)秒殺系統(tǒng).正常情況下,有大批量用戶需要在同一時(shí)間訪問系統(tǒng),那么就從系統(tǒng)結(jié)構(gòu)上分出去這些流量.秒殺系統(tǒng)盡量不影響主流層的入口,這樣就分離出來一部分?jǐn)?shù)據(jù).

接下來講講促銷和價(jià)格.主力調(diào)用價(jià)格的服務(wù)主要在促銷引擎,限流主要是通過購物車服務(wù),購物車到促銷引擎又會(huì)限流,促銷引擎里面會(huì)有令牌.比如,有5000個(gè)庫存,發(fā)50萬個(gè)令牌到前端去,肯定這5000個(gè)庫存會(huì)被搶完,不可能再把其他服務(wù)的量打到后面,這樣會(huì)保護(hù)促銷引擎,這是一種總令牌模式的保護(hù).后面的分流性能,會(huì)分集群式、重要程度去做.

另外,一些廣告的價(jià)格服務(wù),我們會(huì)優(yōu)先降級(jí),如果出問題的話會(huì)限制.另外,有一部分刷引擎刷價(jià)格服務(wù)的數(shù)據(jù),正常情況下是保證它正常使用,但是一旦出現(xiàn)問題,我們會(huì)直接把它降級(jí),這樣就保護(hù)了真實(shí)用戶的最好體驗(yàn),而不是直接清除程序的應(yīng)用.

容災(zāi)降級(jí)

每次雙11活動(dòng),我們會(huì)做很多的容災(zāi)和降級(jí),有多中心交易、機(jī)房容災(zāi)、業(yè)務(wù)容災(zāi)等各種緯度的容災(zāi).大概統(tǒng)計(jì)了一下做過的一些容災(zāi)方案.

首先是網(wǎng)絡(luò)容災(zāi).前面說到SB中間件、域名解析,我們運(yùn)維自己會(huì)做了核心交換機(jī)兩層專線.這是我們運(yùn)維部做的一些網(wǎng)絡(luò)架構(gòu)圖,兩邊相互容災(zāi)的一個(gè)結(jié)構(gòu).有LVS、HA、域名及解析,只是單服務(wù)掛了,通過交換機(jī),我們可以從一個(gè)機(jī)房切換到另一個(gè)機(jī)房,因?yàn)闀?huì)做一些域名的解析和切換.

應(yīng)用系統(tǒng)相互調(diào)用容災(zāi)和降級(jí)：結(jié)算的容災(zāi)和降級(jí).應(yīng)用系統(tǒng)大部分能夠降,比如庫存狀態(tài).如果像優(yōu)惠券這些不重要的服務(wù),備注信息,可直接降級(jí)服務(wù),不用去訪問它,直接提交就行.在提交訂單時(shí)候,首先我們會(huì)保證必要服務(wù),這些服務(wù)都會(huì)有很多的保護(hù)措施.每個(gè)應(yīng)用里面,應(yīng)用級(jí)別、服務(wù)級(jí)別的容災(zāi),比如地址服務(wù)、庫存狀態(tài)容災(zāi)可以直接先降級(jí).到提交的時(shí)候,我們直接對(duì)庫存做限制.

應(yīng)用內(nèi)部的容災(zāi).庫存就是結(jié)算前面的系統(tǒng)應(yīng)用的服務(wù),再到細(xì)一層的我們的庫存服務(wù),這是每一個(gè)服務(wù)的容災(zāi)降級(jí).從庫存狀態(tài)這邊的話,從網(wǎng)絡(luò)設(shè)備內(nèi)層,有網(wǎng)絡(luò)容災(zāi)降級(jí).應(yīng)用內(nèi)部有對(duì)于預(yù)算服務(wù)的降級(jí),預(yù)算服務(wù)會(huì)有預(yù)算庫存,原來是寫MySQL數(shù)據(jù)庫.

正常情況下,預(yù)算庫存是寫MASIC預(yù)算庫,當(dāng)出現(xiàn)問題的時(shí)候,我們會(huì)異步堆列到本地機(jī)器,裝一個(gè)程序去承載這個(gè)異步MySQL數(shù)據(jù)的落地,然后再通過Work把它寫到MySQL服務(wù)里面.正常情況下,是雙寫MySQL、redis,當(dāng)MySQL承載不住的時(shí)候,我們會(huì)把MySQL異步寫到里面.

這里面都會(huì)有開關(guān)系統(tǒng)去控制.當(dāng)提交訂單產(chǎn)生變更的時(shí)候,才會(huì)把庫存狀態(tài)從這邊推到這個(gè)庫存狀態(tài)這邊,因?yàn)閹齑鏍顟B(tài)的調(diào)用量跟價(jià)格一樣很大.今年我們看到的最大調(diào)用量是一分鐘2600萬.

這樣不可能讓它直接回原到MySQL,跟直接庫存的現(xiàn)實(shí)存儲(chǔ)里面.通過預(yù)算系統(tǒng)把這個(gè)狀態(tài)從左邊算好,直接在推送過到真正的存儲(chǔ),這樣就把這個(gè)存儲(chǔ)剝離出來,這也算一種異步異構(gòu),這樣我們會(huì)提升它的容量.

這是原來的結(jié)構(gòu),就是redis直接同步,然后直接訪問.現(xiàn)在把它改成是,直接讓左邊的預(yù)算服務(wù)去推送到狀態(tài)服務(wù)里面.

監(jiān)控

最后主要就是監(jiān)控系統(tǒng),我們運(yùn)維提供了網(wǎng)絡(luò)監(jiān)控、機(jī)器監(jiān)控.

網(wǎng)絡(luò)監(jiān)控包括我們看到的SBR,以及一些專線網(wǎng)絡(luò)監(jiān)控,如交換機(jī)、柜頂交換機(jī)、核心交換機(jī)的監(jiān)控.

接下來是應(yīng)用的系統(tǒng)監(jiān)控.機(jī)器監(jiān)控有CPU、磁盤、網(wǎng)絡(luò)、IO等各方面系統(tǒng)的監(jiān)控.業(yè)務(wù)緯度的監(jiān)控,有訂單量、登陸量、注冊(cè)量等的監(jiān)控.京東機(jī)房微屏專線的一個(gè)網(wǎng)絡(luò)平臺(tái)的監(jiān)控,里面有很多專線,它們相互之間的流量是怎么樣?圖中是我們監(jiān)控系統(tǒng),是機(jī)器之間的監(jiān)控,包括機(jī)器直接對(duì)應(yīng)的交換機(jī)、前面的柜機(jī)交換機(jī)等的網(wǎng)絡(luò)監(jiān)控等.

這是應(yīng)用系統(tǒng)里面的方法監(jiān)控,后面是業(yè)務(wù)級(jí)別的監(jiān)控.訂單級(jí)別的包括注冊(cè)量、庫存、域站,或者區(qū)域的訂單、金額、調(diào)用量的監(jiān)控都會(huì)在這里體現(xiàn).真正到大促的時(shí)候,不可能經(jīng)常去操作我們的系統(tǒng),去修改它的配置.正常情況下都是去查看這些監(jiān)控系統(tǒng).

2012年之后,監(jiān)控系統(tǒng)一點(diǎn)一點(diǎn)積累起來.當(dāng)量越來越大,機(jī)器資源越來越多之后,這些監(jiān)控都會(huì)直接影響正常服務(wù),服務(wù)用戶的質(zhì)量會(huì)下降,可能20臺(tái)機(jī)器宕了一臺(tái)機(jī)器,不會(huì)影響全部效果.所以,監(jiān)控的精準(zhǔn)性是一步步慢慢提高的.

文：楊超

文章出處：InfoQ

轉(zhuǎn)載請(qǐng)注明本頁網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/4460.html