摘要：重構(gòu)系統(tǒng)是一項(xiàng)非常具有挑戰(zhàn)性的事情。架構(gòu)與說(shuō)起來(lái)，我一直是一個(gè)黨。如下圖是采用的架構(gòu)這與我們?cè)陧?xiàng)目上的系統(tǒng)架構(gòu)目前相似。而這是大部分所不支持的。允許內(nèi)容通過(guò)內(nèi)容服務(wù)更新使用于是，有了一個(gè)名為的框架用于管理內(nèi)容，并存儲(chǔ)為。

重構(gòu)系統(tǒng)是一項(xiàng)非常具有挑戰(zhàn)性的事情。通常來(lái)說(shuō)，在我們的系統(tǒng)是第二個(gè)系統(tǒng)的時(shí)候才需要重構(gòu)，即這個(gè)系統(tǒng)本身已經(jīng)很臃腫。我們花費(fèi)了太量的時(shí)間在代碼間的邏輯，開發(fā)新的功能變得越來(lái)越慢。這不僅僅可能只是因?yàn)槲覀冎暗募軜?gòu)沒(méi)有設(shè)計(jì)好，而且在我們開發(fā)的過(guò)程中沒(méi)有保持著原先設(shè)計(jì)時(shí)的一些原則。如果是這樣的情況，那么這就是一個(gè)復(fù)雜的過(guò)程。

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

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

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

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

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

一般來(lái)說(shuō)CMS有下面的特點(diǎn)：

支持多用戶。

角色控制-內(nèi)容管理。如InfoQ的編輯后臺(tái)就會(huì)有這樣的機(jī)制，社區(qū)編輯負(fù)責(zé)創(chuàng)建內(nèi)容，而審核發(fā)布則是另外的人做的。

插件管理。如WordPress和Drupal在這一方面就很強(qiáng)大，基本可以滿足日常的需要。

快捷簡(jiǎn)便地存儲(chǔ)內(nèi)容。簡(jiǎn)單地來(lái)說(shuō)就是所見(jiàn)即所得編輯器，但是對(duì)于開發(fā)者來(lái)說(shuō)，Markdown似乎是好的選擇。

預(yù)發(fā)布。這是一個(gè)很重要的特性，特別是如果你的系統(tǒng)后臺(tái)沒(méi)有相對(duì)應(yīng)的預(yù)覽機(jī)制。

子系統(tǒng)。由于這屬于定制化的系統(tǒng)，并不方便進(jìn)行總結(jié)。

...

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

說(shuō)起來(lái)，我一直是一個(gè)CMS黨。主要原因還在于我可以隨心所欲地去修改網(wǎng)站的內(nèi)容，修改網(wǎng)站的架構(gòu)。好的CMS總的來(lái)說(shuō)都有其架構(gòu)圖，下圖似乎是Drupal的模塊圖

一般來(lái)說(shuō)，其底層都會(huì)有：

ORM

User Management

I18n / L10n

Templates

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

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

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

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

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

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

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

已經(jīng)有足夠多的CMS支持這樣的特性，運(yùn)行起來(lái)似乎特別不錯(cuò)，當(dāng)然這樣的系統(tǒng)也會(huì)有緩存的問(wèn)題。有了APP這后，這個(gè)趨勢(shì)就更加明顯了——人們需要提供一個(gè)API。到底是在現(xiàn)有的系統(tǒng)里提供一個(gè)新的API，還是創(chuàng)建一個(gè)新的API。

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

于是之前我試著用Node.js + RESTify將我的博客重構(gòu)成了一個(gè)SPA，當(dāng)然這個(gè)時(shí)候CMS還在運(yùn)行著。出于SEO的原因我并沒(méi)有在最后采用這個(gè)方案，因?yàn)槲揖W(wǎng)站的主要流量來(lái)源是Google和是百度。但是我在另外的網(wǎng)站里混合了SPA與MPA，其中的性能與應(yīng)用是相當(dāng)?shù)模说谝淮渭虞d頁(yè)面的時(shí)候會(huì)帶來(lái)一些延時(shí)。

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

