怎么用Java Web搭建一個(gè)簡(jiǎn)單的電商系統(tǒng)

今天小編給大家分享一下怎么用Java Web搭建一個(gè)簡(jiǎn)單的電商系統(tǒng)的相關(guān)知識(shí)點(diǎn)，內(nèi)容詳細(xì)，邏輯清晰，相信大部分人都還太了解這方面的知識(shí)，所以分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后有所收獲，下面我們一起來了解一下吧。

階段一、單機(jī)構(gòu)建網(wǎng)站

網(wǎng)站的初期，我們經(jīng)常會(huì)在單機(jī)上跑我們所有的程序和軟件。此時(shí)我們使用一個(gè)容器，如Tomcat、Jetty、Jboss，然后直接使用JSP/Servlet技術(shù)，或者使用一些開源的框架如Maven  + Spring + Struts + Hibernate、Maven + Spring + Spring MVC +  Mybatis。再選擇一個(gè)數(shù)據(jù)庫管理系統(tǒng)來存儲(chǔ)數(shù)據(jù)，如MySQL、SqlServer、Oracle，然后通過JDBC進(jìn)行數(shù)據(jù)庫的連接和操作。

把以上的所有軟件包括數(shù)據(jù)庫、應(yīng)用程序都裝載同一臺(tái)機(jī)器上，應(yīng)用跑起來了，也算是一個(gè)小系統(tǒng)了。此時(shí)系統(tǒng)結(jié)果如下：

階段二、應(yīng)用服務(wù)器與數(shù)據(jù)庫分離

隨著網(wǎng)站的上線，訪問量逐步上升，服務(wù)器的負(fù)載慢慢提高，在服務(wù)器還沒有超載的時(shí)候，我們應(yīng)該就要做好準(zhǔn)備，提升網(wǎng)站的負(fù)載能力。假如我們代碼層面已難以優(yōu)化，在不提高單臺(tái)機(jī)器的性能的情況下，采用增加機(jī)器是一個(gè)不錯(cuò)的方式，不僅可以有效地提高系統(tǒng)的負(fù)載能力，而且性價(jià)比高。

增加的機(jī)器用來做什么呢?此時(shí)我們可以把數(shù)據(jù)庫服務(wù)器和Web服務(wù)器拆分開來，這樣不僅提高了單臺(tái)機(jī)器的負(fù)載能力，也提高了容災(zāi)能力。

應(yīng)用服務(wù)器與數(shù)據(jù)庫分開后的架構(gòu)如下圖所示：

階段三、應(yīng)用服務(wù)器集群

隨著訪問量繼續(xù)增加，單臺(tái)應(yīng)用服務(wù)器已經(jīng)無法滿足需求了。在假設(shè)數(shù)據(jù)庫服務(wù)器沒有壓力的情況下，我們可以把應(yīng)用服務(wù)器從一臺(tái)變成了兩臺(tái)甚至多臺(tái)，把用戶的請(qǐng)求分散到不同的服務(wù)器中，從而提高負(fù)載能力。而多臺(tái)應(yīng)用服務(wù)器之間沒有直接的交互，他們都是依賴數(shù)據(jù)庫各自對(duì)外提供服務(wù)。著名的做故障切換的軟件有KeepAlived，KeepAlived是一個(gè)類似于Layer3、4、7交換機(jī)制的軟件，他不是某個(gè)具體軟件故障切換的專屬品，而是可以適用于各種軟件的一款產(chǎn)品。KeepAlived配合上ipvsadm又可以做負(fù)載均衡，可謂是神器。

我們以增加了一臺(tái)應(yīng)用服務(wù)器為例，增加后的系統(tǒng)結(jié)構(gòu)圖如下：

系統(tǒng)演變到這里，將會(huì)出現(xiàn)下面四個(gè)問題：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 用戶的請(qǐng)求由誰來轉(zhuǎn)發(fā)到到具體的應(yīng)用服務(wù)器?

3. 有那些轉(zhuǎn)發(fā)的算法和策略可以使用?

