概述：

淘淘商城是采用分布式架構(gòu)部署的一個大型網(wǎng)上商城系統(tǒng)，類似于京東商城。本系統(tǒng)分前臺系統(tǒng)和后臺系統(tǒng)。前臺系統(tǒng)主要負責(zé)商城的頁面的顯示功能，這里采用的面向服務(wù)的方式，pc端手機端只負責(zé)顯示頁面，業(yè)務(wù)邏輯都在服務(wù)層實現(xiàn)，客戶端調(diào)用服務(wù)端接口來實現(xiàn)顯示功能。

在前臺系統(tǒng)中主要分為：客戶端：系統(tǒng)前臺頁面顯示系統(tǒng)(portal，8082)。服務(wù)端系統(tǒng)：(1)rest系統(tǒng)(8081)：負責(zé)調(diào)用CMS系統(tǒng)的內(nèi)容，將CMS系統(tǒng)的內(nèi)容顯示到頁面，(這里的CMS內(nèi)容管理系統(tǒng)，在后臺實現(xiàn))。(2)商品的搜索系統(tǒng)(8083)，當(dāng)在頁面輸入商品信息時，可以搜索商品。這里用到了solr技術(shù)，利用solr索引庫來實現(xiàn)。(3)SSO(單點登陸系統(tǒng)，8084)，因為商城采用分布式的系統(tǒng)部署，將整個系統(tǒng)劃分為幾個子系統(tǒng)，所以對于用戶的訪問權(quán)限是一個問題，如何實現(xiàn)一次登陸即其他系統(tǒng)都可以免登陸，sso可以解決。(4)訂單系統(tǒng)(8085)：商城購物少不了訂單系統(tǒng)，所以將此作為一個獨立工程編寫。

后臺系統(tǒng)功能：商城的后臺系統(tǒng)主要是負責(zé)商品的分類，添加、規(guī)格參數(shù)。CMS系統(tǒng)(這里主要是廣告的分類、添加)。

本系統(tǒng)前臺界面設(shè)計采用的easyUI的設(shè)計，后臺采用springMVC、spring、mybatis框架，擦用java語言編程。

步驟分析：

一、項目需求分析：模仿京東商城系統(tǒng)。

二、項目數(shù)據(jù)庫設(shè)計：商品信息表、商品信息分類表、商品信息描述表、商品規(guī)格參數(shù)表、

CMS系統(tǒng)內(nèi)容表、CMS系統(tǒng)內(nèi)容分類表

用戶表、訂單表、訂單的具體明細表

三、具體實現(xiàn)：

1、框架的搭建：

這里采用maven來管理整個項目。優(yōu)勢兩點：1、maven可以以管理整個項目工程，方便熱部署項目，項目發(fā)布方便。2、maven管理你jar包具有很大的優(yōu)勢，可以自動下載所需的jar包，只需定義好版本即可，其他maven自動下載。

因為這個項目比較大，子工程比較多，所以我們建立一個pom類型(聚合工程)parent來管理里所有jar包的版本，這樣其他 子工程都依賴此工程。版本得到了統(tǒng)一，不會出現(xiàn)因版本問題導(dǎo)致的錯誤。其次建立一個專門的(jar類型)common工具類，可以將系統(tǒng)中使用到的工具類都加入此類，其他類也依賴此類，就可以使用這里面的工具了。此工具類也依賴parent類。

下面就是利用SSM框架來搭建工程了：利用框架搭建工程主要分兩步：框架所依賴的jar包，框架的配置文件。弄清了這兩點就好辦了。框架主要分三層：dao層(mybatis)(主要是與數(shù)據(jù)庫打交道)、service層(spring)(主要是負責(zé)調(diào)用dao層，實現(xiàn)業(yè)務(wù)邏輯的編寫)、controller層(springMVC)(這里主要調(diào)用service層，根據(jù)jsp頁面的內(nèi)容，將jsp的內(nèi)容傳遞到service層，然后講數(shù)據(jù)顯示到j(luò)sp頁面)。所以這里的配置文件也就：mybatis的SqlMapConfig.xml (主要是它的插件配置，數(shù)據(jù)庫配置放在dao)。spring將mybatis和springMVC整合起來的application_context_dao.xml(配置數(shù)據(jù)源，與數(shù)據(jù)庫的連接)，application_context_service.xml(將service的文件包引入工程)。application_context_transation.xml(這里將事務(wù)獨立出來，主要是事務(wù)的配置)

