2016年5月28日，華為開發(fā)者匯南京站在安德門黑馬路演中心圓滿落幕。本次沙龍議題增加到六個，時間安排上也從之前的半天擴(kuò)展到全天。講師有來自華為、蘇寧、途牛的多位好手，議題涵蓋”通訊即服務(wù)“、”內(nèi)源開發(fā)“、”探索性測試“、”容器技術(shù)”、“電商平臺遷移”、“訂單架構(gòu)優(yōu)化”。

來自蘇寧易購IT總部高級架構(gòu)師王一硼給大家?guī)眍}為《蘇寧易購O2O電商平臺的變遷之路》的演講，他把蘇寧早期傳統(tǒng)IT架構(gòu)到互聯(lián)網(wǎng)架構(gòu)的變遷做了一個回顧，并將自己在移動互聯(lián)網(wǎng)架構(gòu)上的經(jīng)驗做了分享。其中舉到一個蘇寧易購大促的例子，讓大家對架構(gòu)師工作所要了解的知識面有了充分的理解。

現(xiàn)場實錄：

王一硼：大家好，我今天鉆進(jìn)了一個華為的專場，都是華為的粉。我叫王一硼，現(xiàn)在在蘇寧易購消費(fèi)者研發(fā)平臺，主要從事架構(gòu)工作，涉及到跟架構(gòu)相關(guān)的工作比較多。比如說架構(gòu)優(yōu)化，性能優(yōu)化，網(wǎng)站的穩(wěn)定性等等這些相關(guān)的工作。今天我給大家?guī)淼闹黝}是蘇寧異購O2O電商平臺的變遷之路。今天這個演講主題會給大家介紹一個傳統(tǒng)企業(yè)怎么去改變它的IT架構(gòu)，來適應(yīng)互聯(lián)網(wǎng)時代的發(fā)展，有一個借鑒和方法論。

我們言歸正傳，我將會在三個方面為大家闡述一下。第一個是架構(gòu)演變。蘇寧早期的架構(gòu)是由Commerce+SAP這套架構(gòu)來提供線上的電商服務(wù)的。這套架構(gòu)有什么優(yōu)勢呢，它是套件的，對電商基本的功能是能夠快速定制開發(fā)的。我記得在2004年時候主要推的，快速的實現(xiàn)很多線上的部署。隨著業(yè)務(wù)的發(fā)展，這套架構(gòu)已經(jīng)不能滿足我們業(yè)務(wù)的需求了，隨著業(yè)務(wù)量的增加，我們訪問量越來越大，這套架構(gòu)它的擴(kuò)展性，它的能力已經(jīng)不能滿足我們線上的需求。

有哪些問題呢，這里列了一下，比如說它的(02：07)。舉個例子，蘇寧在前幾年的時候發(fā)布一個版本，因為它早期是Commerce的套件，那個套件可以要達(dá)到1G，下面一個1G的代碼量，開發(fā)人員查代碼都很困難，所以發(fā)布的時間非常長，基本是一個月迭代一次到兩次的周期。這種效率是無法滿足互聯(lián)網(wǎng)的短平快的發(fā)展需求。第二個系統(tǒng)的維護(hù)性差，Commerce內(nèi)部集合了很多的功能，比如像訂單、會員、一些基本的促銷、商品等等一些功能。它想改一個服務(wù)，他買的商業(yè)的版本，套件的東西，涉及到里面的一些技術(shù)要去制定一些IBM的什么，維護(hù)成本特別高。舉個例子，蘇寧現(xiàn)在想拿這個Commerce開發(fā)易購上面一個知名的服務(wù)，就是拍賣，你可以想象這是完全無法做到的，所以這個問題很嚴(yán)重。

第二個它是一個整個的大包，沒辦法進(jìn)行一個垂直化拆分。因為成本高，基本你買的一套套件，都要買IBM的整合套件，擴(kuò)展性差。還有大促期間經(jīng)常會出問題，經(jīng)常系統(tǒng)持續(xù)提供的一些核心穩(wěn)定會掛掉，所以這套系統(tǒng)已經(jīng)無法滿足我們業(yè)務(wù)的發(fā)展了。