4. 應(yīng)用服務(wù)器如何返回用戶的請(qǐng)求?

5. 用戶如果每次訪問到的服務(wù)器不一樣，那么如何維護(hù)session的一致性?

針對(duì)以上問題，常用的解決方案如下：

1、負(fù)載均衡的問題

一般以下有5種解決方案：

1）、HTTP重定向

HTTP重定向就是應(yīng)用層的請(qǐng)求轉(zhuǎn)發(fā)。用戶的請(qǐng)求其實(shí)已經(jīng)到了HTTP重定向負(fù)載均衡服務(wù)器，服務(wù)器根據(jù)算法要求用戶重定向，用戶收到重定向請(qǐng)求后，再次請(qǐng)求真正的集群

• 優(yōu)點(diǎn)：簡(jiǎn)單易用;

• 缺點(diǎn)：性能較差。

2）、DNS域名解析負(fù)載均衡

DNS域名解析負(fù)載均衡就是在用戶請(qǐng)求DNS服務(wù)器，獲取域名對(duì)應(yīng)的IP地址時(shí)，DNS服務(wù)器直接給出負(fù)載均衡后的服務(wù)器IP。

• 優(yōu)點(diǎn)：交給DNS，不用我們?nèi)ゾS護(hù)負(fù)載均衡服務(wù)器;

• 缺點(diǎn)：當(dāng)一個(gè)應(yīng)用服務(wù)器掛了，不能及時(shí)通知DNS，而且DNS負(fù)載均衡的控制權(quán)在域名服務(wù)商那里，網(wǎng)站無法做更多的改善和更強(qiáng)大的管理。

3）、反向代理服務(wù)器

在用戶的請(qǐng)求到達(dá)反向代理服務(wù)器時(shí)(已經(jīng)到達(dá)網(wǎng)站機(jī)房)，由反向代理服務(wù)器根據(jù)算法轉(zhuǎn)發(fā)到具體的服務(wù)器。常用的Apache，Nginx都可以充當(dāng)反向代理服務(wù)器。

• 優(yōu)點(diǎn)：部署簡(jiǎn)單;

• 缺點(diǎn)：代理服務(wù)器可能成為性能的瓶頸，特別是一次上傳大文件。

4）、IP層負(fù)載均衡

在請(qǐng)求到達(dá)負(fù)載均衡器后，負(fù)載均衡器通過修改請(qǐng)求的目的IP地址，從而實(shí)現(xiàn)請(qǐng)求的轉(zhuǎn)發(fā)，做到負(fù)載均衡。

• 優(yōu)點(diǎn)：性能更好;

• 缺點(diǎn)：負(fù)載均衡器的寬帶成為瓶頸。

5）、數(shù)據(jù)鏈路層負(fù)載均衡

在請(qǐng)求到達(dá)負(fù)載均衡器后，負(fù)載均衡器通過修改請(qǐng)求的MAC地址，從而做到負(fù)載均衡，與IP負(fù)載均衡不一樣的是，當(dāng)請(qǐng)求訪問完服務(wù)器之后，直接返回客戶。而無需再經(jīng)過負(fù)載均衡器。

2、集群調(diào)度轉(zhuǎn)發(fā)算法

1）、rr輪詢調(diào)度算法

顧名思義，輪詢分發(fā)請(qǐng)求。

• 優(yōu)點(diǎn)：實(shí)現(xiàn)簡(jiǎn)單

• 缺點(diǎn)：不考慮每臺(tái)服務(wù)器的處理能力

2）、wrr加權(quán)調(diào)度算法

我們給每個(gè)服務(wù)器設(shè)置權(quán)值Weight，負(fù)載均衡調(diào)度器根據(jù)權(quán)值調(diào)度服務(wù)器，服務(wù)器被調(diào)用的次數(shù)跟權(quán)值成正比。

• 優(yōu)點(diǎn)：考慮了服務(wù)器處理能力的不同

3）、sh原地址散列算法

