大型網站架構是一個系列文件，歡迎大家關注。本次分享主題：電商網站架構案例。從電商網站的需求，到單機架構，逐步演變為常用的，可供參考的分散式架構的原型。除具備功能需求外，還具備一定的高效能，高可用，可伸縮，可擴充套件等非功能質量需求（架構目標）。
根據實際需要，進行改造，擴充套件，支援千萬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） 使用叢集對應用伺服器進行冗餘，實現高可用；（負載均衡裝置可與應用一塊部署）
使用資料庫主備模式，實現資料備份和高可用；
四、系統容量預估 預估步驟：
註冊使用者數-日均UV量-每日的PV量-每天的併發量； 峰值預估：平常量的2~3倍； 根據併發量（併發，事務數），儲存容量計算系統容量。 客戶需求：3~5年使用者數達到1000萬註冊使用者；
每秒併發數預估：
每天的UV為200萬（二八原則）； 每日每天點選瀏覽30次； PV量：20030=6000萬； 集中訪問量：240.2=4.8小時會有6000萬0.8=4800萬（二八原則）； 每分併發量：4.860=288分鐘，每分鐘訪問4800/288=16.7萬（約等於）； 每秒併發量：16.7萬/60=2780（約等於）； 假設：高峰期為平常值的三倍，則每秒的併發數可以達到8340次。 1毫秒=1.3次訪問； 沒好好學數學後悔了吧？！（不知道以上算是否有錯誤，呵呵~~）
伺服器預估：（以tomcat伺服器舉例）
按一臺web伺服器，支援每秒300個併發計算。平常需要10臺伺服器（約等於）；[tomcat預設配置是150] 高峰期：需要30臺伺服器； 容量預估：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，建立完善的單點登入或賬戶管理系統。
流程說明
使用者第一次登入時，將會話資訊（使用者Id和使用者資訊），比如以使用者Id為Key，寫入分散式Session； 使用者再次登入時，獲取分散式Session，是否有會話資訊，如果沒有則調到登入頁； 一般採用Cache中介軟體實現，建議使用Redis，因此它有持久化功能，方便分散式Session當機後，可以從持久化儲存中載入會話資訊； 存入會話時，可以設定會話保持的時間，比如15分鐘，超過後自動超時； 結合Cache中介軟體，實現的分散式Session，可以很好的模擬Session會話。
6.5資料庫叢集（讀寫分離，分庫分表）
大型網站需要儲存海量的資料，為達到海量資料儲存，高可用，高效能一般採用冗餘的方式進行系統設計。一般有兩種方式讀寫分離和分庫分表。
讀寫分離：一般解決讀比例遠大於寫比例的場景，可採用一主一備，一主多備或多主多備方式。
本案例在業務拆分的基礎上，結合分庫分表和讀寫分離。如下圖：
業務拆分後：每個子系統需要單獨的庫； 如果單獨的庫太大，可以根據業務特性，進行再次分庫，比如商品分類庫，產品庫； 分庫後，如果表中有資料量很大的，則進行分表，一般可以按照Id，時間等進行分表；（高階的用法是一致性Hash） 在分庫，分表的基礎上，進行讀寫分離； 相關中介軟體可參考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 可以很好的解決不同的地區的訪問速度問題，反向代理則在伺服器機房中快取使用者資源：
- 使用分散式檔案系統
- 資料庫專庫專用：資料垂直拆分。
這樣可以解決部分資料寫的問題
垂直拆分資料庫時，會遇到的問題：
跨業務的事務 應用的配置項多了 關於事務的問題，有兩種辦法：
使用分散式事務 去掉事務或不追求強事務 - 某個業務的資料表的資料量或者更新量達到了單個資料庫的瓶頸：資料水平拆分
將同一個表的資料拆分到兩個資料庫中
資料水平拆分會遇到的問題：
SQL 的路由問題，需要知道某個 User 在哪個資料庫上。 主鍵的策略會有不同。 查詢時的效能問題，如分頁問題
使用搜尋引擎：解決資料查詢問題 部分場景可使用 NoSQL 提高效能 開發資料統一訪問模組：解決上層應用開發的資料來源問題
- 業務拆分及應用拆分
網站的業務日益複雜，建立一個獨立的大型應用來完成這所有的業務變得不實際。從管理角度來，也不方便管理。然而，業務的拆分很難找到一種通用的模式，這是一個企業管理問題和技術問題的混合問題。同時和每個企業的具體情況有關。
但是從這兩本書來看，最終架構都走向服務化，也就是 SOA。而如何實現 SOA，是另一個很大的話題，不是本篇文章的範疇。
我從程立 08 年的演講中截個圖來說明 SOA 後的架構大概是怎樣的：
- 非功能性問題
– 安全性問題、監控問題
– 釋出問題：新的架構意味著新的釋出方式
– 分機房
– 這兩本書都沒有說分機房的問題。我沒有經驗，可是也可以猜到如果要分機房了，所有上面的問題都可能要重新考慮。
– 組織架構的變化
我們的技術架構的變化，勢必會引起我們的組織架構的變化，反之亦然。
這部分看似不應該由我們來管，但是，我覺得，我們技術人員也要參與一部分的組織架構的設計。舉個例子，組織架構的設計會涉及績效，而績效有時很像一個國家的法律。如果一個國家的法律不健全，會發生什麼？你懂的。
同時，我們還必須考慮人員對新架構的學習成本。
這部分我目前在看相關的書籍，還沒有一個系統的認識。
總結：
- 關於演進的順序
在現實中，技術架構的演進不一定就是按文章從頭到尾這樣列下來的，所以，要視具體情況來下決定。
- 關於傳統演進與現代有“雲”環境下的演進
很可惜，只有李智慧談到雲，而且只點了一下——“現在越來越多人的網站從建立之初就是搭建在大型網站提供的雲端計算服務基礎之上，所需的一切資源：計算、儲存、網路都可以按需購買線性伸縮，不需要自己一點一點地拼湊各種資源，綜合使用各種技術方案逐步去完善自己的網站架構”。
因為我用“雲”的時間也不長，還不能總結出有云架構與傳統的無雲架構在演進的時候有什麼不同。
說回傳統的架構演進，我自己總結和思考的結果是：
在對網站進行架構調整時，可以從兩大的維度考慮：資料服務和應用服務。而這個調整的過程中，需要分清當前哪個點是瓶頸，需要知道哪個點優化的優先順序最高。同時，最重要的一點：我們雖然作為技術人員，也應該去學習業務知識，這樣我們在考慮問題時分清哪些是業務問題，哪些是技術問題，分清後才能對症下藥。你要知道有些問題用技術手段並不比用業務手段更有效。12306 的分時賣票就是一個典型例子。