如今項目架構的特點

1.分層開發
2.MVC架構
3.服務器分離部署

集群

集群架構
特點：
1.項目採用多台服務器集群部署

2.mysql數據庫採用多台服務器集群部署

優勢：

1.並發量提高(1000+)

2.容錯性提高(具有高可用性)

但是，我們發現這種集群部署存在兩個問題，什麼問題呢？

1.session如何共享？
我們都知道，session是會話，即一個用戶訪問服務器的時候，就會產生一個session，這個session會一直伴隨着這個用戶的訪問全程，直到用戶關閉瀏覽器結束這次會話，如果用戶訪問服務器時，這台服務器掛掉了(宕機)，那麼原先保存在這台服務器上的session也肯定掛掉了，那麼就會產生一個後果，就是這個用戶原本訪問好好的，現在突然session沒有了，而session沒有了就意味着需要用戶重新登陸才能進行一些相應操作，這顯然是不行的，這樣的服務用戶體驗實在太差了，兩種解決方案：

第一種解決方案：

用Tomcat集群複製(廣播模式)來共享session：

這種解決方案是利用Tomcat來進行集群複製，把每個服務器上的session都共享式的都複製一遍，保證每個服務器上都有着一個用戶的session數據

應用場景：在傳統項目中一般這麼應用，因為傳統項目的用戶量少，可以承擔壓力，但當到互聯網項目時，這種方式就絕對不可取了，打個比方，比如用戶量有100萬，那麼就需要在每個服務器上都複製這100萬個用戶的session，這樣做顯然會極大的消耗系統資源，使系統變得極為臃腫和不穩的，所以在互聯網項目里是絕對不會採用這種方式的

缺點：當有大量用戶時，服務器的壓力會亞歷山大，所以只適合用戶訪問量小的傳統項目

第二種解決方案：

用第三方redis服務器來存儲session

用這種方式來存儲session的話，只需當前正在使用的項目把所有session都放在redis裏面，當有其他項目需要使用時，就可以直接從redis中直接獲取session，從而解決了這個問題。
　　　　

2.這麼服務器，請求該往哪發送？

用nginx服務器來分發請求，實現負載均衡。

雖說集群能夠解決部分問題，但並不能解決所有問題，無論是從公司成本還是運營成本來說，顯然這種傳統的集群架構是不適應現在的互聯網行業的，而且對於一般的公司來說也不可能去花大價錢做這種布置。

所以，這種情況下我們就必須對我們的架構來進行優化了，那麼如何在服務器只有一定數量的情況下，讓我們的項目的成本能達到一定控制，並且讓我們的項目達到一個最優化的並發的訪問量呢？那麼就需要對現有的這種架構進行再次拆分，讓我們的項目成為面向服務的分佈式架構。

面向服務的分佈式架構(SOA)：

1.webserver

如圖所示，第一種方式還是有着明顯的缺點的，如服務層的網絡抖動或是服務層進程繁忙，可能有人對這兩個名詞不太理解，這裡就解釋一下：

網絡抖動：當有大量用戶訪問時，可能會出現service層的延遲現象，而web層因為長期得不到響應，則會拋出時間超出異常

進程繁忙：這個的意思和前邊的差不多，都是指service層業務太多，顧不上web層的請求，web層的請求就只能一直在那等着，時間長了也就拋出超時異常了

2.dubbo

原理講解：看了第一種webservice的方法之後，我們採用了第二種方法，即dubbo這種中間件的方式，採用這種方式有什麼好處呢？

好處：

當服務器啟動時service會把所有的對象通過dubbo註冊給zookeeper，而以後每次需要請求獲取對象時，就可以直接從dubbo中異步獲取，不需要再去訪問service層，這樣就解決了

服務層網絡抖動和服務層進程繁忙的弊端。zeekeeper可以看成是一個數據庫，用來存儲數據的，具體的原理以後會專門開篇文章描述它。

這種方式是目前最常用的，起碼是我最常用的，順嘴一提，dubbo是阿里巴巴開發的一款中間件，性能強大。

總結分佈式架構特點：

優點：
1.大幅提高並發訪問量
2.可以節省開發成本
3.實現了服務層與表現層的解耦合