大型網站技術架構

1、使用緩存減輕數據庫的壓力，提高網站性能。二八定律，80%的業務訪問集中在20%的數據上。

1.緩存在應用服務器上的本地緩存。（Session）

2.緩存在專門的分佈式緩存服務器上的遠程緩存。能夠採用集羣的方式，理論上能夠作到無限擴充。（Redis、memcached等）

2、使用服務器集羣改善網站的併發處理能力。

1.單一服務器沒法知足需求時，不要企圖更換更大的服務器。更恰當的作法是增長服務器來分擔原有服務器的壓力。

2.經過負載均衡調度服務器。

3.數據庫讀寫分離。經過主從配置能夠將一臺數據庫服務器的數據同步到另外一臺服務器，網站利用數據庫的這一功能，實現數據庫的讀寫分離，從而改善數據的負載壓力。（MySql數據主從配置，讀寫分離）

4.使用反向代理和CDN加速網站響應，其基本原理都是緩存，區別在於CDN部署在網絡提供商的機房，用戶能夠從距離本身最近的網絡提供商機房獲取數據；而反向代理部署在網站的中心機房，用戶請求到達後首先訪問的是反向代理服務器，若是反向代理服務器緩存有用戶請求的資源，則將其直接返回給用戶。（Nginx等）

3、使用分佈式文件系統和分佈式數據庫系統。

1.分佈式數據庫是網站數據庫拆分的最後手段，只有在單表數據規模很是龐大的時候纔去使用。不到不得已時，網站經常使用的數據庫拆分手段是業務分庫，將不一樣業務的數據庫部署在不一樣的物理服務器上。

2.使用NoSql和搜索引擎。（經常使用的NoSql有mongodb等，經常使用的搜索引擎有：elasticsearch、solr等）

4、業務拆分

1.爲了應對日益複雜的業務場景，經過分而治之的手段將整個網站拆分紅不用的產品線，分歸不一樣的業務團隊負責。每一個應用獨立部署，應用之間能夠經過超連接創建關係（在首頁的導航連接每一個都指向不一樣的應用地址），也能夠經過消息隊列進行數據分發，實際最多的仍是經過訪問同一個數據存儲系統來構成一個關聯的完整系統。

5、分佈式服務

1.隨着業務拆分愈來愈細，系統部署愈來愈多，網站維護會愈來愈困難，在數萬臺服務器規模的網站中，鏈接數據太多，會致使數據庫鏈接資源不足，拒絕服務。考慮都不少業務都會執行許多相同的操做，咱們能夠把這些可複用的業務獨立出來，單獨部署，經過分佈式服務調用共同業務完成具體業務操做。

2.隨着雲計算技術的日趨成熟，咱們能夠考慮租用雲計算平臺，按需付費，彈性擴充。

 6、網站架構模式

1.分層（橫向切分）。三層分別部署在不一樣的服務器上，這樣可使網站擁有更多的計算資源應對愈來愈多的用戶訪問。分層結構對網站支持高併發向分佈式方向發展相當重要。

2.分割（縱向切分）。同一業務內部，若是規模過於龐大，能夠考慮繼續分割。好比購物業務能夠進一步分割成機票酒店業務、3C業務、小商品業務等更細的粒度。

3.分佈式

分佈式優勢：能夠解決網站高併發的問題。

分佈式缺點：a.分佈式意味着服務調用必須經過網絡，可能對性能形成比較嚴重的影響。

b.服務器越多，宕機的機率越高，一臺服務器宕機可能致使不少應用不可訪問，使網站可用性下降。

c.數據在分佈式的環境中保持數據一致性也很困難，分佈式事物也難以保證。

d.分佈式致使網站依賴錯綜複雜，開發管理維護困難。

綜上所述，分佈式設計要視具體狀況，切莫爲了分佈式而分佈式。

經常使用的分佈式有如下幾種：

a.分佈式應用和服務：將分層和分割後的應用和服務模塊分佈式部署

b.分佈式靜態資源：網站的靜態資源如js、css、logo圖片等資源獨立分佈式部署，並採用獨立域名，即江湖中傳說的動靜分離。

c.分佈式數據和存儲：關係型數據庫分佈式、nosql數據庫分佈式。

d.分佈式計算：Hadoop、MapReduce、Spark。

此外還有分佈式配置、分佈式鎖、分佈式文件系統等。

4.集羣

說白了就是春運買火車票的時候額外增長一些售票窗口。

如何實現多臺服務器網站的同步更新？

5.緩存

經常使用的緩存有如下幾種：

a.CDN

b.反向代理