SpringMVC.xml(主要是前端控制器，試圖解析器的配置)

框架搭建完成后，利用mybatis的逆向工程生成各個表的mapper.xml和mapper.java文件、pojo文件。

2、具體的功能的實現(xiàn)邏輯

(1)后臺系統(tǒng)功能實現(xiàn)

(這里主要講商品的查詢、添加、規(guī)格參數(shù)、CMS系統(tǒng)的分類、添加)

其實對于功能模塊的分析主要有三點：

從哪個數(shù)據(jù)表獲取(主要mapper實現(xiàn))；頁面?zhèn)鬟f是否有參數(shù)，頁面的url是什么(controller實現(xiàn))；返回值是什么(即頁面展示的格式是什么樣子的，這個根據(jù)jsp使用的框架來決定，比如這里的easyUI，可以查詢它的api文檔，找到其返回值類型)；

A、商品的查詢邏輯分析：其實對于商品的查詢主要就是從數(shù)據(jù)庫中將所有商品查詢出來。這簡單的查詢很簡單，可是在頁面分頁顯示出來這就是一個問題了。這里到了mybatis的分頁插件pageHelper來實現(xiàn)。

傳入?yún)?shù)：Easyui頁面默認有page、rows參數(shù)傳遞。

返回值：easyui的格式即datagrid的格式，專門編寫一個對應(yīng)的pojo類放入專門工具類中使用，返回格式即這個pojo。

邏輯：Dao層：Dao層用mybatis的逆向工程

Service調(diào)用mapper的查詢和分頁實現(xiàn)邏輯。

Controller即將參數(shù)傳遞過去，url寫好

B、商品添加：商品添加即將商品信息寫入數(shù)據(jù)庫，頁面?zhèn)鬟f的內(nèi)容當(dāng)點擊提交按鈕時直接寫入數(shù)據(jù)庫，只需補全沒有的字段即可。

這里涉及到商品的類目選擇、上面的圖片上傳、商品的描述信息。

類目選擇首先得將類目展示出來，這里使用的異步樹的格式。查詢api發(fā)現(xiàn)異步樹的返回值的格式。主要思路是：根據(jù)parentId來查詢類目表，默認從0開始，異步樹有個特點，就是每次獲取到的id，如果有子節(jié)點，會發(fā)送url再次請求，如果沒有子節(jié)點則不發(fā)送請求，所以可以都遍歷到所有節(jié)點。(這個是tree的特點，自動請求)

異步樹的特點：從最頂層開始讀取，先讀頂層節(jié)點，如果是閉合狀態(tài)，發(fā)送請求給服務(wù)器讀取子節(jié)點，子節(jié)點的狀態(tài)依賴于父節(jié)點，當(dāng)展開一個封閉的節(jié)點時，如果節(jié)點沒有加載子節(jié)點，它將會把節(jié)點的id的值作為http請求參數(shù)并命名為id，通過url發(fā)送到服務(wù)器上檢索子節(jié)點。所以遍歷一次后，如果父節(jié)點還是父節(jié)點(即存在子節(jié)點)則檢索下面的子節(jié)點的內(nèi)容，將子節(jié)點的id作為parentId來檢索下面的節(jié)點。如果不是父節(jié)點了，則打開下面列表。也就是說這些實現(xiàn)都是 異步樹自動實現(xiàn)的，我們只需要判斷父節(jié)點的狀態(tài)即可，下面的檢索根據(jù)這個狀態(tài)進行。

圖片上傳功能：因為商城的圖片非常多，所以我們將這么多的圖片保存在圖片服務(wù)器中，然后將圖片在服務(wù)器中的具體url寫入數(shù)據(jù)庫，供前臺調(diào)用。前臺獲取到這個url既可獲取到這個圖片。這里圖片上傳到服務(wù)器的功能：先生存圖片的名稱，然后生成圖片保存的格式，然后利用ftpUtil將圖片上傳到服務(wù)器，返回一個url鏈接。

商品規(guī)格參數(shù)，這里采用的規(guī)格參數(shù)模板的形式。：

