摘要：我們本次也要從核心模塊演進細節到核心架構設計思想，最后實現高性能高并發高可用的電商實戰項目。過程中安全性數據分析監控反作弊繼續發展架構服務化消息隊列任務調度多機房因此任何一個高大上的項目技術架構和開發技術實現不是一蹴而就的。

閱讀本文約 “7分鐘”

大家都知道，一個真實的企業級項目開發過程、大型企業項目開發的編碼思維、經驗、技巧、高質量的線上作品都是需要耗費人力物力和成本，同樣我們的項目也需要你擠出時間慢慢消化哦！

讓我們來看看我們最熟悉的淘寶架構

當然，沒有哪個網站一個就是這么豐富的，都是一步一步進展起來的。

我們本次也要從核心模塊-演進細節到核心架構-設計思想，最后實現高性能、高并發、高可用的電商實戰項目。

本次我們將講的有數據庫及接口、項目初始化、用戶模塊、分類模塊、商品模塊、購物車模塊、收貨地址模塊、支付模塊、訂單模塊······

由于是序章，我們先來了解一下，一個大型Java項目架構演進解析

首先從一個小網站說起，一臺服務器就夠了，數據庫與應用均部署到一個服務器上。

隨著用戶增加，數據量增大，硬盤支撐不起，這時一臺服務器已經支持不起了。我們可以將應用服務器和數據服務分離，給應用服務器配置更好的CPU、內存等，給數據服務器配置更好更快的硬盤，如下圖用了三臺服務器以提高性能。

即使文件服務器宕機，該架構依然可以支持使用，隨著訪問的并發增高，為了降低接口訪問時間、提高服務性能，我們需要繼續優化演進，我們會發現有很多數據其實并不需要每次都從數據庫中讀取，于是我們增加了緩存，主要是80%的訪問都集中在20%的數據上（28原則），只要緩存得當，系統的性能也將得到提升，而緩存又分為兩種Local Cache本地緩存、Remote Distributed Cache遠程單機緩存（遠程分布式緩存）下圖為分布式緩存集群（什么樣的業務使用遠程緩存、什么業務使用本地緩存）

這個時候隨著訪問的QPS不斷提高，服務器的處理能力有限，例如Tomcat，則其將成為一個瓶頸，即使購買更好的硬件，但總是存在上限且成本也不低，這時我們就需要做個服務器的集群（負載均衡調度服務器），這樣我們就可以橫向擴展我們的服務器，解決服務器處理能力的瓶頸。

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

我們再看看第二個解決方案，兩個服務器通過復制都保存Browser1的session信息（缺點：應用服務器間的帶寬問題，服務器間要不斷的同步session信息、大量用戶在線時服務器占用內存過多、不適合做大規模集群）

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

接著再看看第四種解決方案，我們將session做成一個session服務器，browser1通過負載均衡請求服務器，服務器將session信息存儲到session服務器中，當想要獲取時就反向進行。（缺點：目前session Server是單點的，如何解決單點，保證可用性）

我們可以將Session Server也做成集群，其適合用于Session數量與web服務數量大的情況下，更改架構后，也要修改應用存儲session的業務邏輯。 接下來我們再看看數據庫，讀寫都要經過數據庫，當用戶量達到一定量時，數據庫又將成為一個瓶頸，則我們將如何解決？我們可以使用數據庫的讀寫分離，主從庫，并通過統一的數據訪問模型進行訪問，將所有讀操作引入到Slave服務器，將寫操作引入到主庫當中，由于數據庫讀寫分離，所以應用程序也要有相應的變化，使用數據訪問模塊讓應用程序開發人員不用理會讀寫分離的存在，這樣多數據源讀寫代碼對我們的業務就沒有了侵入（代碼層的演變，如何支持多數據源、如何封裝對業務沒有侵入、如何使用現用的ORM框架實現數據讀寫分離、是否更換ORM、其優缺點？）

當我們訪問過大，I/O過大，我們數據的讀寫分離又將遇到這幾個問題，主從庫復制時是否延遲（分機房部署、跨機房傳輸），應用對于數據源的路由問題，接著我們為了提高服務器，增加了CND和反向代理服務器，使用CDN可以解決不同地方訪問速度問題、反向代理可以在機房中緩存用戶的資源。

這時文件服務器又出現了瓶頸，我們將文件服務器改為分布式文件服務器集群，我們要考慮到：如何不影響線上的業務訪問，是否需要業務部門幫忙清理數據，是否需要備份服務器，是否需要重新做域名解析。

這時我們的數據庫又出現了新的瓶頸，我們選擇專庫專用的方式，進行數據庫的垂直拆分，可以解決寫數據、并發、量大的問題，分庫后又將帶來一些新的問題：跨業務的事務（分布式事務）

當某個數據的訪問量、數據量、日志等過大達到瓶頸時，這時我們就要進行數據庫的水平拆分，我們將User拆分成Users1和Users2，水平拆分即將同一個數據表的數據拆分到兩個數據庫當中，這時我們就解決了單數據庫的瓶頸。

水平拆分后，SQL路由出現一些問題，假設我們想知道某個用戶是存在Users1還是Users2中，且由于分庫，主鍵的策略也將有所不同，同時也將面臨一個分頁的問題（后臺管理系統在進行展示時還要考慮分頁的問題），當完成后，我們又發現應用服務器的搜索量上升，這時我們將應用服務器的搜索功能提取出來做成搜索引擎，同時部分場景使用NoSQL提高性能，

當然以上架構還存在部分問題，如負載均衡服務器是單點，因此也可以將負載均衡服務器做成集群，進行主從的熱備，同時做一個自動切換的解決方案。

過程中：安全性、數據分析、監控、反作弊… 繼續發展：SOA架構、服務化、消息隊列、任務調度、多機房…

因此任何一個高大上的項目技術架構和開發技術實現不是一蹴而就的。

本文已轉載個人技術公眾號：UncleCatMySelf
歡迎留言討論與點贊
上一篇推薦：【Java貓說】SSM整合Netty5.0詳細說明
下一篇推薦：【Java貓說】實例變量與局部變量