c.本地緩存

d.分佈式緩存

6.異步

 在單一服務器內部可經過多線程共享內存隊列的方式實現異步，處在業務操做前面的線程將輸出寫入到隊列，後面的線程從隊列中讀取數據進行處理；在分佈式系統中，多個服務器集羣經過分佈式消息隊列實現異步，分佈式消息隊列能夠看做內存隊列的分佈式部署。

異步架構是典型的生產者消費者模式，二者不存在直接調用。

優勢：a.提升系統可用性。

b.加快網站響應速度。

c.消除併發訪問高峯。

7.冗餘

a.至少兩臺服務器部署網站，防止忽然的宕機。

b.數據庫除了按期備份，存檔保存，實現冷備份外，爲了保證在線業務高可用，還須要對數據庫進行主從分離，實時同步實現熱備份。

c.爲了抵禦地震、海嘯等不可抗拒的突發天然災難致使的網站徹底癱瘓，能夠進行全球範圍內部署災備數據中心。（固然是牛逼吊炸天的公司嘍）

 8.自動化

自動化失效轉移，將失效的服務器從集羣中隔離出去，再也不處理系統中的應用請求。

9.安全

a.經過密碼和手機驗證碼進行身份認證。

b.登陸、交易等操做須要對網絡通訊進行加密,服務器端存儲的敏感數據也要進行加密處理。

c.使用驗證碼防止機器人程序濫用網絡資源攻擊網站。

d.對於常見的用於攻擊網站的XSS攻擊、SQL注入進行編碼轉換等相應處理。

e.對於垃圾信息、敏感信息進行過濾。

f.對於交易轉帳等重要操做根據交易模式和交易信息進行風險控制。

 7、大型網站核心架構要素

1.性能

a.在瀏覽器端，能夠經過瀏覽器緩存、使用頁面壓縮、合理佈局頁面、減小Cookie傳輸等手段改善。

b.使用CDN緩存熱點數據。

c.在服務端，可使用本地緩存和分佈式緩存加快請求處理過程，減輕數據庫負載壓力。

d.經過異步操做將用戶請求發至消息隊列等待後續任務處理，而當前請求直接返回響應給用戶。

e.能夠將多臺應用程序服務器組成一個集羣共同對外服務，應對多用戶高併發，提高總體 處理能力。

f.代碼層面，可使用多線程、改善內存管理等手段優化性能。

g.在數據庫服務器端，索引、緩存、SQL優化等系能優化手段都已經比較成熟。還能夠考慮使用NoSQL數據庫。

2.可用性

a.網站高可用的主要手段是冗餘，應用程序部署在多臺服務器上同時提供訪問，數據存儲在多臺服務器上互相備份。

應用服務器上不能保存請求的會話信息，不然服務器宕機，會話丟失，即便用戶請求轉發到其餘服務器上也沒法完成業務處理。

3.伸縮性

衡量架構的伸縮性的主要標準就是是否能夠用多臺服務器構建集羣，是否容易向集羣中添加新的服務器。加入新的服務器是否能夠提供和原來的服務器無差異的服務。集羣中可容納的總的服務器的數量是否有限制。

4.擴展性

網站的可伸縮架構的主要手段是事件驅動架構和分佈式服務。

事件驅動架構一般是利用消息隊列實現；分佈式服務則是將業務和可複用服務分離開來。

5.安全性

衡量網站是否安全的標準是針對現存的和潛在的各類攻擊與竊密手段，是否有可靠的應對策略。

8、架構

1.瀏覽器訪問優化

減小http請求。主要手段：合併CSS、合併javascript、合併圖片（經過CSS偏移控制）。

2.使用瀏覽器緩存

a.經過設置http頭中的Cache-Control和Expires的屬性。

b.在某些時候，靜態資源文件的變化須要及時應用到客戶端瀏覽器，這種情概，能夠經過改變文件名實現，及更新整個js文件並非只是更新js文件中的內容，而是生成一個新的js文件並更新html文件中的引用。

c.使用瀏覽器緩存策略的網站在更新靜態資源時，應採用一個文件一個文件逐步更新，並有必定的時間間隔，以避免用戶瀏覽器忽然大量緩存失效，集中更新緩存，形成服務器負載驟增、網絡堵塞的狀況。

3.啓用壓縮

html、css、javascript文件啓用GZip壓縮。壓縮會對服務器和瀏覽器產生必定的壓力，因此要權衡考慮。

4.css放在頁面最上面、JavaScript放在頁面最下面

若是頁面解析時就須要用到JavaScript，這時放到底部就不合適了。

