蘇寧雙11超級工程排頭兵—會員系統架構演進

每年雙十一，不僅是剁手族的狂歡節，更是各大電商技術團隊技術水平與技術創新實踐檢驗的舞臺，不斷創新高的銷售額、交易峰值、支付峰值，這些驚人數字的背後都離不開強力的技術支撐。IT168希望透過技術報導的形式向讀者揭秘各大電商平臺在雙十一這一“超級工程”背後的鉅額投入與技術創新，讓更多人瞭解技術，尊重技術，促進同行業之間的技術交流分享，推動提高行業整體技術水平。

　　本文摘要：

　　2017年11月1日，蘇寧易購線上上線下率先引爆雙十一全民購物狂歡節，線上銷售不到110秒就已突破億元，11月3日展開的線下超級團購日，銷售額突破歷史單日最高銷售記錄，客流量暴增126%，可謂在今年的雙十一前哨戰中打響了“開門紅”的第一炮。

　　經歷了8年瘋狂發展的雙十一，對各大電商平臺來說已經不再只是單純的消費數字比拼，背後技術實力的較量才是真正的重頭戲。但技術上的準備不是一蹴而就的，需要長期的積累和演變。歷經多年大促洗禮的老兵蘇寧在雙十一技術準備方面已然變得遊刃有餘，本文以會員系統為例，回首過去會員系統經歷了哪些變遷，展望未來會員系統又將向著哪些方向邁進?

　　作者：孫遷 龔鋼

　　孫遷，蘇寧雲商 IT總部總監，擁有十多年 IT 系統規劃及研發工作，其中包括多年網際網路平臺的建設和研發管理經驗。前期主要負責企業內部內控系統的建設以及包括企業整合匯流排、簡訊平臺、監控平臺、以及基礎技術元件的研發工作。後續負責支撐銷售的核心交易系統的研發工作，其中包括購物車、訂單、價格、庫存、會員、促銷、尋源等系統。在高併發及大資料系統設計、運維及研發管理方面有豐富的經驗。

　　龔鋼，擁有十多年軟體開發和架構設計經驗，曾任IBM顧問時服務於蘇寧易購，現擔任蘇寧雲商IT總部高階架構師，全面負責蘇寧O2O會員融合的中臺系統。親歷了蘇寧前中後臺架構分離及會員系統垂直切分的演變，推動參與了會員中臺、商品中臺、訂單中臺及統一支付系統的建設工作。在架構設計、系統切換演進、系統平臺化方面有很深的思考和領悟，現正和研發團隊一起建設會員相關平臺系統的多活部署，持續最佳化系統效能，保障系統穩定。

　　正文：

　　1990年創業至今的28年間，蘇寧不僅完成了從線下零售商向O2O網際網路企業的轉型，而且擁有云商、置業、文創、金融、投資、體育產業集團。蘇寧始終堅持“店商+電商+零售服務商”的概念，以雲技術為支撐，以開放平臺為架構，全力打造融合線上線下，開放前臺後臺的雲商模式。

　　與以往的雙十一不同，今年的雙十一不僅是蘇寧智慧零售從概念到落地的第一次大考，也是一場線上線下融合、六大產業協同的“大閱兵”。而會員系統作為全產業融合的核心，自然也就站在了雙十一技術保障排頭兵的位置上。

　　為了保障雙十一大促期間的業務，蘇寧會員系統做了以下籌備工作：根據預估的業務量、歷年訪問行為及壓力分佈等情況對系統進行容量評估，並進行擴容;進行生產環境全鏈路效能測試，發現並解決各種潛在的效能瓶頸;持續更新並完善應急預案，以應對各種異常場景;對參與大促監控的人員進行全面培訓及實戰，精簡彙報線，減少異常處理時間。

　　任何的技術準備都不是一蹴而就的，需要長期的積累和演變，蘇寧會員系統也不例外。隨著業務的不斷快速發展，2005年上線的蘇寧會員系統也在這10多年間經歷了從初期架構到易購會員系統，再到系統垂直切分，以及現在同城雙活這四個階段的不斷演進。