蘇寧好的一些業(yè)務(wù)，一些主流的業(yè)務(wù)架構(gòu)，還有符合我們自身業(yè)務(wù)發(fā)展的，對我們的架構(gòu)進(jìn)行了自動化拆分。蘇寧做自動化拆分是怎么做的呢，首先會對我們系統(tǒng)進(jìn)行前中后三個平臺的劃分。前臺基本都是一些展示類的處理，這樣前端可以敏捷化開發(fā)，小團(tuán)隊作戰(zhàn)。比如說蘇寧是四端融合，哪四端呢，PC端，POS端，APP端，還有門店端，這四端融合，每一個端的業(yè)務(wù)需求展示都不一樣。所以我們在前臺相當(dāng)于四個結(jié)構(gòu)的，所以每一端它的展示可以快速的迭代。中臺我們是大中臺的服務(wù)，主要提供一些基礎(chǔ)服務(wù)能力，比如上面提供一些商品信息的查詢，提供一些價格的查詢，這些我們進(jìn)行一個中臺化的處理，保證對外部提供一些穩(wěn)定的服務(wù)。后臺是一些數(shù)據(jù)的管理，我們有一些大數(shù)據(jù)平臺，還有前臺、中臺產(chǎn)生一些數(shù)據(jù)進(jìn)行分析處理，來為前中臺進(jìn)行一些數(shù)據(jù)的支持。

做這個SO化，大家都知道做SO化最主要的就是一個基礎(chǔ)服務(wù)。因為現(xiàn)在是面向服務(wù)了，不是像之前我是面向的套件開發(fā)的方案。蘇寧在做SO化，它在基礎(chǔ)服務(wù)上做了很多的研發(fā)。它都做了哪些工作呢?我大概的講一下，由于時間關(guān)系不可能講那么細(xì)。做服務(wù)化關(guān)鍵的就是要服務(wù)化框架。大家都知道現(xiàn)在業(yè)界比較有名的服務(wù)化框架(06：26)，是開源的。當(dāng)然每個公司都有自己的，為什么蘇寧要作ISO這套服務(wù)框架呢，其實一些早期的架構(gòu)大家都會用ESP，ESP的問題是它是集中式的，會有一個集中的代理點(diǎn)，代理點(diǎn)如果流量很大的話，傳輸?shù)膲毫κ呛艽蟮摹Ｐ碌姆?wù)框架都是點(diǎn)對點(diǎn)的，我從一端到另一端，不會有一個中間的路由的過程，所以它減少了這個問題。

蘇寧要做服務(wù)框架，當(dāng)時也討論了很多問題，我是用開源的，還是用自己的，其實最后還是用自己的研發(fā)的。為什么呢，其實服務(wù)化里面最重要的要知道它有一個管理，就是我服務(wù)治理的問題。(07：16)可能治理有一套服務(wù)治理，但是真正產(chǎn)生數(shù)據(jù)，比如某個借口的訪問量是多少，我怎么控制它的流量，這些都是要經(jīng)過我們二次定制化開發(fā)的，或者我要跟周邊的基礎(chǔ)組件進(jìn)行一些交互的，一樣還是要進(jìn)行開發(fā)的。比如說我們要有一個調(diào)量監(jiān)控，APM，這種文化我們能夠要嵌入到服務(wù)化框架里面去看看每個東西的響應(yīng)時間狀態(tài)，這些信息我們必須要定制這一塊IF框架。

數(shù)據(jù)層我們有自己的數(shù)據(jù)層框架，現(xiàn)在蘇寧的數(shù)據(jù)庫基本全部遷移到MySQL存儲的方案。我會有一個中間層，中間層提供一個分庫分表的處理，動態(tài)數(shù)據(jù)遷移。比如在一個老的機(jī)器，從DB2，或者從原來一個老架構(gòu)的方案上可以進(jìn)行一個動態(tài)數(shù)據(jù)處理，或者動態(tài)擴(kuò)容的。還有一個(08：33)，這個很關(guān)鍵，很多開發(fā)人員寫SQL的時候并不了解SQL的時候性能，你為了避免這些產(chǎn)生的事故，我們都會進(jìn)行一些控制，有SQL怎么支持，或者管理SQL，這是中間件。

