說起系統穩定性,其實已經有很多文章了.我這裏結合自己實際項目中的一些情況,進行了反思.

業務場景其實也很簡單.就是我們需要做一個爬蟲去爬取別的網站的文章和圖片.

主要問題出在圖片上,當時我在想可不可以不爬取圖片,結果還是被要求把圖片也爬取下來.

我們的系統是有一個預覽模式的,就是這些爬取的文章在上線之前,會被人工檢測,沒有問題才上線.

在這個業務基礎上,我首先想到了公司有圖片服務器,可以直接把圖片url提供出去,讓服務器下載.服務器下載完了之後,會返回一個特定的公網鏈接.最後我再去修改爬取到的html代碼中的圖片鏈接,把指向本站的鏈接都改成指向圖片服務器的.

但是一看圖片服務器,使用了CDN.而手冊上又強調不能上傳"違法圖片".理由是如果上傳到運營商(比如電信)的圖片違法被發現,運營商會封掉整個CDN.

所以這裏有個雞生蛋蛋生雞的問題:如果不下載到圖片服務器(使用CDN),就沒法改寫html裏面的連接,就無法檢測這些圖片是否違法.而上傳到CDN,就有被運營商發現的危險.

目前的幾種方案:

1. 在文章正文提供原始來源的網頁url,在檢測的時候點進去看.

2. 先把圖片存儲在一個雲服務中,這個雲服務也可以通過訪問的域名控制是否開啟CDN.在預覽的時候,使用不開啟CDN的域名,在上線的時候,替換為使用CDN的域名

3. 直接使用CDN

4. 先爬取所有圖片,人工看一次

這幾種方案,也就第二種稍微靠譜一點.但是還是不太好.

原因就是系統穩定性,在預覽模式下,看到的html代碼會在上線時改動,這本身無論如何都引入和風險點.

這讓我想起了另外一個地方.那就是預覽模式的實現.(預覽模式需要跨站點,從一個應用跳轉到另外一個應用)

一開始,我們用了很簡單的方式,就是在url後面拼接一個密碼(拼接了這個密碼之後,即使沒有審核通過的,也可以被看到,也就是預覽).結果業務方說不行.他們要的效果是沒有審核通過,外部(公網)就看不到.

我的提議本來是做cookie進行識別.但是問題是cookie需要申請權限.

所以最後采取了別人的一個方案:預覽模式使用我們的預發環境.這個預發環境只有內網才能訪問.

這個解決方案怎麽樣呢?在我眼中是很不好的,因為用"業務"方法解決了"技術"問題.使用cookie是解決這個問題的"正途".因為跨站訪問的身份識別就應該用cookie.而這個方案看上去很簡單就解決了問題.但是引入了無窮多的問題點:

1. 每次上預發,預覽模式就不能正確使用

2. 業務方可能會在預覽模式下看到我們還沒有正式上線的內容(在預發環境回歸測試)

3. 改動較大時,預覽模式完全不可用.(預發環境裏面有的靜態資源直接使用了正式環境的域名,比如css這些,歷史遺留問題)

但是最後我沒能說服他們,多花點時間用"正途"解決問題.

最後談下我的思考吧.

很多人說"黑貓白貓,能抓耗子就是好貓",如果能用業務方法解決技術問題,那就沒必要改代碼,或者可以少改代碼.

但是我個人覺得這要根據具體情況來看.我目前看到的是,絕大多數情況下,一些"看上去很聰明"的業務式解決方案,本質上是規避了問題,埋下了隱患.在當時能被leader或者產品經理誇獎,但是最後遺留的問題還是要別人去解決.如果接手者不去解決這個問題,而通過業務方式再打個包往下傳遞,那麽這個系統的穩定性就會一步一步降低.

這恐怕就是大多數程序員痛苦的根源.

實際項目中對系統穩定性的一些思考