【Java貓說】項目架構的演進史（大型電商系列）

閱讀本文約 「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貓說】實例變量與局部變量