分布式緩存，互聯(lián)網(wǎng)公司大家都知道緩存很關(guān)鍵，每次大促，搶購，都是靠緩沖來支撐過去的。蘇寧在分布式緩存是基于Redis的一個集群上面進(jìn)行改造，還有一些分級的處理，分級緩存，或者是熱點(diǎn)數(shù)據(jù)緩存。舉個例子，蘇寧的商店信息等一些重點(diǎn)信息，因為數(shù)據(jù)量很大，要快速的提供給用戶，可能會對某一些數(shù)據(jù)進(jìn)行存儲，分級緩存。這樣靠Redis的內(nèi)存是放不下的，所以我們自己研發(fā)了一個方案，可以在熱點(diǎn)上進(jìn)行內(nèi)存，有些可以在磁盤上取。Redis有一些磁盤的存儲方案，但是性能是很差的，所以我們進(jìn)行一個改造。還有一些分布式的文件系統(tǒng)，蘇寧的一些靜態(tài)資源，圖片啊，還有蘇寧云，都是及上集成商。還有自己的私有云，私有云提供了蘇寧快速的部署，快速的擴(kuò)容，這樣一些功能。還有一些大數(shù)據(jù)平臺，對我們后端數(shù)據(jù)處理，對前端進(jìn)行一些提供。還有一些持續(xù)集成平臺，這是我們發(fā)布、降級一般都需要人為的發(fā)布，手工的發(fā)布。蘇寧在這方面研發(fā)了自己的持續(xù)發(fā)布平臺，開發(fā)人員在這方面發(fā)布的成本大大降低。我們還有一個全鏈路的監(jiān)控，剛才說過了ATM，還有對每個節(jié)點(diǎn)等的一些監(jiān)控。

這是我們RSF的一些架構(gòu)圖，是二期的一個角度，現(xiàn)在已經(jīng)改變了。但是方案都差不多，其實都一樣，一個服務(wù)交付到一個提供端，IT數(shù)據(jù)的架構(gòu)。關(guān)鍵的問題是對數(shù)據(jù)的查詢，因為每個服務(wù)分發(fā)和調(diào)度的一些數(shù)據(jù)表進(jìn)行一些采集和控制，進(jìn)行管理。大致就是這些功能，大家看一下(圖)。這是蘇寧的私有云，提供持續(xù)集成、動態(tài)部署這些功能。界面，比如部署一套環(huán)境的話是這樣做的。還有監(jiān)控剛才也說過了，從端到端的，整體鏈路的監(jiān)控。

剛才講的是傳統(tǒng)架構(gòu)或者說發(fā)展一個互聯(lián)網(wǎng)公司架構(gòu)的一些概括。下面我再強(qiáng)調(diào)一下，因為現(xiàn)在已經(jīng)進(jìn)入了移動互聯(lián)網(wǎng)時代，移動互聯(lián)網(wǎng)時代和以前的互聯(lián)網(wǎng)時代還有一些區(qū)別，我們可能在這方面碰到了一些問題，解決了一些問題。第一個，現(xiàn)在劫持是很嚴(yán)重的，像阿里的做全端的DNS，百度最早也做的全端的DNS。蘇寧做反劫持的時候是怎么做的，它在AP端是有一個相關(guān)模塊的。首先劫持分兩部分，第一個是DNS劫持，第二個是內(nèi)容劫持。DNS劫持我們通過APP端里面的模塊，自動的會判斷查找那個localDNS，蘇寧有一個自己的APPDNSserver的服務(wù)。它會判斷你這個分配的IP第一個對不對，不對我就給你一個正確的IP。第二個我能提供一個最優(yōu)的全體節(jié)點(diǎn)鏈路的查找，這樣可以減少鏈路的訪問端，提高一些性能，這是我們反劫持做的。

蘇寧內(nèi)容劫持，雖然我們已經(jīng)在做了，估計蘇寧也會在互聯(lián)網(wǎng)當(dāng)中做到全端的內(nèi)容APS。其實內(nèi)容劫持有幾方面，第一個是在PC端，在PC端沒有辦法(14：13)。移動端有兩個方案，你可以把你的請求進(jìn)行一些非APP化，因為在移動端APP這種請求根本不是移動端的問題，可以進(jìn)行一些自己協(xié)議的處理，或者是APS化。這樣內(nèi)容劫持無非就是標(biāo)記你的域名，他是標(biāo)記不到的，可能就劫持不了了。

蘇寧在內(nèi)容智能分發(fā)上，現(xiàn)在大家都知道你訪問每一個手機(jī)，型號都不一樣的，圖片大小合適肯定都不一樣。第一是圖片大和小的問題，傳遞一個大圖片的話，數(shù)據(jù)大，性能也不是很好。蘇寧這塊在資源的配置上會進(jìn)行一些預(yù)熱，預(yù)熱之后我會自動的分發(fā)，做成不同的格式，當(dāng)APP發(fā)起的時候，判斷你APP的手機(jī)型號，我會給你分發(fā)不同的東西。