提取用戶IP，根據(jù)散列函數(shù)得出一個(gè)key，再根據(jù)靜態(tài)映射表，查處對(duì)應(yīng)的value，即目標(biāo)服務(wù)器IP。過目標(biāo)機(jī)器超負(fù)荷，則返回空。

• 優(yōu)點(diǎn)：實(shí)現(xiàn)同一個(gè)用戶訪問同一個(gè)服務(wù)器。

4）、dh目標(biāo)地址散列算法

原理同上，只是現(xiàn)在提取的是目標(biāo)地址的IP來做哈希。

• 優(yōu)點(diǎn)：實(shí)現(xiàn)同一個(gè)用戶訪問同一個(gè)服務(wù)器。

5）、lc最少連接算法

優(yōu)先把請(qǐng)求轉(zhuǎn)發(fā)給連接數(shù)少的服務(wù)器。

• 優(yōu)點(diǎn)：使得集群中各個(gè)服務(wù)器的負(fù)載更加均勻。

6）、wlc加權(quán)最少連接算法

在lc的基礎(chǔ)上，為每臺(tái)服務(wù)器加上權(quán)值。算法為：(活動(dòng)連接數(shù) * 256 + 非活動(dòng)連接數(shù)) ÷ 權(quán)重，計(jì)算出來的值小的服務(wù)器優(yōu)先被選擇。

• 優(yōu)點(diǎn)：可以根據(jù)服務(wù)器的能力分配請(qǐng)求。

7）、sed最短期望延遲算法

其實(shí)sed跟wlc類似，區(qū)別是不考慮非活動(dòng)連接數(shù)。算法為：(活動(dòng)連接數(shù) +1 ) * 256 ÷ 權(quán)重，同樣計(jì)算出來的值小的服務(wù)器優(yōu)先被選擇。

8)、nq永不排隊(duì)算法

改進(jìn)的sed算法。我們想一下什么情況下才能“永不排隊(duì)”，那就是服務(wù)器的連接數(shù)為0的時(shí)候，那么假如有服務(wù)器連接數(shù)為0，均衡器直接把請(qǐng)求轉(zhuǎn)發(fā)給它，無需經(jīng)過sed的計(jì)算。

9)、LBLC基于局部性最少連接算法

負(fù)載均衡器根據(jù)請(qǐng)求的目的IP地址，找出該IP地址最近被使用的服務(wù)器，把請(qǐng)求轉(zhuǎn)發(fā)之。若該服務(wù)器超載，最采用最少連接數(shù)算法。

10)、LBLCR帶復(fù)制的基于局部性最少連接算法

負(fù)載均衡器根據(jù)請(qǐng)求的目的IP地址，找出該IP地址最近使用的“服務(wù)器組”，注意，并不是具體某個(gè)服務(wù)器，然后采用最少連接數(shù)從該組中挑出具體的某臺(tái)服務(wù)器出來，把請(qǐng)求轉(zhuǎn)發(fā)之。若該服務(wù)器超載，那么根據(jù)最少連接數(shù)算法，在集群的非本服務(wù)器組的服務(wù)器中，找出一臺(tái)服務(wù)器出來，加入本服務(wù)器組，然后把請(qǐng)求轉(zhuǎn)發(fā)。

3、集群請(qǐng)求返回模式問題

1)、NAT

負(fù)載均衡器接收用戶的請(qǐng)求，轉(zhuǎn)發(fā)給具體服務(wù)器，服務(wù)器處理完請(qǐng)求返回給均衡器，均衡器再重新返回給用戶。

2)、DR

負(fù)載均衡器接收用戶的請(qǐng)求，轉(zhuǎn)發(fā)給具體服務(wù)器，服務(wù)器出來玩請(qǐng)求后直接返回給用戶。需要系統(tǒng)支持IP Tunneling協(xié)議，難以跨平臺(tái)。

3)、TUN

同上，但無需IP Tunneling協(xié)議，跨平臺(tái)性好，大部分系統(tǒng)都可以支持。

4、集群Session一致性問題

1)、Session

