四種JavaEE架構簡介

來源：blog.csdn.net/rj151YY/article/details/84383550

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.

（3）已經存在兩臺伺服器，如果其中一臺伺服器的掛掉了，第二臺伺服器是正常的狀態，負載均衡伺服器會將所有請求轉到第二臺伺服器，所以訪問第二臺伺服器沒有問題。

（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的方式呼叫微服務，目的是為了降低所產生的效能開銷。同時每個模組仍然可以搭建叢集，從而實現高可用。

4.1 SOA架構

是當服務過多時，服務之間呼叫關係複雜混亂，不利於維護。

使用dubbo。使用rpc協議進行遠端呼叫，直接使用socket通訊。傳輸效率高，並且可以統計系統之間的呼叫關係，呼叫次數。（由於dubbo阿里公司已經停止更新，建議使用springcloud）。

4.2 Dobbo

dubbo體系結構圖：

如下是一個典型的基於SOA電商專案架構圖：

說明：如果服務與服務之間存在呼叫，dobbo可以通過名字去鑑別因為編碼時每個模組之間都有呼叫關係，且該關係也被dobbo掌握。

4.3 SpringCloud

SpringCloud是一個基於 Spring Boot 實現的服務治理工具包；Spring Boot 專注於快速、方便整合的單個微服務個體；Spring Cloud 關注全域性的服務治理框架。

解釋一下這張圖中各元件的執行流程：

• ① 所有請求都統一通過 API 閘道器（Zuul）來訪問內部服務。

• ② 閘道器接收到請求後，從註冊中心（Eureka）獲取可用服務。

• ③ 由 Ribbon 進行均衡負載後，分發到後端的具體例項。

• ④ 微服務之間通過 Feign 進行通訊處理業務。

• ⑤ Hystrix 負責處理服務超時熔斷。

• ⑥ Turbine 監控服務間的呼叫和熔斷相關指標。

SpringCloud和Dobbo的區別：

（1）Dubbo的註冊中心可以選擇zookeeper,redis等多種；Spring Cloud:的註冊中心只能用eureka或者自研。

（2）Dubbo通過rpc協議遠端呼叫，直接通過socket通訊，效率高；SpringCloud通過http協議呼叫。

PS：如果覺得我的分享不錯，歡迎大家隨手點贊、轉發。

（完）

Java團長

專注於Java乾貨分享

掃描上方二維碼獲取更多Java乾貨