蘇寧易購(gòu)CMS架構(gòu)演進(jìn)：泰坦平臺(tái)的探索與實(shí)踐！

產(chǎn)品演變歷程

2012年

蘇寧易購(gòu)所有的網(wǎng)站內(nèi)容管理在核心主系統(tǒng)commerce上，完成了第一版本網(wǎng)站上線，并且形成了內(nèi)容管理框架理論，后續(xù)產(chǎn)品和技術(shù)思路也是基于此框架演變

2014年

內(nèi)容管理業(yè)務(wù)完成了從commerce中拆分，CMS 1.0版本誕生，成為一個(gè)獨(dú)立系統(tǒng)，確立了頁(yè)面模板化、模塊化的概念，具備了并行開(kāi)發(fā)和靈活發(fā)布的條件；但痛點(diǎn)仍然存在，例如前端模板與后端系統(tǒng)的耦合、頁(yè)面迭代慢、開(kāi)發(fā)效率低、整體性能較差等

2015年

CMS 2.0平臺(tái)實(shí)現(xiàn)了模板與應(yīng)用的動(dòng)靜分離、模板的動(dòng)態(tài)發(fā)布、在線編輯、性能TP99優(yōu)化、系統(tǒng)自動(dòng)降級(jí)，拓展完成了對(duì)易購(gòu)絕大部分前臺(tái)頁(yè)面管理和支撐，同時(shí)成功推進(jìn)易購(gòu)從PC時(shí)代向移動(dòng)時(shí)代轉(zhuǎn)變的進(jìn)程；缺陷是界面交互復(fù)雜，頁(yè)面搭建效率低、運(yùn)營(yíng)功能不夠健全。

2017年

CMS 3.0主要解決對(duì)于APP原生化的內(nèi)容管理問(wèn)題，概念上摒棄了固化模板的概念，攻克了APP多版本的數(shù)據(jù)同步問(wèn)題。同時(shí)完成了易購(gòu)全站https化，加強(qiáng)了后端容錯(cuò)和管控，確保全年0事故發(fā)生。

2018年

隨著蘇寧提出的“造極”以及“多產(chǎn)業(yè)協(xié)調(diào)發(fā)展”戰(zhàn)略，日常的內(nèi)容管理不能僅僅滿足于零售業(yè)態(tài)下的業(yè)務(wù)，以及傳統(tǒng)人工機(jī)械式的工作方式，因此，泰坦平臺(tái)（CMS 4.0）應(yīng)運(yùn)而生，系統(tǒng)架構(gòu)從頂層上支持不同業(yè)態(tài)下內(nèi)容管理，并且提供了豐富的模塊組件庫(kù)，而且還支持組件高度定制，接入OOP、ES6、VUE片段多種技術(shù)形式，為平臺(tái)制定規(guī)范提供了基礎(chǔ)技術(shù)，底層架構(gòu)設(shè)計(jì)上采取抽象概念、動(dòng)態(tài)數(shù)據(jù)類型、模塊組件化實(shí)現(xiàn)前后端分離是泰坦平臺(tái)化后端技術(shù)核心所在，不僅連接了蘇寧內(nèi)部團(tuán)隊(duì)，而且還賦能第三方品牌商和運(yùn)營(yíng)商；通過(guò)提供各種應(yīng)用功能模塊充分與應(yīng)用場(chǎng)景、應(yīng)用架構(gòu)以及人相連接的“平臺(tái)生態(tài)建設(shè)”上來(lái)

核心能力一：抽象業(yè)務(wù)模型，構(gòu)建系統(tǒng)框架

產(chǎn)品、前端開(kāi)發(fā)、服務(wù)端開(kāi)發(fā)、設(shè)計(jì)師、測(cè)試、運(yùn)營(yíng)，這些崗位的人員增長(zhǎng)速度遠(yuǎn)遠(yuǎn)不及業(yè)務(wù)發(fā)展的需要，工期時(shí)間也一樣，也就是我們常說(shuō)的資源不足，如何在有限的資源條件下滿足更多的需求呢？首先就是提升效率和模塊復(fù)用?？梢暬庉嫷牟僮鳎e木式頁(yè)面結(jié)構(gòu)以及高度公共化的模塊組件，成為解決問(wèn)題的核心。

