從蘇寧十年技術演進，看架構意識轉變的關鍵一步

雙11狂歡結束后，又是一輪長期的技術復盤時間，這個階段往往是互聯網電商醞釀新一輪架構演進的契機。演進實踐中不僅需要解決大促遺留下的問題，還需要判斷新的設計是否能夠滿足未來發展的需要。如何朝著合適的架構演進以減少未來意想不到的坑和教訓，這往往是不少架構師需要深思熟慮的問題。

孫遷，蘇寧云商IT總部總監，擁有十多年IT系統規劃及研發工作，其中包括多年互聯網平臺的建設和研發管理經驗。前期主要負責企業內部內控系統的建設以及包括企業集成總線、短信平臺、監控平臺、以及基礎技術組件的研發工作。后續負責支撐銷售的核心交易系統的研發工作，其中包括購物車、訂單、價格、庫存、會員、促銷、尋源等系統。在高并發及大數據系統設計、運維及研發管理方面有豐富的經驗。

InfoQ：能否簡單回顧自己的工作經歷，從蘇寧云商近十年的演變過程中您如何看待未來短期乃至長期電商技術的發展？

孫遷：十多年前作為剛踏出大學校園的畢業生加入蘇寧，在這十多年中，有幸親身經歷了蘇寧的信息化歷程。從我個人經歷來看，主要經歷了以下三個階段：

1. 負責內控系統研發，使我對業務運作和管理方面有了很深入的積累；

2. 負責監控體系、服務治理、核心技術組件以及基礎平臺研發，這個過程中具備了堅實的技術能力以及持續治理和優化方面的能力；

3. 負責核心業務交易鏈路研發，這個階段對業務和技術的廣度有了很大的延伸。

科學技術是第一生產力，技術的發展很大程度上推動了業務的演進，同時業務的演進進一步促進技術往更高的層面發展，但是技術服務于業務的本質不會變化，電商行業的技術發展同樣類似。

InfoQ：能否簡單概括蘇寧十年架構演進內容？

孫遷：蘇寧核心系統的架構大概經歷了四次演進，大致的演進過程如下：

1. 線下連鎖店架構如下圖，銷售前端POS直連后端ERP，之間通過專線連接，這個階段的架構分前后端，前端負責展示及打印發票等部分必要的功能，后端ERP實現了核心交易邏輯，此階段的架構滿足了線下的快速開店。

2. 線上初期架構總體架構演變成了線下POS，線上WCS，后端ERP的架構。此階段實現了線上業務的快速上線，滿足了短期內的線上業務發展。但是后續如何保證系統的穩定性和擴展性成了很大的問題。

3. 前臺、中臺、后臺分離架構將核心邏輯從ERP中剝離，構建了中臺系統，其中包括訂單、庫存、會員等系統，一方面為ERP系統減壓，同時實現了多端協調、邏輯整合和一定層度上的快速擴展的目標。前中后化改造的本質沒有調整核心邏輯，僅僅是做了系統上的拆分，目標是提升系統擴展性及系統穩定性，業務復雜度沒有本質的改變，在交易過程中還需考慮復雜的后端業務邏輯，一定層度上導致了系統的不高效。

4. 平臺化架構平臺化架構主要是將自營店鋪化，同時考慮自營和商戶交易核心邏輯一致性，將自營業務核心邏輯后置，徹底的將后端管理與前端交易剝離，從而簡化前端交易邏輯，極大程度上提升了核心交易鏈路的擴展性和性能；同時前端WCS系統及后端各履約系統系統也進一步的拆分和重構，目標是提升整體系統的擴展性及性能，ERP僅僅保存財務部分的內容。

InfoQ：特別地，實體店的存在給系統架構演進帶來怎樣的影響？

孫遷：這是蘇寧最大的特色所在，雖然實體店及線上店最終的本質都是為了銷售而存在，但是實體店的運作方式和線上的運作方式還是有很大的不同之處。如何更好地利用目前的資源，做到最大程度的融合是蘇寧面臨和要解決的問題，而且基本上是沒有任何參考案例的，只能持續地摸索，不斷地總結，才能探尋出適合自己的路。

在業務方案及架構設計上必須要深入考慮這些特點，關注各種可能區分及融合的場景，需要我們比任何一個單一渠道的同行考慮地更多，從而設計出適合自身業務發展的系統架構。在交易鏈路上的各個環節，比如庫存、價格、尋源、促銷、會員、購物車及訂單都和同行有一定的差異，這些差異會給系統設計帶來 更多的輸入同時引入更多的可變因素 ，從而對架構設計提出了更高的要求。