　　目前蘇寧會員業務模組主要由賬號資料、等級、賬戶、雲鑽引擎以及會員報表組成 。

　　支援線下門店，蘇寧會員系統的初期架構

　　蘇寧的業務初期主要集中線上下門店，門店銷售系統採用的是CS架構，各門店安裝客戶端軟體，服務端使用IIS作為應用伺服器。基於windows平臺提供視覺化介面進行操作，客戶端透過TCP協議與服務端通訊，服務端再透過ODBC協議與sybase資料庫進行互動。同時服務端應用也分為給客戶端提供服務的前臺模組和提供給系統管理員使用的後臺模組。

　　該架構支撐了蘇寧早期的線下門店銷售，但是隨著門店數量的增加，該架構逐漸出現效能瓶頸。與此同時，蘇寧開始擴充了線上銷售業務，交易量的增加導致系統壓力急速增加。而此時的系統已經很難進行擴充套件和改造，對業務的支撐舉步維艱，直接限制了業務的增長。

　　會員系統只是整個POS系統中的一個模組，需要與其他模組緊密耦合在一起，所以對會員系統的任何一處調整都要考慮對其他模組的影響。由於涉及面很廣，所以有時只需釋出一個很小的功能，卻不得不進行測試的全場景迴歸，併發布整個系統，不僅需求的響應週期很長，同時研發團隊的運作效率也很低。

　　另外，由於各模組對應的業務功能不同，無可避免的會出現模組之間訪問量的差異，呈現到系統層面就是模組對硬體資源需求的差異，所以不得不根據資源消耗最大的模組來決定整個系統所需的資源，直接導致了硬體資源的浪費。

　　基於上述問題，蘇寧必須對整套銷售及其關聯絡統進行重構，同時獨立構建新的會員系統，並使用高擴充套件、高效能的技術和框架實現業務功能。但此時蘇寧的IT技術能力比較薄弱，不足以獨立搭建理想的系統，所以選擇了與外部廠商進行合作，購買其硬體裝置和軟體系統，並與其開發人員合作共同研發新交易系統，新的會員系統也在此時應運而生。

　　引入外部廠商，易購會員系統誕生

　　易購會員系統是蘇寧與外部廠商合作搭建完成的，主要設計思路如下圖所示：

　　1.透過與外部廠商合作，引入E-Commerce、ECIF等軟體框架，採用WebSphere Application Server(以下簡稱WAS)作應用，DB2資料庫伺服器來構建新交易系統。

　　2.新會員系統透過ESB(企業服務匯流排)對外圍系統提供實時服務，使用MQ實現非同步通訊。

　　3.新會員系統主要分通訊介面卡、交易處理、廣播服務、後臺批處理以及後臺管理五大模組，各個模組分別負責不同的業務或者整合場景;

　　4.部署架構方面，前臺應用使用WAS叢集部署，透過ESB連線F5負載均衡器，輪詢訪問WAS叢集，使用高可靠的小型機作為資料庫伺服器。

　　但是隨著近年來蘇寧業務量的急劇增長，這套系統架構也很快就暴露出了問題。首先，商業化套件在一定程度上限制了業務的快速變化，新業務的支援和研發週期特別長，應對業務的變化能力很弱。

　　其次，由於程式碼框架的限制，只能訪問單資料來源，當配置升級到頂配後，資料庫效能無法再提升，只能透過最佳化索引、調整業務、資料歸檔、定期清理等手段最佳化資料庫。架構方面雖然做了讀寫分離，並且儘可能多的將變化不頻繁的資料放到redis快取中，但是資料的訪問壓力仍然很大。

　　總體來說，系統的橫向擴充套件能力很弱。

　　值得慶幸的是，當時蘇寧的前中後臺架構搭建已初具規模，同時也積累了一定的技術能力。為了降低總體研發成本及研發效率，蘇寧引入了開源的技術和服務，並從融入平臺化思想、業務垂直拆分和去商業化三個方面對會員系統重新進行架構設計，逐漸形成了易購平臺會員系統群。

　　自研技術加持，蘇寧會員系統垂直切分