如React一樣解決DOM性能的問(wèn)題就是跳過(guò)DOM這個(gè)坑，要跳過(guò)動(dòng)態(tài)網(wǎng)站的性能問(wèn)題就是讓網(wǎng)站變成靜態(tài)。

越來(lái)越多的開發(fā)人員開始在使用Github Pages作為他們的博客，這是一個(gè)很有意思的轉(zhuǎn)變。主要的原因是這是免費(fèi)的，并且基本上可以保證24x7小時(shí)是可用的——當(dāng)且僅當(dāng)Github發(fā)現(xiàn)故障的時(shí)候才會(huì)不可訪問(wèn)。

在這一類靜態(tài)站點(diǎn)生成器(Github)里面，比較流行的有下面的內(nèi)容（數(shù)據(jù)來(lái)源： http://segmentfault.com/a/1190000002476681）:

Jekyll / OctoPress。Jekyll和OctoPress是最流行的靜態(tài)博客系統(tǒng)。

Hexo。Hexo是NodeJS編寫的靜態(tài)博客系統(tǒng)，其生成速度快，主題數(shù)量相對(duì)也比較豐富。是OctoPress的優(yōu)秀替代者。

Sculpin。Sculpin是PHP的靜態(tài)站點(diǎn)系統(tǒng)。Hexo和Octopress專注于博客，而有時(shí)候我們的需求不僅僅是博客，而是有類似CMS的頁(yè)面生成需求。Sculpin是一個(gè)泛用途的靜態(tài)站點(diǎn)生成系統(tǒng)，在支持博客常見(jiàn)的分頁(yè)、分類tag等同時(shí)，也能較好地支持非博客的一般頁(yè)面生成。

Hugo。Hugo是GO語(yǔ)言編寫的靜態(tài)站點(diǎn)系統(tǒng)。其生成速度快，且在較好支持博客和非博客內(nèi)容的同時(shí)提供了比較完備的主題系統(tǒng)。無(wú)論是自己寫主題還是套用別人的主題都比較順手。

通常這一類的工具里會(huì)有下面的內(nèi)容：

模板

支持Markdown

元數(shù)據(jù)

如Hexo這樣的框架甚至提供了一鍵部署的功能。

在我們寫了相關(guān)的代碼之后，隨后要做的就是生成HTML。對(duì)于個(gè)人博客來(lái)說(shuō)，這是一個(gè)非常不錯(cuò)的系統(tǒng)，但是對(duì)于一些企業(yè)級(jí)的系統(tǒng)來(lái)說(shuō)，我們的要求就更高了。如下圖是Carrot采用的架構(gòu)：

這與我們?cè)陧?xiàng)目上的系統(tǒng)架構(gòu)目前相似。作為一個(gè)博主，通常來(lái)說(shuō)我們修改博客的主題的頻率會(huì)比較低， 可能是半年一次。如果你經(jīng)常修改博客的主題，你博客上的文章一定是相當(dāng)?shù)纳佟?/p>

上圖中的編輯者通過(guò)一個(gè)名為Contentful CMS來(lái)創(chuàng)建他們的內(nèi)容，接著生成RESTful API。而類似的事情，我們也可以用Wordpress + RESTful 插件來(lái)完成。如果做得好，那么我想這個(gè)API也可以直接給APP使用。

上圖中的開發(fā)者需要不斷地將修改的主題或者類似的東西PUSH到版本管理系統(tǒng)上，接著會(huì)有webhook監(jiān)測(cè)到他們的變化，然后編譯出新的靜態(tài)頁(yè)面。

最后通過(guò)Netlify，他們編譯到了一起，然后部署到生產(chǎn)環(huán)境。除了Netlify，你也可以編寫生成腳本，然后用Bamboo、Go這類的CI工具進(jìn)行編譯。

