摘要：我們本次也要從核心模塊演進(jìn)細(xì)節(jié)到核心架構(gòu)設(shè)計(jì)思想，最后實(shí)現(xiàn)高性能高并發(fā)高可用的電商實(shí)戰(zhàn)項(xiàng)目。過(guò)程中安全性數(shù)據(jù)分析監(jiān)控反作弊繼續(xù)發(fā)展架構(gòu)服務(wù)化消息隊(duì)列任務(wù)調(diào)度多機(jī)房因此任何一個(gè)高大上的項(xiàng)目技術(shù)架構(gòu)和開(kāi)發(fā)技術(shù)實(shí)現(xiàn)不是一蹴而就的。

閱讀本文約 “7分鐘”

大家都知道，一個(gè)真實(shí)的企業(yè)級(jí)項(xiàng)目開(kāi)發(fā)過(guò)程、大型企業(yè)項(xiàng)目開(kāi)發(fā)的編碼思維、經(jīng)驗(yàn)、技巧、高質(zhì)量的線(xiàn)上作品都是需要耗費(fèi)人力物力和成本，同樣我們的項(xiàng)目也需要你擠出時(shí)間慢慢消化哦！

讓我們來(lái)看看我們最熟悉的淘寶架構(gòu)

當(dāng)然，沒(méi)有哪個(gè)網(wǎng)站一個(gè)就是這么豐富的，都是一步一步進(jìn)展起來(lái)的。

我們本次也要從核心模塊-演進(jìn)細(xì)節(jié)到核心架構(gòu)-設(shè)計(jì)思想，最后實(shí)現(xiàn)高性能、高并發(fā)、高可用的電商實(shí)戰(zhàn)項(xiàng)目。

本次我們將講的有數(shù)據(jù)庫(kù)及接口、項(xiàng)目初始化、用戶(hù)模塊、分類(lèi)模塊、商品模塊、購(gòu)物車(chē)模塊、收貨地址模塊、支付模塊、訂單模塊······

由于是序章，我們先來(lái)了解一下，一個(gè)大型Java項(xiàng)目架構(gòu)演進(jìn)解析

首先從一個(gè)小網(wǎng)站說(shuō)起，一臺(tái)服務(wù)器就夠了，數(shù)據(jù)庫(kù)與應(yīng)用均部署到一個(gè)服務(wù)器上。

隨著用戶(hù)增加，數(shù)據(jù)量增大，硬盤(pán)支撐不起，這時(shí)一臺(tái)服務(wù)器已經(jīng)支持不起了。我們可以將應(yīng)用服務(wù)器和數(shù)據(jù)服務(wù)分離，給應(yīng)用服務(wù)器配置更好的CPU、內(nèi)存等，給數(shù)據(jù)服務(wù)器配置更好更快的硬盤(pán)，如下圖用了三臺(tái)服務(wù)器以提高性能。

即使文件服務(wù)器宕機(jī)，該架構(gòu)依然可以支持使用，隨著訪(fǎng)問(wèn)的并發(fā)增高，為了降低接口訪(fǎng)問(wèn)時(shí)間、提高服務(wù)性能，我們需要繼續(xù)優(yōu)化演進(jìn)，我們會(huì)發(fā)現(xiàn)有很多數(shù)據(jù)其實(shí)并不需要每次都從數(shù)據(jù)庫(kù)中讀取，于是我們?cè)黾恿司彺?，主要?0%的訪(fǎng)問(wèn)都集中在20%的數(shù)據(jù)上（28原則），只要緩存得當(dāng)，系統(tǒng)的性能也將得到提升，而緩存又分為兩種Local Cache本地緩存、Remote Distributed Cache遠(yuǎn)程單機(jī)緩存（遠(yuǎn)程分布式緩存）下圖為分布式緩存集群（什么樣的業(yè)務(wù)使用遠(yuǎn)程緩存、什么業(yè)務(wù)使用本地緩存）

這個(gè)時(shí)候隨著訪(fǎng)問(wèn)的QPS不斷提高，服務(wù)器的處理能力有限，例如Tomcat，則其將成為一個(gè)瓶頸，即使購(gòu)買(mǎi)更好的硬件，但總是存在上限且成本也不低，這時(shí)我們就需要做個(gè)服務(wù)器的集群（負(fù)載均衡調(diào)度服務(wù)器），這樣我們就可以橫向擴(kuò)展我們的服務(wù)器，解決服務(wù)器處理能力的瓶頸。

