資訊保安聚合 Sec-News 的重構之路

NO IMAGE

不知道什麼時候突然發現我已經穩定執行了近半年的 sec-news ( http://wiki.ioin.in )突然變得特別慢,為跳轉效率我也是嘗試了很多方法,比如加快取。我使用了一個叫 flask-cache 的快取: https://pythonhosted.org/Flask-Cache/ ,很好用的 cache 。

特別喜歡 python 的一點就是,修飾器(@Decorator )的存在,讓很多功能變得簡單。 flask-cache 裡有一種 cache 方式叫 Memoization ,它可以簡單地用 Decorator 的方式放在任意函式上。根據函式引數的值,來快取函式的結果。

class Person(db.Model):
@cache.memoize(50)
def has_membership(self, role_id):
return Group.query.filter_by(user=self, role_id=role_id).count() >= 1

上面是文件裡給出的一個 example ,其快取了 has_membership 函式,當我們呼叫 has_membership(1)的時候,就快取下 50 秒這個函式的返回值。那麼下次再呼叫 has_membership(1)的時候,就會直接返回快取的結果,但如果你呼叫 has_membership(2),就是另一個快取了。

我將 flask-cache 加到 flask 的 view 裡,這樣就可以快取整個頁面了。

但是,快取永遠不是解決效率問題的根本方法,解決問題是找到根本原因。我仔細分析了我的 sec-news ,我認為以前使用的 mongodb 資料庫,是導致整個網站執行慢的原因。

也的確,我設計 mongodb 的概念和以前設計 mysql 的概念完全不同,我設計了這樣一個集合:

Rss

  • id

  • url

  • title

  • posts (array)

這個集合用來儲存 Rss 資料,比如 http://www.leavesongs.com/rss.php ,這是一個訂閱 Rss 。這個訂閱的內容,其實就是它的文章( posts ),我的訂閱列表中有幾個 Rss ,其中包含的文章已經超過 1000 篇,也就是 posts 陣列大小已經超過 1000 ,且陣列中每篇文章我都儲存了文章的標題和內容。

所以其實當我們沒有設計好 ORM 的情況下,提取出這個 Rss 集合,將佔用大量記憶體,導致 Sec-news 整體速度變慢。

這是我覺得影響網站效率的最大原因。備份資料後,我刪掉了所有文章的內容,再次測試,結果也一樣,速度並沒有變快。

我開始懷疑架構問題,我開始懷疑是 mongodb 哪裡有坑被我踩中了。這種問題對於半吊子開發我來說,實在是難以發現,難以解決。但在電腦維修界,有著名的『萬金油定律』——重啟、重灌、換電腦。既然解決不了問題,不如用簡單點的辦法規避問題。

我現在的位置可能位於重啟到重灌這條路上,在替換一些資料(重啟)的情況下並不能解決效率問題,那麼我就需要思考『重灌』的問題了。所謂的重灌,也就是換掉 mongodb 。

sec-news 在開發的時候就已經做到了 MVR ( Model – View – Route ),程式碼耦合性也比較低,但實際上替換資料庫的過程還是需要重構大量程式碼,主要原因就是 mongodb->mysql 是一場 Nosql 到 Sql 的轉變,基礎架構需要調整。

不過總程式碼量也不大,整個 view model 也只有 700 行程式碼左右,需要改動的部分不超過 200 行。重構過程還改進了很多功能、使用者體驗方面的問題(主要是後臺)。

重構後的 sec-news 還是用 ORM ,我在 peewee 和 sqlalchemy 中選擇了後者,因為 flask-sqlalchemy 是一個比較成熟的搭配,在實際開發中我比較看重穩定性,雖然個人感覺 peewee 更『酷』。

除了替換資料庫。細節上還有一處改進:我將 flask 原生的 client-side-session 換成了一個叫”flask-session”的 server-side-session 的外掛,以規避前段時間自己發現的『驗證碼繞過漏洞』。 flask-session 儲存在 redis 中,我喜歡 redis 勝過 memcache ,原因是 memcache 所擁有的功能 redis 都有,但 redis 所擁有的功能 memcache 並不一定有,所以我一般都不用 memcache 。

另外,我實現了後臺多使用者許可權控制,其實說起來也比較簡單:

def check_role(request_role):
def do_check(role_array):
def check(func):
@functools.wraps(func)
def do_function(*args, **kwargs):
if flask.session.get("user_id") > 0:
if flask.session.get("role") in role_array:
return func(*args, **kwargs)
else:
return permission_deny(*args, **kwargs)
else:
return flask.redirect(flask.url_for("login"))
return do_function
return check
return do_check(request_role)
@app.route('/admin')
@check_role(["admin", "user"])
def admin():
#show administrator index page
@app.route('/admin/add')
@check_role(["admin"])
def add():
#add a new administrator

再次感謝 python 的 Decorator ,我用一個簡單的 check_role 函式即可實現許可權控制。比如 admin 函式,可以允許 user 、 admin 兩個角色訪問,而 add 函式就只允許 admin 角色訪問,假設既不是 user 也不是 admin ,就直接跳到 login 頁面。

Decorator 也是我遲遲放不下 python 的原因,假設 php 裡也加入這個語法糖,那我保準不會用 python 寫網站了,很多方面還是 php 更方便。

在 Route 方面,我也做了一些改進。因為 mongodb 的預設索引_id 是一個 24 位 hash 值,不容易被使用者猜到,而 mysql 的主鍵通常是一個 AUTO_INCREMENT 的數字,好事者只需要編寫一個指令碼即可遍歷我的所有文章,我不喜歡這樣。

我用了 hashids 這個庫,將 int 型別的 id 轉換成了一個 hashids ,好事者猜不到這個字串,也就無法遍歷我的文章了。(當然可以寫爬蟲爬取,但這和遍歷有本質區別)

重構用了大概一天半,傳到原來的伺服器上,發現……這 TM 還是一樣慢啊……我真是錯怪 mongodb 了,我給你賠罪!

那麼現在,『重灌』這條路也死了,並沒有解決問題。

最後也就只剩『換電腦』了,我一咬牙一跺腳買了一臺阿里雲青島的伺服器(按流量計費,算下來還是不貴的,一個月 50RMB 左右)。這時候我基本上已經心力交瘁了,只想儘快把問題解決我好乾別的。

我用最快的速度部署好伺服器:

apt-get update
apt-get install nginx mysql-server mysql-client redis-server libjpeg-dev
git clone xxx
pip install -r requirements.txt
pip install gunicorn supervisor

直接安預設的,能用就行。因為伺服器帶的 ubuntu14 沒有 systemd ,我就選擇用 supervisor 管理我的 gunicorn 服務, nginx 簡單配了一下就了好了, mysql 最開始也直接用 root 賬號。

伺服器移到國內,還有一個問題就是域名,我的 leavesongs.com 是沒有備案的,所以新的 sec-news 域名不能再用這個子域名了。還好自己手上剛備案了一個新域名,我就直接用新域名下的子域名作為 sec-news 的域名。

那麼老域名的”遺產”怎麼辦?

400f4ee7jw1ezz0rwroe1j21320w2qdu.jpg

如上圖,有些網站還保留著我的老域名下的連結,我想盡量保持一切不變。於是我從老資料庫匯出了一個 json 格式的物件:_id : url ,在老 vps 上做了個簡單的轉發:

location ^~ /url/ {
rewrite ^/url/(.*)$ /old.php?hash=$1 last;
}
location = /old.php {
fastcgi_pass  unix:/var/run/php5-fpm.sock;
fastcgi_index index.php;
include fastcgi.conf;
}
location / {
rewrite ^/(.*) http://wiki.ioin.in/$1 permanent;
}

將所有 /url/開頭的連結轉發到 old.php 裡處理,其他連結就直接 301 到新域名下。那麼 old.php 就專門處理以前_id 是 24 位 hash 的連結:

<?php
$old_data = json_decode(file_get_contents('olddata.txt'), TRUE);
$hash = isset($_GET['hash']) ? $_GET['hash'] : "";
if($hash && array_key_exists($hash, $old_data)) {
header('Location: ' . $old_data[$hash]);
} else {
header('Location: http://wiki.ioin.in/url/' . $hash);
}

這樣就能保證以前的連結全部能夠訪問,新連結直接跳轉到新域名。

後面有空閒時間又慢慢優化了許多地方,找到幾個小夥伴一起更新一些好文章, sec-news 正式復活了。

希望我這次重構之路對大家的開發有啟發,也歡迎大家訂閱 Sec-News 的 RSS ,主頁: http://wiki.ioin.in ,訂閱: http://wiki.ioin.in/atom

分享幾張重構後後臺的截圖:

400f4ee7jw1ezz0t4jcjhj21kw0snwjr.jpg

400f4ee7jw1ezz0tb88i4j21ku0ksgp2.jpg

400f4ee7jw1ezz0tjdo64j21jm0tuwqu.jpg

400f4ee7jw1ezz14hna7yj21k40x4gs0.jpg

400f4ee7jw1ezz0u0b601j212c0jkgn3.jpg

400f4ee7jw1ezz0u7s1byj212e0py0ul.jpg