還有一個是移動端，APP大家都知道，它跟PC端有點(diǎn)不一樣的是，APP端請求數(shù)是有控制的，不像PC瀏覽器一樣，早期IE可能有，現(xiàn)在谷歌等瀏覽器在這方面是很好的，但是移動端是有控制的。在這方面我們做了一個獨(dú)立接入，對后端系統(tǒng)進(jìn)行一些請求的合并，同時本地帶一些緩存，我們有一級緩存和二級緩存。第一個就是介紹域名和查詢，第二個發(fā)請求合并，可以滿足我APP，盡量控制那個請求數(shù)，保證APP性能，這是我們做的一定的優(yōu)化。我覺得其中的技術(shù)主要是ngx+lua的方式，lua大可能是一個攜程，攜程在這方面性能是很好的。

做了這些事情，怎么能夠保證這套架構(gòu)真正能滿足我們的業(yè)務(wù)需求呢。其實大促才是見證我們系統(tǒng)能力的關(guān)鍵。蘇寧是怎么做大促保障的呢，第一個我們會有自己的系統(tǒng)巡檢，我們會有自己的系統(tǒng)巡檢工具。系統(tǒng)巡檢工具會在大促之前，比如前兩個禮拜做專門的系統(tǒng)巡檢，測各項指標(biāo)都會進(jìn)行判斷，用自動化工具來判斷。同時進(jìn)行(17：25)，來判斷這個系統(tǒng)是不是穩(wěn)定。第二個我們要分析整個大促的核心業(yè)務(wù)鏈，我會通過用戶的訪問模型，分析出，比如說我估計這個大促從那條鏈路能夠進(jìn)來。舉個例子，我們從首頁，整個要經(jīng)過這些系統(tǒng)。每個都是小單元的系統(tǒng)，每個系統(tǒng)是不是能夠承載這些能力，我會找到一些系統(tǒng)短板，進(jìn)行一些優(yōu)化和擴(kuò)容。比如我們可能在雙十一之前進(jìn)行一些小的促銷的時候，在流量引入的時候，發(fā)現(xiàn)我購物車容量是不夠的，通過我們的私有云平臺可以自動化。

還有很關(guān)鍵的就是容量評估，做大促的話，業(yè)務(wù)肯定會給你一個指標(biāo)，我今天要做一個大促，相當(dāng)于日常訪問量的10倍、20倍，上百倍。這個業(yè)務(wù)指標(biāo)就是我們要保證這個系統(tǒng)是不是能承載一些請求量，這個就是做容量評估。首先我要知道我的系統(tǒng)能夠承載的量是多少，現(xiàn)在系統(tǒng)在的水位是多少。這個怎么做呢，我們通過一些壓測的方案。壓測現(xiàn)在比較流行的是，一個是引流壓測，蘇寧有自己的引流壓測的方案，我們會在每個系統(tǒng)上，把流量引入到我們的生產(chǎn)，或者是同類型的(19：31)環(huán)節(jié)，進(jìn)行一個定時放大或者同時放大的測試，看看是不是能夠真正滿足業(yè)務(wù)的需求。這個引流壓測有什么優(yōu)點(diǎn)呢，第一個它是真實的用戶流量，不是通過測試偽造的，完全是相當(dāng)于同一個用戶，可能訪問一次，并發(fā)的訪問十多次或者上百次的請求。當(dāng)然大部分主要是在讀層，寫商品的話不可能把用戶同時寫，我們下一個訂單，下一百個訂單，肯定是不行的，在引流壓測的時候有一些控制。這是我們自研的一套引流壓測平臺，現(xiàn)在已經(jīng)提升到web平臺上去了。它的體系就是我在系統(tǒng)抓包，把一個相關(guān)的請求進(jìn)行IP放大。早期網(wǎng)易有一套(20：29)，我們當(dāng)時也拿過來研究過，發(fā)現(xiàn)不能滿足我們的業(yè)務(wù)需求。某些域名直接打到我們的生產(chǎn)環(huán)節(jié)，這是我們整個研發(fā)的內(nèi)部結(jié)構(gòu)，主要是(20：58)，性能也比較高，進(jìn)行一個測試。在IP層有(21：05)，三臺機(jī)器最大的承載能力是在五千KPS，超過五千的話會有一些丟包。但是從我們這么多經(jīng)驗來看，三臺機(jī)器很少能超過五千的KPS，我說的是虛擬環(huán)境，不是實體。

