我們知道在面向?qū)ο缶幊讨校倳?huì)想著各種辦法來(lái)實(shí)現(xiàn)代碼的解耦，從而讓項(xiàng)目中的各種人員面對(duì)自己熟悉的業(yè)務(wù)進(jìn)行開(kāi)發(fā)，

做到術(shù)業(yè)有專(zhuān)攻，比如大家非常熟悉的三層架構(gòu)，MVC，MVP以及MVVM模式，讓前端設(shè)計(jì)專(zhuān)注于html的制作，讓后端開(kāi)發(fā)人員

更加專(zhuān)注于業(yè)務(wù)邏輯的編寫(xiě)，可以看到，我們這么做的目的就是想最大程度的做到系統(tǒng)的可擴(kuò)展和可維護(hù)性，那么我們的大型網(wǎng)站

是不是也要遵守這種模式呢？

一：分層和分割

1：分層

    對(duì)于分層，我們可能非常熟知了，數(shù)據(jù)訪問(wèn)層，業(yè)務(wù)邏輯層，緩存層，應(yīng)用層，層層專(zhuān)注于自己的業(yè)務(wù)，然后根據(jù)需要建立起

 各自的集群，各自分離部署，而從達(dá)到系統(tǒng)的擴(kuò)展性和維護(hù)性。

2：分割

    如果說(shuō)前面是橫向切割，那分割就是縱向切割，我們可以把網(wǎng)站的整體業(yè)務(wù)切分成很多的小業(yè)務(wù)，比如博客園的導(dǎo)航欄，我們都

可以認(rèn)為是一個(gè)獨(dú)立的網(wǎng)站，配上各自的二級(jí)域名，建立各自的集群來(lái)實(shí)現(xiàn)系統(tǒng)的擴(kuò)展性，當(dāng)然這個(gè)粒度可大可小。

如果說(shuō)這些子網(wǎng)站不存在相互調(diào)用，那么我們新增模塊或者修改模塊基本上都不會(huì)對(duì)其他模塊造成影響，這也是我們做擴(kuò)展性的終極

目標(biāo)，現(xiàn)在既然都做到解耦了，下面的目標(biāo)就是做如何通信了，通信可以分為“同步”和“異步”，這篇主要是討論下異步操作，在分布式

系統(tǒng)中做到"異步操作“，當(dāng)然少不了強(qiáng)大的消息隊(duì)列。

二：消息隊(duì)列

    在分布式的系統(tǒng)中使用消息隊(duì)列后，我們的生產(chǎn)者只管向消息隊(duì)列中甩完數(shù)據(jù)后立即返回，而不管是哪個(gè)消費(fèi)者來(lái)消費(fèi)，可以看到

其實(shí)消息隊(duì)列有如下三個(gè)優(yōu)點(diǎn)。

1.  加快網(wǎng)站的相應(yīng)速度

　   這個(gè)剛才也說(shuō)了，應(yīng)用層直接把消息給消息隊(duì)列然后直接返回調(diào)用端，這樣就避免了處理復(fù)雜的業(yè)務(wù)邏輯然后同步的插入到數(shù)據(jù)

  庫(kù)后再返回造成的響應(yīng)延遲，在很多網(wǎng)站上用戶提交訂單就是這么處理的，應(yīng)用層生成一個(gè)訂單號(hào)之后，將訂單丟給消息隊(duì)列，然后

  直接到訂單成功頁(yè)面，此時(shí)后端消費(fèi)者對(duì)訂單還沒(méi)有處理完畢，因?yàn)楹竺鏁?huì)有比較多的數(shù)據(jù)操作，比如減庫(kù)存，數(shù)據(jù)庫(kù)同步等等，而

  用戶如果想要看到訂單詳情，需要點(diǎn)擊“訂單號(hào)”才能進(jìn)入到訂單詳情頁(yè)，這種處理也是因?yàn)橄㈥?duì)列的非及時(shí)性，所以需要得到網(wǎng)站

  設(shè)計(jì)方改進(jìn)和支持。

2. 提供系統(tǒng)的可用性

    既然是異步操作，就造成了生產(chǎn)者不知道消費(fèi)者的存在，而反過(guò)來(lái)消費(fèi)者不知道生產(chǎn)者的存在，如果消費(fèi)者掛了就不會(huì)影響到生產(chǎn)者，

  生產(chǎn)者還會(huì)照常無(wú)誤的向消息隊(duì)列甩消息，當(dāng)消費(fèi)者恢復(fù)正常后就會(huì)繼續(xù)消費(fèi)消息隊(duì)列，系統(tǒng)的表現(xiàn)可能就是email或者短信延遲收到，

  不會(huì)對(duì)系統(tǒng)造成太大的影響。

3. 并發(fā)削峰

   既然是大型網(wǎng)站就免不了高并發(fā)的讀寫(xiě)操作，很典型的一個(gè)例子就是電商中的秒殺，這種高并發(fā)的寫(xiě)操作，如果一下子都涌入到數(shù)據(jù)庫(kù)

里面去了，會(huì)導(dǎo)致數(shù)據(jù)庫(kù)的壓力非常大，從而導(dǎo)致客戶端的訪問(wèn)延遲，就是不掛也容易造成數(shù)據(jù)庫(kù)的死鎖從而造成很多靈異事件，遇到這

種一擁而入的情況，我們就必須進(jìn)行線性化操作，在代碼層面上我們可以用lock機(jī)制來(lái)串行化，在分布式中我們用“消息隊(duì)列”來(lái)串行化，

而且還可以通過(guò)邏輯操作來(lái)對(duì)消息隊(duì)列進(jìn)行動(dòng)態(tài)的防洪，控洪。

 在消息隊(duì)列的選擇上，微軟有自己的MSMQ，但是在大型網(wǎng)站中，我們的消息隊(duì)列同樣需要集群，并且希望能跑在內(nèi)存中，并且支持序列

化硬盤(pán)，同時(shí)在“伸縮性”和“可靠性”上要有好的作為，所以推薦大家用用開(kāi)源的RabbitMQ，網(wǎng)址：http://www.rabbitmq.com/  不過(guò)很

多公司都有自己開(kāi)發(fā)的消息隊(duì)列，比如攜程的CMessage，淘寶的MetaQ。