這時(shí)我們還要思考幾個(gè)問(wèn)題，所謂負(fù)載均衡的調(diào)度策略是什么，適合什么場(chǎng)景，當(dāng)我們登錄A服務(wù)器，Session信息存儲(chǔ)在A服務(wù)器上，假設(shè)我們的（IPHash）負(fù)載均衡將其信息分散到其他服務(wù)器，但是其不夠分散也不夠均勻，可能造成某些服務(wù)器壓力過(guò)大，某些則沒(méi)有壓力，這時(shí)機(jī)器網(wǎng)卡的帶寬就可能成為瓶頸，這時(shí)我們使用輪詢(xún)或最小連接負(fù)載的策略，可能導(dǎo)致訪(fǎng)問(wèn)A服務(wù)器后，再訪(fǎng)問(wèn)B服務(wù)器時(shí)讀取不到Session信息，這時(shí)我們就要解決Session管理的問(wèn)題，我們使用Session Sticky（粘制會(huì)話(huà)）來(lái)處理這個(gè)問(wèn)題，就比如說(shuō)每次吃飯都為了保證用的是我們自己的碗筷，只要在飯店中存了我們的碗筷，則每次去這家飯店吃就好了，其處理方式：對(duì)于同一連接中的數(shù)據(jù)包，負(fù)載均衡將其進(jìn)行一個(gè)NAT轉(zhuǎn)換后轉(zhuǎn)發(fā)至后端固定的服務(wù)器進(jìn)行處理，如下圖所示，這種方案解決了session共享問(wèn)題（缺點(diǎn)：服務(wù)器一旦重啟其session將全部消失、負(fù)載均衡服務(wù)器成為一個(gè)有狀態(tài)的服務(wù)器，比較難實(shí)現(xiàn)容災(zāi)）

我們?cè)倏纯吹诙€(gè)解決方案，兩個(gè)服務(wù)器通過(guò)復(fù)制都保存Browser1的session信息（缺點(diǎn)：應(yīng)用服務(wù)器間的帶寬問(wèn)題，服務(wù)器間要不斷的同步session信息、大量用戶(hù)在線(xiàn)時(shí)服務(wù)器占用內(nèi)存過(guò)多、不適合做大規(guī)模集群）

再看看第三個(gè)方案，基于cookie，即每次吃飯都帶上自己的碗筷，則去哪家飯店都可以吃飯，用攜帶session信息的cookie去訪(fǎng)問(wèn)服務(wù)器，其也解決了session共享的問(wèn)題（缺點(diǎn)：cookie長(zhǎng)度有限，且保存在瀏覽器上，安全性沒(méi)有保障）

接著再看看第四種解決方案，我們將session做成一個(gè)session服務(wù)器，browser1通過(guò)負(fù)載均衡請(qǐng)求服務(wù)器，服務(wù)器將session信息存儲(chǔ)到session服務(wù)器中，當(dāng)想要獲取時(shí)就反向進(jìn)行。（缺點(diǎn)：目前session Server是單點(diǎn)的，如何解決單點(diǎn)，保證可用性）

我們可以將Session Server也做成集群，其適合用于Session數(shù)量與web服務(wù)數(shù)量大的情況下，更改架構(gòu)后，也要修改應(yīng)用存儲(chǔ)session的業(yè)務(wù)邏輯。 接下來(lái)我們?cè)倏纯磾?shù)據(jù)庫(kù)，讀寫(xiě)都要經(jīng)過(guò)數(shù)據(jù)庫(kù)，當(dāng)用戶(hù)量達(dá)到一定量時(shí)，數(shù)據(jù)庫(kù)又將成為一個(gè)瓶頸，則我們將如何解決？我們可以使用數(shù)據(jù)庫(kù)的讀寫(xiě)分離，主從庫(kù)，并通過(guò)統(tǒng)一的數(shù)據(jù)訪(fǎng)問(wèn)模型進(jìn)行訪(fǎng)問(wèn)，將所有讀操作引入到Slave服務(wù)器，將寫(xiě)操作引入到主庫(kù)當(dāng)中，由于數(shù)據(jù)庫(kù)讀寫(xiě)分離，所以應(yīng)用程序也要有相應(yīng)的變化，使用數(shù)據(jù)訪(fǎng)問(wèn)模塊讓?xiě)?yīng)用程序開(kāi)發(fā)人員不用理會(huì)讀寫(xiě)分離的存在，這樣多數(shù)據(jù)源讀寫(xiě)代碼對(duì)我們的業(yè)務(wù)就沒(méi)有了侵入（代碼層的演變，如何支持多數(shù)據(jù)源、如何封裝對(duì)業(yè)務(wù)沒(méi)有侵入、如何使用現(xiàn)用的ORM框架實(shí)現(xiàn)數(shù)據(jù)讀寫(xiě)分離、是否更換ORM、其優(yōu)缺點(diǎn)？）

