對一個「老」架構的從新思考

前言

五年前，我在CNBLOG寫的一篇文章，《php+mysql下，對網站架構方面的一些認識（以我維護的站點爲例）》，固然，整套架構不是作的，而是配合當初的運維部門，共同完成。那個時候我從入行PHP兩年，對所謂的「架構」也是懵懂。只以爲很深奧，很高大上。那時候，架構師，那簡直就是神通常的職位。

當時，這篇文章被不少站點收錄，諸如：51CTO、CSDN等這樣的大站，也有不少小站。不過文章中，我已經去掉了不少的配圖，由於可能涉及到安全因素。在當時看，架構仍是蠻不錯的。可是也存在較多問題。

放眼如今，咱們能夠從新整理這套架構

• 找到能夠優化的地方

• 找到替代的方案

須要思考地方

咱們先來看下架構圖：

從上圖，咱們分兩大部分，分析：

• 左側的程序代碼同步

• 右側的架構

如何優化

現有作法：

從版本管理工具拉取最新代碼，除去.svn標記等文件，同步到生產環境

svn拉取最新代碼 -> 測試服務器 -->rsync同步--> 生產環境

存在的問題：

一、採用svn進行版本管理，不利於團隊協做開發；常常會出現修改的文件又被以前的覆蓋了，白作了

二、在項目較大的狀況下，全部的資源控制系統都是把文件的元信息隱藏在一個相似.svn，這個.svn文件會巨大，
svn是按照文件進行比較的，會佔用很大資源

進一步優化：

使用SVN進行版本管理，和程序發佈，不方便進行測試環境和生產環境的代碼區分，麻煩點，能夠解決

trunk->tag

trunk的發佈到測試環境

tag的發佈到生產環境

tag的程序均是通過測試經過的，由trunk合併過來的

最優方案：

採用git版本管理工具

svn 與 git 的區別

• 最核心的區別Git是分佈式的，而Svn不是分佈的。svn必須聯網進行操做。好處是跟其餘同事不會有太多的衝突，本身寫的代碼放在本身電腦上，一段時間後再提交、合併，也能夠不用聯網在本地提交。

• GIT把內容按元數據方式存儲，而SVN是按文件。你會發現有個.svn 這個文件會愈來愈大。

• GIT分支和SVN的分支不一樣。分支在svn中並不突出。常見的就是branch，它是一個完整的目錄。而git的特徵就是分支。

SVN的特色是簡單，使用一箇中央版本庫。

Git的對分支和合並有更好的支持,這是開發者最關心的。

具體作法：

一、創建兩個分支：master 和 develop
二、master用於生產環境，develop用戶測試環境。
三、master分支禁止被提交（commit、push），只准從develop或hotfix（線上bug）合併而來。
四、服務器上寫一個shell腳本，用來作兩件事，一是拉取最新代碼，而是rsync同步代碼

剩下的是團隊成員開發協做、以及發佈流程相關問題。

一、如何協做開發？參考這篇文章 Git 在團隊中的最佳實踐--如何正確使用Git Flow，寫的很不錯。不少公司在此基礎上進行優化和改進

二、發佈流程，我這裏草擬了一份，增長了一個pre_product預發佈分支。可能在你公司就不適合，請酌情調整。

咱們用的是Teambition項目管理工具，能夠新建個TAB，如：opend、working on、pull request、review、

merged、done。任務有技術負責人下發，成員認領開發。

代碼審查

你Google一下Code Reivew這個關鍵詞，你就會發現Code Review的好處基本上是不存在爭議的，有不少不少的文章和博文都在說Code Review的重要性，怎麼作會更好，並且不少公司在面試過程當中會加入「Code Review」的問題。

可是，咱們常常會遇到這種狀況：

1）工期壓得太緊，時間連coding都不夠，以上線爲目的，

2）需求老變，代碼的生命週期過短。因此，寫好的代碼沒有任何意義，爛就爛吧，反正與績效無關。

其實，我認爲這是很不負責任的。後面，咱們會用大量時間來解決以前本不應發生的問題。

架構優化

LVS部分可使用nginx的反向代理去實現，道理與LVS相同。用戶請求到代理服務器，nginx代理服務器分發請求到後端WEB,我找了個圖，方便你們去理解

nginx特色

nginx性能好，承擔高的負載壓力且穩定，能夠負載超過1萬的併發。

工做在網絡的7層之上，能夠針對http應用作一些分流的策略，好比針對域名、目錄結構；

Nginx對網絡的依賴比較小；

Nginx安裝和配置比較簡單，測試起來比較方便；

Nginx對請求的異步處理能夠幫助節點服務器減輕負載；

LVS的特色

抗負載能力強、是工做在網絡4層之上僅做分發之用，沒有流量的產生；

配置性比較低，這是一個缺點也是一個優勢，由於沒有可太多配置的東西，因此並不須要太多接觸，大大減小了人爲出錯的概率；

工做穩定，自身有完整的雙機熱備方案；

無流量，保證了均衡器IO的性能不會收到大流量的影響；

LVS須要向IDC多申請一個IP來作Visual IP，所以須要必定的網絡知識，因此對操做人的要求比較高；

具體看你的業務狀況，使用nginx或者lvs。當初公司的日均PV均超過100W，因此採用的是LVS方案+雙機熱備

集羣優化

架構圖上是兩主兩從MMM （Master-Masterreplication manager for MySQL）。其實很長狀況下，是一主三從模式。只有在master1宕機的狀況下，才啓用master2。

主從複製

MySQL複製基於主服務器在二進制日誌中跟蹤全部對數據庫的更改(更新、刪除等等)。所以，要進行復制，必須在主服務器上啓用二進制日誌。

每一個從服務器從主服務器接收主服務器已經記錄到其二進制日誌的保存的更新，以便從服務器能夠對其數據拷貝執行相同的更新。

從架構圖中咱們能夠分析，在大併發量較大的狀況下，會出現主從複製延遲這種問題，如何解決？目前已經有了比較成熟的方案。

主從複製原理圖：

步驟1： 全部數據更新都會被主庫記錄到主庫的二進制日誌。

步驟2： 與此同時從庫的IO線程會從主庫上讀取二進制日誌，寫入到從庫的中繼日誌上。

步驟3： 從庫的SQL線程讀取中繼日誌上的內容來更新從庫。

形成延遲的緣由

一、併發較大的狀況下，master產生的DDL和DML數量大於salve的可接受數。從庫的Slave_SQL_Running是單線程做業，不能併發執行，因此當主庫的TPS併發較高時，就容易產生延遲。

二、slave將主庫的DDL和DML操做在slave實施。DML和DDL的IO操做是隨即的，不是順序的，成本高不少，還可能可slave上的其餘查詢產生lock爭用，因此一個DDL卡主了，須要執行10分鐘，那麼全部以後的DDL會等待這個DDL執行完纔會繼續執行，這就致使了延時

如何解決

一、減小slave同步延時的方案就是在架構上作優化，儘可能讓主庫的DDL快速執行

二、主庫寫對數據安全性較高，好比sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之類的設置，而slave則不須要這麼高的數據安全，徹底能夠將sync_binlog設置爲0或者關閉binlog，innodb_flushlog也能夠設置爲0來提升sql的執行效率

三、使用比主庫更好的硬件設備做爲slave

四、使用mysql5.7 參看 《MySQL 5.7 並行複製實現原理與調優》

分庫分表

這篇文章寫的很好，須要好好拜讀

http://www.cnblogs.com/hackxh...

以上是對幾年前的架構進行能夠優化的地方