摘要：常見的就是，它是一個完整的目錄。的特點是簡單，使用一個中央版本庫。當初公司的日均均超過，所以采用的是方案雙機熱備集群優化架構圖上是兩主兩從。

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

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

放眼現在，我們可以重新整理這套架構

找到可以優化的地方

找到替代的方案

我們先來看下架構圖：

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

左側的程序代碼同步

右側的架構

現有做法：

從版本管理工具拉取最新代碼，除去.svn標記等文件，同步到生產環境
svn拉取最新代碼  -> 測試服務器 -->rsync同步--> 生產環境

存在的問題：

1、采用svn進行版本管理，不利于團隊協作開發；經常會出現修改的文件又被之前的覆蓋了，白做了
2、在項目較大的情況下，所有的資源控制系統都是把文件的元信息隱藏在一個類似.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的對分支和合并有更好的支持,這是開發者最關心的。

具體做法：

1、建立兩個分支：master 和 develop
2、master用于生產環境，develop用戶測試環境。
3、master分支禁止被提交（commit、push），只準從develop或hotfix（線上bug）合并而來。
4、服務器上寫一個shell腳本，用來做兩件事，一是拉取最新代碼，而是rsync同步代碼

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

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

2、發布流程，我這里草擬了一份，增加了一個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線程讀取中繼日志上的內容來更新從庫。

造成延遲的原因

1、并發較大的情況下，master產生的DDL和DML數量大于salve的可接受數。從庫的Slave_SQL_Running是單線程作業，不能并發執行，所以當主庫的TPS并發較高時，就容易產生延遲。
2、slave將主庫的DDL和DML操作在slave實施。DML和DDL的IO操作是隨即的，不是順序的，成本高很多，還可能可slave上的其他查詢產生lock爭用，所以一個DDL卡主了，需要執行10分鐘，那么所有之后的DDL會等待這個DDL執行完才會繼續執行，這就導致了延時

如何解決

1、減少slave同步延時的方案就是在架構上做優化，盡量讓主庫的DDL快速執行
2、主庫寫對數據安全性較高，比如sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之類的設置，而slave則不需要這么高的數據安全，完全可以將sync_binlog設置為0或者關閉binlog，innodb_flushlog也可以設置為0來提高sql的執行效率
3、使用比主庫更好的硬件設備作為slave
4、使用mysql5.7  參看 《MySQL 5.7 并行復制實現原理與調優》

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

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

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