結(jié)合CMS領(lǐng)域業(yè)務(wù)模型，從上到下逐層抽象出：頁(yè)面->模塊->元素->數(shù)據(jù)模型->基礎(chǔ)字段，實(shí)現(xiàn)積木式頁(yè)面搭建和高復(fù)用性。

良好的業(yè)務(wù)模型抽象，是高復(fù)用性的基礎(chǔ)，數(shù)據(jù)結(jié)構(gòu)如下：

核心能力二：組件化平臺(tái)，前后端分離實(shí)踐

組件平臺(tái)主要是管理系統(tǒng)內(nèi)的模塊組件從無(wú)到有的全流程，包括模塊的源文件管理、在線開(kāi)發(fā)、分支和版本管理、發(fā)布流程管理等，前端開(kāi)發(fā)將開(kāi)發(fā)好的模塊組件源文件上傳至平臺(tái)內(nèi)進(jìn)行管理，每個(gè)模塊組件都是一個(gè)獨(dú)立的發(fā)布分支，開(kāi)發(fā)人員在平臺(tái)內(nèi)進(jìn)行開(kāi)發(fā)后，可以自行提交分支代碼，如果需要至生產(chǎn)環(huán)境，還需要經(jīng)歷發(fā)布流程的審批，最終才能夠?qū)⒛K組件發(fā)布至生產(chǎn)環(huán)境，發(fā)布至生產(chǎn)的模塊組件就可以給各個(gè)頁(yè)面使用了。下面就給大家介紹一下模塊組件的前后端原理和工作方式。

后端對(duì)組件標(biāo)準(zhǔn)制定和發(fā)布管理

泰坦后臺(tái)提供了模塊全方位的定義能力，前端開(kāi)發(fā)人員可以使用該能力專注前端開(kāi)發(fā)，實(shí)現(xiàn)前后端的完美分離。

模塊數(shù)據(jù)定義：

模塊樣式數(shù)據(jù)定義

模塊樣式定義，實(shí)際上是規(guī)定了該模塊包含的樣式控制項(xiàng)，例如背景顏色、樣式等

模塊業(yè)務(wù)數(shù)據(jù)定義

模塊數(shù)據(jù)定義，實(shí)際上是規(guī)定了模塊可維護(hù)的業(yè)務(wù)數(shù)據(jù)的各個(gè)數(shù)據(jù)項(xiàng)，例如商品名稱、商品編碼等

在模塊數(shù)據(jù)定義中，使用了動(dòng)態(tài)數(shù)據(jù)類型（元素）簡(jiǎn)化模塊數(shù)據(jù)定義，大大提高了模塊開(kāi)發(fā)工作量，對(duì)于抽象出的動(dòng)態(tài)數(shù)據(jù)類型，在某些極端場(chǎng)景中無(wú)法支持某些模塊的數(shù)據(jù)定義的，支持使用基礎(chǔ)字段二次擴(kuò)展，支持極端的業(yè)務(wù)場(chǎng)景。

模塊頁(yè)面渲染定義

泰坦使用模塊定義完成了頁(yè)面樓層中涉及的各個(gè)方面問(wèn)題，除了包含樣式控制項(xiàng)的定義、模塊業(yè)務(wù)數(shù)據(jù)維護(hù)項(xiàng)的定義以外，當(dāng)然還包含如何將運(yùn)營(yíng)人員維護(hù)的樣式控制項(xiàng)內(nèi)容、業(yè)務(wù)數(shù)據(jù)內(nèi)容整合渲染的樓層渲染定義。為了提供該功能，泰坦支持在定義模塊時(shí)，上傳模塊渲染的JS文件，結(jié)合使用高性能的云存儲(chǔ)服務(wù)器，實(shí)現(xiàn)快速、準(zhǔn)確的樓層渲染：

復(fù)雜組件的抽象與定義：

頁(yè)面除了普通模塊以外，目前還存在一種特殊模塊-Tab簽?zāi)K。為了處理Tab簽?zāi)K，系統(tǒng)對(duì)其進(jìn)行分析抽象，抽象出復(fù)合模塊->布局模塊->普通模塊的層級(jí)概念：

