◆雷蕾

優(yōu)化網(wǎng)站重要頁面發(fā)布流程以提升內(nèi)容安全性

◆雷蕾

（新華網(wǎng)股份有限公司 北京 100031）

對網(wǎng)頁內(nèi)容安全性有較高要求的網(wǎng)站，必須從采編和技術(shù)兩個方面提高稿件的頁面的正確性。本文以網(wǎng)站首頁為例，通過對重要頁面的發(fā)布流程進行改造，將現(xiàn)有發(fā)布流程中位于發(fā)稿系統(tǒng)中的審看環(huán)節(jié)后置到真正的網(wǎng)絡分發(fā)前，有效隔離了編輯、傳輸、篡改等可能導致錯誤的環(huán)節(jié)對于重要頁面內(nèi)容正確性的影響。該優(yōu)化方案權(quán)衡了發(fā)稿效率、技術(shù)系統(tǒng)改造量、內(nèi)容安全性等各方面因素，在對現(xiàn)有機制最小化擾動的基礎上提升了內(nèi)容安全性。

網(wǎng)站發(fā)布流程；網(wǎng)頁內(nèi)容安全性；CDN分發(fā)

1 引言

對于內(nèi)容安全性有較高要求的網(wǎng)站在內(nèi)容發(fā)布之前，都會有嚴格的審校、預覽要求。但是，目前廣泛采用的網(wǎng)頁發(fā)布流程的預覽環(huán)節(jié)被安排在發(fā)稿環(huán)節(jié)，而最終真正分發(fā)到互聯(lián)網(wǎng)上的頁面，審校人員無法看到。這種情況下，不可避免發(fā)生展示效果和預期效果（預覽效果）有差異的情況，對于網(wǎng)站來講，即產(chǎn)生錯誤，例如圖片無法顯示（可能是文件存儲失敗）、稿件列表排序錯誤（可能是指令傳輸失?。┑?。

具體來看，就是在當前常用的網(wǎng)站發(fā)布模式中，內(nèi)容被預覽審核后，還需要經(jīng)歷幾個環(huán)節(jié)才能進入真正的網(wǎng)絡分發(fā)，即：頁面在發(fā)布前，預覽操作由編輯人員在內(nèi)容管理系統(tǒng)（CMS：Content Management System）中進行；而實際網(wǎng)民看到的頁面，來自內(nèi)容分發(fā)網(wǎng)絡（CDN：Content Delivery Network）服務器[1]，這些服務器上的內(nèi)容，是CMS中的內(nèi)容經(jīng)過多環(huán)節(jié)傳遞后的復制版本（見圖1 ）。也就是說，編輯人員預覽的內(nèi)容，存儲于CMS服務器，網(wǎng)民真正看到的頁面，存儲于CDN服務器；編輯人員預覽檢查的內(nèi)容和互聯(lián)網(wǎng)上的內(nèi)容，是兩個完全獨立的實例。因此，會發(fā)生正確的內(nèi)容經(jīng)過傳輸后發(fā)生錯誤，但是仍然被發(fā)布出去的問題。甚至有些拼裝頁面，頁面內(nèi)容生成后，經(jīng)過自動發(fā)布后，才能查看，無法預覽。

圖1 現(xiàn)有發(fā)布流程

當前常用的發(fā)布流程一般分為三部分（見圖中①②③）：

第一部分，由“CMS”和“編輯人員操作”共同組成。編輯人員對內(nèi)容進行編輯，然后在CMS中確定沒有問題后，點擊“發(fā)布”，CMS內(nèi)就生成靜態(tài)頁面，編輯人員進行預覽；

第二部分，是機器自動分發(fā)環(huán)節(jié)。CMS將第一部分產(chǎn)生的內(nèi)容發(fā)布到網(wǎng)頁防篡改系統(tǒng)（iGuard）上，iGuard再將這些內(nèi)容分發(fā)給Web服務器群（此處設定為20臺服務器。這些服務器存儲同樣的內(nèi)容，互為備份，由負載均衡設備負責任務分工調(diào)用）[2]；

第三部分，CDN自動獲取內(nèi)容并加速的部分。CDN根據(jù)配置，自動以一定的時間間隔經(jīng)過負載均衡設備獲取Web服務器上的各種內(nèi)容資源，并推給大量的CDN節(jié)點服務器進行緩存[3]。網(wǎng)民訪問網(wǎng)頁時，CDN會自動就近或者根據(jù)訪問壓力，將網(wǎng)民訪問引導到接入率較高的節(jié)點服務器。