5.減小cookie傳輸

太大的cookie會嚴重影響數據傳輸，所以慎重考慮哪些數據要寫入cookie。

6.CDN加速

CDN可以緩存的通常是靜態資源，如圖片、文件、css、script腳本、靜態網頁等。

7.反向代理

安全功能、緩存功能、負載均衡提高網站併發能力。

9、應用服務器性能優化

1.分佈式緩存

a.網站性能優化第必定律：優先考慮使用緩存優化性能。緩存的本質是一個內存的Hsah表。

2.合理使用緩存

a.緩存預熱

緩存系統啓動時就把熱點數據加載好。

b.緩存穿透

若是由於不恰當的業務或者惡意攻擊持續高併發地請求某個不存在的數據，因爲緩存沒有保存該數據，全部的請求都會落到數據庫上，會對數據庫形成很大壓力，甚至崩潰。一個簡單的對策就是將不存在的數據也緩存起來（其value值爲null）。

3.分佈式緩存架構

a.兩種架構：一種是以JBossCache爲表明的須要更新同步的分佈式緩存；一種是以Memcached爲表明的不互相通訊的分佈式緩存。

b.異步操做

10、萬無一失：網站的高可用架構

1.Session服務器

2.網站發佈

3.自動化測試

目前比較流行的web自動化測試工具是Selenium。

 11、網站的伸縮性架構

1.不一樣功能進行物理分離實現伸縮。

具體能夠分爲如下兩種：

a.縱向分離：將業務處理流程上的不一樣部分分離部署。

b.橫向分離：將不一樣的業務模塊分離部署。

2.負載均衡

a.HTTP重定向負載均衡（缺點是瀏覽器須要兩次請求服務器才能完成一次訪問，性能差，因此此種方案不推薦使用）

b.DNS域名解析負載均衡

大型網站老是部分使用DNS域名解析，利用域名解析做爲第一級負載均衡手段，即域名解析獲得的一組服務器並非實際提供web服務器的物理服務器，而是一樣提供負載均衡服務的內部服務器，這組內部負載均衡服務器進行負載均衡，將請求分發到真實的web服務器上。

c.反向代理負載均衡（反向代理服務器轉發請求在HTTP協議層面。優勢是和反向代理服務器功能集成在一塊兒，部署簡單。缺點是反向代理服務器是全部請求和響應的中轉站，其性能可能會成爲瓶頸）

d.IP負載均衡（在網絡層經過修改請求地址進行負載均衡）

 e.數據鏈路層負載均衡（使用三角傳輸模式的鏈路層負載均衡是目前大型網站普遍使用的手段，Linux平臺上最好的鏈路層負載均衡開源產品是LVS（Linux Virtual Server））

3.負載均衡算法

a.輪詢

b.加權輪詢

c.隨機

d.最少鏈接：記錄每一個應用服務器正在處理的鏈接數，將新到的請求分發到最少鏈接的服務器。

e.源地址散列：根據請求來源的IP地址進行Hash計算，獲得應用服務器，這樣來自一個IP地址的請求總在同一個服務器上處理。

4.分佈式緩存集羣

a.Memcached分佈式緩存

5.分佈式緩存的一致性Hash算法

6.關係數據庫集羣

a.MySQL集羣伸縮性方案:數據寫操做都在主服務器上，有主服務器將數據同步到其餘的從服務器，數據庫讀操做都在從服務器上進行。

b.除了數據庫主從讀寫分離，也能夠將不一樣業務數據表部署在不一樣的數據庫集羣上，即俗稱的數據分庫。這種方式的制約條件是垮褲表不能進行Join操做。

c.單表數據過大的時候，還須要進行分片，將一張表拆開分別存儲在多個數據庫中。目前比較成熟的支持數據分片的分佈式關係數據庫產品主要有開源的Amoeba和Cobar。

7.NoSQL

目前使用最普遍的是Apache HBase。

 12、網站的可擴展架構

1.分佈式消息隊列

十3、網站的安全架構

1.XSS攻擊

XSS攻擊即跨站腳本攻擊。分爲另種：一種是反射型XSS攻擊；一種是持久型XSS攻擊。

主要有兩種防攻擊手段：

a.消毒--即對某些html危險字符轉義。

b.HttpOnly--即瀏覽器禁止頁面JavaScript訪問帶有HttpOnly屬性的Cookie，對存放敏感信息的cookie，可經過對該cookie添加HttpOnly屬性，避免被攻擊腳本竊取。

2.注入攻擊

注入攻擊主要有兩種形式：SQL注入攻擊和OS注入攻擊。