通過(guò)模塊層級(jí)，可以靈活配置以適配頁(yè)面遇到的復(fù)雜樓層場(chǎng)景，不僅僅圖中的單層Tab簽場(chǎng)景，還可以支持雙層Tab簽，甚至三層或更多層的場(chǎng)景。通過(guò)定義復(fù)合模塊、布局模塊、普通模塊之間的關(guān)系，實(shí)現(xiàn)層級(jí)之間的關(guān)聯(lián)，同時(shí)各層級(jí)模塊的樣式與數(shù)據(jù)定義依然遵從普通模塊的一般配置定義場(chǎng)景，實(shí)現(xiàn)動(dòng)靜結(jié)合，各安其分。

從技術(shù)角度來(lái)看，后臺(tái)通過(guò)定義模塊關(guān)系表，支持動(dòng)態(tài)的模塊層級(jí)關(guān)系綁定，理論上可以支持任何層級(jí)的模塊關(guān)系，具備更好的靈活性和擴(kuò)展性。

1) 復(fù)合模塊定義界面：

通過(guò)拖拽方式定義復(fù)合模塊和布局模塊之間的關(guān)系，操作簡(jiǎn)單友好。

2) 布局模塊定義界面：

通過(guò)拖拽方式定義布局模塊可選擇的普通模塊，定義頁(yè)面中Tab簽下可放置的樓層類型（例如普通商品）。

組件平臺(tái)是泰坦的一個(gè)重要概念，因?yàn)樗且环N抽象，允許我們使用小型、獨(dú)立和通?？蓮?fù)用的組件構(gòu)建大型頁(yè)面。仔細(xì)想想，幾乎任意類型的界面都可以抽象為一個(gè)組件樹(shù)。

例如頁(yè)面你可能會(huì)有頭圖、輪播、熱區(qū)等組件，而通過(guò)TAB又可以把這些組件聚合到某個(gè)TAB切下，組件的“嵌套”增強(qiáng)了組件的形態(tài)，使得組件可以掛載到父組件當(dāng)中，所以一個(gè)頁(yè)面有很多復(fù)用的組件構(gòu)成，為防止多組件帶來(lái)的污染，組件采取 “禁用”設(shè)計(jì)與封閉隔離，既能避免組件對(duì)全局的影響，又能讓組件對(duì)系統(tǒng)不依賴，即插即用。

后端發(fā)布管理流程：

前端組件與后端系統(tǒng)間的數(shù)據(jù)通信

組件數(shù)據(jù)分為“樣式數(shù)據(jù)”和“業(yè)務(wù)數(shù)據(jù)”兩種，樣式數(shù)據(jù)提供展現(xiàn)，業(yè)務(wù)數(shù)據(jù)提供邏輯，互不干擾。

組件的使用都會(huì)實(shí)例化，實(shí)例化過(guò)程時(shí)會(huì)產(chǎn)生一系列過(guò)程，比如數(shù)據(jù)監(jiān)聽(tīng)、模版解析、虛擬DOM生成，然后完成組件渲染，同時(shí)在這個(gè)過(guò)程中也會(huì)運(yùn)行一些叫做生命周期鉤子的函數(shù)，這給了用戶在不同階段添加自己的代碼的機(jī)會(huì)。

頁(yè)面是唯一數(shù)據(jù)對(duì)象，頁(yè)面和組件之間是單工方式，數(shù)據(jù)只會(huì)從頁(yè)面流向組件，而頁(yè)面和“組件控制面板”之間是雙工方式，都能收發(fā)數(shù)據(jù)，實(shí)現(xiàn)DOM和對(duì)象更新。

組件的最優(yōu)實(shí)踐

組件要求獨(dú)立內(nèi)聚，所以其中聚合HTML、CSS、JS內(nèi)容， 然后WEBPACK編譯生成BUNDLE文件，整體上組件采用OOP設(shè)計(jì)，使得組件具備對(duì)象的特性，封裝、繼承、多態(tài)。因此加載到頁(yè)面中的是組件的實(shí)例，這也保證了同一組件可以多次加載，避免組件污染的問(wèn)題。

一個(gè)完整的組件分為兩部分：

組件內(nèi)容

組件內(nèi)容是完整的對(duì)外的JS文件, 分編輯JS（提供泰坦系統(tǒng)使用，運(yùn)營(yíng)可視化的展示，不需要調(diào)用業(yè)務(wù)接口）和預(yù)覽JS（真實(shí)的，用戶能看到的）兩套。編輯JS側(cè)重突出對(duì)數(shù)據(jù)的UPDATE操作，選擇性忽略組件的動(dòng)畫(huà)交互，而預(yù)覽JS由于數(shù)據(jù)已配好，所以不UPDATE，但多了對(duì)交互和接口的關(guān)注，