上述發(fā)布流程是目前大型主流網(wǎng)站廣泛使用的發(fā)布模式，經(jīng)過多年發(fā)展進化，對于有海量發(fā)布任務的網(wǎng)站，這種模式有效地平衡了發(fā)布效率和內(nèi)容安全之間的關(guān)系。

但是，針對內(nèi)容安全性要求較高的網(wǎng)站，第二部分漫長的分發(fā)通道成為前面所述的漏洞。一旦分發(fā)通道中的任何一個環(huán)節(jié)出現(xiàn)問題，例如硬件故障（硬盤磁道有瑕疵、電源模塊出問題導致電壓不穩(wěn)而使得寫入失敗等）、軟件自身漏洞、軟件執(zhí)行線程沖突、網(wǎng)絡抖動、被攻擊等等，都有可能使網(wǎng)民看到的最終實例出錯。盡管出現(xiàn)這種失敗的概率很小，但是對于內(nèi)容安全性要求較高的網(wǎng)站，也可能會造成很嚴重的后果。

為了解決上述問題，考慮對現(xiàn)有內(nèi)容發(fā)布機制進行優(yōu)化：在CDN發(fā)布前增加預覽功能，改CDN自動更新為手動更新，以提高網(wǎng)站內(nèi)容安全性。鑒于手動更新效率有限，這樣的優(yōu)化不適合大量稿件發(fā)布，上述優(yōu)化方案限定只針對網(wǎng)站某些特定重要區(qū)域的內(nèi)容發(fā)布，本文討論針對首頁進行優(yōu)化。

首頁作為網(wǎng)站瀏覽入口，重要性不言而喻，對于差錯的敏感度極高，以下是首頁相關(guān)優(yōu)化過程。

1.1 首頁發(fā)布流程優(yōu)化一

在發(fā)布流程中，增加首頁在CDN發(fā)布前的預覽環(huán)節(jié)（見圖2）：

（1）對于首頁，取消CDN自動刷新發(fā)布，改為“手動刷新”。首先，確保首頁資源能夠通過一定規(guī)則篩選出來，以便CDN能夠在抓取目錄中，定位到首頁資源，從而制定獨立的抓取規(guī)則。其次，由于CDN并不支持取消自動刷新，所以，需將自動刷新間隔設置為較長時間，從而通過在較短間隔內(nèi)進行手動刷新的方式來模擬實現(xiàn)屏蔽自動刷新；

（2）在CDN刷新環(huán)節(jié)前，增加“首頁預覽”環(huán)節(jié)，即提供手段通過負載均衡瀏覽Web服務器上的待發(fā)布內(nèi)容。

但是，在這個架構(gòu)中，Web服務器群中會有多臺服務器（本例中是20臺），負載均衡每次隨機命中其中一臺對外提供服務，因此，在“首頁預覽”環(huán)節(jié)所看到的首頁以及手動刷新CDN時被發(fā)布的頁面，分別不確定會來自多臺中的哪一臺，很可能出現(xiàn)編輯看到的頁面沒有問題，但是真正發(fā)布的頁面，來自于另外一臺有問題的服務器，最終導致用戶看到的內(nèi)容有問題。因此，還需進一步優(yōu)化。

1.2 首頁發(fā)布流程優(yōu)化二

為了確保預覽和發(fā)布的頁面都沒有問題，針對上面的結(jié)構(gòu)，就必須檢查所有Web服務器上的內(nèi)容都是正確的。除此之外，還要從“負載均衡”的角度去確認一遍，以確保Web服務器上的頁面沒有問題，并且經(jīng)過負載均衡這個傳遞過程后，頁面也沒有問題（見圖3）。

圖3 首頁發(fā)布流程優(yōu)化二

但是，Web服務器有20臺，加上負載均衡這個節(jié)點，如果一一檢查確認的話，工作量很大，發(fā)布時效必將不能滿足要求，因此，必須減少編輯需要審看的節(jié)點。

1.3 首頁發(fā)布流程優(yōu)化三

為了確保發(fā)布時效，就必須減少編輯查看節(jié)點的數(shù)量，即上述方案中的Web服務器數(shù)量。