這里有兩個表：一個模板表(根據(jù)商品的分類建立的模板，根據(jù)分類id)，一個展示模板表(根據(jù)商品的信息寫入模板表，根據(jù)商品id查詢商品信息，然后寫入對應(yīng)訂單模板中，然后生成HTML)。

商品的描述：這里采用文本的形式存儲的，寫入即可。富文本編輯器。

CMS分類：這里的格式也是用了異步樹的格式，所以顯示方法是一樣的。

分類添加：像表中插入數(shù)據(jù)庫即可。

(2)前臺功能實現(xiàn)

首頁大廣告位的實現(xiàn)：這里是從CMS系統(tǒng)中獲取廣告位的圖片，然后展示在頁面。但是前臺跟后臺是不一樣的端口，如何從前臺訪問后臺呢，可以使用jsonp的形式。但是我們這里系統(tǒng)是采用面向服務(wù)的編程，所以采用rest接口的方式然后功能前臺調(diào)用，這里用的httpcliet來調(diào)用接口。

商品搜索功能的實現(xiàn)：

首先在linux下部署好solr服務(wù)器，然后將數(shù)據(jù)庫的表字段導(dǎo)入到solr索引庫。然后編寫search服務(wù)接口，然后供前臺調(diào)用這個服務(wù)接口。

Rest功能：

商品詳情頁面展示：寫三個服務(wù)：根據(jù)id查詢商品的具體信息顯示到頁面，根據(jù)id查詢商品的內(nèi)容表，根據(jù)id查詢商品的規(guī)格參數(shù)，即將三個信息展示到頁面。然后前臺分別調(diào)用。

SSO系統(tǒng)：這里涉及到攔截器。

這里是利用了sso的接口文檔，即校驗接口、注冊、登錄接口、根據(jù)token查詢用戶接口、安全退出接口。

這個的調(diào)用服務(wù)層是利用jsonp的形式訪問的服務(wù)接口，實現(xiàn)跨域訪問。客戶端全部在jsp頁面實現(xiàn)的。

具體流程：

當(dāng)用戶點擊注冊的時候，跳轉(zhuǎn)到注冊頁面，即用戶信息的保存功能。檢驗用戶名是否存在、手機號和郵箱不能為空。

當(dāng)用戶點擊登錄按鈕的時候，用戶輸入用戶名和密碼，檢驗用戶名是否在數(shù)據(jù)庫中存在，然后用戶名密碼是否正確。這里的密碼是用了spring的MD5加密技術(shù)。當(dāng)全部成功后，給用戶頒發(fā)一個token令牌(利用uuid實現(xiàn))，然后將token存入到redis中(token的key是它生成的號，值是用戶的名字)，然后設(shè)置在redis的過期時間。這相當(dāng)于用戶的session。

然后將token寫入cookie中，前臺頁面利用jsonp調(diào)用，根據(jù)cookie中的token的值，調(diào)用sso的根據(jù)token查詢用戶的服務(wù)，查看用戶是否有效，如果有效則將用戶返回前臺頁面，前臺頁面獲取用戶的用戶名顯示在首頁，表示***已登陸。

這里的cookie是設(shè)置了共享域，即全部子系統(tǒng)都可以訪問到cookie。

當(dāng)用戶登錄其他子系統(tǒng)時，先從從cookie中獲取token信息，根據(jù)token信息獲取用戶信息，判斷用戶信息是否有效，如果有效則放行，如果無效，則利用攔截器攔截跳轉(zhuǎn)到登錄頁面。用戶再次登錄的時候刷新redis的時間，重新設(shè)置有效期。

攔截器的攔截，在springMVC.xml中設(shè)置攔截的名稱。

購物車功能：

購物車功能注意到這里商品加入購物車，是將購物車保存在cookie中。這里用到cookieUtil工具來實現(xiàn)這些保存刪除功能。在商品詳情頁面點擊“加入購物車”按鈕提交一個請求吧商品id傳遞給Controller，Controller接收id，Controller調(diào)用Service根據(jù)商品id查詢商品基本信息，購物車的商品專門寫一個pojo對象，因為商品的很多信息購物車里面用不到。將購物車的商品的pojo，把商品寫入cookie中，加入cookie之前先從cookie中把購物車的商品取出來判斷當(dāng)前購物車商品列表中是否有此商品，如果有數(shù)量加一，如果沒有添加一個商品，數(shù)量為1。展示給用戶購物車列表。

