蘇寧易購CMS架構演進：泰坦平臺的探索與實踐！

產品演變歷程

2012年

蘇寧易購所有的網站內容管理在核心主系統commerce上，完成了第一版本網站上線，並且形成了內容管理框架理論，後續產品和技術思路也是基於此框架演變

2014年

內容管理業務完成了從commerce中拆分，CMS 1.0版本誕生，成為一個獨立系統，確立了頁面模板化、模組化的概念，具備了並行開發和靈活釋出的條件；但痛點仍然存在，例如前端模板與後端系統的耦合、頁面迭代慢、開發效率低、整體效能較差等

2015年

CMS 2.0平臺實現了模板與應用的動靜分離、模板的動態釋出、線上編輯、效能TP99最佳化、系統自動降級，擴充完成了對易購絕大部分前臺頁面管理和支撐，同時成功推進易購從PC時代向移動時代轉變的程式；缺陷是介面互動複雜，頁面搭建效率低、運營功能不夠健全。

2017年

CMS 3.0主要解決對於APP原生化的內容管理問題，概念上摒棄了固化模板的概念，攻克了APP多版本的資料同步問題。同時完成了易購全站https化，加強了後端容錯和管控，確保全年0事故發生。

2018年

隨著蘇寧提出的“造極”以及“多產業協調發展”戰略，日常的內容管理不能僅僅滿足於零售業態下的業務，以及傳統人工機械式的工作方式，因此，泰坦平臺（CMS 4.0）應運而生，系統架構從頂層上支援不同業態下內容管理，並且提供了豐富的模組元件庫，而且還支援元件高度定製，接入OOP、ES6、VUE片段多種技術形式，為平臺制定規範提供了基礎技術，底層架構設計上採取抽象概念、動態資料型別、模組元件化實現前後端分離是泰坦平臺化後端技術核心所在，不僅連線了蘇寧內部團隊，而且還賦能第三方品牌商和運營商；透過提供各種應用功能模組充分與應用場景、應用架構以及人相連線的“平臺生態建設”上來

核心能力一：抽象業務模型，構建系統框架

產品、前端開發、服務端開發、設計師、測試、運營，這些崗位的人員增長速度遠遠不及業務發展的需要，工期時間也一樣，也就是我們常說的資源不足，如何在有限的資源條件下滿足更多的需求呢？首先就是提升效率和模組複用。視覺化編輯的操作，積木式頁面結構以及高度公共化的模組元件，成為解決問題的核心。

結合CMS領域業務模型，從上到下逐層抽象出：頁面->模組->元素->資料模型->基礎欄位，實現積木式頁面搭建和高複用性。

良好的業務模型抽象，是高複用性的基礎，資料結構如下：

核心能力二：元件化平臺，前後端分離實踐

元件平臺主要是管理系統內的模組元件從無到有的全流程，包括模組的原始檔管理、線上開發、分支和版本管理、釋出流程管理等，前端開發將開發好的模組元件原始檔上傳至平臺內進行管理，每個模組元件都是一個獨立的釋出分支，開發人員在平臺內進行開發後，可以自行提交分支程式碼，如果需要至生產環境，還需要經歷釋出流程的審批，最終才能夠將模組元件釋出至生產環境，釋出至生產的模組元件就可以給各個頁面使用了。下面就給大家介紹一下模組元件的前後端原理和工作方式。

後端對元件標準制定和釋出管理

泰坦後臺提供了模組全方位的定義能力，前端開發人員可以使用該能力專注前端開發，實現前後端的完美分離。

模組資料定義：

模組樣式資料定義

模組樣式定義，實際上是規定了該模組包含的樣式控制項，例如背景顏色、樣式等

模組業務資料定義

模組資料定義，實際上是規定了模組可維護的業務資料的各個資料項，例如商品名稱、商品編碼等

在模組資料定義中，使用了動態資料型別（元素）簡化模組資料定義，大大提高了模組開發工作量，對於抽象出的動態資料型別，在某些極端場景中無法支援某些模組的資料定義的，支援使用基礎欄位二次擴充套件，支援極端的業務場景。

模組頁面渲染定義

泰坦使用模組定義完成了頁面樓層中涉及的各個方面問題，除了包含樣式控制項的定義、模組業務資料維護項的定義以外，當然還包含如何將運營人員維護的樣式控制項內容、業務資料內容整合渲染的樓層渲染定義。為了提供該功能，泰坦支援在定義模組時，上傳模組渲染的JS檔案，結合使用高效能的雲端儲存伺服器，實現快速、準確的樓層渲染：

複雜元件的抽象與定義：

頁面除了普通模組以外，目前還存在一種特殊模組-Tab籤模組。為了處理Tab籤模組，系統對其進行分析抽象，抽象出複合模組->佈局模組->普通模組的層級概念：

