說明：傳統項目中我們的Controller、Service、DAO、POJO都寫在一個工程中，在分布式的項目中我們將每個模塊分開。

項目分前臺和後臺兩個部分：

前臺是普通用戶看到的網站，比如你看到的淘寶頁面就是前臺。

後臺是公司內部的管理人員使用的，用於管理商品信息，比如淘寶的店主需要編輯商品。

父工程：分布式架構中，通常設計一個父工程，父工程中不寫業務代碼，只在pom文件中配置jar包的版本信息。所有的工程都繼承它，從父工程中獲取jar包版本信息。這樣在jar包升級的時候，我們只要修改父工程的pom文件，而不需要修改每個子工程。

DAO和Service：數據層和服務層都分開寫兩個模塊，通過面向接口的形式編程。其中Service以服務的形式發布出去，Service只提供業務接口，沒有界面。表現層是web網站還是app都和它沒有關系。同一個數據接口可以被多個表現層復用。

表現層：Controller和View。Controller從Service中獲取數據並展示給用戶View。View並不一定是html頁面，也可以是單純的json數據，如安卓或Ios的數據接口。Controller提供json數據給app，由app在手機界面上展示給用戶。

分布式的好處：

　　比如一個項目中有以下幾個模塊：註冊登錄、用戶信息修改、商品搜索和下單支付。非分布式項目裏我們把這四個模塊寫到一個工程中。如果其中一個模塊修改，就要重新部署整個工程。而且在實際運營中發現，搜索模塊用的最高，其次是支付。註冊和登錄用的並不多。比如雙十一的時候，用戶都是提前註冊的老用戶，登錄後系統記錄了用戶的登錄狀態。所以多數的用戶都在搜索商品和下單支付。一臺服務器的性能有限，假設能承載50個用戶，如果有100個用戶來，我們就要加一臺服務器。這個叫做負載。負載均衡是把同一個工程部署到多臺服務器上，由一個入口的應用判斷要把請求分配到哪臺服務器。但是前面我們已經說過，註冊和登錄用的並不多，真正需要加負載的是搜索和支付。根據實際情況，可能搜索使用的頻率更大於支付。非分布式的項目裏，整個工程一起打包部署，代碼都寫到一個工程中，註冊和登錄占用了分配給搜索和支付的資源。分布式的項目可以按模塊或者功能拆分代碼。比如我們把註冊登錄和信息修改寫到一個工程裏；商品搜索寫到一個工程；支付寫一個工程。根據運營的情況給每個模塊加負載，註冊登錄分1臺服務器，搜索加10臺，支付加5臺。而且修改了其中的一個模塊，只要重新部署這個模塊所在的服務器就可以，不會影響其他模塊服務器的運行。

　　當然並不是說分布式就一定好，如果工程比較小的話，寫成分布式的反而會消耗系統的性能。根據實際情況來設計整個項目的架構。在項目設計的初期，要考慮工程的可擴展性。

下面簡單說明創建一個分布式系統的流程：

1.創建父工程

不使用模板，直接創建maven工程，父工程travel-parent的打包方式是pom

父工程裏不寫代碼，只寫jar包配置，其它子工程繼承travel-parent，從這裏引用jar包，方便管理整個分布式架構中的jar包版本。

創建工程後需要發布工程，這樣其它的工程就可以繼承父工程了。在idea右側的菜單中雙擊install

2.創建通用工程

不使用模板，創建通用工程travel-common，這個工程中存放實體類和一些通用的工具類。

此工程要繼承travel-parent，打包方式是jar

3.創建後臺管理聚合工程

後臺管理中，將dao接口、service接口、service實現類寫到三個模塊中

其中travel-manager是pom聚合工程

其余三個是model模塊，每個model都有一個自己的pom.xml

創建的方法是在travel-manager上右鍵->New->Module

3.1travel-manager

travel-manager的pom.xml，繼承travel-parent

3.2travel-manager-dao

travel-manager-dao的打包方式是jar，即創建工程的時候不需要模板

3.3travel-manager-interface

travel-manager-interface的打包方式是jar，即創建工程的時候不需要模板

3.4travel-manager-service

travel-manager-service是web工程，打包方式是war，創建工程時需要選用webapp模板

4.創建後臺web工程

搭建簡單的分布式系統