訂單系統(tǒng)：訂單系統(tǒng)主要是訂單的創(chuàng)建、查詢、修改、刪除功能。

訂單系統(tǒng)因為pc端和移動端都需要調(diào)用此功能模塊，所以將訂單系統(tǒng)也單獨作為一個服務(wù)接口供客戶端調(diào)用。

訂單服務(wù)接口也有接口文檔，根據(jù)文檔進行訂單的創(chuàng)建。

訂單的創(chuàng)建需要用戶登錄，這里用到了攔截器在springMVC中配置下攔截方式即可。

當(dāng)用戶攔截成功后，用戶登錄該商城，這時候注意將用戶保存在request中，目的是因為查詢訂單的時候需要根據(jù)用戶的id來查詢，不同的用戶具有不同的訂單啊。

然后用request的get和setAttribute來獲取值和設(shè)定值。為什么可以從request中取，因為我們整個商城都是http協(xié)議訪問的。

(1)訂單創(chuàng)建邏輯：

當(dāng)點擊去去購物車結(jié)算時，顯示購物車的列表，當(dāng)選中購物車的商品點擊去結(jié)算的時候，顯示商品的提交訂單之前的一系列信息(也就是結(jié)算頁)：針對數(shù)據(jù)庫三張表：訂單基本信息表、訂單明細表(購買的商品信息)、訂單配送(收貨人的地址電話信息)

傳入?yún)?shù)：因為創(chuàng)建訂單也就是向數(shù)據(jù)庫中插入一系列的信息，而對應(yīng)的是數(shù)據(jù)庫中的三個表，所以根據(jù)頁面的內(nèi)容，傳入的參數(shù)也就是三個pojo類，然后頁面填寫的+補全頁面上在數(shù)據(jù)庫中沒有的字段。所以主要是對數(shù)據(jù)庫中的三個表進行插入操作。服務(wù)接口是負責(zé)接收這三個pojo類，所以客戶端要想辦法將這三個pojo類傳遞過來。

根據(jù)接口文檔，返回的是一個json格式的數(shù)據(jù)，即這三張表的數(shù)據(jù)是在一個json串中，所以這里要想辦法將這三個表單獨建立一個pojo來保存這個返回值。

接收的pojo類：

這里采用了這種方式巧妙的將三個表合并起來了。

接下來就是數(shù)據(jù)的插入操作了，這個在service層實現(xiàn)：逐個表的插入數(shù)據(jù)庫即可，然后返回一個訂單號即訂單的id。

controller層傳遞的就是這個pojo類，然后返回給客戶端。

客戶端也是將這個pojo類傳遞給服務(wù)接口，返回一個訂單號給客戶端。提交訂單的時候顯示訂單提交成功頁面時候，看下jsp頁面顯示哪些字段，然后用model傳遞給頁面。

(2)訂單的分頁查詢：

前面我們將用戶保存在了request中，然后獲取到用戶的id，根據(jù)用戶的id來查詢訂單，前臺頁面默認傳遞page和rows，利用mybatis的分頁查詢來查詢訂單即可。

傳入?yún)?shù)：page和rows

執(zhí)行操作：根據(jù)用戶id查詢訂單，根據(jù)page和rows分頁

返回值：訂單的列表信息，即用戶的多個訂單信息。根據(jù)接口文檔，我們發(fā)現(xiàn)這個返回的信息就是數(shù)據(jù)中訂單表的部分信息，所以用幾個字段組成一個新的pojo來接收返回值。

(3)根據(jù)訂單id查詢訂單：

根據(jù)訂單id查詢訂單這個顯示的信息就比較全面了，這個返回值跟之前的三個數(shù)據(jù)庫的表對應(yīng)，所以根據(jù)id，分別查詢這三個表，來獲取對應(yīng)的信息。

傳入?yún)?shù)：訂單id

操作：三個表分別查詢

返回值：之前新定義的三個表的Order的pojo類。

總結(jié)

以上是生活随笔為你收集整理的电商项目java经验_分布式电商系统项目总结的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。