透過模組層級，可以靈活配置以適配頁面遇到的複雜樓層場景，不僅僅圖中的單層Tab籤場景，還可以支援雙層Tab籤，甚至三層或更多層的場景。透過定義複合模組、佈局模組、普通模組之間的關係，實現層級之間的關聯，同時各層級模組的樣式與資料定義依然遵從普通模組的一般配置定義場景，實現動靜結合，各安其分。

從技術角度來看，後臺透過定義模組關係表，支援動態的模組層級關係繫結，理論上可以支援任何層級的模組關係，具備更好的靈活性和擴充套件性。

1) 複合模組定義介面：

透過拖拽方式定義複合模組和佈局模組之間的關係，操作簡單友好。

2) 佈局模組定義介面：

透過拖拽方式定義佈局模組可選擇的普通模組，定義頁面中Tab簽下可放置的樓層型別（例如普通商品）。

元件平臺是泰坦的一個重要概念，因為它是一種抽象，允許我們使用小型、獨立和通常可複用的元件構建大型頁面。仔細想想，幾乎任意型別的介面都可以抽象為一個元件樹。

例如頁面你可能會有頭圖、輪播、熱區等元件，而透過TAB又可以把這些元件聚合到某個TAB切下，元件的“巢狀”增強了元件的形態，使得元件可以掛載到父元件當中，所以一個頁面有很多複用的元件構成，為防止多元件帶來的汙染，元件採取 “禁用”設計與封閉隔離，既能避免元件對全域性的影響，又能讓元件對系統不依賴，即插即用。

後端釋出管理流程：

前端元件與後端系統間的資料通訊

元件資料分為“樣式資料”和“業務資料”兩種，樣式資料提供展現，業務資料提供邏輯，互不干擾。

元件的使用都會例項化，例項化過程時會產生一系列過程，比如資料監聽、模版解析、虛擬DOM生成，然後完成元件渲染，同時在這個過程中也會執行一些叫做生命週期鉤子的函式，這給了使用者在不同階段新增自己的程式碼的機會。

頁面是唯一資料物件，頁面和元件之間是單工方式，資料只會從頁面流向元件，而頁面和“元件控制皮膚”之間是雙工方式，都能收發資料，實現DOM和物件更新。

元件的最優實踐

元件要求獨立內聚，所以其中聚合HTML、CSS、JS內容， 然後WEBPACK編譯生成BUNDLE檔案，整體上元件採用OOP設計，使得元件具備物件的特性，封裝、繼承、多型。因此載入到頁面中的是元件的例項，這也保證了同一元件可以多次載入，避免元件汙染的問題。

一個完整的元件分為兩部分：

元件內容

元件內容是完整的對外的JS檔案, 分編輯JS（提供泰坦系統使用，運營視覺化的展示，不需要呼叫業務介面）和預覽JS（真實的，使用者能看到的）兩套。編輯JS側重突出對資料的UPDATE操作，選擇性忽略元件的動畫互動，而預覽JS由於資料已配好，所以不UPDATE，但多了對互動和介面的關注，

元件的控制皮膚

元件控制皮膚是提供給運營視覺化可操作的頁面來實現元件最終效果。在新增模組的時候，有個“模組控制皮膚”的選項，預設是雙TAB，可以在此處修改。

樣式欄位是開發者透過元件的樣式編輯功能新增生成，比如元件需要的樣式欄位，都可以透過下圖配置，每個欄位裡面的欄位名在當前元件裡唯一，這個欄位名也會是你在元件裡面資料的鍵值。

同樣業務資料需要的欄位也能透過資料編輯功能新增生成。

1.是雙TAB的展示，樣式和維護資料的欄位都是開發者自定義，充分給開發者足夠的擴充套件空間。

2.業務是多型的，視覺是多變的，總有拖拽無法生成的欄位樣式，因此VUE片段應運而生，比如圖片熱區這種是自定義的樣式展示，開發者VUE實現，VUE實現意味頁面需要自己開發，開發者，同樣在樣式編輯裡面的，有個“頁面片段”，貼上你編譯後的JS程式碼。

說起開發者的實現，開發者只關注皮膚的展示和資料的變數儲存，對於資料的通訊系統已經提供通用的API，並且完成必須的資料監聽、資料更新操作，簡化開發。

系統的自定義化促成了更多複雜定製元件的生成，比如之前提到的TAB元件，它是複合型的元件，支援巢狀，皮膚同樣是開發定製。

最終，編寫完的元件，釋出包是ZIP包，包名是模組標識，editFilePath裡面存放編輯JS，modelFilePath裡面存放預覽JS，這兩個目錄名固定。打包之後，透過模組修改功能，釋出元件

核心能力三：動態資料模型的多元化與延展性

所謂的動態是指能夠靈活擴充套件，不需要上線也不需要擴充套件資料庫欄位，支援自由擴充套件，能夠快速響應電商網站的日益靈活多變的需求。同時將模組元件內所需要的欄位進行拆解和歸類，形成顆粒度更為精細的欄位元件，文字輸入框、下拉選擇、單選、多選等都成為了這些最小單元，任何模組元件都是透過這些欄位元件透過不同的排列組合形成的，可擴充套件性非常強，而且還滿足不同業務需要時，擴充套件欄位變得很方便快捷，實現動態可配置，由於配置不需要釋出，極大化降低了模組元件的釋出風險，對正在使用頁面和業務不造成影響，安全性更高。

