大型网站电商网站架构案例和技术架构的示例
大型網站架構是一個系列文檔，歡迎大家關注。本次分享主題：電商網站架構案例。從電商網站的需求，到單機架構，逐步演變為常用的，可供參考的分布式架構的原型。除具備功能需求外，還具備一定的高性能，高可用，可伸縮，可擴展等非功能質量需求（架構目標）。
根據實際需要，進行改造，擴展，支持千萬PV，是沒問題的。
本次分享大綱
電商網站案例，一共有三篇本篇主要說明網站的需求，網站初始架構，系統容量估算方法。
一、電商案例的原因
分布式大型網站，目前看主要有幾類1.大型門戶，比如網易，新浪等；2.SNS網站，比如校內，開心網等；3.電商網站：比如阿里巴巴，京東商城，國美在線，汽車之家等。大型門戶一般是新聞類信息，可以使用CDN，靜態化等方式優化，開心網等交互性比較多，可能會引入更多的NOSQL，分布式緩存，使用高性能的通信框架等。電商網站具備以上兩類的特點，比如產品詳情可以采用CDN，靜態化，交互性高的需要采用NOSQL等技術。因此，我們采用電商網站作為案例，進行分析。
二、電商網站需求
客戶需求：
- 建立一個全品類的電子商務網站（B2C），用戶可以在線購買商品，可以在線支付，也可以貨到付款；
- 用戶購買時可以在線與客服溝通；
- 用戶收到商品后，可以給商品打分，評價；
- 目前有成熟的進銷存系統；需要與網站對接；
- 希望能夠支持3~5年，業務的發展；
- 預計3~5年用戶數達到1000萬；
- 定期舉辦雙11，雙12,三八男人節等活動；
- 其他的功能參考京東或國美在線等網站。
客戶就是客戶，不會告訴你具體要什么，只會告訴你他想要什么，我們很多時候要引導，挖掘客戶的需求。好在提供了明確的參考網站。因此，下一步要進行大量的分析，結合行業，以及參考網站，給客戶提供方案。
其他的略~~~~~
需求功能矩陣
需求管理傳統的做法，會使用用例圖或模塊圖（需求列表）進行需求的描述。這樣做常常忽視掉一個很重要的需求（非功能需求），因此推薦大家使用需求功能矩陣，進行需求描述。
本電商網站的需求矩陣如下：
?
| 網站需求 | 功能需求 | 非功能需求 |
| 全品類的電子商務網站 | 分類管理，商品管理 | 方便進行多品類管理（靈活性）網站訪問速度要快（高性能） |
圖片存儲的要求（海量小圖片）用戶可以在線購買商品會員管理，購物車，結算功能良好購物體驗（可用性，性能）在線支付或貨到付款多種在線支付方式支付過程要安全，數據加密（安全性）多種支付接口靈活切換（靈活性，擴展性）可以在線與客服溝通在線客服功能可靠性：即時通訊商品打分評價商品評論?目前有成熟的進銷存系統對接進銷存屬于約束條件對接時要考慮數據一致性，魯棒性支持3~5年，業務的發展?屬于約束條件伸縮性，可擴展性3~5年用戶數達到1000萬?約束條件舉辦雙11，雙12,三八男人節等活動活動管理，秒殺突增訪問流量（可伸縮）實時性要求（高性能）參考京東或國美在線?參考條件
以上是對電商網站需求的簡單舉例，目的是說明（1）需求分析的時候，要全面，大型分布式系統重點考慮非功能需求；（2）描述一個簡單的電商需求場景，使大家對下一步的分析設計有個依據。
三、網站初級架構
一般網站，剛開始的做法，是三臺服務器，一臺部署應用，一臺部署數據庫，一臺部署NFS文件系統。
這是前幾年比較傳統的做法，之前見到一個網站10萬多會員，垂直服裝設計門戶，N多圖片。使用了一臺服務器部署了應用，數據庫以及圖片存儲。出現了很多性能問題。
如下圖：
但是，目前主流的網站架構已經發生了翻天覆地的變化。一般都會采用集群的方式，進行高可用設計。至少是下面這個樣子。
（1）?????? 使用集群對應用服務器進行冗余，實現高可用；（負載均衡設備可與應用一塊部署）
使用數據庫主備模式，實現數據備份和高可用；
四、系統容量預估
預估步驟：
客戶需求：3~5年用戶數達到1000萬注冊用戶；
每秒并發數預估：
沒好好學數學后悔了吧？！（不知道以上算是否有錯誤，呵呵~~）
服務器預估：（以tomcat服務器舉例）
容量預估：70/90原則
系統CPU一般維持在70%左右的水平，高峰期達到90%的水平，是不浪費資源，并比較穩定的。內存，IO類似。
以上預估僅供參考，因為服務器配置，業務邏輯復雜度等都有影響。在此CPU，硬盤，網絡等不再進行評估。
五、網站架構分析
根據以上預估，有幾個問題：
- 需要部署大量的服務器，高峰期計算，可能要部署30臺Web服務器。并且這三十臺服務器，只有秒殺，活動時才會用到，存在大量的浪費。
- 所有的應用部署在同一臺服務器，應用之間耦合嚴重。需要進行垂直切分和水平切分。
- 大量應用存在冗余代碼
- 服務器SESSION同步耗費大量內存和網絡帶寬
- 數據需要頻繁訪問數據庫，數據庫訪問壓力巨大。
大型網站一般需要做以下架構優化（優化是架構設計時，就要考慮的，一般從架構/代碼級別解決，調優主要是簡單參數的調整，比如JVM調優；如果調優涉及大量代碼改造，就不是調優了，屬于重構）：
- 業務拆分
- 應用集群部署（分布式部署，集群部署和負載均衡）
- 多級緩存
- 單點登錄（分布式Session）
- 數據庫集群（讀寫分離，分庫分表）
- 服務化
- 消息隊列
- 其他技術
六、網站架構優化
6.1業務拆分
根據業務屬性進行垂直切分，劃分為產品子系統，購物子系統，支付子系統，評論子系統，客服子系統，接口子系統（對接如進銷存，短信等外部系統）。
根據業務子系統進行等級定義，可分為核心系統和非核心系統。核心系統：產品子系統，購物子系統，支付子系統；非核心：評論子系統，客服子系統，接口子系統。
業務拆分作用：提升為子系統可由專門的團隊和部門負責，專業的人做專業的事，解決模塊之間耦合以及擴展性問題；每個子系統單獨部署，避免集中部署導致一個應用掛了，全部應用不可用的問題。
等級定義作用：用于流量突發時，對關鍵應用進行保護，實現優雅降級；保護關鍵應用不受到影響。
拆分后的架構圖：
參考部署方案2
6.2應用集群部署（分布式，集群，負載均衡）
分布式部署：將業務拆分后的應用單獨部署，應用直接通過RPC進行遠程通信；
集群部署：電商網站的高可用要求，每個應用至少部署兩臺服務器進行集群部署；
負載均衡：是高可用系統必須的，一般應用通過負載均衡實現高可用，分布式服務通過內置的負載均衡實現高可用，關系型數據庫通過主備方式實現高可用。
集群部署后架構圖：
6.3 多級緩存
緩存按照存放的位置一般可分為兩類本地緩存和分布式緩存。本案例采用二級緩存的方式，進行緩存的設計。一級緩存為本地緩存，二級緩存為分布式緩存。（還有頁面緩存，片段緩存等，那是更細粒度的劃分）
一級緩存，緩存數據字典，和常用熱點數據等基本不可變/有規則變化的信息，二級緩存緩存需要的所有緩存。當一級緩存過期或不可用時，訪問二級緩存的數據。如果二級緩存也沒有，則訪問數據庫。
緩存的比例，一般1:4，即可考慮使用緩存。（理論上是1:2即可）。
根據業務特性可使用以下緩存過期策略：
6.4單點登錄（分布式Session）
系統分割為多個子系統，獨立部署后，不可避免的會遇到會話管理的問題。一般可采用Session同步，Cookies，分布式Session方式。電商網站一般采用分布式Session實現。
再進一步可以根據分布式Session，建立完善的單點登錄或賬戶管理系統。
流程說明
結合Cache中間件，實現的分布式Session，可以很好的模擬Session會話。
6.5數據庫集群（讀寫分離，分庫分表）
大型網站需要存儲海量的數據，為達到海量數據存儲，高可用，高性能一般采用冗余的方式進行系統設計。一般有兩種方式讀寫分離和分庫分表。
讀寫分離：一般解決讀比例遠大于寫比例的場景，可采用一主一備，一主多備或多主多備方式。
本案例在業務拆分的基礎上，結合分庫分表和讀寫分離。如下圖：
相關中間件可參考Cobar（阿里，目前已不在維護），TDDL（阿里），Atlas（奇虎360），MyCat（在Cobar基礎上，國內很多牛人，號稱國內第一開源項目）。
分庫分表后序列的問題，JOIN，事務的問題，會在分庫分表主題分享中，介紹。
6.6服務化
將多個子系統公用的功能/模塊，進行抽取，作為公用服務使用。比如本案例的會員子系統就可以抽取為公用的服務。
6.7消息隊列
消息隊列可以解決子系統/模塊之間的耦合，實現異步，高可用，高性能的系統。是分布式系統的標準配置。本案例中，消息隊列主要應用在購物，配送環節。
目前使用較多的MQ有Active MQ,Rabbit MQ,Zero MQ，MS MQ等，需要根據具體的業務場景進行選擇。建議可以研究下Rabbit MQ。
6.8其他架構（技術）
除了以上介紹的業務拆分，應用集群，多級緩存，單點登錄，數據庫集群，服務化，消息隊列外。還有CDN，反向代理，分布式文件系統，大數據處理等系統。
此處不詳細介紹，大家可以問度娘/Google，有機會的話也可以分享給大家。
七、架構總結
以上是本次分享的架構總結，其中細節可參考前面分享的內容。其中還有很多可以優化和細化的地方，因為是案例分享，主要針對重要部分做了介紹，工作中需要大家根據具體的業務場景進行架構設計。
以上是電商網站架構案例的分享一共有三篇，從電商網站的需求，到單機架構，逐步演變為常用的，可供參考的分布式架構的原型。除具備功能需求外，還具備一定的高性能，高可用，可伸縮，可擴展等非功能質量需求（架構目標）。
2.網站技術架構示例
最近我在閱讀 2 本關于大型網站架構的書：《大型網站技術架構——核心原理與案例分析》李智慧、《大型網站系統與 Java 中間件實踐》曾憲杰。
我期望從這些書中學習到大型網站是如何做架構的，這個過程會遇到什么問題。當看完這 2 本書后，我總結出兩個大問題：
1. 網站技術架構為什么會演進？換個說法就是為什么網站會變大？
2. 演進的過程會遇到什么問題？或者說為了演進，會遇到什么問題？
網站技術架構為什么會演進
我個人總結出來我們的技術架構演進的兩種驅動力，驅動著我們為什么演進網站的技術架構：
1. 內在驅動力：我們期望把當前的業務做得更好，開發更多新業務
2. 外在驅動力：用戶量的上升、用戶種類的多樣化
這兩種驅動力不是獨立的，更多時候是并行的。我想淘寶就是兩種驅動力并行驅動的結果。
演進的原因很簡單。但是在什么時機我們就應該演進網站的技術架構了，以及如何演進？面對這些問題，說實話，我沒有任何經驗，再說現實中每家企業當時都面臨的問題都不一樣，所以，我很難從經驗中總結出什么是演進的時機。
但是我可以從另一個角度切入這個問題：研究網站內外結構，找到這些結構可能出現的問題點，知道或者預見到問題點了，你當然就知道應該怎么演進了。類似于你了解了 PC 機的結構，你也就知道什么時候要加內存了，什么時候要加硬盤了。
那么我們先看看網站的外部結構：
外部結構中，我們可以看由以下幾個部分構成：
U：代表用戶群。當用戶群變了，我們的網站如何演進？用戶群的分析，我目前能知道的維度有：數量，種類，地理位置（區域）。
N：代表網絡環境。網絡環境在每個地區都不同。你可以想像我們為什么需要 CDN。當我們期望每個區域的用戶都能得到好的體驗，我們的網站如何演進？
S：代表安全。就是我們要安全到什么程度？這與網站當前所處階段及你網站的性質有關。
C：代表我們的網站。屬于內部結構
網站的內部結構：
內部結構的組成：
A：應用服務。
D：數據服務
總結下來就是我們在考慮網站是否應該演進了或者如何演進時，這些組成部分為我們提供了考慮問題的基準。
那么我們為什么不一開始就把網站設計成“大型”的。李智慧在后記里寫到：“不要企圖去設計一個大型網站”，“原因是互聯網發展運行有其自己的規律，短暫的互聯網歷史已經一再證明這種企圖行不通”。還說了：“大型網站不是設計出來的，而是逐步演化出來的”。對于最后這句話，我需要提醒下：“不是設計出來的”并不代表“隨意設計”。
對于“大型網站的設計”，我個人的看法是現在我們的有“云”了，計算是可以買的，只要我們的設計能適應“云”，我是不是就可以一開始就設計大型網站了？
演進的過程會遇到什么問題
-?最初
從一個小網站說起。一臺服務器也就足夠了。
-?數據服務與應用服務分離
越來越多的用戶代表著越來越多的數據，一臺服務器已經滿足不了。我們將數據服務和應用服務分離，給應用服務器配置更好的 CPU，內存。而給數據服務器配置更好更大的硬盤。
- 使用緩存
因為 80% 的業務訪問都集中在 20% 的數據上，如果我們能將這部分數據緩存下來，性能一下子就上來了。而緩存又分為兩種：本地緩存和遠程分布式緩存。具體使用哪種？還是兩種都用，我目前不知道。
這里有一個問題，書沒有提到：應該緩存哪些數據？應該有一些原則的吧。
- 使用服務器集群
當這臺服務器的處理能力達到上限時，它就會成為瓶頸。雖然你是可以通過購買更強大的硬件，但總會有上限。這時，我們就需要服務器的集群。這時，就必須加個新東西：負載均衡調度服務器。
但是，使用服務器集群時，需要考慮一個問題：Session 的管理問題。Session 的管理有以下幾種方式：
Session Sticky：打個比方就是如果我們每次吃飯都要保證我們用的是自己的碗筷，而只要我們在一家飯店里存著我們的碗筷，只要我們每次去這家飯店吃飯就好了。
這種方式的問題：
1. 一臺服務器重啟，上面的 session 都沒了
2. 負載均衡器成了有狀態的機器，要實現容災會有麻煩
Session 復制：就像我們在所有的飯店里都存一份自己的碗筷。不適合做大規模集群，適合機器不多的情況
這種方案的問題：
1. 應用服務器間帶寬問題
2. 大量用戶在線時，占用內存過多
基于 Cookie：類似于每次吃飯都把自己的碗筷帶上
這種方案的問題：
1. Cookie 的長度限制
2. 安全性
3. 數據中心外部帶寬的消耗
4. 性能影響，服務器處理每次的請求的內容又多了
Session 服務器：同樣可以是集群的。這種方式適用于 session 數量及 web 服務器數量大的情況
這種方案需要考慮的是：
1. 保證 session 服務器的可用性
2. 我們在寫應用時需要做調整，我目前不知道應用服務器能否將這部分邏輯透明化
- 數據庫讀寫分離
數據庫的一部分讀（未緩存、緩存過期）及所有的寫操作都還需要經過數據庫。當用戶量達到一定量，數據庫將會成為瓶頸。這邊我們使用數據庫提供的熱備功能，將所有的讀操作引入 slave 服務器。注意：讀寫分離解決的是讀壓力大的問題。
因為數據庫的讀寫分離了，所以，我們的應用程序也得做相應的變化。我們實現一個數據訪問模塊使上層寫代碼的人不知道讀寫分離的存在。這里，我很想知道如果我使用 ORM 模型時，如何實現讀寫的分離？
數據庫讀寫分離會遇到如下問題：
- 使用反向代理和 CDN 加速網站響應
使用 CDN 可以很好的解決不同的地區的訪問速度問題，反向代理則在服務器機房中緩存用戶資源：
- 使用分布式文件系統
- 數據庫專庫專用：數據垂直拆分。
這樣可以解決部分數據寫的問題
垂直拆分數據庫時，會遇到的問題：
關于事務的問題，有兩種辦法：
-?某個業務的數據表的數據量或者更新量達到了單個數據庫的瓶頸：數據水平拆分
將同一個表的數據拆分到兩個數據庫中
數據水平拆分會遇到的問題：
?
- 使用搜索引擎：解決數據查詢問題
- 部分場景可使用 NoSQL 提高性能
- 開發數據統一訪問模塊：解決上層應用開發的數據源問題
- 業務拆分及應用拆分
網站的業務日益復雜，建立一個獨立的大型應用來完成這所有的業務變得不實際。從管理角度來，也不方便管理。然而，業務的拆分很難找到一種通用的模式，這是一個企業管理問題和技術問題的混合問題。同時和每個企業的具體情況有關。
但是從這兩本書來看，最終架構都走向服務化，也就是 SOA。而如何實現 SOA，是另一個很大的話題，不是本篇文章的范疇。
我從程立 08 年的演講中截個圖來說明 SOA 后的架構大概是怎樣的：
- 非功能性問題
? ?– 安全性問題、監控問題
– 發布問題：新的架構意味著新的發布方式
– 分機房
–?這兩本書都沒有說分機房的問題。我沒有經驗，可是也可以猜到如果要分機房了，所有上面的問題都可能要重新考慮。
– 組織架構的變化?
我們的技術架構的變化，勢必會引起我們的組織架構的變化，反之亦然。
這部分看似不應該由我們來管，但是，我覺得，我們技術人員也要參與一部分的組織架構的設計。舉個例子，組織架構的設計會涉及績效，而績效有時很像一個國家的法律。如果一個國家的法律不健全，會發生什么？你懂的。
同時，我們還必須考慮人員對新架構的學習成本。
這部分我目前在看相關的書籍，還沒有一個系統的認識。
總結：
- 關于演進的順序
在現實中，技術架構的演進不一定就是按文章從頭到尾這樣列下來的，所以，要視具體情況來下決定。
- 關于傳統演進與現代有“云”環境下的演進
很可惜，只有李智慧談到云，而且只點了一下——“現在越來越多人的網站從建立之初就是搭建在大型網站提供的云計算服務基礎之上，所需的一切資源：計算、存儲、網絡都可以按需購買線性伸縮，不需要自己一點一點地拼湊各種資源，綜合使用各種技術方案逐步去完善自己的網站架構”。
因為我用“云”的時間也不長，還不能總結出有云架構與傳統的無云架構在演進的時候有什么不同。
說回傳統的架構演進，我自己總結和思考的結果是：
在對網站進行架構調整時，可以從兩大的維度考慮：數據服務和應用服務。而這個調整的過程中，需要分清當前哪個點是瓶頸，需要知道哪個點優化的優先級最高。同時，最重要的一點：我們雖然作為技術人員，也應該去學習業務知識，這樣我們在考慮問題時分清哪些是業務問題，哪些是技術問題，分清后才能對癥下藥。你要知道有些問題用技術手段并不比用業務手段更有效。12306 的分時賣票就是一個典型例子。
總結
以上是生活随笔為你收集整理的大型网站电商网站架构案例和技术架构的示例的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 写一个函数取出php,写一个函数,尽可能
- 下一篇： 微信小程序中实现瀑布流布局和无限加载