1.傳統的專案的架構

無論有多少個需求和功能都放在了一個，一套MVC架構中，所以造成的缺點非常明顯

1.程式碼耦合度非常高

2.後期維護的成本很高（當你要修改 查尋商品 的程式碼的時候，需要將整個專案全部停掉。）

3.由於部署在一個伺服器上，所以並不能實現高併發的需求。

2.併發

使用叢集，來實現併發訪問。

1.將專案部署到多個伺服器上，就可以實現併發訪問。
2.不能解決程式碼耦合度高的問題
3.不能解決維護成本高的問題
4.而且思考這麼一個問題，當用戶傳送一個登入請求，被Nginx分配到 Tomcat1伺服器上，儲存在Tomcat1伺服器上的 session中，但是當用戶再次傳送一個其他請求，
卻被分配到Tomcat2伺服器上，此時Tomcat2中的Session中並沒有使用者資訊，所以還要再登陸。那假如有100個呢？
5.當然也可以解決，需要session共享，是以session廣播的形式，比較消耗資源，寬頻。
 

如果要達到10000併發

需要20臺伺服器做tomcat叢集。當tomcat叢集中節點數量增加，服務能力先增加後下降。

所以叢集中節點數量不能太多，一般也就5個左右。

3.分散式架構

將每一個功能模組都拆分成一個個系統，分別部署，有的使用頻率非常高的系統，就讓部署的伺服器多一些，這樣併發量也就高了。但是還是有它的缺陷。

叢集：相當於同一個工程程式碼拷貝多份部署到多臺伺服器，每臺伺服器單獨獨立部署執行。
分散式架構：
	把系統按照模組拆分成多個子系統；多個子系統相互協作才能完成業務流程系統之間需要進行通訊。
優點：
1、把模組拆分，使用介面通訊，降低模組之間的耦合度。
2、把專案拆分成若干個子專案，不同的團隊負責不同的子專案。
3、增加功能時只需要再增加一個子專案，呼叫其他系統的介面就可以。
4、可以靈活的進行分散式部署。（每個系統進行叢集部署）

缺點：
1、系統之間互動需要使用遠端通訊，需要開發介面，增加工作量。
2、各個模組有一些通用的業務邏輯無法公用。(比如查詢系統和後臺管理系統，都會有一個查詢的功能，其業務邏輯是一樣的，但是無法實現程式碼的複用，在兩個系統中都分別進行了開發)
 

4.SOA的專案架構

SOA：Service Oriented Architecture面向服務的架構。也就是把工程都拆分成服務層工程、表現層工程。
服務層中包含業務邏輯，只需要對外提供服務即可。
表現層只需要處理和頁面的互動，業務邏輯都是呼叫服務層的服務來實現。工程都可以獨立部署。

用自己的話說就是：前面的傳統專案架構，分散式的架構 其針對的是 某個功能，某個邏輯業務來進行開發。但SOA則不是，SOA針對的是某個物件來進行開發（服務層）。比如 商品服務，訂單服務，搜尋服務..........商品中有搜尋，刪除，增加等許多功能，當變現層需要什麼，就去呼叫相應的服務。

這是專案的整體架構：

其實可以這樣理解，服務層其實就是原來的Controller層，處理頁面的。而服務層就相當於 原來的Service層和Dao層。單他們是解耦和的，分別部署的。