Session  就是把同一個(gè)用戶在某一個(gè)會(huì)話中的請(qǐng)求，都分配到固定的某一臺(tái)服務(wù)器中，這樣我們就不需要解決跨服務(wù)器的session問題了，常見的算法有ip_hash算法，即上面提到的兩種散列算法。

• 優(yōu)點(diǎn)：實(shí)現(xiàn)簡(jiǎn)單;

• 缺點(diǎn)：應(yīng)用服務(wù)器重啟則session消失。

2)、Session Replication

Session replication就是在集群中復(fù)制session，使得每個(gè)服務(wù)器都保存有全部用戶的session數(shù)據(jù)。

• 優(yōu)點(diǎn)：減輕負(fù)載均衡服務(wù)器的壓力，不需要要實(shí)現(xiàn)ip_hasp算法來轉(zhuǎn)發(fā)請(qǐng)求;

• 缺點(diǎn)：復(fù)制時(shí)網(wǎng)絡(luò)帶寬開銷大，訪問量大的話Session占用內(nèi)存大且浪費(fèi)。

3)、Session數(shù)據(jù)集中存儲(chǔ)

Session數(shù)據(jù)集中存儲(chǔ)就是利用數(shù)據(jù)庫來存儲(chǔ)session數(shù)據(jù)，實(shí)現(xiàn)了session和應(yīng)用服務(wù)器的解耦。

• 優(yōu)點(diǎn)：相比Session replication的方案，集群間對(duì)于寬帶和內(nèi)存的壓力大幅減少;

• 缺點(diǎn)：需要維護(hù)存儲(chǔ)Session的數(shù)據(jù)庫。

4)、Cookie Base

Cookie  base就是把Session存在Cookie中，由瀏覽器來告訴應(yīng)用服務(wù)器我的session是什么，同樣實(shí)現(xiàn)了session和應(yīng)用服務(wù)器的解耦。

• 優(yōu)點(diǎn)：實(shí)現(xiàn)簡(jiǎn)單，基本免維護(hù)。

• 缺點(diǎn)：cookie長(zhǎng)度限制，安全性低，帶寬消耗。

值得一提的是：

• Nginx目前支持的負(fù)載均衡算法有wrr、sh(支持一致性哈希)、fair(lc)。但Nginx作為均衡器的話，還可以一同作為靜態(tài)資源服務(wù)器。

• Keepalived + ipvsadm比較強(qiáng)大，目前支持的算法有：rr、wrr、lc、wlc、lblc、sh、dh

• Keepalived支持集群模式有：NAT、DR、TUN

• Nginx本身并沒有提供session同步的解決方案，而Apache則提供了session共享的支持。

解決了以上的問題之后，系統(tǒng)的結(jié)構(gòu)如下：

階段四、數(shù)據(jù)庫讀寫分離化

上面我們總是假設(shè)數(shù)據(jù)庫負(fù)載正常，但隨著訪問量的的提高，數(shù)據(jù)庫的負(fù)載也在慢慢增大。那么可能有人馬上就想到跟應(yīng)用服務(wù)器一樣，把數(shù)據(jù)庫一份為二再負(fù)載均衡即可。

但對(duì)于數(shù)據(jù)庫來說，并沒有那么簡(jiǎn)單。假如我們簡(jiǎn)單的把數(shù)據(jù)庫一分為二，然后對(duì)于數(shù)據(jù)庫的請(qǐng)求，分別負(fù)載到A機(jī)器和B機(jī)器，那么顯而易見會(huì)造成兩臺(tái)數(shù)據(jù)庫數(shù)據(jù)不統(tǒng)一的問題。那么對(duì)于這種情況，我們可以先考慮使用讀寫分離和主從復(fù)制的方式。

讀寫分離后的系統(tǒng)結(jié)構(gòu)如下：

這個(gè)結(jié)構(gòu)變化后也會(huì)帶來兩個(gè)問題：

• 主從數(shù)據(jù)庫之間數(shù)據(jù)同步問題。

• 應(yīng)用對(duì)于數(shù)據(jù)源的選擇問題。

解決方案：

