?
我們知道在面向對象編程中，總會想著各種辦法來實現代碼的解耦，從而讓項目中的各種人員面對自己熟悉的業務進行開發，
做到術業有專攻，比如大家非常熟悉的三層架構，MVC，MVP以及MVVM模式，讓前端設計專注于html的制作，讓后端開發人員
更加專注于業務邏輯的編寫，可以看到，我們這么做的目的就是想最大程度的做到系統的可擴展和可維護性，那么我們的大型網站
是不是也要遵守這種模式呢？
?
一：分層和分割
1：分層
??? 對于分層，我們可能非常熟知了，數據訪問層，業務邏輯層，緩存層，應用層，層層專注于自己的業務，然后根據需要建立起
?各自的集群，各自分離部署，而從達到系統的擴展性和維護性。
?
2：分割
? ? 如果說前面是橫向切割，那分割就是縱向切割，我們可以把網站的整體業務切分成很多的小業務，比如博客園的導航欄，我們都
可以認為是一個獨立的網站，配上各自的二級域名，建立各自的集群來實現系統的擴展性，當然這個粒度可大可小。
如果說這些子網站不存在相互調用，那么我們新增模塊或者修改模塊基本上都不會對其他模塊造成影響，這也是我們做擴展性的終極
目標，現在既然都做到解耦了，下面的目標就是做如何通信了，通信可以分為“同步”和“異步”，這篇主要是討論下異步操作，在分布式
系統中做到"異步操作“，當然少不了強大的消息隊列。
?
二：消息隊列
? ? 在分布式的系統中使用消息隊列后，我們的生產者只管向消息隊列中甩完數據后立即返回，而不管是哪個消費者來消費，可以看到
其實消息隊列有如下三個優點。
?
1. ?加快網站的相應速度
? 這個剛才也說了，應用層直接把消息給消息隊列然后直接返回調用端，這樣就避免了處理復雜的業務邏輯然后同步的插入到數據
? 庫后再返回造成的響應延遲，在很多網站上用戶提交訂單就是這么處理的，應用層生成一個訂單號之后，將訂單丟給消息隊列，然后
? 直接到訂單成功頁面，此時后端消費者對訂單還沒有處理完畢，因為后面會有比較多的數據操作，比如減庫存，數據庫同步等等，而
? 用戶如果想要看到訂單詳情，需要點擊“訂單號”才能進入到訂單詳情頁，這種處理也是因為消息隊列的非及時性，所以需要得到網站
? 設計方改進和支持。
?
2. 提供系統的可用性
? ? 既然是異步操作，就造成了生產者不知道消費者的存在，而反過來消費者不知道生產者的存在，如果消費者掛了就不會影響到生產者，
? 生產者還會照常無誤的向消息隊列甩消息，當消費者恢復正常后就會繼續消費消息隊列，系統的表現可能就是email或者短信延遲收到，
? 不會對系統造成太大的影響。
?
3. 并發削峰
? ?既然是大型網站就免不了高并發的讀寫操作，很典型的一個例子就是電商中的秒殺，這種高并發的寫操作，如果一下子都涌入到數據庫
里面去了，會導致數據庫的壓力非常大，從而導致客戶端的訪問延遲，就是不掛也容易造成數據庫的死鎖從而造成很多靈異事件，遇到這
種一擁而入的情況，我們就必須進行線性化操作，在代碼層面上我們可以用lock機制來串行化，在分布式中我們用“消息隊列”來串行化，
而且還可以通過邏輯操作來對消息隊列進行動態的防洪，控洪。
?
?在消息隊列的選擇上，微軟有自己的MSMQ，但是在大型網站中，我們的消息隊列同樣需要集群，并且希望能跑在內存中，并且支持序列
化硬盤，同時在“伸縮性”和“可靠性”上要有好的作為，所以推薦大家用用開源的RabbitMQ，網址：http://www.rabbitmq.com/? 不過很
多公司都有自己開發的消息隊列，比如攜程的CMessage，淘寶的MetaQ。
?
?
)