組件的控制面板

組件控制面板是提供給運(yùn)營(yíng)可視化可操作的頁(yè)面來(lái)實(shí)現(xiàn)組件最終效果。在新增模塊的時(shí)候，有個(gè)“模塊控制面板”的選項(xiàng)，默認(rèn)是雙TAB，可以在此處修改。

樣式字段是開(kāi)發(fā)者通過(guò)組件的樣式編輯功能添加生成，比如組件需要的樣式字段，都可以通過(guò)下圖配置，每個(gè)字段里面的字段名在當(dāng)前組件里唯一，這個(gè)字段名也會(huì)是你在組件里面數(shù)據(jù)的鍵值。

同樣業(yè)務(wù)數(shù)據(jù)需要的字段也能通過(guò)數(shù)據(jù)編輯功能添加生成。

1.是雙TAB的展示，樣式和維護(hù)數(shù)據(jù)的字段都是開(kāi)發(fā)者自定義，充分給開(kāi)發(fā)者足夠的擴(kuò)展空間。

2.業(yè)務(wù)是多態(tài)的，視覺(jué)是多變的，總有拖拽無(wú)法生成的字段樣式，因此VUE片段應(yīng)運(yùn)而生，比如圖片熱區(qū)這種是自定義的樣式展示，開(kāi)發(fā)者VUE實(shí)現(xiàn)，VUE實(shí)現(xiàn)意味頁(yè)面需要自己開(kāi)發(fā)，開(kāi)發(fā)者，同樣在樣式編輯里面的，有個(gè)“頁(yè)面片段”，粘貼你編譯后的JS代碼。

說(shuō)起開(kāi)發(fā)者的實(shí)現(xiàn)，開(kāi)發(fā)者只關(guān)注面板的展示和數(shù)據(jù)的變量存儲(chǔ)，對(duì)于數(shù)據(jù)的通信系統(tǒng)已經(jīng)提供通用的API，并且完成必須的數(shù)據(jù)監(jiān)聽(tīng)、數(shù)據(jù)更新操作，簡(jiǎn)化開(kāi)發(fā)。

系統(tǒng)的自定義化促成了更多復(fù)雜定制組件的生成，比如之前提到的TAB組件，它是復(fù)合型的組件，支持嵌套，面板同樣是開(kāi)發(fā)定制。

最終，編寫(xiě)完的組件，發(fā)布包是ZIP包，包名是模塊標(biāo)識(shí)，editFilePath里面存放編輯JS，modelFilePath里面存放預(yù)覽JS，這兩個(gè)目錄名固定。打包之后，通過(guò)模塊修改功能，發(fā)布組件

核心能力三：動(dòng)態(tài)數(shù)據(jù)模型的多元化與延展性

所謂的動(dòng)態(tài)是指能夠靈活擴(kuò)展，不需要上線也不需要擴(kuò)展數(shù)據(jù)庫(kù)字段，支持自由擴(kuò)展，能夠快速響應(yīng)電商網(wǎng)站的日益靈活多變的需求。同時(shí)將模塊組件內(nèi)所需要的字段進(jìn)行拆解和歸類，形成顆粒度更為精細(xì)的字段組件，文本輸入框、下拉選擇、單選、多選等都成為了這些最小單元，任何模塊組件都是通過(guò)這些字段組件通過(guò)不同的排列組合形成的，可擴(kuò)展性非常強(qiáng)，而且還滿足不同業(yè)務(wù)需要時(shí)，擴(kuò)展字段變得很方便快捷，實(shí)現(xiàn)動(dòng)態(tài)可配置，由于配置不需要發(fā)布，極大化降低了模塊組件的發(fā)布風(fēng)險(xiǎn)，對(duì)正在使用頁(yè)面和業(yè)務(wù)不造成影響，安全性更高。

當(dāng)然，將組件抽象、顆?；耐瑫r(shí)，也兼顧到一些常用的數(shù)據(jù)類型的聚類，形成了系統(tǒng)內(nèi)的基礎(chǔ)元素，常見(jiàn)的基礎(chǔ)元素有：圖片元素、文字元素、商品元素、券元素等。