• 使用MySQL自帶的Master + Slave的方式實(shí)現(xiàn)主從復(fù)制。

• 采用第三方數(shù)據(jù)庫中間件，例如MyCat。MyCat是從Cobar發(fā)展而來的，而Cobar是阿里開源的數(shù)據(jù)庫中間件，后來停止開發(fā)。MyCat是國內(nèi)比較好的MySql開源數(shù)據(jù)庫分庫分表中間件。

階段五、用搜索引擎緩解讀庫的壓力

數(shù)據(jù)庫做讀庫的話，常常對(duì)模糊查找力不從心，即使做了讀寫分離，這個(gè)問題還未能解決。以我們所舉的交易網(wǎng)站為例，發(fā)布的商品存儲(chǔ)在數(shù)據(jù)庫中，用戶最常使用的功能就是查找商品，尤其是根據(jù)商品的標(biāo)題來查找對(duì)應(yīng)的商品。對(duì)于這種需求，一般我們都是通過like功能來實(shí)現(xiàn)的，但是這種方式的代價(jià)非常大，而且結(jié)果非常不準(zhǔn)確。此時(shí)我們可以使用搜索引擎的倒排索引來完成。

搜索引擎具有的優(yōu)點(diǎn)：它能夠大大提高查詢速度和搜索準(zhǔn)確性。

引入搜索引擎的開銷

• 帶來大量的維護(hù)工作，我們需要自己實(shí)現(xiàn)索引的構(gòu)建過程，設(shè)計(jì)全量/增加的構(gòu)建方式來應(yīng)對(duì)非實(shí)時(shí)與實(shí)時(shí)的查詢需求。

• 需要維護(hù)搜索引擎集群

搜索引擎并不能替代數(shù)據(jù)庫，它解決了某些場(chǎng)景下的精準(zhǔn)、快速、高效的“讀”操作，是否引入搜索引擎，需要綜合考慮整個(gè)系統(tǒng)的需求。

引入搜索引擎后的系統(tǒng)結(jié)構(gòu)如下：

階段六、用緩存緩解讀庫的壓力

常用的緩存機(jī)制包括頁面級(jí)緩存、應(yīng)用數(shù)據(jù)緩存和數(shù)據(jù)庫緩存。

應(yīng)用層和數(shù)據(jù)庫層的緩存

隨著訪問量的增加，逐漸出現(xiàn)了許多用戶訪問同一部分熱門內(nèi)容的情況，對(duì)于這些比較熱門的內(nèi)容，沒必要每次都從數(shù)據(jù)庫讀取。我們可以使用緩存技術(shù)，例如可以使用Google的開源緩存技術(shù)Guava或者使用Memecahed作為應(yīng)用層的緩存，也可以使用Redis作為數(shù)據(jù)庫層的緩存。

另外，在某些場(chǎng)景下，關(guān)系型數(shù)據(jù)庫并不是很適合，例如我想做一個(gè)“每日輸入密碼錯(cuò)誤次數(shù)限制”的功能，思路大概是在用戶登錄時(shí)，如果登錄錯(cuò)誤，則記錄下該用戶的IP和錯(cuò)誤次數(shù)，那么這個(gè)數(shù)據(jù)要放在哪里呢?假如放在內(nèi)存中，那么顯然會(huì)占用太大的內(nèi)容;假如放在關(guān)系型數(shù)據(jù)庫中，那么既要建立數(shù)據(jù)庫表，還要簡(jiǎn)歷對(duì)應(yīng)的Java  bean，還要寫SQL等等。而分析一下我們要存儲(chǔ)的數(shù)據(jù)，無非就是類似{ip:errorNumber}這樣的key:value數(shù)據(jù)。對(duì)于這種數(shù)據(jù)，我們可以用NOSQL數(shù)據(jù)庫來代替?zhèn)鹘y(tǒng)的關(guān)系型數(shù)據(jù)庫。

頁面緩存