　　蘇寧會員系統的第三階段主要是按功能模組垂直切分系統，根據業務模組拆分出前置組合、等級、賬號資料、賬戶和會員報表幾個子系統。其中前置組合系統，提供跨等級系統、賬戶系統、賬號資料系統的組合服務，並提供別名、屬性名對映會員編號功能。等級、賬號資料、賬戶系統對應管理各自業務，會員報表透過大資料平臺實現。

　　在技術實現方面均使用蘇寧自主研發的Suning Framework(SNF)框架，資料訪問層使用Data Access Layer(DAL)元件;系統間互動使用Remote Service Framework(RSF)做實時訪問元件，ActiveMQ、kafka等做非同步訊息中介軟體;使用Suning Configuration Management(SCM)做統一配置管理，實現配置修改實時生效;對redis和日誌操作進行API封裝，使程式碼呼叫更加便捷;後臺管理使用了User Account and Authentication(UAA)做統一登入驗證;定時任務透過Unification Task Server(UTS)進行管理和觸發執行。

　　部署架構方面，前後臺應用分別部署到各自叢集，使用Wildfly作為應用服務並搭建叢集，Mysql作為資料庫，每組一主兩從，多組構成資料庫叢集，並按照業務功能和特點的不同分為公共庫、業務庫和索引庫。

　　從第二階段易購會員系統過渡到第三階段系統垂直切分面臨很多困難：

　　·系統對外提供的介面很多，其中每個介面又有很多呼叫方系統，每個呼叫方系統使用的技術各不相同，而且新平臺使用的介面協議與老系統不同，各個外圍呼叫方系統都需要根據各自的版本排期進行切換，不能同時切換;

　　·所有老系統在生產環境中一直執行著，系統切換時要儘量保證不能停機;

　　·資料需要進行遷移，新系統與老系統使用的資料庫型別不同，資料模型存在差異，分庫分表的規則也不同;

　　·新系統上線可能存在各種bug，需要考慮如何降低切換風險以及如何修復資料;

　　針對以上難點，蘇寧做出了以下應對方案：

　　在資料遷移方面選擇了spark及相關技術實施，每類表(有多張分表的為一類表)對應一套任務，具體步驟如下：

　　使用spark程式，把DB2中所有分表的全量資料抽到Hive資料庫A類表;

　　將A類表資料分類，分別放入B、C、D類表，其中B為無效資料;C為按過濾條件過濾後的乾淨資料;D為被過濾出來的資料;

　　將B類表資料遷移插入新系統對應的歷史表;

　　C類表資料根據轉換邏輯的複雜度進行判斷：邏輯簡單的表直接拼sql插入新系統;邏輯複雜的表將轉換後的資料寫hive資料庫 E類表，用另一個任務查詢後拼sql插入新系統;

　　修復指定會員資料時，先刪除新系統裡這些會員的相關資料，重新轉換後再進行插入。

　　在系統切換方面，以老系統做路由，在不影響外圍系統的情況下，先完成系統內部的路由切換，再引導外圍系統切換直接呼叫新系統，同時保留老系統路由鏈路，直到所有呼叫方切換呼叫新系統後再廢棄。

　　內部新老系統的路由切換，使用灰度切換和功能切換兩種方式組合，整體可分為兩個步驟：

　　步驟一：切換實時性要求不高的查詢類介面(如圖7所示)：

　　老系統的建立/更新(含刪除)操作在老系統成功後，記錄待處理資料表;

　　建立時間在記表時間之前的全量資料，透過spark和hive任務初始化到新系統;

　　完成資料對比驗證後，開啟定時任務，處理待處理資料表的記錄，按會員維度並行處理(一個會員如果有一條資料處理失敗，則該會員的所有後續請求都會積壓在待處理資料表中)，根據新老系統的介面對映關係，轉換呼叫新系統的建立/更新介面;

　　監控待處理資料表，同時監控新系統的介面和日誌，對各種異常進行分析和處理，如果是新系統的bug，先修復程式碼，然後透過指定會員覆蓋遷移方式進行新系統中錯誤資料的修復;

　　追平資料後，再次進行資料對比驗證，透過按照會員號區間段逐步放大路由呼叫新系統的查詢介面。

