Repractise架構篇一：CMS的重構與演進

重構系統(tǒng)是一項非常具有挑戰(zhàn)性的事情。通常來說，在我們的系統(tǒng)是第二個系統(tǒng)的時候才需要重構，即這個系統(tǒng)本身已經很臃腫。我們花費了太量的時間在代碼間的邏輯，開發(fā)新的功能變得越來越慢。這不僅僅可能只是因為我們之前的架構沒有設計好，而且在我們開發(fā)的過程中沒有保持著原先設計時的一些原則。如果是這樣的情況，那么這就是一個復雜的過程。

還有一種情況是我們發(fā)現了一種更符合我們當前業(yè)務的框架。

動態(tài)CMS

CMS簡介

CMS是Content Management System的縮寫，意為"內容管理系統(tǒng)".它可以做很多的事情，但是總的來說就是Page和Blog——即我們要創(chuàng)建一些頁面可以用于寫一些About US、Contact Me，以及持續(xù)更新的博客或者新聞，以及其他子系統(tǒng)——通常更新不活躍。通過對這些博客或者新聞進行分類，我們就可以有不同的信息內容，如下圖：

CMS是政府和企業(yè)都需要的系統(tǒng)，他們有很多的信息需要公開，并且需要對其組織進行宣傳。在我有限的CMS交付經驗里（大學時期），一般第一次交付CMS的時候，已經創(chuàng)建了大部分頁面。有時候這些頁面可能直接存儲在數據庫中，后來發(fā)現這不是一個好的方案，于是很多頁面變成了靜態(tài)頁面。隨后，在CMS的生命周期里就是更新內容。

因而，CMS中起其主導的東西還是Content，即內容。而內容是一些持續(xù)可變的東西。這也就是為什么WordPress這么流行于CMS界，它是一個博客系統(tǒng)，但是多數時候我們只需要更新內容。除此不得不提及的一個CMS框架是Drupal，兩者一對比會發(fā)現Drupal比較強大。通常來說，強大的一個負作用就是——復雜。

WordPress和Drupal這一類的系統(tǒng)都屬于發(fā)布系統(tǒng)，而其后臺可以稱為編輯系統(tǒng)。

一般來說CMS有下面的特點：

• 支持多用戶。
• 角色控制-內容管理。如InfoQ的編輯后臺就會有這樣的機制，社區(qū)編輯負責創(chuàng)建內容，而審核發(fā)布則是另外的人做的。
• 插件管理。如WordPress和Drupal在這一方面就很強大，基本可以滿足日常的需要。
• 快捷簡便地存儲內容。簡單地來說就是所見即所得編輯器，但是對于開發(fā)者來說，Markdown似乎是好的選擇。
• 預發(fā)布。這是一個很重要的特性，特別是如果你的系統(tǒng)后臺沒有相對應的預覽機制。
• 子系統(tǒng)。由于這屬于定制化的系統(tǒng)，并不方便進行總結。
• ...

CMS一直就是這樣一個緊耦合的系統(tǒng)。

CMS架構與Django

說起來，我一直是一個CMS黨。主要原因還在于我可以隨心所欲地去修改網站的內容，修改網站的架構。好的CMS總的來說都有其架構圖，下圖似乎是Drupal的模塊圖

一般來說，其底層都會有：

• ORM
• User Management
• I18n / L10n
• Templates

我一直在使用一個名為Django的Python Web框架，它最初是被開發(fā)來用于管理勞倫斯出版集團旗下的一些以新聞內容為主的網站的，即是CMS（內容管理系統(tǒng)）軟件。它是一個MTV框架——與多數的框架并沒有太大的區(qū)別。

層次職責 模型（Model），即數據存取層 處理與數據相關的所有事務：如何存取、如何驗證有效性、包含哪些行為以及數據之間的關系等。 模板(Template)，即表現層 處理與表現相關的決定： 如何在頁面或其他類型文檔中進行顯示。 視圖（View），即業(yè)務邏輯層 存取模型及調取恰當模板的相關邏輯。模型與模板之間的橋梁。

從框架本身來上看它和別的系統(tǒng)沒有太大的區(qū)別。

但是如果我們已經有多外模塊（即Django中app的概念），那么系統(tǒng)的架構就有所不同了。

這就是為何我喜歡用這個CMS的原因了，我的每個子系統(tǒng)都以APP的形式提供服務——博客是一個app，sitemap是一個app，api是一個app。系統(tǒng)直接解耦為類似于混合服務的架構，即不像微服務一樣多語言化，又不會有宏應用的緊耦合問題。

編輯-發(fā)布分離

我們的編輯和發(fā)布系統(tǒng)在某種意義上緊耦合在一起了，當用戶訪問量特別大的時候，這樣會讓我們的應用變得特定慢。有時候編輯甚至發(fā)布不了新的東西，如下圖引示:

或者你認識出了上圖是源自Martin Folwer的編輯-發(fā)布分離

編輯-發(fā)布分離是幾年前解耦復雜系統(tǒng)游來開來帶來的一個成果。今天這個似乎已經很常見了，編輯的時候是在后臺進行的，等到發(fā)布的時候已經變成了一個靜態(tài)的HTML。

已經有足夠多的CMS支持這樣的特性，運行起來似乎特別不錯，當然這樣的系統(tǒng)也會有緩存的問題。有了APP這后，這個趨勢就更加明顯了——人們需要提供一個API。到底是在現有的系統(tǒng)里提供一個新的API，還是創(chuàng)建一個新的API。

這時候，我更愿意選擇后者——畢竟緊耦合一個系統(tǒng)總會在后期帶來足夠多的麻煩。而且基于數據庫構建一個只讀的RESTful API并不是一個復雜的過程，而且也危險。這時候的瓶頸就是數據庫，但是似乎數據庫都是多數系統(tǒng)的瓶頸。人們想出了各種各樣的技術來解決這個瓶頸。

于是之前我試著用Node.js + RESTify將我的博客重構成了一個SPA，當然這個時候CMS還在運行著。出于SEO的原因我并沒有在最后采用這個方案，因為我網站的主要流量來源是Google和是百度。但是我在另外的網站里混合了SPA與MPA，其中的性能與應用是相當的，除了第一次加載頁面的時候會帶來一些延時。

除了Node.js + RESTify，也試了試Python + Falcon（一個高性能的RESTful框架）。這個API理論上也應該可以給APP直接使用，并且可以直接拿來生成靜態(tài)頁面。

網頁題目：Repractise架構篇一：CMS的重構與演進
分享路徑：http://bm7419.com/news/86705.html

成都網站建設公司_創(chuàng)新互聯(lián)，為您提供移動網站建設、微信公眾號、服務器托管、靜態(tài)網站、企業(yè)網站制作、網站改版

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)