當(dāng)我們?cè)L問(wèn)過(guò)大，I/O過(guò)大，我們數(shù)據(jù)的讀寫(xiě)分離又將遇到這幾個(gè)問(wèn)題，主從庫(kù)復(fù)制時(shí)是否延遲（分機(jī)房部署、跨機(jī)房傳輸），應(yīng)用對(duì)于數(shù)據(jù)源的路由問(wèn)題，接著我們?yōu)榱颂岣叻?wù)器，增加了CND和反向代理服務(wù)器，使用CDN可以解決不同地方訪(fǎng)問(wèn)速度問(wèn)題、反向代理可以在機(jī)房中緩存用戶(hù)的資源。

這時(shí)文件服務(wù)器又出現(xiàn)了瓶頸，我們將文件服務(wù)器改為分布式文件服務(wù)器集群，我們要考慮到：如何不影響線(xiàn)上的業(yè)務(wù)訪(fǎng)問(wèn)，是否需要業(yè)務(wù)部門(mén)幫忙清理數(shù)據(jù)，是否需要備份服務(wù)器，是否需要重新做域名解析。

這時(shí)我們的數(shù)據(jù)庫(kù)又出現(xiàn)了新的瓶頸，我們選擇專(zhuān)庫(kù)專(zhuān)用的方式，進(jìn)行數(shù)據(jù)庫(kù)的垂直拆分，可以解決寫(xiě)數(shù)據(jù)、并發(fā)、量大的問(wèn)題，分庫(kù)后又將帶來(lái)一些新的問(wèn)題：跨業(yè)務(wù)的事務(wù)（分布式事務(wù)）

當(dāng)某個(gè)數(shù)據(jù)的訪(fǎng)問(wèn)量、數(shù)據(jù)量、日志等過(guò)大達(dá)到瓶頸時(shí)，這時(shí)我們就要進(jìn)行數(shù)據(jù)庫(kù)的水平拆分，我們將User拆分成Users1和Users2，水平拆分即將同一個(gè)數(shù)據(jù)表的數(shù)據(jù)拆分到兩個(gè)數(shù)據(jù)庫(kù)當(dāng)中，這時(shí)我們就解決了單數(shù)據(jù)庫(kù)的瓶頸。

水平拆分后，SQL路由出現(xiàn)一些問(wèn)題，假設(shè)我們想知道某個(gè)用戶(hù)是存在Users1還是Users2中，且由于分庫(kù)，主鍵的策略也將有所不同，同時(shí)也將面臨一個(gè)分頁(yè)的問(wèn)題（后臺(tái)管理系統(tǒng)在進(jìn)行展示時(shí)還要考慮分頁(yè)的問(wèn)題），當(dāng)完成后，我們又發(fā)現(xiàn)應(yīng)用服務(wù)器的搜索量上升，這時(shí)我們將應(yīng)用服務(wù)器的搜索功能提取出來(lái)做成搜索引擎，同時(shí)部分場(chǎng)景使用NoSQL提高性能，

當(dāng)然以上架構(gòu)還存在部分問(wèn)題，如負(fù)載均衡服務(wù)器是單點(diǎn)，因此也可以將負(fù)載均衡服務(wù)器做成集群，進(jìn)行主從的熱備，同時(shí)做一個(gè)自動(dòng)切換的解決方案。

過(guò)程中：安全性、數(shù)據(jù)分析、監(jiān)控、反作弊… 繼續(xù)發(fā)展：SOA架構(gòu)、服務(wù)化、消息隊(duì)列、任務(wù)調(diào)度、多機(jī)房…

因此任何一個(gè)高大上的項(xiàng)目技術(shù)架構(gòu)和開(kāi)發(fā)技術(shù)實(shí)現(xiàn)不是一蹴而就的。

本文已轉(zhuǎn)載個(gè)人技術(shù)公眾號(hào)：UncleCatMySelf
歡迎留言討論與點(diǎn)贊
上一篇推薦：【Java貓說(shuō)】SSM整合Netty5.0詳細(xì)說(shuō)明
下一篇推薦：【Java貓說(shuō)】實(shí)例變量與局部變量