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

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

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

放眼現(xiàn)在，我們可以重新整理這套架構(gòu)

找到可以優(yōu)化的地方

找到替代的方案

我們先來看下架構(gòu)圖：

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

左側(cè)的程序代碼同步

右側(cè)的架構(gòu)

現(xiàn)有做法：

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

存在的問題：

1、采用svn進行版本管理，不利于團隊協(xié)作開發(fā)；經(jīng)常會出現(xiàn)修改的文件又被之前的覆蓋了，白做了
2、在項目較大的情況下，所有的資源控制系統(tǒng)都是把文件的元信息隱藏在一個類似.svn，這個.svn文件會巨大，
svn是按照文件進行比較的，會占用很大資源

進一步優(yōu)化：

使用SVN進行版本管理，和程序發(fā)布，不方便進行測試環(huán)境和生產(chǎn)環(huán)境的代碼區(qū)分，麻煩點，可以解決
trunk->tag
trunk的發(fā)布到測試環(huán)境
tag的發(fā)布到生產(chǎn)環(huán)境
tag的程序均是經(jīng)過測試通過的，由trunk合并過來的

最優(yōu)方案：

采用git版本管理工具

svn 與 git 的區(qū)別

最核心的區(qū)別Git是分布式的，而Svn不是分布的。svn必須聯(lián)網(wǎng)進行操作。好處是跟其他同事不會有太多的沖突，自己寫的代碼放在自己電腦上，一段時間后再提交、合并，也可以不用聯(lián)網(wǎng)在本地提交。

GIT把內(nèi)容按元數(shù)據(jù)方式存儲，而SVN是按文件。你會發(fā)現(xiàn)有個.svn 這個文件會越來越大。

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

SVN的特點是簡單，使用一個中央版本庫。
Git的對分支和合并有更好的支持,這是開發(fā)者最關(guān)心的。

具體做法：

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

剩下的是團隊成員開發(fā)協(xié)作、以及發(fā)布流程相關(guān)問題。

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

2、發(fā)布流程，我這里草擬了一份，增加了一個pre_product預發(fā)布分支?？赡茉谀愎揪筒贿m合，請酌情調(diào)整。

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

merged、done。任務有技術(shù)負責人下發(fā)，成員認領開發(fā)。

你Google一下Code Reivew這個關(guān)鍵詞，你就會發(fā)現(xiàn)Code Review的好處基本上是不存在爭議的，有很多很多的文章和博文都在說Code Review的重要性，怎么做會更好，而且很多公司在面試過程中會加入“Code Review”的問題。

但是，我們經(jīng)常會遇到這種情況：

1）工期壓得太緊，時間連coding都不夠，以上線為目的，
2）需求老變，代碼的生命周期太短。所以，寫好的代碼沒有任何意義，爛就爛吧，反正與績效無關(guān)。

其實，我認為這是很不負責任的。后面，我們會用大量時間來解決之前本不該發(fā)生的問題。

LVS部分可以使用nginx的反向代理去實現(xiàn)，道理與LVS相同。用戶請求到代理服務器，nginx代理服務器分發(fā)請求到后端WEB,我找了個圖，方便大家去理解

nginx特點

nginx性能好，承擔高的負載壓力且穩(wěn)定，可以負載超過1萬的并發(fā)。 
工作在網(wǎng)絡的7層之上，可以針對http應用做一些分流的策略，比如針對域名、目錄結(jié)構(gòu)；
Nginx對網(wǎng)絡的依賴比較小；
Nginx安裝和配置比較簡單，測試起來比較方便；
Nginx對請求的異步處理可以幫助節(jié)點服務器減輕負載；

LVS的特點

抗負載能力強、是工作在網(wǎng)絡4層之上僅作分發(fā)之用，沒有流量的產(chǎn)生；
配置性比較低，這是一個缺點也是一個優(yōu)點，因為沒有可太多配置的東西，所以并不需要太多接觸，大大減少了人為出錯的幾率；
工作穩(wěn)定，自身有完整的雙機熱備方案；
無流量，保證了均衡器IO的性能不會收到大流量的影響；
LVS需要向IDC多申請一個IP來做Visual IP，因此需要一定的網(wǎng)絡知識，所以對操作人的要求比較高；

具體看你的業(yè)務情況，使用nginx或者lvs。當初公司的日均PV均超過100W，所以采用的是LVS方案+雙機熱備

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

主從復制

MySQL復制基于主服務器在二進制日志中跟蹤所有對數(shù)據(jù)庫的更改(更新、刪除等等)。因此，要進行復制，必須在主服務器上啟用二進制日志。
每個從服務器從主服務器接收主服務器已經(jīng)記錄到其二進制日志的保存的更新，以便從服務器可以對其數(shù)據(jù)拷貝執(zhí)行相同的更新。

從架構(gòu)圖中我們可以分析，在大并發(fā)量較大的情況下，會出現(xiàn)主從復制延遲這種問題，如何解決？目前已經(jīng)有了比較成熟的方案。

主從復制原理圖：

步驟1： 所有數(shù)據(jù)更新都會被主庫記錄到主庫的二進制日志。
步驟2： 與此同時從庫的IO線程會從主庫上讀取二進制日志，寫入到從庫的中繼日志上。
步驟3： 從庫的SQL線程讀取中繼日志上的內(nèi)容來更新從庫。

造成延遲的原因

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

如何解決

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

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

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

以上是對幾年前的架構(gòu)進行可以優(yōu)化的地方