動(dòng)態(tài)數(shù)據(jù)類型定義操作界面：

通過(guò)抽象出基礎(chǔ)字段（例如單選、復(fù)選、選色板、時(shí)間選擇器），由基礎(chǔ)字段組合成數(shù)據(jù)類型（元素），實(shí)現(xiàn)動(dòng)態(tài)數(shù)據(jù)類型：

通過(guò)概念抽象及分級(jí)：頁(yè)面->模塊->元素->數(shù)據(jù)模型->基礎(chǔ)字段，以及各級(jí)抽象概念物理模型的獨(dú)立表達(dá)與存儲(chǔ)，達(dá)到各級(jí)概念抽象間關(guān)系管理的動(dòng)態(tài)綁定和各級(jí)概念抽象本身的獨(dú)立定義，實(shí)現(xiàn)數(shù)據(jù)類型的動(dòng)態(tài)擴(kuò)展和自由擴(kuò)展，無(wú)需代碼更改及版本發(fā)布，提供更好的靈活性和面向未來(lái)的可擴(kuò)展性。

核心能力四：多終端多業(yè)態(tài)支撐

愿景：覆蓋蘇寧集團(tuán)八大產(chǎn)業(yè)，成為蘇寧業(yè)務(wù)組件化、平臺(tái)化以及對(duì)外賦能的基石。

泰坦再設(shè)計(jì)之初就構(gòu)建了多業(yè)態(tài)支撐的雛形，本著為集團(tuán)全產(chǎn)業(yè)提供服務(wù)的角度出發(fā)， 在系統(tǒng)設(shè)計(jì)時(shí)，做了產(chǎn)業(yè)概念的劃分，做到各產(chǎn)業(yè)之間共用底層系統(tǒng)服務(wù)的同時(shí)不會(huì)影響到各自業(yè)務(wù)邏輯，產(chǎn)業(yè)間的業(yè)務(wù)隔離，業(yè)務(wù)邏輯隔離，降低系統(tǒng)風(fēng)險(xiǎn)，保障各產(chǎn)業(yè)的業(yè)務(wù)能夠順利開(kāi)展。在組件的平臺(tái)化和復(fù)用性方面，同樣是為了解決各產(chǎn)業(yè)集團(tuán)之間資源缺口問(wèn)題，將核心的前端技術(shù)能力共享，設(shè)計(jì)能力共享，另一方面，也是整合了集團(tuán)的所有開(kāi)發(fā)資源和設(shè)計(jì)資源，各集團(tuán)產(chǎn)業(yè)設(shè)計(jì)和開(kāi)發(fā)的模塊組件都可以共享。

產(chǎn)品支撐框架：

技術(shù)支撐框架：

核心能力五：強(qiáng)大的自檢和監(jiān)控，確保系統(tǒng)和業(yè)務(wù)穩(wěn)定 

產(chǎn)業(yè)隔離

各產(chǎn)業(yè)間的邏輯可以相互獨(dú)立，不會(huì)交叉干擾，底層服務(wù)基本一致，支持有各自的定制化需要。

獨(dú)立權(quán)限

權(quán)限的申請(qǐng)和審批均在系統(tǒng)內(nèi)完成，角色職責(zé)分明，使用者在系統(tǒng)內(nèi)僅可見(jiàn)自己創(chuàng)建的頁(yè)面或者被授權(quán)頁(yè)面，相當(dāng)于每個(gè)使用者都擁有屬于自己的工作空間，而不需要受到其他人創(chuàng)建的頁(yè)面干擾，同時(shí)這樣做也保障了自己頁(yè)面的安全性。

系統(tǒng)內(nèi)自檢

系統(tǒng)內(nèi)會(huì)對(duì)于維護(hù)的頁(yè)面鏈接進(jìn)行一些自檢，例如圖片的大小、跳轉(zhuǎn)的鏈接是否能夠正常訪問(wèn)，是否為蘇寧鏈接等

敏感詞校驗(yàn)

系統(tǒng)目前開(kāi)放給內(nèi)部員工和商戶使用，為了避免一些敏感詞在頁(yè)面上直接展示露出，在系統(tǒng)內(nèi)進(jìn)行維護(hù)時(shí)，進(jìn)行了敏感詞校驗(yàn)，如果匹配到是敏感詞庫(kù)內(nèi)存在的敏感詞，將不能維護(hù)到系統(tǒng)內(nèi)，并給出提示。

