摘要：服務(wù)器移到國內(nèi)，還有一個問題就是域名，我的是沒有備案的，所以新的域名不能再用這個子域名了。還好自己手上剛備案了一個新域名，我就直接用新域名下的子域名作為的域名。

不知道什么時候突然發(fā)現(xiàn)我已經(jīng)穩(wěn)定運行了近半年的 sec-news （ http://wiki.ioin.in ）突然變得特別慢，為跳轉(zhuǎn)效率我也是嘗試了很多方法，比如加緩存。我使用了一個叫 flask-cache 的緩存: https://pythonhosted.org/Flask-Cache/ ，很好用的 cache 。

特別喜歡 python 的一點就是，修飾器（@Decorator ）的存在，讓很多功能變得簡單。 flask-cache 里有一種 cache 方式叫 Memoization ，它可以簡單地用 Decorator 的方式放在任意函數(shù)上。根據(jù)函數(shù)參數(shù)的值，來緩存函數(shù)的結(jié)果。

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 函數(shù)，當(dāng)我們調(diào)用 has_membership(1)的時候，就緩存下 50 秒這個函數(shù)的返回值。那么下次再調(diào)用 has_membership(1)的時候，就會直接返回緩存的結(jié)果，但如果你調(diào)用 has_membership(2)，就是另一個緩存了。

我將 flask-cache 加到 flask 的 view 里，這樣就可以緩存整個頁面了。

但是，緩存永遠不是解決效率問題的根本方法，解決問題是找到根本原因。我仔細分析了我的 sec-news ，我認為以前使用的 mongodb 數(shù)據(jù)庫，是導(dǎo)致整個網(wǎng)站運行慢的原因。

也的確，我設(shè)計 mongodb 的概念和以前設(shè)計 mysql 的概念完全不同，我設(shè)計了這樣一個集合：

Rss

id

url

title

posts (array)

這個集合用來存儲 Rss 數(shù)據(jù)，比如 http://www.leavesongs.com/rss.php ，這是一個訂閱 Rss 。這個訂閱的內(nèi)容，其實就是它的文章（ posts ），我的訂閱列表中有幾個 Rss ，其中包含的文章已經(jīng)超過 1000 篇，也就是 posts 數(shù)組大小已經(jīng)超過 1000 ，且數(shù)組中每篇文章我都保存了文章的標題和內(nèi)容。

所以其實當(dāng)我們沒有設(shè)計好 ORM 的情況下，提取出這個 Rss 集合，將占用大量內(nèi)存，導(dǎo)致 Sec-news 整體速度變慢。

這是我覺得影響網(wǎng)站效率的最大原因。備份數(shù)據(jù)后，我刪掉了所有文章的內(nèi)容，再次測試，結(jié)果也一樣，速度并沒有變快。

我開始懷疑架構(gòu)問題，我開始懷疑是 mongodb 哪里有坑被我踩中了。這種問題對于半吊子開發(fā)我來說，實在是難以發(fā)現(xiàn)，難以解決。但在電腦維修界，有著名的『萬金油定律』——重啟、重裝、換電腦。既然解決不了問題，不如用簡單點的辦法規(guī)避問題。

我現(xiàn)在的位置可能位于重啟到重裝這條路上，在替換一些數(shù)據(jù)（重啟）的情況下并不能解決效率問題，那么我就需要思考『重裝』的問題了。所謂的重裝，也就是換掉 mongodb 。

sec-news 在開發(fā)的時候就已經(jīng)做到了 MVR （ Model - View - Route ），代碼耦合性也比較低，但實際上替換數(shù)據(jù)庫的過程還是需要重構(gòu)大量代碼，主要原因就是 mongodb->mysql 是一場 Nosql 到 Sql 的轉(zhuǎn)變，基礎(chǔ)架構(gòu)需要調(diào)整。

不過總代碼量也不大，整個 view + model 也只有 700 行代碼左右，需要改動的部分不超過 200 行。重構(gòu)過程還改進了很多功能、用戶體驗方面的問題（主要是后臺）。

