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

來自蘇寧易購IT總部高級架構師王一硼給大家帶來題為《蘇寧易購O2O電商平臺的變遷之路》的演講，他把蘇寧早期傳統IT架構到互聯網架構的變遷做了一個回顧，并將自己在移動互聯網架構上的經驗做了分享。其中舉到一個蘇寧易購大促的例子，讓大家對架構師工作所要了解的知識面有了充分的理解。

現場實錄：

王一硼：大家好，我今天鉆進了一個華為的專場，都是華為的粉。我叫王一硼，現在在蘇寧易購消費者研發平臺，主要從事架構工作，涉及到跟架構相關的工作比較多。比如說架構優化，性能優化，網站的穩定性等等這些相關的工作。今天我給大家帶來的主題是蘇寧異購O2O電商平臺的變遷之路。今天這個演講主題會給大家介紹一個傳統企業怎么去改變它的IT架構，來適應互聯網時代的發展，有一個借鑒和方法論。

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

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

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

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

做這個SO化，大家都知道做SO化最主要的就是一個基礎服務。因為現在是面向服務了，不是像之前我是面向的套件開發的方案。蘇寧在做SO化，它在基礎服務上做了很多的研發。它都做了哪些工作呢?我大概的講一下，由于時間關系不可能講那么細。做服務化關鍵的就是要服務化框架。大家都知道現在業界比較有名的服務化框架(06：26)，是開源的。當然每個公司都有自己的，為什么蘇寧要作ISO這套服務框架呢，其實一些早期的架構大家都會用ESP，ESP的問題是它是集中式的，會有一個集中的代理點，代理點如果流量很大的話，傳輸的壓力是很大的。新的服務框架都是點對點的，我從一端到另一端，不會有一個中間的路由的過程，所以它減少了這個問題。

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

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

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

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

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

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

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

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

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

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

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

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

這是我演講的全部內容，時間有限，我就講這些。

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

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

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

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

提問：因為這是一個很大的系統，有分布式部署的，調用的時候是通過RSF，有可能一項動作會涉及到多個模塊一塊去協同，會涉及到一個分布式事務的問題。

嘉賓：分布式事務我們盡量不去用分布式事務來處理，現在互聯網模式都用異步的方案，或者一些補償的方案。舉個例子，我庫存的一些信息要去查后端的，我可能會發一些PO的消息，一些方式進行通知。當我發現前面已經進行了一些失敗的話，我可能再發一個進行刪除處理。因為有些情況互聯網公司沒必要做到完全的一致性，部分的一致性就可以了。

記者：就是基于補償的。

嘉賓：對，基于補償的方式。

記者：假設我生成了一條數據，接下來我會補償它，對不對?

嘉賓：對。

記者：假設這中間有一個時間段，這段時間假設我又操作了這個數據的話，會不會產生一種問題，就是我在補償之前操作了這個數據。

嘉賓：我們會有一個控制，在應用系統上進行一些處理方案，這是屬于應用系統里面內部的設計，肯定要控制這些關鍵點。我只是舉了一個例子，因為不可能講特別細，你要想講特別細的話，可能要拿一個真正的系統的架構方案，這樣會講一些細節性的東西。我今天主要展示一下一個互聯網企業要做的IT變革，有哪些東西要改變。

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

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

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

嘉賓：流控我們有兩層，第一層會有一個應用防火墻對總體的流控，第二個會每個對系統有一個策略流控。流控無非就是我超過每分鐘訪問多少次，bug多少次，這是跟(31：25)有點相似的。在應用防火墻前端大致做了一下，做了一個NG大量的，前端是進行控制的。同樣發現一些不對的時候，會進行一些丟棄或者一些處理。對于每個系統的時候，我們也會判定每個系統，有很多策略，比如說它的線程數，每個應用的線程數最大是多少，響應時間是多少，或者堵塞的情況下會進行一些控制和處理，一些策略。可能會自動化分析，同時后面會分析用戶行為軌跡，防止誤殺。現在很多流控誤殺的情況還是比較大的，所以在這方面要做一些細節。

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

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

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

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

提問：這里面有一點，蘇寧易購跟淘寶上面有一點區別，作為客戶來講你肯定就是認準蘇寧電器，你作為一個統家。但是在你的后臺也好，你的所有的庫存也好，你應該有一個總的調度調配的。

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

提問：技術上也可以做。

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

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

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

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

(結束)