敏感圖過(guò)濾

方式與敏感詞的校驗(yàn)基本相同，除了校驗(yàn)圖片上的敏感詞之外，還會(huì)校驗(yàn)一些水印和違規(guī)二維碼等

頁(yè)面上線前校驗(yàn)

人工創(chuàng)建和維護(hù)的頁(yè)面，難以保證上線時(shí)不存在問(wèn)題，所以我們?cè)陧?yè)面上線時(shí)對(duì)頁(yè)面進(jìn)行了一次系統(tǒng)審核，提前設(shè)置好一些頁(yè)面的各種規(guī)范（包括頁(yè)面性能、首屏加載速度），上線校驗(yàn)時(shí)會(huì)按照這些規(guī)范一一進(jìn)行匹配，如果不滿足這些規(guī)范要求，頁(yè)面是不允許上線的，以保證能夠給消費(fèi)者最好的頁(yè)面瀏覽體驗(yàn)。

全天候?qū)崟r(shí)監(jiān)控和報(bào)警

對(duì)于已經(jīng)上線的頁(yè)面，會(huì)視重要程度，配置頁(yè)面監(jiān)控，對(duì)于頁(yè)面在線上的過(guò)程中，出現(xiàn)的數(shù)據(jù)失效，頁(yè)面過(guò)期等等問(wèn)題建立起報(bào)警機(jī)制，給予頁(yè)面維護(hù)的運(yùn)營(yíng)人員發(fā)送消息提醒，以便及時(shí)發(fā)現(xiàn)問(wèn)題和解決問(wèn)題。

頁(yè)面降級(jí)

頁(yè)面上線的過(guò)程中，難以避免需要對(duì)頁(yè)面進(jìn)行調(diào)整，這些調(diào)整可能輸數(shù)據(jù)層面的，也可能是頁(yè)面結(jié)構(gòu)上的。對(duì)于頁(yè)面結(jié)構(gòu)的調(diào)整，對(duì)頁(yè)面整體的影響較大，如果在系統(tǒng)內(nèi)調(diào)整頁(yè)面結(jié)構(gòu)的同時(shí)讓消費(fèi)者看到頁(yè)面上展示出的問(wèn)題，顯然是不合適的，因此我們建立了頁(yè)面降級(jí)機(jī)制，在對(duì)頁(yè)面結(jié)構(gòu)進(jìn)行調(diào)整時(shí)，會(huì)將頁(yè)面自動(dòng)降級(jí)，使頁(yè)面停留在改變結(jié)構(gòu)前的一刻，不影響消費(fèi)者瀏覽頁(yè)面，降級(jí)期間頁(yè)面數(shù)據(jù)將不會(huì)進(jìn)行更新，運(yùn)營(yíng)人員調(diào)整完頁(yè)面后，重新上線頁(yè)面，頁(yè)面即可取消降級(jí)，頁(yè)面數(shù)據(jù)正常更新。

我們的愿景

未來(lái)的產(chǎn)品架構(gòu)圖：

未來(lái)的系統(tǒng)架構(gòu)圖：

未來(lái)希望能夠有更多的業(yè)務(wù)、技術(shù)力量加入泰坦平臺(tái)，為越來(lái)越多的定制化頻道活動(dòng)提供技術(shù)支持和產(chǎn)品服務(wù)，也希望開(kāi)發(fā)者們享受體驗(yàn)開(kāi)發(fā)，調(diào)試，灰度，發(fā)布一整套流程，給我們提出寶貴的意見(jiàn)建議，共同提高。

【 作者 】

畢定，蘇寧易購(gòu)消費(fèi)者平臺(tái)研發(fā)中心產(chǎn)品經(jīng)理，2015年加入蘇寧，一直負(fù)責(zé)蘇寧易購(gòu)平臺(tái)內(nèi)容管理系統(tǒng)的產(chǎn)品工作，經(jīng)歷了系統(tǒng)的演化變遷，產(chǎn)品改版和迭代，致力于蘇寧全產(chǎn)業(yè)內(nèi)容管理平臺(tái)的建設(shè)工作。