重構(gòu)后的 sec-news 還是用 ORM ，我在 peewee 和 sqlalchemy 中選擇了后者，因為 flask-sqlalchemy 是一個比較成熟的搭配，在實際開發(fā)中我比較看重穩(wěn)定性，雖然個人感覺 peewee 更『酷』。

除了替換數(shù)據(jù)庫。細節(jié)上還有一處改進：我將 flask 原生的 client-side-session 換成了一個叫"flask-session"的 server-side-session 的插件，以規(guī)避前段時間自己發(fā)現(xiàn)的『驗證碼繞過漏洞』。 flask-session 儲存在 redis 中，我喜歡 redis 勝過 memcache ，原因是 memcache 所擁有的功能 redis 都有，但 redis 所擁有的功能 memcache 并不一定有，所以我一般都不用 memcache 。

另外，我實現(xiàn)了后臺多用戶權(quán)限控制，其實說起來也比較簡單：

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 函數(shù)即可實現(xiàn)權(quán)限控制。比如 admin 函數(shù)，可以允許 user 、 admin 兩個角色訪問，而 add 函數(shù)就只允許 admin 角色訪問，假設(shè)既不是 user 也不是 admin ，就直接跳到 login 頁面。

Decorator 也是我遲遲放不下 python 的原因，假設(shè) php 里也加入這個語法糖，那我保準不會用 python 寫網(wǎng)站了，很多方面還是 php 更方便。

在 Route 方面，我也做了一些改進。因為 mongodb 的默認索引_id 是一個 24 位 hash 值，不容易被用戶猜到，而 mysql 的主鍵通常是一個 AUTO_INCREMENT 的數(shù)字，好事者只需要編寫一個腳本即可遍歷我的所有文章，我不喜歡這樣。

我用了 hashids 這個庫，將 int 類型的 id 轉(zhuǎn)換成了一個 hashids ，好事者猜不到這個字符串，也就無法遍歷我的文章了。（當(dāng)然可以寫爬蟲爬取，但這和遍歷有本質(zhì)區(qū)別）

重構(gòu)用了大概一天半，傳到原來的服務(wù)器上，發(fā)現(xiàn)……這 TM 還是一樣慢啊……我真是錯怪 mongodb 了，我給你賠罪！

那么現(xiàn)在，『重裝』這條路也死了，并沒有解決問題。

最后也就只剩『換電腦』了，我一咬牙一跺腳買了一臺阿里云青島的服務(wù)器（按流量計費，算下來還是不貴的，一個月 50RMB 左右）。這時候我基本上已經(jīng)心力交瘁了，只想盡快把問題解決我好干別的。

我用最快的速度部署好服務(wù)器：

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

直接安默認的，能用就行。因為服務(wù)器帶的 ubuntu14 沒有 systemd ，我就選擇用 supervisor 管理我的 gunicorn 服務(wù)， nginx 簡單配了一下就了好了， mysql 最開始也直接用 root 賬號。

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

那么老域名的"遺產(chǎn)"怎么辦？

如上圖，有些網(wǎng)站還保留著我的老域名下的鏈接，我想盡量保持一切不變。于是我從老數(shù)據(jù)庫導(dǎo)出了一個 json 格式的對象：_id : url ，在老 vps 上做了個簡單的轉(zhuǎn)發(fā)：

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/開頭的鏈接轉(zhuǎn)發(fā)到 old.php 里處理，其他鏈接就直接 301 到新域名下。那么 old.php 就專門處理以前_id 是 24 位 hash 的鏈接：

這樣就能保證以前的鏈接全部能夠訪問，新鏈接直接跳轉(zhuǎn)到新域名。
后面有空閑時間又慢慢優(yōu)化了許多地方，找到幾個小伙伴一起更新一些好文章， sec-news 正式復(fù)活了。
希望我這次重構(gòu)之路對大家的開發(fā)有啟發(fā)，也歡迎大家訂閱 Sec-News 的 RSS ，主頁： http://wiki.ioin.in ，訂閱： http://wiki.ioin.in/atom
分享幾張重構(gòu)后后臺的截圖：