還有一個是寫上去的壓測，寫上去的壓測我們用自己的壓測工具和平臺。因為開元和商業(yè)的是不能完全滿足我們需求的，內(nèi)部協(xié)議是不一樣的，要進(jìn)行一些接口級的壓測評估，從前端請求各方面的壓測，我們有自己的研發(fā)的壓測平臺來進(jìn)行處理。還有個關(guān)鍵的，因為你在大促當(dāng)天數(shù)據(jù)是準(zhǔn)備好的，不能進(jìn)行任何改變。你不能說現(xiàn)在發(fā)現(xiàn)問題，我來改動。怎么辦呢，我們每個要進(jìn)行一些應(yīng)急預(yù)案的處理，比如預(yù)先我們要考慮到這個系統(tǒng)假設(shè)會出現(xiàn)某些問題，比如我碰到了DNS攻擊，碰到了大量黃牛軟件的刷單，這些情況我們要怎么樣去處理。當(dāng)然我們可以通過測試工具模擬測試，考慮一些應(yīng)急預(yù)案。首先我們會跟系統(tǒng)進(jìn)行一個分級，比如一級、二級、三級的系統(tǒng)，對不同的系統(tǒng)會有不同的降級方案，比如購物車?yán)锩婺骋粋€功能進(jìn)行降級，它可能是次級服務(wù)，不影響我整個下單的流程。為了保證整個系統(tǒng)的正常，我們會進(jìn)行一些控制，或者我進(jìn)行一些流控。同時我們還有現(xiàn)場決策，判斷這個時候是不是一定要觸發(fā)這個預(yù)案。

還有什么都不可控了，我們在最后一道圖，會有一個流控平臺，每一個系統(tǒng)都會接入流控，對每個系統(tǒng)請求的狀態(tài)會進(jìn)行一個判定。大家都看過小米、阿里都有流動平臺，自己在搶單的時候比較忙或者什么，其實就是觸發(fā)了規(guī)則。我們蘇寧也一樣，也有流控平臺，通過我們在前端數(shù)據(jù)收集之后，判定是否能夠觸發(fā)，會推出前端的控制。同時我們會進(jìn)行針對觸發(fā)流控的用戶，他的一些行為，我們會分析他的頁面訪問軌跡，他是不是從某些頁面進(jìn)的，我來判定他是不是一些黃牛行為，防止一些誤傷。因為一些黃牛直接就刷訂單的接口，刷重點(diǎn)的一些對他有利益的接口，這是我們的流控。這是我們在雙十一時候解決一些頂點(diǎn)峰值的時候控制，我們有效的控制流量的高峰，削峰的時候，判定大量的黃牛來刷，保障系統(tǒng)是穩(wěn)定的。

這是我演講的全部內(nèi)容，時間有限，我就講這些。

提問：在線測試除了傳統(tǒng)有一些被動的測試，比如性能指標(biāo)，或者是磁盤的問題，被動測試，你的在線測試還有哪些保證我系統(tǒng)是正常的?

嘉賓：在線剛才提到了，我們有自己的監(jiān)控平臺，監(jiān)控平臺要了解一下API，API這個領(lǐng)域是整個調(diào)用鏈。因為SO是完全提供服務(wù)的，我壓測一個系統(tǒng)，可能不會只對這個系統(tǒng)產(chǎn)生一些問題，可能會對后端有。比如我壓測我的購物車，購物車可能會調(diào)不同的服務(wù)等等。是不是會給庫存帶來很大的壓力，我們會有自己監(jiān)控的APM平臺，會判定這個指標(biāo)，當(dāng)它達(dá)到多少值的時候，尤其達(dá)到60%，我這時候就預(yù)警了，它的請求的時間不長的時候，我已經(jīng)預(yù)警。等等一些判定的指標(biāo)，我們每個系統(tǒng)都會進(jìn)行控制的?，F(xiàn)場寫流量主要還是一個工具，像我剛才說的用戶流量大部分都是讀，你只要把寫引進(jìn)來的話，你下一個單，下十個單，我買十個商品肯定是不同意的。所以寫的話是模擬一些用戶的。為什么我們要自研一些工具呢，我們內(nèi)部的一些協(xié)議是不同的，不可能用RLO的協(xié)議，肯定跟你外部的APP的協(xié)議是不一樣的。你用你的開源工具肯定是不支持的，還有一些測試的案例等等我會有收集管理。所以在這方面自研了一套方案。