通常來(lái)說(shuō)，生產(chǎn)環(huán)境可以使用CDN，如CloudFront服務(wù)。與動(dòng)態(tài)網(wǎng)站相比，靜態(tài)網(wǎng)站很容易直接部署到CDN，并可以直接從離用戶近的本地緩存提供服務(wù)。除此，直接使用AWS S3的靜態(tài)網(wǎng)站托管也是一個(gè)非常不錯(cuò)的選擇。

盡管我們已經(jīng)在項(xiàng)目上實(shí)施了基于Github的部分內(nèi)容管理已經(jīng)有些日子里，但是由于找不到一些相關(guān)的資料，便不好透露相關(guān)的細(xì)節(jié)。直到我看到了《An Incremental Approach to Content Management Using Git 1》，我才意識(shí)到這似乎已經(jīng)是一個(gè)成熟的技術(shù)了。看樣子這項(xiàng)技術(shù)首先已經(jīng)應(yīng)用到了ThoughtWorks的官網(wǎng)上了。

文中提到了使用這種架構(gòu)的幾個(gè)點(diǎn)：

快速地開始項(xiàng)目，而不是學(xué)習(xí)或者配置框架。

需要使用我們信奉的原則，如TDD。而這是大部分CMS所不支持的。

基于服務(wù)的架構(gòu)。

靈活的語(yǔ)言和工具

我們是開發(fā)人員。

So，so，這些開發(fā)人員做了些什么：

內(nèi)容存儲(chǔ)為靜態(tài)文件

不是所有的內(nèi)容都是平等的

引入內(nèi)容服務(wù)

使用Github。所有的content會(huì)提交到一個(gè)repo里，同時(shí)在我們push內(nèi)容的時(shí)候，可以實(shí)時(shí)更新這些內(nèi)容。

允許內(nèi)容通過(guò)內(nèi)容服務(wù)更新

使用Github API

于是，有了一個(gè)名為Hacienda的框架用于管理內(nèi)容，并存儲(chǔ)為JSON。這意味著什么？

因?yàn)槭褂昧薌it，我們可以了解到一個(gè)文件內(nèi)容的歷史版本，相比于WordPress來(lái)說(shuō)更直觀，而且更容易 上手。

開發(fā)人員修改完他們的代碼后，就可以直接提交，不會(huì)影響到Editor使用網(wǎng)站。Editor通過(guò)一個(gè)編輯器添加內(nèi)容，在保存后，內(nèi)容以JSON的形式出現(xiàn)直接提交代碼到Github上相應(yīng)的代碼庫(kù)中。CI或者Builder監(jiān)測(cè)到他們的辦法，就會(huì)生成新的靜態(tài)頁(yè)面。在這時(shí)候，我們可以選擇有一個(gè)預(yù)覽的平臺(tái)，并且可以一鍵部署。那么，事情似乎就完成得差不多了。

如果我們有APP，那么我們就可以使用Content Servies來(lái)做這些事情。甚至可以直接拿其搭建一個(gè)SPA。

如果我們需要全文搜索功能，也變得很簡(jiǎn)單。我們已經(jīng)不需要直接和數(shù)據(jù)庫(kù)交互，我們可以直接讀取JSON并且構(gòu)建索引。這時(shí)候需要一個(gè)簡(jiǎn)單的Web服務(wù)，而且這個(gè)服務(wù)還是只讀的。

在需要的時(shí)候，如手機(jī)APP，我們可以通過(guò)Content Servies來(lái)創(chuàng)建博客。

思考完這些后，我想到了一個(gè)符合學(xué)習(xí)的場(chǎng)景。

我們構(gòu)建的核心都可以基于Travis CI來(lái)完成，唯一存在風(fēng)險(xiǎn)的環(huán)節(jié)是我們似乎需要暴露我們的Key。

原文: Repractise架構(gòu)篇一: CMS的重構(gòu)與演進(jìn)

參考文章:

靜態(tài)網(wǎng)站生成器將會(huì)成為下一個(gè)大熱門

EditingPublishingSeparation

An Incremental Approach to Content Management Using Git 1

Part 2: Implementing Content Management and Publication Using Git