當然，將元件抽象、顆粒化的同時，也兼顧到一些常用的資料型別的聚類，形成了系統內的基礎元素，常見的基礎元素有：圖片元素、文字元素、商品元素、券元素等。

動態資料型別定義操作介面：

透過抽象出基礎欄位（例如單選、複選、選色板、時間選擇器），由基礎欄位組合成資料型別（元素），實現動態資料型別：

透過概念抽象及分級：頁面->模組->元素->資料模型->基礎欄位，以及各級抽象概念物理模型的獨立表達與儲存，達到各級概念抽象間關係管理的動態繫結和各級概念抽象本身的獨立定義，實現資料型別的動態擴充套件和自由擴充套件，無需程式碼更改及版本釋出，提供更好的靈活性和麵向未來的可擴充套件性。

核心能力四：多終端多業態支撐

願景：覆蓋蘇寧集團八大產業，成為蘇寧業務元件化、平臺化以及對外賦能的基石。

泰坦再設計之初就構建了多業態支撐的雛形，本著為集團全產業提供服務的角度出發， 在系統設計時，做了產業概念的劃分，做到各產業之間共用底層系統服務的同時不會影響到各自業務邏輯，產業間的業務隔離，業務邏輯隔離，降低系統風險，保障各產業的業務能夠順利開展。在元件的平臺化和複用性方面，同樣是為了解決各產業集團之間資源缺口問題，將核心的前端技術能力共享，設計能力共享，另一方面，也是整合了集團的所有開發資源和設計資源，各集團產業設計和開發的模組元件都可以共享。

產品支撐框架：

技術支撐框架：

核心能力五：強大的自檢和監控，確保系統和業務穩定 

產業隔離

各產業間的邏輯可以相互獨立，不會交叉干擾，底層服務基本一致，支援有各自的定製化需要。

獨立許可權

許可權的申請和審批均在系統內完成，角色職責分明，使用者在系統內僅可見自己建立的頁面或者被授權頁面，相當於每個使用者都擁有屬於自己的工作空間，而不需要受到其他人建立的頁面干擾，同時這樣做也保障了自己頁面的安全性。

系統內自檢

系統內會對於維護的頁面連結進行一些自檢，例如圖片的大小、跳轉的連結是否能夠正常訪問，是否為蘇寧連結等

敏感詞校驗

系統目前開放給內部員工和商戶使用，為了避免一些敏感詞在頁面上直接展示露出，在系統內進行維護時，進行了敏感詞校驗，如果匹配到是敏感詞庫記憶體在的敏感詞，將不能維護到系統內，並給出提示。

敏感圖過濾

方式與敏感詞的校驗基本相同，除了校驗圖片上的敏感詞之外，還會校驗一些水印和違規二維碼等

頁面上線前校驗

人工建立和維護的頁面，難以保證上線時不存在問題，所以我們在頁面上線時對頁面進行了一次系統稽核，提前設定好一些頁面的各種規範（包括頁面效能、首屏載入速度），上線校驗時會按照這些規範一一進行匹配，如果不滿足這些規範要求，頁面是不允許上線的，以保證能夠給消費者最好的頁面瀏覽體驗。

全天候實時監控和報警

對於已經上線的頁面，會視重要程度，配置頁面監控，對於頁面線上上的過程中，出現的資料失效，頁面過期等等問題建立起報警機制，給予頁面維護的運營人員傳送訊息提醒，以便及時發現問題和解決問題。

頁面降級

頁面上線的過程中，難以避免需要對頁面進行調整，這些調整可能輸資料層面的，也可能是頁面結構上的。對於頁面結構的調整，對頁面整體的影響較大，如果在系統內調整頁面結構的同時讓消費者看到頁面上展示出的問題，顯然是不合適的，因此我們建立了頁面降級機制，在對頁面結構進行調整時，會將頁面自動降級，使頁面停留在改變結構前的一刻，不影響消費者瀏覽頁面，降級期間頁面資料將不會進行更新，運營人員調整完頁面後，重新上線頁面，頁面即可取消降級，頁面資料正常更新。

我們的願景

未來的產品架構圖：

未來的系統架構圖：

未來希望能夠有更多的業務、技術力量加入泰坦平臺，為越來越多的定製化頻道活動提供技術支援和產品服務，也希望開發者們享受體驗開發，除錯，灰度，釋出一整套流程，給我們提出寶貴的意見建議，共同提高。

【 作者 】

畢定，蘇寧易購消費者平臺研發中心產品經理，2015年加入蘇寧，一直負責蘇寧易購平臺內容管理系統的產品工作，經歷了系統的演化變遷，產品改版和迭代，致力於蘇寧全產業內容管理平臺的建設工作。