提問：你們自研的RCF跟Double，跟他們比較的話有什么優(yōu)勢，或者說RCF有沒有借鑒Double的一些設(shè)計思想?

嘉賓：我覺得做服務(wù)框架最主要的就是三個方面，第一個就是服務(wù)的消費(fèi)者，第二個是服務(wù)的提供商，第三個就是服務(wù)的管理和控制，就是調(diào)用。這三個方面是基本的元素，基本上任何一個服務(wù)框架都會有，但問題為什么要自研呢，它在數(shù)據(jù)流轉(zhuǎn)過程中產(chǎn)生一些數(shù)據(jù)和控制。舉個例子，像我剛才說的，我現(xiàn)在想去判定某個系統(tǒng)的響應(yīng)時間，比如說我從購物車調(diào)我的庫存服務(wù)，庫存服務(wù)的一個響應(yīng)時間是超過多長，超過多少秒，或者調(diào)用量是多少。我完全用Double的話，我可能調(diào)一個接口，或者寫一個二次開發(fā)，這個分析我們是要通過自研處理的。你可能要了解一下為什么阿里不用Double，他用HLF，他其實內(nèi)部嵌了很多框架在里面，比如它的ACF就嵌了ATF監(jiān)控的數(shù)據(jù)，這些數(shù)據(jù)一樣要抽出來的。如果只是一些基本的服務(wù)控制和管理的話，可能能滿足你的需求。但是如果你有一些特定需求的時候，可能就不行了。

提問：因為這是一個很大的系統(tǒng)，有分布式部署的，調(diào)用的時候是通過RSF，有可能一項動作會涉及到多個模塊一塊去協(xié)同，會涉及到一個分布式事務(wù)的問題。

嘉賓：分布式事務(wù)我們盡量不去用分布式事務(wù)來處理，現(xiàn)在互聯(lián)網(wǎng)模式都用異步的方案，或者一些補(bǔ)償?shù)姆桨?。舉個例子，我?guī)齑娴囊恍┬畔⒁ゲ楹蠖说?，我可能會發(fā)一些PO的消息，一些方式進(jìn)行通知。當(dāng)我發(fā)現(xiàn)前面已經(jīng)進(jìn)行了一些失敗的話，我可能再發(fā)一個進(jìn)行刪除處理。因為有些情況互聯(lián)網(wǎng)公司沒必要做到完全的一致性，部分的一致性就可以了。

記者：就是基于補(bǔ)償?shù)摹?/p>

嘉賓：對，基于補(bǔ)償?shù)姆绞健?/p>

記者：假設(shè)我生成了一條數(shù)據(jù)，接下來我會補(bǔ)償它，對不對?

嘉賓：對。

記者：假設(shè)這中間有一個時間段，這段時間假設(shè)我又操作了這個數(shù)據(jù)的話，會不會產(chǎn)生一種問題，就是我在補(bǔ)償之前操作了這個數(shù)據(jù)。

嘉賓：我們會有一個控制，在應(yīng)用系統(tǒng)上進(jìn)行一些處理方案，這是屬于應(yīng)用系統(tǒng)里面內(nèi)部的設(shè)計，肯定要控制這些關(guān)鍵點(diǎn)。我只是舉了一個例子，因為不可能講特別細(xì)，你要想講特別細(xì)的話，可能要拿一個真正的系統(tǒng)的架構(gòu)方案，這樣會講一些細(xì)節(jié)性的東西。我今天主要展示一下一個互聯(lián)網(wǎng)企業(yè)要做的IT變革，有哪些東西要改變。

提問：咱們蘇寧這邊的分布式文件系統(tǒng)是哪一個?

嘉賓：也是自研的，具體我這個也不太清楚，好像是原來一個華為的人過來搞的。

提問：剛才咱們說到流控，是在你剛才說的同步之前，還是在應(yīng)用層之前?