除了數(shù)據(jù)緩存，還有頁面緩存。比如使用HTML5的localstroage或者Cookie。除了頁面緩存帶來的性能提升外，對(duì)于并發(fā)訪問且頁面置換頻率小的頁面，應(yīng)盡量使用頁面靜態(tài)化技術(shù)。

• 優(yōu)點(diǎn)：減輕數(shù)據(jù)庫的壓力， 大幅度提高訪問速度;

• 缺點(diǎn)：需要維護(hù)緩存服務(wù)器，提高了編碼的復(fù)雜性。

值得一提的是：

緩存集群的調(diào)度算法不同與上面提到的應(yīng)用服務(wù)器和數(shù)據(jù)庫。采用一致性哈希算，這樣才能提高結(jié)果的概率。

加入緩存后的系統(tǒng)結(jié)構(gòu)如下：

階段七、數(shù)據(jù)庫水平拆分與垂直拆分

我們的網(wǎng)站演進(jìn)到現(xiàn)在，交易、商品、用戶的數(shù)據(jù)都還在同一個(gè)數(shù)據(jù)庫中。盡管采取了增加緩存和讀寫分離的方式，但隨著數(shù)據(jù)庫的壓力繼續(xù)增加，數(shù)據(jù)庫數(shù)據(jù)量的瓶頸越來越突出，此時(shí)，我們可以有數(shù)據(jù)垂直拆分和水平拆分兩種選擇。

數(shù)據(jù)垂直拆分

垂直拆分的意思是把數(shù)據(jù)庫中不同的業(yè)務(wù)數(shù)據(jù)拆分到不同的數(shù)據(jù)庫中，結(jié)合現(xiàn)在的例子，就是把交易、商品、用戶的數(shù)據(jù)分開。

優(yōu)點(diǎn)：

• 解決了原來把所有業(yè)務(wù)放在一個(gè)數(shù)據(jù)庫中的壓力問題;

• 可以根據(jù)業(yè)務(wù)的特點(diǎn)進(jìn)行更多的優(yōu)化。

缺點(diǎn)：

• 需要維護(hù)多個(gè)數(shù)據(jù)庫的狀態(tài)一致性和數(shù)據(jù)同步。

問題：

• 需要考慮原來跨業(yè)務(wù)的事務(wù);

• 跨數(shù)據(jù)庫的Join。

解決問題方案：

• 應(yīng)該在應(yīng)用層盡量避免跨數(shù)據(jù)庫的分布式事務(wù)，如果非要跨數(shù)據(jù)庫，盡量在代碼中控制。

• 通過第三方中間件來解決，如上面提到的MyCat，MyCat提供了豐富的跨庫Join方案，詳情可參考MyCat官方文檔。

數(shù)據(jù)垂直拆分后的結(jié)構(gòu)如下：

數(shù)據(jù)水平拆分

數(shù)據(jù)水平拆分就是把同一個(gè)表中的數(shù)據(jù)拆分到兩個(gè)甚至多個(gè)數(shù)據(jù)庫中。產(chǎn)生數(shù)據(jù)水平拆分的原因是某個(gè)業(yè)務(wù)的數(shù)據(jù)量或者更新量到達(dá)了單個(gè)數(shù)據(jù)庫的瓶頸，這時(shí)就可以把這個(gè)表拆分到兩個(gè)或更多個(gè)數(shù)據(jù)庫中。

優(yōu)點(diǎn)：

• 如果能克服以上問題，那么我們將能夠很好地對(duì)數(shù)據(jù)量及寫入量增長(zhǎng)的情況。

問題：

• 訪問用戶信息的應(yīng)用系統(tǒng)需要解決SQL路由的問題，因?yàn)楝F(xiàn)在用戶信息分在了兩個(gè)數(shù)據(jù)庫中，需要在進(jìn)行數(shù)據(jù)操作時(shí)了解需要操作的數(shù)據(jù)在哪里。

• 主鍵 的處理也變得不同，例如原來自增字段，現(xiàn)在不能簡(jiǎn)單地繼續(xù)使用。

• 如果需要分頁查詢，那就更加麻煩。

解決問題方案：