a.SQL注入攻擊--攻擊者須要對數據庫結構有所瞭解才能進行，攻擊者獲取數據庫表結構信息的手段有以下幾種：開源（Discuz搭建的論壇，數據結構是公開的）、錯誤回顯（內部錯誤500錯誤會顯示到瀏覽器）、盲注（根據頁面變化狀況判斷sql語句的執行狀況，據此猜想數據庫結構）。

防護手段：

a.首先要避免攻擊者猜想到表名等數據庫表結構信息。

b.消毒--經過正則匹配，過濾掉請求數據中可能注入的sql，如「drop table等」。

c.參數綁定--強力推薦使用參數化，此方法是最好的防sql注入的方法。

3.CSRF攻擊

 CSRF（Cross Site Request Forgery，跨站點請求僞造），其核心是利用了瀏覽器Cookie或服務器Session策略，盜取用戶身份。

防護手段主要是識別請求者身份。主要有一下幾種方法：

a.表單Token--在頁面表單中增長一個隨機數做爲Token，每次響應頁面的Token都不相同，正常頁面提交的請求會包含該Token值，而僞造的請求沒法得到該值，服務器檢查請求參數中Token的值是否存在而且正確以肯定請求提交者是否合法。

b.驗證碼--體驗很差，因此在必要時使用，如支付交易等關鍵頁面。

c.Referer check--http請求頭的Referer域中記錄着請求來源，可經過檢查請求來源，驗證其是否合法（使用此功能實現圖片防盜鏈）。

4.其餘攻擊和漏洞

a.Error Code--也稱做錯誤回顯。防護手段很簡單：經過配置web服務器參數，跳轉500頁面到專門的錯誤頁面便可。

b.Html註釋--刪除註釋而後再上線。

c.文件上傳--用戶可能會上傳可執行的程序，最有效的防護手段：經過文件過濾，只容許上傳可靠的文件類型。

d.路徑遍歷--攻擊者在請求的URL中使用相對路徑，遍歷系統未開放的目錄和文件。防護方法：將js、css訂資源文件部署在獨立的服務器，使用獨立域名，其餘文件不使用靜態的URl訪問，動態參數不包含文件路徑信息。

5.web應用防火牆

ModSecurity是一個開源的web應用防火牆。

除了開源的ModeSecurity，還有一些商業產品的web應用防火牆，如NEC的SiteShell。

6.網站安全漏洞掃描

不按期對網站的服務器進行掃描，查漏補缺。

7.信息加密技術及密鑰安全管理

a.信息加密技術可分爲三類：

單項散列加密--MD五、SHA

對稱加密--DES算法、RC算法等

和非對稱加密--RSA算法

8.分類算法

a.貝葉斯分類算法(會存在誤判)。

b.TAN算法。

c.ARCS算法。

 十4、淘寶架構演變

1.2003年LAMP架構

.

2.2004年java+Oracle+MVC框架(本身開發的Webx)+ORM框架（IBatis）

3.2006年

4.如今迴歸到開源的MySQL及NoSQL系統。有些路，走事後，再回頭，不過是一覽衆山小。

5.秒殺系統的應對策略

a.秒殺系統應獨立部署--防止拖垮主網站。

b.秒殺商品頁面靜態化--將商品描述、商品參數、成交記錄和用戶評價所有寫入一個靜態頁面，用戶請求不須要通過應用服務器的業務邏輯處理，也無需訪問數據庫。

c.租借秒殺活動網絡寬帶

d.動態生成隨機下單頁面URL--避免用戶直接訪問下單URL。

十5、大型網站典型故障

1.寫日誌引起的故障

故障緣由：大量日誌佔滿磁盤空間

解決辦法：關閉沒必要要的日誌

2.高併發訪問數據庫引起的故障

故障緣由：首頁頻繁訪問數據庫

解決辦法：首頁訪問頻繁，首頁須要的數據能夠從緩存服務器或者搜索引擎服務器獲取。首頁最好是靜態的。

3.高併發狀況下鎖引起的故障。

故障緣由：單例對象多處使用了獨一的this。

經驗教訓：使用鎖操做要謹慎。

 十6、架構師

沒有懶惰的員工，只有沒被激發出來的熱情。

互聯網正在並將繼續改變這個世界，一切纔剛剛開始，你我正生逢其時！

.................................................................................................................................................................................................................................................................................

以上內容出自李智慧的《大型網站架構》一書，這些只是本人的讀書筆記，不少地方記錄的不夠詳盡，哪位大蝦若有興趣，可自行下載原書閱讀。