　　步驟二：切換實時性要求的查詢類介面和建立/更新類介面(如圖8所示)：

　　第一步，切換新系統產生會員的所有介面：

　　根據時間段開啟路由開關，在新系統生成會員編號(與老系統生成的會員編號隔開一定的號段，防止灰度切換過程中生成的會員編號衝突)，同時這些會員的所有介面都路由呼叫新系統;

　　開啟的時間段開始可以設定為幾分鐘或幾小時，透過監控新系統的介面和日誌、外圍系統的反饋、內部人員使用驗證以及資料對比驗證等方式發現問題，並修復新系統bug和資料(資料不回寫老系統，在新系統產生的會員資料必須在新系統裡進行修復)，多次反覆此步驟，直到路由開關一直開啟。

　　第二步，切換老系統存量會員的所有介面。考慮到新系統的所有介面功能在前面的步驟中均已得到驗證，故老系統中的存量會員一次性全部路由切換到新系統，從而完成新老系統內部路由切換。後續在保留原有呼叫鏈路的情況下，引導外圍系統逐步切換呼叫新系統的介面服務。

　　單機房的資源始終是有限制的，隨著業務量的持續高速增長，系統擴容受到機房內基礎設施的限制。此外單機房的單點問題也逐漸暴露，一旦基礎設施層面出現問題，對業務的影響是災難性的。所以在這樣的背景下，蘇寧會員系統的架構進一步向多活方面進行演進。

　　擺脫單機房，蘇寧會員系統實現同城雙活

　　多機房部署需要一個過程，所以蘇寧首先進行了同城雙活。將現有機房做為主機房，同時承擔子機房A的角色，對現有系統分批進行多活改造。會員相關係統屬於基礎服務系統，所以首批進行了改造。易購會員系統，即第二階段的會員中心繫統，由於外圍系統尚未全部切換呼叫賬號資料、等級、賬戶三個新平臺系統，並且系統不具備多活改造條件，所以只在主機房保留其路由功能。

　　新建備機房，同時承擔子機房B的角色，賬號資料、等級、賬戶三個新平臺系統經過改造後，同時在兩個機房部署，對外圍系統直接提供服務。

　　賬號資料系統包含競爭服務、共享服務、獨佔服務、後臺服務和變更服務，其中競爭服務和後臺服務只在主機房被啟用使用;賬戶系統和等級系統類似，都只包含獨佔服務、後臺服務和變更服務，其中後臺服務只在主機房被啟用。

　　兩個機房之間可以路由呼叫RSF介面服務，但對於一個系統介面服務的內部邏輯處理，原則上不允許跨機房呼叫，特例場景(如會員註冊)可以跨機房呼叫。

　　底層資料庫透過binlog同步資料進行備份。

　　展望未來，蘇寧會員系統將繼續朝著異地多活邁進

　　同城雙活只是蘇寧實現異地雙活的第一步，未來，蘇寧會員系統會繼續朝著異地雙活邁進。會員資料全量同步到所有機房，所有機房都是子機房，並且可以無限擴充套件，根據路由規則處理各自的獨佔型會員資料，其中有兩個機房同時還作為主/備機房，出現故障時互相切換。

　　除此之外，蘇寧會員系統還將延續平臺化發展，與更多的會員平臺進行會員融合或賬號打通，打造大蘇寧會員體系。同時還將向第三方可租用的會員雲平臺發展，實現蘇寧會員平臺的開放。

　　“雙十一超級工程”系列專題下期預告：

　　雙十一大促活動的本質就是低價，當你摩拳擦掌等在電腦前，不斷重新整理頁面，準備搶幾張優惠券，並相信這次收藏的商品志在必得時，但即使整點重新整理，優惠券還是瞬間消失，心愛的商品庫存秒變為0。感到無比鬱悶的同時，你是不是很疑惑：why?這是因為同樣坐在電腦跟你拼手速的，除了正常使用者外，還有一批專業的羊毛黨。全民消費狂歡日的當前，電商平臺應該如何應對羊毛黨大軍，且看《網易雙11“超級工程”：反欺詐系統應用實踐解析》。