javaEE架構
1.傳統三層架構(all in one項目)
傳統三層架構大致可以分爲表現層，業務層和持久層（數據訪問層）。其中表現層負責接受請求和轉發請求。業務層負責處理請求（注：事務管理，日誌記錄等AOP類型的操作均封裝在這一層）。持久層主要負責數據庫與實體之間的操作。
struts典型的mvc三層架構：模型層，視圖層，控制層。
SpringMVC中的MVC指的是什麼：當一個請求到達服務器時，由中央控制器DispatcherServlet（控制層）查找要訪問的controller，然後controller->調用service->調用dao，之後將獲取的數據返回到jsp頁面（視圖層）。
即：嚴格來說在SpringMVC中控制器是DispacterServlet,模型層是controller（即該模型層又可以看成一個MVC架構）,視圖層是jsp頁面。
另外，利用框架可以簡化各層的開發：表現層使用SpringMVC或者struts2,持久層使用Mybatis或Hibernate，使用spring管理表現層，業務層和持久層三層之間的關係。
2.集羣架構(屬於水平拓展)
由於傳統的三層架構中存在許多問題，比如業務層中的不同模塊佔用系統資源相差太大，導致佔用系統資源，可以使用集羣解決問題。（相當於備份多個文件，多臺服務器反問的是同一個項目資源，集羣架構的目的也是爲了系統資源的高可用性。）
在集羣架構中存在一個重要的角色就是反向代理服務器，他的任務是實現負載均衡，接收用戶請求，轉發到目標服務器，其中反向代理服務器可以使用nginx實現（簡單來說也就是一個實現負載均衡的算法）。
說明：
（1）集羣架構相當於把同一個項目部署到多個服務器上（相當於複製備份），然後通過負載均衡服務器nginx將請求分別均衡的派發到不同的tomcat服務器上，實際上不同服務器上運行的是同一個web項目。
（2）大部分能企業通過nginx實現負載均衡算法。
軟件層面負載均衡項目：nginx, apache的httpd;
硬件負載均衡器：f5.
（2）已經存在兩臺服務器，如果其中一臺服務器的掛掉了，第二臺服務器是正常的狀態，負載均衡服務器會將所有請求轉到第二臺服務器，所以訪問第二臺服務器沒有問題。
（4）如果你在訪問第一臺服務器時，正在購物，此時已經有多件商品被加入購物車了，且購物車數據是通過session存儲的，倘若此時你訪問的這臺服務器掛掉了，那麼負載均衡服務器將你的請求派送到另一臺服務器上，那麼此時你的購物車裏面的數據依然還存在，因爲集羣的服務器之間的session是共享的。
（5）不同的Tomcat服務器之間如何做到session共享？
tomcat服務器本身就支持session共享，但是需要在集羣的tomcat服務器的配置文件server.xml中做相同的如下配置：
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster" channelSendOptions="8">
<Manager className="org.apache.catalina.ha.session.DeltaManager"
expireSessionsOnShutdown="false"
otifyListenersOnReplication="true"/>
<Channel className="org.apache.catalina.tribes.group.GroupChannel">
<Membership className="org.apache.catalina.tribes.membership.McastService"
address="228.0.0.4"
port="45564"
frequency="500"
dropTime="3000"/>
<Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
address="auto"
port="4000"
autoBind="100"
selectorTimeout="5000"
maxThreads="6"/>
<Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
<Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
</Sender>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
</Channel>
<Valve className="org.apache.catalina.ha.tcp.ReplicationValve"
filter=""/>
<Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
<Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
tempDir="/tmp/war-temp/"
deployDir="/tmp/war-deploy/"
watchDir="/tmp/war-listen/"
watchEnabled="false"/>
<ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
</Cluster>
好處：高可用。
弊端：如果該項目很大，且併發量高，包含多個可拆分的模塊（子系統）那就不適用集羣架構了。
3.分佈式架構（垂直拆分）
分佈式架構特點：多個模塊完成一個功能，每個模塊又可以搭建集羣，從而實現高可用。
說明：
分佈式架構與集羣架構的區別：
（1）集羣架構是將同一個完整的項目部署到多臺服務器上，通過負載均衡完成請求的派發。而分佈式架構是將項目拆分成不同的模塊（子系統），然後將不同模塊存放在不同的服務器上，所以分佈式架構很大的一個特點就是分開還能合作完成一個請求。（注：現在雲計算就有分佈式的的概念。）
（2）簡單的分佈式架構仍然存在問題，如果其中一個tomcat服務器掛掉了，則其中一個模塊則不可運行了，所以考慮到分佈式集羣架構，即將一個大系統分成多個獨立的模塊，部署到多個服務器上，每個模塊再考慮存放在多個服務器上形成一個集羣，如此才能實現高可用性。如下圖：
好處：高可用，效率高。
弊端：模塊之間的關係不易於管理。
4.微服務架構（垂直劃分）
根據產品的業務功能模塊劃分服務的種類，客戶端可以通過基於HTTP或者RPC的方式調用微服務，目的是爲了降低所產生的性能開銷。同時每個模塊仍然可以搭建集羣，從而實現高可用。
3.1 SOA架構
說明：
（1）由於基於soa架構的項目，表現層和服務層是不同的工程，所以要相應一個請求需要兩個系統之間進行通信，SOA架構實現系統之間的通信有三種方式：
（2）webservice通信：webservice通信是基於soa介意的，效率低，項目中不建議使用。
（3）使用restful形式的服務：http+json的方式，很多項目中都有應用，但是當服務過多時，服務之間調用關係複雜混亂，不利於維護。
（4）使用dubbo。使用rpc協議進行遠程調用，直接使用socket通信。傳輸效率高，並且可以統計系統之間的調用關係，調用次數。（由於dubbo阿里公司已經停止更新，建議使用springcloud）。
3.2 Dobbo
如下圖：dubbo體系結構圖：
如下是一個典型的基於SOA電商項目架構圖：
說明：如果服務與服務之間存在調用，dobbo可以通過名字去鑑別因爲編碼時每個模塊之間都有調用關係，且該關係也被dobbo掌握。
3.3 SpringCloud
SpringCloud是一個基於 Spring Boot 實現的服務治理工具包；Spring Boot 專注於快速、方便集成的單個微服務個體；Spring Cloud 關注全局的服務治理框架。
解釋一下這張圖中各組件的運行流程：
（1）所有請求都統一通過 API 網關（Zuul）來訪問內部服務。
（2）網關接收到請求後，從註冊中心（Eureka）獲取可用服務。
（3）由 Ribbon 進行均衡負載後，分發到後端的具體實例。
（4）微服務之間通過 Feign 進行通信處理業務。
（5）Hystrix 負責處理服務超時熔斷。
（6）Turbine 監控服務間的調用和熔斷相關指標。
SpringCloud和Dobbo的區別：
（1）Dubbo的註冊中心可以選擇zookeeper,redis等多種；
Spring Cloud:的註冊中心只能用eureka或者自研；
（2）Dubbo通過rpc協議遠程調用，直接通過socket通信，效率高
SpringCloud通過http協議調用。