• 我們還是可以通過可以解決第三方中間件，如MyCat。MyCat可以通過SQL解析模塊對(duì)我們的SQL進(jìn)行解析，再根據(jù)我們的配置，把請(qǐng)求轉(zhuǎn)發(fā)到具體的某個(gè)數(shù)據(jù)庫。

• 我們可以通過UUID保證自定義ID方案來解決。

• MyCat也提供了豐富的分頁查詢方案，比如先從每個(gè)數(shù)據(jù)庫做分頁查詢，再合并數(shù)據(jù)做一次分頁查詢等等。

數(shù)據(jù)水平拆分后的結(jié)構(gòu)如下：

階段八、應(yīng)用的拆分

按微服務(wù)拆分應(yīng)用

隨著業(yè)務(wù)的發(fā)展，業(yè)務(wù)越來越多，應(yīng)用越來越大。我們需要考慮如何避免讓應(yīng)用越來越臃腫。這就需要把應(yīng)用拆開，從一個(gè)應(yīng)用變?yōu)閭z個(gè)甚至更多。還是以我們上面的例子，我們可以把用戶、商品、交易拆分開。變成“用戶、商品”和“用戶，交易”兩個(gè)子系統(tǒng)。

拆分后的結(jié)構(gòu)：

問題：

這樣拆分后，可能會(huì)有一些相同的代碼，如用戶相關(guān)的代碼，商品和交易都需要用戶信息，所以在兩個(gè)系統(tǒng)中都保留差不多的操作用戶信息的代碼。如何保證這些代碼可以復(fù)用是一個(gè)需要解決的問題。

解決問題：

通過走服務(wù)化SOA的路線來解決頻繁公共的服務(wù)。

走SOA服務(wù)化治理道路

為了解決上面拆分應(yīng)用后所出現(xiàn)的問題，我們把公共的服務(wù)拆分出來，形成一種服務(wù)化的模式，簡(jiǎn)稱SOA。

采用服務(wù)化之后的系統(tǒng)結(jié)構(gòu)：

優(yōu)點(diǎn)：

• 相同的代碼不會(huì)散落在不同的應(yīng)用中了，這些實(shí)現(xiàn)放在了各個(gè)服務(wù)中心，使代碼得到更好的維護(hù)。

• 我們把對(duì)數(shù)據(jù)庫的交互業(yè)務(wù)放在了各個(gè)服務(wù)中心，讓前端的Web應(yīng)用更注重與瀏覽器交互的工作。

問題：

• 如何進(jìn)行遠(yuǎn)程的服務(wù)調(diào)用?

解決方法：

• 可以通過下面的引入消息中間件來解決。

階段九、引入消息中間件

隨著網(wǎng)站的繼續(xù)發(fā)展，的系統(tǒng)中可能出現(xiàn)不同語言開發(fā)的子模塊和部署在不同平臺(tái)的子系統(tǒng)。此時(shí)我們需要一個(gè)平臺(tái)來傳遞可靠的，與平臺(tái)和語言無關(guān)的數(shù)據(jù)，并且能夠把負(fù)載均衡透明化，能在調(diào)用過程中收集并分析調(diào)用數(shù)據(jù)，推測(cè)出網(wǎng)站的訪問增長(zhǎng)率等等一系列需求，對(duì)于網(wǎng)站應(yīng)該如何成長(zhǎng)做出預(yù)測(cè)。開源消息中間件有阿里的Dubbo，可以搭配Google開源的分布式程序協(xié)調(diào)服務(wù)Zookeeper實(shí)現(xiàn)服務(wù)器的注冊(cè)與發(fā)現(xiàn)。

引入消息中間件后的結(jié)構(gòu)：

以上就是“怎么用Java Web搭建一個(gè)簡(jiǎn)單的電商系統(tǒng)”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家閱讀完這篇文章都有很大的收獲，小編每天都會(huì)為大家更新不同的知識(shí)，如果還想學(xué)習(xí)更多的知識(shí)，請(qǐng)關(guān)注億速云行業(yè)資訊頻道。