軟件架構閱讀筆記13

京東上千頁面搭建基石——CMS先後端分離演進史

CMS即內容管理系統（ContentManagementSystem），目的是用於快速進行網站建設或者網頁開發。

CMS最核心的目的就是進行數據和模板的統一管理、頁面的統一發布,從而減小以前的不少重複工做。

cms是一個集標準服務管理、標準組件服務和智能投放於一體的標準化導購運營系統。具備如下特色：

• 搭建快速，統一發布，統一架構；
• 先後端分離，後端再也不負責頁面渲染，只提供高性能、可複用的API；
• 移動端頁面支持；
• 數據分析、智能投放的特色；

業務支持場景：

首頁、頻道頁、垂直頁、活動頁的搭建及單品頁、列表頁部分可維護的業務等。

架構的三個階段：

CMS 1.0——虛擬分類系統

CMS 2.0——CMS系統

CMS 3.0——CMS-portal系統

CMS 1.0—虛擬分類系統

虛擬分類系統當時只是一個基礎數據維護平臺。

存在問題：沒法實現信息的共享、複用和集約化管理。這就會存在各類各樣的頻道頁系統，致使管理混亂，性能上各有差別，出現過不少次事故。並且各系統須要獨立配置，致使工做量大，佔用資源多，沒法快速響應業務需求。

CMS 2.0—CMS系統

Cms2.0總結了1.0時的不足，從節省資源、控制成本的角度考慮，把導購類的個體頁面業務進行了統一，模板能複用的複用，之前虛擬分類系統的頻道也須要遷移到新的系統。

改進：

• CMS 2.0數據結構適合虛擬分類體系，方便新老數據兼容；
• 升級架構，統一配置、發佈流程；去memcache爲redis，作大量性能壓測來調優php-fpm配置，單機TPS能達到3000+； 配置定時任務，保證redis數據實時性；
• 單點發布，一鍵預覽加強採銷維護數據的機動性；
• 單機閉環，單機閉環服務設計是CMS總體架構的核心部分，須要展現的內容在本機獲取、封裝、校驗；
• 模塊化、動態數據類型初期版本

對比1.0，新的CMS可讓頻道頁的開發週期下降2~4周，大大提升了業務需求的響應速度；它看起來更獨立，更像一個總體，在容災、規避風險方面作了嚴謹的優化；同時讓採銷在維護數據時，更方便、更簡單。

存在問題：

後續因爲個性化的需求愈來愈多，大量的頻道業務須要開發人員一個一個套模板來實現，大大加大了開發人員的工做強度，以前的模板複用方式已經沒法知足業務的需求，同時太簡單的數據模塊，須要手工來綁定數據類型也增長了開發成本

CMS 3.0—CMS-portal系統

改進：

CMS 2.0後也存在不少痛點，所以咱們也想在CMS3.0上解決這些問題：

• 本質問題就是要快：快速支持、響應業務愈來愈多的垂直化頁面改版；
• 先後端分離，頁面渲染讓前端實現，解放後端讓後端作高大上的事情；
• 減輕運營人員的工做量，系統簡單好用，提升導購類商品的轉化率；
• 其餘系統的支撐，實現CMS的集約化管理；
• 兼容手機端；
• 站點管理、統一架構、容災、高性能、水平擴容；

經過兩版CMS系統的開發，發現CMS無外乎管理的是數據和模板，另外須要好的預覽、一鍵發佈支持。而傳統數據管理都是靜態數據類型，而作了動態數據類型的設計；另外咱們作了模板管理中心，並抽象了模板、樓層、元件、模塊的概念，從而實現更好的複用性。