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

不知道什么時候突然發現我已經穩定運行了近半年的 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 的域名。

那么老域名的"遺產"怎么辦？

如上圖，有些網站還保留著我的老域名下的鏈接，我想盡量保持一切不變。于是我從老數據庫導出了一個 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 的鏈接：

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