為了應對渠道差異下的融合，同時為了更好地發揮線上線下的綜合能力，最終實現1+1>2的目標，單一渠道的分析思維不利于蘇寧發展，這么多年我們也在持續地摸索和總結，任何業務場景的分析都需要考慮到融合的特點。

InfoQ：能否簡單介紹蘇寧云商目前的核心交易系統，這套系統如何滿足多種業務形態的需求，在接下來的發展中還會有哪些調整和優化？

孫遷：蘇寧整體業務系統主要分為 前臺、中臺和后臺 三大部分，三個部分各司其職。

• 中臺主要負責核心交易系統及所依賴的核心業務系統的構建工作，其中包括但不限于庫存、價格、尋源、促銷、會員、購物車及訂單系統，基本上所有的業務都是運行在這些系統之上；

• 前臺則以這些系統提供的服務構建各種各樣的炫酷的產品。

這種松耦合的架構設計思路一方面可以盡可能地保證各個系統能夠快速應對自身業務的變化和新產品的快速發展，同時在錯綜復雜的業務場景下給系統性能及擴展能力提供了相對穩定的基礎。

就像通用處理器和專用處理器的區別，上述描述的中臺各系統構建出來了一個通用處理器，可以更好地適應業務的變化，但是也帶來了一些問題：比如特定場景下可能不是太高效。

舉個例子：我們在實現爆款搶購等高并發業務時采用了這種基礎業務組件和系統來構建，后面遇到了極大的性能問題，基本上很難保證此產品的使用及推廣。后續的架構選型更傾向于一個 簡單而高效的專用處理器 的設計理念，交易過程中的處理過程是完全不同的一條系統鏈路去支撐的，這條鏈路上的處理單元相對簡單，只做和其相關聯的必要的業務校驗邏輯及鏈路，去掉了很多無關的通用業務校驗和鏈路，甚至在邏輯部署上也是完全獨立的，但是這樣差異化的設計不代表會帶來差異化的用戶體驗。

其實問題的關鍵就是如何正確識別、選擇及設計“通用處理器”和“專用處理器”，在后續的發展過程中我們主要也會從以上方面去持續優化，以設計出可以更快速的應對業務變化且更高效的組件或者系統。

InfoQ：蘇寧云商計劃依靠數據做哪些決策，如何做到？能否從開發和用戶體驗兩方面談談目前大數據給蘇寧云商帶來了哪些影響和變化？

孫遷： 這是個很大的話題，從用戶行為、銷售預測、商品采購、庫存調撥、智能定價、定向推廣、促銷規劃、貨架擺放、運輸路線等各個環節都會依賴大量的數據分析以提升各個環節的運作效率，這里舉兩個例子：

• 拿個簡單的 “千人千面” 例子來講，不同的人登陸易購后看到不同的內容，這里面關聯的數據包括但不限于用戶行為、購物車、收藏夾、訂單等數據，綜合分析出了更適合或者用戶更喜歡的商品或者服務，這樣一方面簡化了用戶的選擇過程，同時帶來轉化率的提升；

• 另外我們上線了綜合業務決策平臺，內部稱呼為 “諸葛” ，這個以大數據為支撐的平臺可以極大地減少定價失誤，同時完善倉庫覆蓋以及對促銷分析及促銷建議等功能，給業務應對市場的快速變化提供了極大的數據支持和驅動。

InfoQ：關于庫存方面，在線上和線下的庫存分配平時是如何安排的，在大促時如何調整？是否存在動態調配方案來解決庫存分配不均的情況？

孫遷：蘇寧各銷售渠道的庫存是共享的，尤其隨著O2O的進一步探索和演進，對要求共享庫存的場景越來越多，如果連庫存都不能共享的話，則很難做到各渠道的融合。

具體的技術實現分兩種類型，一種是數據上 完全共享 ，另一種是 動態調撥 ，這兩種方式在蘇寧當前都存在。

拿動態調撥來說，基本實現原理是為不同渠道設置不同的預警閾值，超過閾值則觸發自動調撥操作。如何能更高效地進行調撥及如何能盡量減少調撥導致的渠道無貨或者貨物賣不出去的情況，這些需要結合著商品特性、銷量預測以及倉庫分布及輻射能力等情況去綜合分析，而不是單一地靠靜態庫存數量來進行調撥，這樣的話勢必會出現各種問題。經過了多年的優化和積累，目前蘇寧在庫存這方面基本不會存在庫存分配不均或者單渠道無貨的情況發生。