極端情況，如果Web服務器只有1臺，則可以確保無論編輯審看，還是CDN發(fā)布，內(nèi)容都來自這一臺機器。但是，因為單臺服務器的不可靠性，因此，考慮使用2臺Web服務器是否能夠滿足實際使用要求（見圖4）。

圖4 首頁發(fā)布流程優(yōu)化三

將Web服務器縮減至2臺，如果能夠滿足全站的載荷需求，那么方案三已經(jīng)能夠滿足加強首頁安全的要求。

但是，大型網(wǎng)站的CDN更新時對于Web服務器的并發(fā)連接數(shù)要求，遠遠大于2臺Web服務器的接入能力。因此，實際使用中，并不能簡單地縮減Web服務器數(shù)量。

1.4 首頁發(fā)布流程優(yōu)化四——最終方案

既要保證全站W(wǎng)eb服務器資源滿足CDN刷新連接數(shù)的要求，又要保證編輯檢查的頁面盡可能少，可以考慮首頁獨立使用2臺Web服務器，其他頁面共用其余更多的Web服務器（見圖5）。

圖5 首頁發(fā)布流程優(yōu)化四

要做到首頁Web服務器獨立，就需要：

（1）將首頁的資源和其他頁面資源完全獨立，以便CDN能夠使用特定路徑針對首頁制定獨立的刷新規(guī)則；

（2）驗證2臺Web服務器是否能夠承接首頁刷新的連接數(shù)要求。也就是說，手動刷新首頁機制下，對于服務器的并發(fā)連接數(shù)峰值是否在2臺Web服務器的連接處理能力內(nèi)。

實際上，采用手動刷新CDN首頁方式時，每次需要建立的連接，主要是用于獲取首頁的index文件，并以index文件為入口，進而對里面的因資源更新而產(chǎn)生的連接（如果是之前已有的舊資源，CDN不會去建立連接獲?。？紤]到首頁本身的資源量非常有限，并且每次發(fā)生變更的資源數(shù)量有限，2臺Web服務器完全能夠滿足要求。

以某政府網(wǎng)站為例，在瀏覽器獲取首頁時，資源請求連接數(shù)為150。在此基礎上，對于CDN刷新來講，考慮到每次更新首頁的資源變更有限，其對服務器的實際請求連接數(shù)要遠小于150。

在新增兩臺獨立Web服務器的情況下，為了最大限度確保編輯從負載均衡獲取到的預覽頁面和CDN從負載均衡獲取到的分發(fā)頁面來自同一臺服務器，可調(diào)整兩臺服務器在負載上的命中比例為極大值，本例中為16:1，則被檢驗頁面和CDN分發(fā)頁面來自同一臺機器的比例可以達到94.5%（1-16/17*1/17≈94.5%）。因此，權(quán)衡工作量和出錯概率，基本可以認為從負載均衡得到的預覽頁面和CDN分發(fā)頁面來自同一臺機器，只需從負載均衡預覽檢驗頁面內(nèi)容，不必單獨檢驗兩臺Web服務器上的內(nèi)容。

2 結(jié)論

本方案針對網(wǎng)站重要頁面，將現(xiàn)有發(fā)布機制中內(nèi)容預覽環(huán)節(jié)后置到網(wǎng)絡分發(fā)前，確保了CDN獲取并分發(fā)的頁面一定是經(jīng)過編輯確認后的內(nèi)容，即使在前面流程環(huán)節(jié)出現(xiàn)因編輯、傳輸、篡改而發(fā)生錯誤后，錯誤的內(nèi)容也不會被發(fā)布。該方案僅增加一條新的獨立發(fā)布鏈路，不改變和影響現(xiàn)有發(fā)布流程的技術(shù)架構(gòu)，不增加編輯工作量，有效提高了重要頁面發(fā)布內(nèi)容的正確性。

[1]李喬，何慧，張宏莉. 內(nèi)容分發(fā)網(wǎng)絡研究[J].電子學報， 2013（08）：106-114.

[2]張建超，張連堂. 網(wǎng)站架構(gòu)演變技術(shù)研究[J]. 現(xiàn)代計算機：專業(yè)版，2012（04）：55-57.

[3]韓強. 內(nèi)容分發(fā)網(wǎng)絡技術(shù)（CDN）簡析[J].中國傳媒科技，2006（4）：19-22.