嘉賓：流控我們有兩層，第一層會有一個應(yīng)用防火墻對總體的流控，第二個會每個對系統(tǒng)有一個策略流控。流控?zé)o非就是我超過每分鐘訪問多少次，bug多少次，這是跟(31：25)有點(diǎn)相似的。在應(yīng)用防火墻前端大致做了一下，做了一個NG大量的，前端是進(jìn)行控制的。同樣發(fā)現(xiàn)一些不對的時候，會進(jìn)行一些丟棄或者一些處理。對于每個系統(tǒng)的時候，我們也會判定每個系統(tǒng)，有很多策略，比如說它的線程數(shù)，每個應(yīng)用的線程數(shù)最大是多少，響應(yīng)時間是多少，或者堵塞的情況下會進(jìn)行一些控制和處理，一些策略?？赡軙詣踊治?，同時后面會分析用戶行為軌跡，防止誤殺。現(xiàn)在很多流控誤殺的情況還是比較大的，所以在這方面要做一些細(xì)節(jié)。

提問：了解蘇寧(32：32)的應(yīng)用。

嘉賓：剛才我也提到了蘇寧在DB中間站在會實現(xiàn)，我也在主推。還有剛才的引流壓測，這個都是做很多性能測試的。我個人還是比較推崇GO，因為我覺得JAVA這兩年發(fā)展太快了，尤其在攜程這塊做的基本沒有什么推進(jìn)，被甲骨文收購了，幾乎天天跟谷歌打仗，不是一個IT人要做的事情。GO我覺得它現(xiàn)在在1.5到1.6的穩(wěn)定性是很好的，而且它現(xiàn)在貢獻(xiàn)非常大，我覺得它有點(diǎn)像JAVA1.5之后的發(fā)展趨勢。像Docker夜襲夠?qū)崿F(xiàn)的，所以可以建議大家去研討，研究一下，這個還是比較好的。

提問：我是去年因為裝修在你們蘇寧易購上采購了一個電器，因為我在南寧，電器分配的時候是在山東那邊，對客戶來講要快，第二個是價格上面。后來山東的商家就講，他說我暫時沒有這個產(chǎn)品，又從其他調(diào)度。我想問一下，像你們在數(shù)據(jù)分配上面，哪個路線在哪里。

嘉賓：蘇寧這塊涉及到庫存的問題，我會根據(jù)你的手機(jī)APP查你當(dāng)?shù)氐膸齑妫蛘吒鶕?jù)你的收貨地址進(jìn)行一個判定，這是一個。第二個我不你剛才說的是西店還是自營的，自營的是這套規(guī)律，西店的話就不一樣了，西店的話就是商家那一塊，可能就涉及的比較復(fù)雜了。自營我們是就近原則，根據(jù)你的IP地址的信息，或者你收貨的信息進(jìn)行控制。這也是我們B2C和C2C的區(qū)別，在這方面性能是要有很大提升的，我們也做了一些處理。

提問：這里面有一點(diǎn)，蘇寧易購跟淘寶上面有一點(diǎn)區(qū)別，作為客戶來講你肯定就是認(rèn)準(zhǔn)蘇寧電器，你作為一個統(tǒng)家。但是在你的后臺也好，你的所有的庫存也好，你應(yīng)該有一個總的調(diào)度調(diào)配的。

嘉賓：這個涉及到管理層的事情，不是技術(shù)上能處理的事情。

提問：技術(shù)上也可以做。

嘉賓：技術(shù)上也可以做，你要知道跟后端打通很多的事情。像淘寶也一樣，有些服務(wù)，像他調(diào)銀行，銀行掛了，不保證你質(zhì)量，我也說支付寶有問題，這些有時候是管理上的事情。

提問：我看你們緩存用Redis，你們在Redis上需求開發(fā)了哪些功能?

嘉賓：Redis有一個好處，就是它的性能很好，性能是非常高效的，單擊到兩三萬簡單的命令是沒有問題的。它有最大的問題就是存儲，內(nèi)存是很貴的，你不可能買幾百G的內(nèi)存。第二存量量大的時候性能也會下降，這是一個問題。蘇寧有很多的數(shù)據(jù)量比較大的時候，又要使用到緩存，這種怎么解決。我們會在技術(shù)上進(jìn)行一個綁定，比如我會有一個熱點(diǎn)數(shù)據(jù)內(nèi)存去Redis，非熱我可能會讀硬盤。完全靠Redis，畢竟有一套存儲方案，但是那個存儲方案你可以去研究一下，會要很大的性能。所以這方面我也會改造，你可以看一下京東的Redis，他在這方面也有一些處理。

主持人：如果沒有其他問題的話，我們就掌聲謝謝王一硼老師。

(結(jié)束)