InfoQ：能否為大家總結蘇寧云商大促時容易出現哪些系統瓶頸，能否進一步地談談針對意想不到的大流量時，你們大促當日會有哪些應急手段？

孫遷：在高流量場景下，任何一個細微的問題或者瓶頸都有可能會引發巨大的故障。故我們從包括但不限于 物理層面 的鏈路流量、負載設備及機器計算能力等，到 中間件層面 的各種參數設置、 應用層面 的性能狀況以及 業務系統層面 等都會存在各種瓶頸和異常。

應對不同層面、不同場景的瓶頸處理方式既相同也不同，whatever，一套完整的監控體系是所有業務及系統穩定運行的根基，避免完全不清楚系統運行狀況的場景發生。目前我們在物理層、中間件層、應用層及業務層等各個層面都進行了大量的運行時數據采集，以及具備實時數據分析的功能，任何一點異常情況都會被立即發現并觸發不同的處理預案，定期會對系統的運維狀況進行巡檢及總結，同時在新系統上線前會進行多輪的功能、性能以及線上實際引流及放大回放測試等工作，絕大部分的問題都會在系統上線前被發現并解決。

嚴格來講所有的系統設計在一定程度上都會有一個上限，或者面臨各種“意想不到”的場景。比如網絡蜂擁或者其它超出了系統設計容量的場景，這個時候常見的處理方式會采用 業務降級 ，極端情況下會采用 流控 等策略去處理。簡單來講就是犧牲一部分業務或者用戶體驗來減少對系統性能的消耗，從而保證核心鏈路的穩定。

隨著能力的提升， 各種“意想不到”的場景往往會變成“假設存在”的場景被考慮 ，比如流量蜂擁，機器宕機，業務異常等。目前我們總結了幾千條異常場景，同時都會有對應的應急預案。一切的一切都是以快速恢復服務，減少對用戶的影響為最終目標，而不是當問題發生時再去思考如何解決問題，這樣會顯著加長問題的處理時間，會對業務及用戶帶來很大的傷害。

InfoQ：大促高并發下如何快速定位到錯誤發生點并解決？針對系統問題，能否介紹運維人員大促常用的預備方案？特別地，哪些預備方案是你們最關注并反復演練的？

孫遷：快速定位錯誤發生點的前提是要有完善的監控體系，這樣在事前或者事中可以快速發現異常，同時必須要持續積累和完善各種應急預案，知道異常發生時如何快速應對，這樣兩方面結合才能更快速解決問題。

我們其實沒有常用和非常用的應急預案例，往往概率越高的問題越會被重視，隨后慢慢演變成一個常態，也就無應急和非應急之分了。

給系統帶來最大的不穩定因素還是來自于各種偏門的場景，尤其是沒有預料到的場景。一切影響核心鏈路穩定的場景基本上我們都有反復演練，比如 關鍵及非關鍵業務系統宕機 等場景。

InfoQ：您在ArchSummit演講中將會提到“架構設計意識的轉變”，優秀的架構師應該具備怎樣的架構意識？能否結合自己十多年研發經驗提前為大家分享這個體會？

孫遷：經歷了這么多年的業務及系統設計經歷，讓我體會最深刻的一點是在不同時期及能力下對于問題處理的思路和邏輯的不同。

對于一個架構師來講，除了應該具備堅實的技術基礎，另一個非常重要的方面是需要 擁抱業務 ，同時對業務演進及外界環境變化具備極其敏銳的分析能力，這樣才能更好地洞察及適應業務的變化，同時才能設計出更適合支撐業務及考慮到后續業務變化的架構。

我經常會對我的團隊成員尤其是新加入團隊的成員打這樣一個比喻：農民兄弟知道種瓜得瓜種豆得豆，同時明白什么季節應該種瓜什么季節應該種豆，我們需要搞清楚的不僅僅是瓜和豆對刨地深淺的不同要求，同時要理解和知道為什么種瓜為什么種豆。 做一個全面的技術農民，而不是專業刨地的技術農民 ，這僅僅是意識轉變的第一步，也是最至關重要的一步！

同時我覺得架構沒有嚴格的對與不對，只有合適與不合適，結合業務發展需要考慮多方面因素，這樣才能可以很大程度上避免設計不足或者過度設計。

 

 

來自：http://www.infoq.com/cn/news/2016/11/suning-10-Architecture-conscious