nginx實現老項目無痛重構及PHP多版本共存

本文已參與好文召集令活動，點擊查看：後端、大前端雙賽道投稿，2萬元獎池等你挑戰！

背景

剛進公司不久，我接手了一個老項目，看到項目代碼，我崩潰了，php5.3，程序和數據庫都是gbk編碼，手寫的orm操做，開發了一段時間以後，讓我彆扭的地方主要有如下幾點：

一、框架和不少組件都是之前的開發本身封裝的，沒有使用文檔。

二、程序和數據庫都是gbk編碼，運營的同事時不時的過來問，我剛纔填的東西怎麼又亂碼了... ...

三、php版本低，不少高版本的方法用不了，沒有自動加載，許多新的組件包引入不了，而且穩定的最新包都要求php7以上版本。

四、項目經手的開發人員太多，業務邏輯複雜，不少無用的代碼沒有刪除，有很明顯爲了完成某個小功能簡單修補的痕跡。

與技術負責人和產品經理討論以後，由於這個項目後面調整的地方比較多而且要長期維護的，因此爲了項目更好的發展，仍是決定重構一下。

這裏仍是要說明一下，重構並非說以前的項目很糟糕，相反通過這麼多年的產品迭代，這麼多人員的開發，還能穩定的運行和開發，說明架構仍是能夠的，我也從裏面許多開發人員本身封裝的功能中學到了不少。

重構流程

一、服務器上再配一個高版本的PHP，我配置的是php7.3。

二、框架選擇的是Yii2（也能夠選擇其餘框架，本身使用方便就好），配置好數據庫、redis及其餘第三方庫的鏈接，與老項目保持一致。

三、與產品肯定要重構的第一個url地址，在新框架裏重寫該地址的代碼。

四、服務器nginx配置上面url地址的重定向。

五、長時間重複三、4步操做，直到重構完大部分核心頁面（到如今我也沒重構完，由於有些頁面功能簡單，並且之後改動概率極低）。

六、與運維一塊兒把數據庫編碼所有改爲utf-8，線上操做前仍是要反覆在測試服務器上轉碼測試，確保不會出現亂碼的問題。

注：其實更改數據庫編碼與重構項目代碼沒有前後順序，不一樣編碼的程序數據庫鏈接時指定好對應的編碼就好了，另外要提醒的是，該操做要根據實際狀況，若是數據在不斷的實時更新，數據準確性要求比較高，仍是建議不要操做，挺危險的。

Nginx配置和PHP多版本共存

因爲這個項目是個很老的項目，框架也是以前的開發本身寫的，美化url的方法是用了nginx的rewrite模塊來實現url的重寫，nginx配置大體是這樣的：

server {
    listen 80;
    server_name  www.test.com;
    # 老項目的代碼目錄
    root /var/www/test.com;
    index index.php index.html index.htm;

    location / {
        # 大體意思就是 找post控制器裏的detail方法，並把id參數傳過去
        rewrite "^/post/(\d{1,6}).html$" /server/index.php?con=post&ac=detail&id=$1 last;
        # 意思基本同上
        rewrite "^/article/(\d{1,6}).html$" /server/index.php?con=article&ac=detail&id=$1 last;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_split_path_info  ^((?U).+\.php)(/?.+)$;
        fastcgi_pass unix:/var/run/php/php5.3-fpm.sock;
    }
}
複製代碼

若是不作url的美化，上面想訪問詳情頁url地址是：

http://www.test.com/server/index.php?con=post&ac=detail&id=123 
http://www.test.com/server/index.php?con=article&ac=detail&id=123
複製代碼

nginx把url地址重寫後，訪問詳情頁就變成了：

http://www.test.com/post/123.html  
http://www.test.com/article/123.html
複製代碼

很顯然第二種url地址，用戶看起來更順眼，但寫成第二種方式顯然不是爲了讓用戶看着順眼，而是第二種方式搜索引擎更喜歡，更容易幫咱們引流。

如今的框架好比laravel或者yii2框架都是自帶url重寫功能，因此上面那種nginx配置已經很難見到了。其餘的就很少說了，看如何更改上面的nginx配置。

經過觀察上面的nginx配置能夠發現，若是咱們想要在url地址不變的狀況下，用新框架重寫單個url地址的代碼，只須要把rewrite後面的指向更改一下就行，例如

# 更改後的地址
rewrite "^/post/(\d{1,6}).html$" /index.php?r=post/detail&id=$1 last;
# 沒更改的地址
rewrite "^/article/(\d{1,6}).html$" /server/index.php?con=article&ac=detail&id=$1 last;
複製代碼

更改完問題來了，新老代碼是兩個項目，有兩個問題：

1. 怎麼讓第一個地址訪問新項目的代碼，讓第二個訪問老項目的代碼
2. 新項目代碼是用的php7.3，老項目用的是php5.3，怎麼讓它根據項目自動選擇php版本

經過觀察nginx配置咱們發現，最下面那個location是用了正則匹配的，匹配地址中有".php"默認用PHP去解析，因此咱們只須要再加一個正則，新老項目添加一個明顯的區分標識就好了，根據這個標識判斷項目和php版本，我是更改的入口文件，把index.php更改爲index-prod.php，更改完是這樣的

# 更改後的地址
rewrite "^/post/(\d{1,6}).html$" /index-prod.php?r=post/detail&id=$1 last;
# 沒更改的地址
rewrite "^/article/(\d{1,6}).html$" /server/index.php?con=article&ac=detail&id=$1 last;
複製代碼

完整的nginx配置是這樣的：

server {
    listen 80;
    server_name  www.test.com;
    # 老項目的代碼目錄
    root /var/www/test.com;
    index index.php index.html index.htm index-prod.php;

    location / {
        # 更改後的地址
        rewrite "^/post/(\d{1,6}).html$" /index-prod.php?r=post/detail&id=$1 last;
        # 沒更改的地址
        rewrite "^/article/(\d{1,6}).html$" /server/index.php?con=article&ac=detail&id=$1 last;
    }
    
    # 匹配入口文件，判斷是否要走新代碼
    location ~ index\-prod.php$ {
        # 更改項目路徑
        root /var/www/new.test.com/frontend/web;
        include snippets/fastcgi-php.conf;
        # 更改新代碼使用的PHP版本
        fastcgi_pass unix:/var/run/php/php7.3-fpm.sock;
        fastcgi_split_path_info  ^((?U).+\.php)(/?.+)$;
    }

    # 默認走老代碼
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_split_path_info  ^((?U).+\.php)(/?.+)$;
        fastcgi_pass unix:/var/run/php/php5.3-fpm.sock;
    }
}
複製代碼

結語

經過上面的方法，我在不耽誤正常業務開發的狀況下，一點一點完成了核心業務的重構，雖然如今也沒有重構完，但已經不影響新的開發和新的員工的融入。有些url改動概率很低功能也很穩定，因此就不動了，也不能爲了重構而重構，畢竟咱們還有好多工做。

nginx的功能有不少，上面只用了不多的一部分，感興趣的朋友能夠深刻了解一下，必定會給你不少驚喜。上面有不對的地方，也歡迎你們指正。