大型網(wǎng)站架構
網(wǎng)站架構包括：前端架構+應用層架構+服務層架構+存儲層架構+后臺架構+數(shù)據(jù)中心機房架構+安全架構+數(shù)據(jù)采集與監(jiān)控。
前端架構
- 瀏覽器優(yōu)化技術
并不是優(yōu)化瀏覽器，而是通過優(yōu)化響應頁面，加快瀏覽器頁面的加載和顯示，常用的有頁面緩存、合并HTTP 減少請求次數(shù)、使用頁面壓縮等。 - CDN
內(nèi)容分發(fā)網(wǎng)絡，部署在網(wǎng)絡運營商機房，通過將靜態(tài)頁面內(nèi)容分發(fā)到離用戶最近的CDN 服務器，使用戶可以通過最短路徑獲取內(nèi)容。 - 動靜分離，靜態(tài)資源獨立部署
靜態(tài)資源，如JS,CSS 等文件部署在專門的服務器集群上，和Web 應用動態(tài)內(nèi)容服務分離，并使用專門的（二級）域名。 - 圖片服務
圖片不是指網(wǎng)站Logo 按鈕圖標等，這些文件屬于上面提到的靜態(tài)資源，應該和JS CSS 部署在一起。這里的圖片指用戶上傳的圖片，如產(chǎn)品圖片、用戶頭像等，圖片服務同樣使用獨立部署的圖片服務器集群，并使用獨立（二級）域名。 - 反向代理
部署在網(wǎng)站機房，在應用服務器、靜態(tài)資源服務器、圖片服務器之前，提供頁面緩存服務。 - DNS
域名服務，將域名解析成IP 地址，利用DNS 可以實現(xiàn)DNS 負載均衡，配置CDN也需要修改DNS使域名解析后指向CDN 服務器。
應用層架構
應用層是處理網(wǎng)站主要業(yè)務邏輯的地方。
- 開發(fā)框架
- 頁面渲染
將分別開發(fā)維護的動態(tài)內(nèi)容和靜態(tài)頁面模板集成起來，組合成最終顯示給用戶的完整頁面。 - 負載均衡
將多臺應用服務器組成一個集群，通過負載均衡技術將用戶請求分發(fā)到不同的服務器上，以應對大量用戶同時訪問時產(chǎn)生的高并發(fā)負載壓力。 - Session 管理
為了實現(xiàn)高可用的應用服務器集群，應用服務器通常設計為無狀態(tài)，不保存用戶請求上下文信息，但是網(wǎng)站業(yè)務通常需要保持用戶會話信息，需要專門的.機制管理Session
使集群內(nèi)甚至跨集群的應用服務器可以共享Session - 動態(tài)頁面靜態(tài)化
對于訪問量特別大而更新又不很頻繁的動態(tài)頁面，可以將其靜態(tài)化，即生成一個靜態(tài)頁面，利用靜態(tài)頁面的優(yōu)化手段加速用戶訪問，如反向代理、CDN、 瀏覽器緩存等。 - 業(yè)務拆分
將復雜而又龐大的業(yè)務拆分開來，形成多個規(guī)模較小的產(chǎn)品，獨立開發(fā)、部署、維護，除了降低系統(tǒng)耦合度，也便于數(shù)據(jù)庫業(yè)務分庫。按業(yè)務對關系數(shù)據(jù)庫進行拆分，技術難度相對較小，而效果又相對較好。 - 虛擬化服務器
將一臺物理服務器虛擬化成多臺虛擬服務器，對于并發(fā)訪問較低的業(yè)務，更容易用較少的資源構建高可用的應用服務器集群。
服務層架構
提供基礎服務，供應用層調用，完成網(wǎng)站業(yè)務。
- 分布式消息
利用消息隊列機制，實現(xiàn)業(yè)務和業(yè)務、業(yè)務和服務之間的異步消息發(fā)送及低耦合的業(yè)務關系。 - 分布式服務
提供高性能、低耦合、易復用、易管理的分布式服務，在網(wǎng)站實現(xiàn)面向服務架構SOA - 分布式緩存
通過可伸縮的服務器集群提供大規(guī)模熱點數(shù)據(jù)的緩存服務，是網(wǎng)站性能優(yōu)化的重要手段。 - 分布式配置
系統(tǒng)運行需要配置許多參數(shù)，如果這些參數(shù)需要修改，比如分布式緩存集群加入新的緩存服務器，需要修改應用程序客戶端的緩存服務器列表配置，并重啟應用程序服務器。分布式配置在系統(tǒng)運行期提供配置動態(tài)推送服務，將配置修改實時推送到應用系統(tǒng),無需重啟服務器。
存儲層架構
分布式文件
網(wǎng)站在線業(yè)務需要存儲的文件大部分都是圖片、網(wǎng)頁、視頻等比較小的文件，但是這些文件的數(shù)量非常龐大，而且通常都在持續(xù)增加，需要伸縮性設計比較好的分布式文件系統(tǒng)。關系數(shù)據(jù)庫
大部分網(wǎng)站的主要業(yè)務是基于關系數(shù)據(jù)庫開發(fā)的，但是關系數(shù)據(jù)庫對集群伸縮性的支持比較差。通過在應用程序的數(shù)據(jù)訪問層增加數(shù)據(jù)庫訪問路由功能，根據(jù)業(yè)務配置將數(shù)據(jù)庫訪問路由到不同的物理數(shù)據(jù)庫上，可實現(xiàn)關系數(shù)據(jù)庫的分布式訪問NoSQL 數(shù)據(jù)庫
目前各種NoSQL 數(shù)據(jù)庫層出不窮，在內(nèi)存管理、數(shù)據(jù)模型、集群分布式管理等方面各有優(yōu)勢，不過從社區(qū)活躍性角度看，HBase 無疑是目前最好的。數(shù)據(jù)同步
在支持全球范圍內(nèi)數(shù)據(jù)共享的分布式數(shù)據(jù)庫技術成熟之前，擁有多個數(shù)據(jù)中心的網(wǎng)站必須在多個數(shù)據(jù)中心之間進行數(shù)據(jù)同步，以保證每個數(shù)據(jù)中心都擁有完整的數(shù)據(jù)。在實踐中，為了減輕數(shù)據(jù)庫壓力，將數(shù)據(jù)庫的事務日志（或者NoSQL 的寫操作Log) 同步到其他數(shù)據(jù)中心，根據(jù)Log 進行數(shù)據(jù)重演，實現(xiàn)數(shù)據(jù)同步。
后臺架構
網(wǎng)站應用中，除了要處理用戶的實時訪問請求外，還有一些后臺非實時數(shù)據(jù)分析要處理。
- 搜索引擎
即使是網(wǎng)站內(nèi)部的搜索引擎，也需要進行數(shù)據(jù)增量更新及全量更新、構建索引等。
這些操作通過后臺系統(tǒng)定時執(zhí)行。 - 數(shù)據(jù)倉庫
根據(jù)離線數(shù)據(jù)，提供數(shù)據(jù)分析與數(shù)據(jù)挖掘服務。 - 推薦系統(tǒng)
社交網(wǎng)站及購物網(wǎng)站通過挖掘人和人之間的關系，人和商品之間的關系，發(fā)掘潛在的人際關系和購物興趣，為用戶提供個性化推薦服務。
數(shù)據(jù)采集與監(jiān)控
監(jiān)控網(wǎng)站訪問情況與系統(tǒng)運行情況，為網(wǎng)站運營決策和運維管理提供支持保障。
- 瀏覽器數(shù)據(jù)采集
通過在網(wǎng)站頁面中嵌入JS 腳本釆集用戶瀏覽器環(huán)境與操作記錄，分析用戶行為。 - 服務器業(yè)務數(shù)據(jù)采集
服務器業(yè)務數(shù)據(jù)包括兩種，一種是采集在服務器端記錄的用戶請求操作日志；一種是釆集應用程序運行期業(yè)務數(shù)據(jù)，比如待處理消息數(shù)目等。 - 服務器性能數(shù)據(jù)采集
采集服務器性能數(shù)據(jù)，如系統(tǒng)負載、內(nèi)存使用率、網(wǎng)卡流量等。 - 系統(tǒng)監(jiān)控
將前述采集的數(shù)據(jù)以圖表的方式展示，以便運營和運維人員監(jiān)控網(wǎng)站運行狀況，做
到這一步僅僅是系統(tǒng)監(jiān)視。更先進的做法是根據(jù)釆集的數(shù)據(jù)進行自動化運維，自動處理
系統(tǒng)異常狀況，實現(xiàn)自動化控制。 - 系統(tǒng)報警
如果采集來的數(shù)據(jù)超過預設的正常情況的閾值，比如系統(tǒng)負載過高，就通過郵件、
短信、語音電話等方式發(fā)出報警信號，等待工程師干預。
安全架構
保護網(wǎng)站免遭攻擊及敏感信息泄露。
- Web 攻擊
以HTTP 請求的方式發(fā)起的攻擊，危害最大的就是XSS 和SQL 注入攻擊。但是只要
措施得當，這兩種攻擊都是比較容易防范的。 - 數(shù)據(jù)保護
敏感信息加密傳輸與存儲，保護網(wǎng)站和用戶資產(chǎn)。
數(shù)據(jù)中心機房架構
山寨與創(chuàng)新的最大區(qū)別不在于是否抄襲、是否模仿，而在于對問題和需求是否真正理解與把握
在解決問題之前，能夠認真思考自己面對的真正問題究竟是什么，有哪些技術方案可以選擇，其基本原理是什么。
網(wǎng)站架構其實并不難，真正能解決問題的技術一定是簡單的。
大型網(wǎng)站的特點：
高并發(fā)、大流量；高可用；海量數(shù)據(jù)；用戶分布廣泛且網(wǎng)絡環(huán)境復雜；安全環(huán)境惡劣；需求快速變更，發(fā)布頻繁；漸進式發(fā)展。
網(wǎng)站系統(tǒng)的演進：
- 單機部署
- 數(shù)據(jù)和應用分離
- 使用緩存減少數(shù)據(jù)庫壓力
網(wǎng)站訪問特點和現(xiàn)實世界的財富分配一樣遵循二八定律：80%的業(yè)務訪問集中在20%
的數(shù)據(jù)上 - 應用服務器集群化
可擴展性，負載均衡 - 數(shù)據(jù)庫讀寫分離
利用的是數(shù)據(jù)庫的主從熱備。寫主讀從。 - 加速網(wǎng)站訪問速度：CDN和反向代理。
CDN 和反向代理的基本原理都是緩存，區(qū)別在于CDN 部署在網(wǎng)絡提供商的機房，使
用戶在請求網(wǎng)站服務時，可以從距離自己最近的網(wǎng)絡提供商機房獲取數(shù)據(jù)；而反向代理
則部署在網(wǎng)站的中心機房，當用戶請求到達中心機房后，首先訪問的服務器是反向代理
服務器，如果反向代理服務器中緩存著用戶請求的資源，就將其直接返回給用戶。 - 分布式數(shù)據(jù)庫和分布式文件系統(tǒng)
網(wǎng)站更常用的數(shù)據(jù)庫拆分手段是業(yè)務分庫，將不同業(yè)務的數(shù)據(jù)
庫部署在不同的物理服務器上。 - 使用NoSQL和搜索引擎
- 業(yè)務拆分
- 分布式服務
但事物發(fā)展到一定階段，就會擁有自身的發(fā)展沖動，擺脫其初衷，向著使自己更強
大的方向發(fā)展。既然大型網(wǎng)站架構解決了海量數(shù)據(jù)的管理和高并發(fā)事務的處理，那么就
可以把這些解決方案應用到網(wǎng)站自身以外的業(yè)務上去。我們看到目前許多大型網(wǎng)站都開
始建設云計算平臺，將計算作為一種基礎資源出售，中小網(wǎng)站不需要再關心技術架構問
題，只需要按需付費，就可以使網(wǎng)站隨著業(yè)務的增長逐漸獲得更大的存儲空間和更多的
計算資源。
這個世界沒有哪個網(wǎng)站從誕生起就是大型網(wǎng)站；也沒有哪個網(wǎng)站第一次發(fā)布就擁有
龐大的用戶，高并發(fā)的訪問，海量的數(shù)據(jù)；大型網(wǎng)站都是從小型網(wǎng)站發(fā)展而來。網(wǎng)站的
價值在于它能為用戶提供什么價值，在于網(wǎng)站能做什么，而不在于它是怎么做的，所以
在網(wǎng)站還很小的時候就去追求網(wǎng)站的架構是舍本逐末，得不償失的。小型網(wǎng)站最需要做
的就是為用戶提供好的服務來創(chuàng)造價值，得到用戶的認可，活下去，野蠻生長。
技術是用來解決業(yè)務問題的，而業(yè)務的問題，也可以通過業(yè)務的手段去解決。
恩，不要妄圖用技術解決所有問題。
大型網(wǎng)站架構模式
- 分層
單一職責，上層對下層的依賴關系。 - 分割
業(yè)務縱向分割，分布式部署。 - 分布式
分層和分割都是為了便于分布式部署。
常用的分布式方案有：分布式應用和服務；分布式靜態(tài)資源；分布式數(shù)據(jù)和存儲；分布式計算。 - 集群
- 緩存
緩存是改善軟件性能的第一手段。
使用緩存有兩個前提條件，一是數(shù)據(jù)訪問熱點不均衡，某些數(shù)據(jù)會被更頻繁的訪問，
這些數(shù)據(jù)應該放在緩存中；二是數(shù)據(jù)在某個時間段內(nèi)有效，不會很快過期，否則緩存的
數(shù)據(jù)就會因已經(jīng)失效而產(chǎn)生臟讀，影響結果的正確性。 - 異步
將一個業(yè)務操作分成多個階段，每個階段之間通過共享數(shù)據(jù)的方式異步執(zhí)行進行協(xié)作。
在分布式系統(tǒng)中，多個服務器集群通過分布式消息隊列實現(xiàn)異步，分布式消息隊列可以看作內(nèi)存隊列的分布式部署。
提高系統(tǒng)可用性。
加快網(wǎng)站響應速度。
消除并發(fā)訪問高峰。 - 冗余
架構要素
從性能、可用性、伸縮性、擴展性、安全這五個要素。
所謂伸縮性是指通過不斷向集群中加入服務器的手段來緩解不斷上升的
用戶并發(fā)訪問壓力和不斷增長的數(shù)據(jù)存儲需求。
衡量架構伸縮性的主要標準就是是否可以用多臺服務器構建集群，是否容易向集群
中添加新的服務器。加入新的服務器后是否可以提供和原來的服務器無差別的服務。集
群中可容納的總的服務器數(shù)量是否有限制。
關系數(shù)據(jù)庫雖然支持數(shù)據(jù)復制，主從熱備等機制，但是很難做到大規(guī)模集群的可伸
縮性，因此關系數(shù)據(jù)庫的集群伸縮性方案必須在數(shù)據(jù)庫之外實現(xiàn)，通過路由分區(qū)等手段
將部署有多個數(shù)據(jù)庫的服務器組成一個集群
至于大部分NoSQL 數(shù)據(jù)庫產(chǎn)品，由于其先天就是為海量數(shù)據(jù)而生，因此其對伸縮性
的支持通常都非常好，可以做到在較少運維參與的情況下實現(xiàn)集群規(guī)模的線性伸縮。
擴展性是指的功能擴展，伸縮是指性能伸縮。
性能優(yōu)化
System Load 即系統(tǒng)負載，指當前正在被CPU 執(zhí)行和等待被CPU 執(zhí)行的進程數(shù)目總和，是反映系統(tǒng)忙閑程度的重要指標。多核CPU 的情況下，完美情況是所有CPU 都在使用，沒有進程在等待處理，所以Load 的理想值是CPU 的數(shù)目。當Load 值低于CPU 數(shù)目的時候，表示CPU 有空閑，資源存在浪費；當Load 值高于CPU 數(shù)目的時候，表示進程在排隊等待CPU 調度，表示系統(tǒng)資源不足，影響應用程序的執(zhí)行性能。
在Linux 系統(tǒng)中使用top 命令査看，該值是三個浮點數(shù)，表示最近1 分鐘，10 分鐘，15 分鐘的運行隊列平均進程數(shù)。
性能測試是一個總稱，具體可細分為性能測試、負載測試、壓力測試、穩(wěn)定性測試。
排査一個網(wǎng)站的性能瓶頸和排査一個程序的性能瓶頸的手法基本相同：檢査請求處
理的各個環(huán)節(jié)的日志，分析哪個環(huán)節(jié)響應時間不合理、超過預期；然后檢査監(jiān)控數(shù)據(jù)，
分析影響性能的主要因素是內(nèi)存、磁盤、網(wǎng)絡、還是cpu? 是代碼問題還是架構設計不
合理，或者系統(tǒng)資源確實不足。
前端性能優(yōu)化
主要優(yōu)化手段有優(yōu)化瀏覽器訪問、使用反向代理、CDN 等。
優(yōu)化瀏覽器訪問的措施：
- 減少http請求。
HTTP 協(xié)議是無狀態(tài)的應用層協(xié)議，意味著每次HTTP 請求都需要建立通信鏈路、進行數(shù)據(jù)傳輸，而在服務器端，每個HTTP 都需要啟動獨立的線程去處理。這些通信和服務的開銷都很昂貴，減少HTTP 請求的數(shù)目可有效提高訪問性能。
減少HTTP 的主要手段是合并CSS,合并JavaScript,合并圖片。將瀏覽器一次訪問需要的JavaScript CSS 合并成一個文件，這樣瀏覽器就只需要一次請求。圖片也可以合并，多張圖片合并成一張，如果每張圖片都有不同的超鏈接，可通過CSS 偏移響應鼠標點擊操作，構造不同的URL - 使用瀏覽器緩存
對一個網(wǎng)站而言，CSS? JavaScript , Logo圖標這些靜態(tài)資源文件更新的頻率都比較低，而這些文件又幾乎是每次HTTP 請求都需要的，如果將這些文件緩存在瀏覽器中，可以極好地改善性能。
通過設置HTTP 頭中Cache-Control 和Expires 的屬性，可設定瀏覽
器緩存，緩存時間可以是數(shù)天，甚至是幾個月。
在某些時候，靜態(tài)資源文件變化需要及時應用到客戶端瀏覽器，這種情況，可通改變文件名實現(xiàn)，即更新JavaScript 文件并不是更新JavaScript 文件內(nèi)容，而是生成一個新的JS 文件并更新HTML 文件中的引用。
使用瀏覽器緩存策略的網(wǎng)站在更新靜態(tài)資源時，應采用批量更新的方法，比如需要更新10 個圖標文件，不宜把10 個文件一次全部更新，而是應一個文件一個文件逐步更
新，并有一定的間隔時間，以免用戶瀏覽器突然大量緩存失效，集中更新緩存，造成服
務器負載驟增、網(wǎng)絡堵塞的情況。 - 啟用壓縮
在服務器端對文件進行壓縮，在瀏覽器端對文件解壓縮，可有效減少通信傳輸?shù)臄?shù)
據(jù)量。文本文件的壓縮效率可達80%以上，因此HTML? CSS? JavaScript 文件啟用GZip
壓縮可達到較好的效果。但是壓縮對服務器和瀏覽器產(chǎn)生一定的壓力，在通信帶寬良好，
而服務器資源不足的情況下要權衡考慮。 - CSS 放在頁面最上面、JavaScript 放在頁面最下面
但如果頁面解析時就需要用到JavaScript, 這時放在底部就不合適了。
5，減少cookie傳輸
服務器端性能優(yōu)化
- 分布式緩存
網(wǎng)站性能優(yōu)化第一定律：優(yōu)先考慮使用緩存優(yōu)化性能。
產(chǎn)品在設計之初就需要一個明確的定位：什么是產(chǎn)品要實現(xiàn)的功能，什么
不是產(chǎn)品提供的特性。在產(chǎn)品漫長的生命周期中，會有形形色色的困難和誘惑
來改變產(chǎn)品的發(fā)展方向，左右搖擺、什么都想做的產(chǎn)品，最后有可能成為一個
失去生命力的四不像。
緩存預熱
緩存穿透 - 異步
消息隊列。需要注意的是，由于數(shù)據(jù)寫入消息隊列后立即返回給用戶，數(shù)據(jù)在后續(xù)的業(yè)務校驗、寫數(shù)據(jù)庫等操作可能失敗，因此在使用消息隊列進行業(yè)務異步處理后，需要適當修改業(yè)
務流程進行配合
任何可以晚點做的事情都應該晚點做。 - 使用集群。
- 代碼優(yōu)化
- 多線程。
啟動線程數(shù)= [任務執(zhí)行時間/ (任務執(zhí)行時間-10 等待時間）] xCPU 內(nèi)核數(shù)
最佳啟動線程數(shù)和CPU 內(nèi)核數(shù)量成正比，和IO 阻塞時間成反比。
如果是計算型任務，那么線程數(shù)最多不超過CPU 內(nèi)核數(shù)，因為啟動再多線程，CPU 也來不及調度；相反如果是任務需要等待磁盤操作，網(wǎng)絡響應，那么多啟動線程有助于提高任務并
發(fā)度，提高系統(tǒng)吞吐能力，改善系統(tǒng)性能。 - 對象復用。單例和池技術。
- 數(shù)據(jù)結果。
- 垃圾回收。
- 多線程。
存儲性能優(yōu)化
B+樹，關系型數(shù)據(jù)庫多采用此數(shù)據(jù)結構。
NoSql產(chǎn)品多采用LSM樹作為主要數(shù)據(jù)結構。
在LSM 樹上進行一次數(shù)據(jù)更新不需要磁盤訪問，在內(nèi)存即可完成，速度遠快于B+
樹。當數(shù)據(jù)訪問以寫操作為主，而讀操作則集中在最近寫入的數(shù)據(jù)上時，使用LSM樹可以極大程度地減少磁盤的訪問次數(shù)，加快訪問速度。
RAID，通過使用RAID 技術，實現(xiàn)數(shù)據(jù)在多塊磁盤上的并發(fā)讀寫和數(shù)據(jù)備份。
RAID 技術在傳統(tǒng)關系數(shù)據(jù)庫及文件系統(tǒng)中應用比較廣泛，但是在大型網(wǎng)站比
較喜歡使用的NoSQL? 以及分布式文件系統(tǒng)中，RAID 技術卻遭到冷落。
高可用性優(yōu)化
4個9也就是一年中大約最多53 分鐘不可用。
主要手段是數(shù)據(jù)和服務的冗余備份及失效轉移。
分級管理，部署隔離。
超時設置。
異步調用。
服務降級。
冪等性設計。
CAP 原理認為，一個提供數(shù)據(jù)服務的存儲系統(tǒng)無法同時滿足數(shù)據(jù)一致性
(Consistency)、數(shù)據(jù)可用性（Availibility )、分區(qū)耐受性即可擴展性（Patition Tolerance? 系統(tǒng)具有跨網(wǎng)絡分區(qū)的伸縮性）這三個條件。
通常我們必須去保證A可用性和P擴展性，某種程度上放棄C一致性。
數(shù)據(jù)最終一致性，這是數(shù)據(jù)一致性中較弱的一種，數(shù)據(jù)可能不一致，但經(jīng)過一段時間的自我恢復和修正，數(shù)據(jù)達到最終一致。
數(shù)據(jù)備份，冷備和熱備。熱備又分同步熱備和異步熱備。
失效轉移操作由三部分組成：失效確認、訪問轉移、數(shù)據(jù)恢復。
伸縮性優(yōu)化
實現(xiàn)負載均衡的基礎技術：
- HTTP 重定向
這種負載均衡方案的優(yōu)點是比較簡單。缺點是瀏覽器需要兩次請求服務器才能完成
一次訪問，性能較差；重定向服務器自身的處理能力有可能成為瓶頸，整個集群的伸縮
性規(guī)模有限；使用HTTP302 響應碼重定向，有可能使搜索引擎判斷為SEO 作弊，降低搜
索排名。因此實踐中使用這種方案進行負載均衡的案例并不多見。 - DNS 域名解析負載均衡
事實上，大型網(wǎng)站總是部分使用DNS 域名解析，利用域名解析作為第一級負載均衡
手段，即域名解析得到的一組服務器并不是實際提供Web 服務的物理服務器，而是同樣
提供負載均衡服務的內(nèi)部服務器，這組內(nèi)部負載均衡服務器再進行負載均衡，將請求分
發(fā)到真實的Web 服務器上。 - 反向代理負載均衡
- IP 負載均衡
- 數(shù)據(jù)鏈路層負載均衡
這種數(shù)據(jù)傳輸方式又稱作三角傳輸模式，負載均衡數(shù)據(jù)分發(fā)過程中不修改IP 地址，
只修改目的mac 地址，通過配置真實物理服務器集群所有機器虛擬IP 和負載均衡服務器
IP 地址一致，從而達到不修改數(shù)據(jù)包的源地址和目的地址就可以進行數(shù)據(jù)分發(fā)的目的
是目前大型網(wǎng)站使用最廣的一種負載均衡手段。在Linux 平臺上最好的鏈路層負載均衡開源產(chǎn)品是LVS ( Linux Virtual Server )。
分布式緩存
一致性哈希
計算機領域有句話：計算機的任何問題都可以通過增加一個虛擬層來解決。
。那么在實踐中，一臺物理服務器虛擬為多少個虛擬服務器節(jié)點合適呢？太多會影響
性能，太少又會導致負載不均衡，一般說來，經(jīng)驗值是150，當然根據(jù)集群規(guī)模和負載均
衡的精度需求，這個值應該根據(jù)具體情況具體對待。
關系型數(shù)據(jù)庫
使用開源中間件，如Cobar。原理是在數(shù)據(jù)庫之上又加了一層。是一個分布式數(shù)據(jù)庫的訪問代理。
當前分布式數(shù)據(jù)庫無法解決的問題是，無法跨庫Join，更無法實現(xiàn)跨庫事務。
所以需要從業(yè)務上避免分布式數(shù)據(jù)庫的缺點：避免事務或者利用事務補償機制代替數(shù)據(jù)庫事務。分解數(shù)據(jù)訪問邏輯避免Join操作。
還有一類分布式數(shù)據(jù)庫可以支持JOIN 操作執(zhí)行復雜
的SQL 査詢，如GreenPlum? 但是這類數(shù)據(jù)庫的訪問延遲比較大（可以想象，JOIN 操作
需要在服務器間傳輸大量的數(shù)據(jù)）， 因此一般使用在數(shù)據(jù)倉庫等非實時業(yè)務中。
NoSql
NoSQL數(shù)據(jù)庫產(chǎn)品都放棄了關系數(shù)據(jù)庫的兩大重要基礎：以關系代數(shù)為基礎的結構化査詢語言
( SQL ) 和事務一致性保證（ACID )。而強化其他一些大型網(wǎng)站更關注的特性：高可用性
和可伸縮性。
可擴展性架構
設計網(wǎng)站可擴展架構的核心思想是模塊化，并在此基礎之上，降低模塊間的耦合性，
提高模塊的復用性。
- 利用分布式消息隊列降低系統(tǒng)耦合性
- 利用分布式服務框架，如Dubbo
- 搭建開放平臺建設網(wǎng)站生態(tài)圈
API接口，協(xié)議轉換，安全，審計，路由，流程
安全架構
常見攻擊
XSS，跨站點腳本攻擊。惡意腳本執(zhí)行。
防御：消毒（特殊字符轉義）
httponly，防止XSS 攻擊者竊取Cookie。
注入攻擊，消毒，預編譯
CSRF，跨站點請求偽造。其核心是利用了瀏覽器Cookie 或服務器Session 策略，盜取用戶身份。
防御：表單Token，驗證碼，referer check（請求來源檢查）
web應用防火墻
ModSecurity
加密
- 單項散列加密
常用的單向散列算法有MD5? SHA 等。單向散列算法還有一個特點就是輸入的任何
微小變化都會導致輸出的完全不同，這個特性有時也會被用來生成信息摘要、計算具有
高離散程度的隨機數(shù)等用途。 - 對稱加密
常用的對稱加密算法有DES 算發(fā)、RC 算法等 - 非對稱加密
非對稱加密的常用算法有RSA 算法
信息過濾
- 文本匹配
正則表達式的效率一般較差，僅適用于短文本及低并發(fā)場景。
高并發(fā)時使用的公幵的算法有很多，基本上都是Trie 樹的變種，空間和時間復雜度都比較好
的有雙數(shù)組Trie 算法等。
秒殺系統(tǒng)架構
網(wǎng)站如果為秒殺時的最高并發(fā)訪問量進行設計部署，就需要比正常運營多得多的服務器，而這些服務器在絕大部分時候都是用不著的，浪費驚人。所以網(wǎng)站的秒殺業(yè)務不能使用正常的網(wǎng)站業(yè)務流程，也不能和正常的網(wǎng)站交易業(yè)務共用服務器，必須設計部署專門的秒殺系統(tǒng)，進行專門應對。
技術挑戰(zhàn)
- 對現(xiàn)有網(wǎng)站業(yè)務沖擊。
如果部署在一起，稍有不慎全業(yè)務癱瘓。 - 高并發(fā)下的應用、數(shù)據(jù)庫負載。
- 突然增加的網(wǎng)絡及服務器帶寬
- 直接下單
下單頁面也是一個普通的URL, 如果得到這個URL， 不用等到秒殺開始就可以下單了。
應對策略
- 獨立部署
2，秒殺產(chǎn)品頁面靜態(tài)化
使其不需要經(jīng)過web服務器和數(shù)據(jù)庫服務器。
3，租借秒殺活動帶寬 - 動態(tài)生成隨機下單頁面URL
為了避免用戶直接訪問下單頁面URL. 需要將該URL 動態(tài)化，即使秒殺系統(tǒng)的開發(fā)
者也無法在秒殺開始前訪問下單頁面的URL. 辦法是在下單頁面URL 加入由服務器端生
成的隨機數(shù)作為參數(shù)，在秒殺開始的時候才能得到。
架構設計
- 如何控制秒殺按鈕的點亮
解決辦法是使用JavaScript 腳本控制，在秒殺商品靜態(tài)頁面中加入一個JavaScript 文
件引用，該JavaScript 文件中加入秒殺是否開始的標志和下單頁面URL 的隨機數(shù)參數(shù)，
當秒殺開始的時候生成一個新的JavaScript 文件并被用戶瀏覽器加載，控制秒殺商品頁面
的展示。這個javaScript 文件使用隨機版本號，并且不被瀏覽器、CDN 和反向代理服務
器緩存。
2，只允許用戶的第一個下單請求到達服務器
并且服務器接收到的單量超過設定值后，其他的請求直接秒殺結束。
如果服務器出錯，直接秒殺結束頁面。
經(jīng)驗教訓
寫日志導致磁盤滿
- 控制業(yè)務日志級別warn
- 某些第三方包也會打太多錯誤日志，要關閉
- 自己的業(yè)務日志和第三方的日志要分開配置
數(shù)據(jù)庫load高
原因：首頁訪問了數(shù)據(jù)庫
- 首頁訪問頻繁，不要直接訪問數(shù)據(jù)庫
- 首頁最好應該做出靜態(tài)的
高并發(fā)下鎖超時
- 減小粒度
- 謹慎使用
緩存
緩存服務器宕機，數(shù)據(jù)庫壓力陡增引發(fā)宕機。
- 緩存服務器也很重要，大家普遍不夠重視
應用啟動不同步引發(fā)故障
原因：應用程序Web 環(huán)境使用Apache+JBoss 的模式，用戶請求通過Apache 轉
發(fā)JBoss? 在發(fā)布時，Apache 和JBoss 同時啟動，由于JBoss 啟動時需要加載很多應用并
初始化，花費時間較長，結果JBoss 還沒有完全啟動，Apache 就已經(jīng)啟動完畢開始接收
用戶請求，大量請求阻塞在JBoss 進程中，最終導致JBoss 崩潰。除了這種Apache 和JBoss
啟動不同步的情況，網(wǎng)站還有很多類似的場景，都需要后臺服務準備好，前臺應用才能
啟動，否則就會導致故障。
大文件讀寫獨占磁盤
有幾個文件非常大，有數(shù)百兆，讀寫這些大文件一
次需要幾十秒，這段時間，磁盤基本被這個文件操作獨占，導致其他用戶的文件操作緩慢。
- 大文件和小文件區(qū)分存儲，區(qū)別對待。
架構師
架構師作為項目組最資深的專業(yè)技術人員，是項目組開發(fā)測試工程師的前輩。從架
構師的身上，工程師可以看到自己的未來，因此架構師在做人做事方面需要嚴格要求自
己，做好表率。
關注人而不是產(chǎn)品
一定要堅信：一群優(yōu)秀的人做一件他們熱愛的事，一定能取得成功。不管過程多么
曲折，不管外人看來多么不可思議不靠譜。
領導的真諦：尋找一個值得共同奮斗的目標，營造一個讓大家都能最大限度
發(fā)揮自我價值的工作氛圍。
沒有懶惰的員工，只有沒被激發(fā)出來的激情。所有強迫員工加班的管理者都應該為
自己的無能而羞愧。
發(fā)覺人的優(yōu)秀
是事情成就了人，而不是人成就了事。指望優(yōu)秀的人來幫自己成事，不如做成一件
事讓自己和參與的人都變得優(yōu)秀。
共享美好藍圖
架構師要和項目組全體成員共同描繪一個藍圖，這個藍圖是整個團隊能夠認同的，
是團隊共同奮斗的目標。
藍圖應該是表述清楚的：產(chǎn)品要做什么、不做什么、要達到什么業(yè)務目標，都需要
描述清楚。
藍圖應該是形象的：產(chǎn)品能為用戶創(chuàng)造什么價值、能實現(xiàn)什么樣的市場目標、產(chǎn)品
最終會長什么樣，都需要形象地想象出來。
藍圖應該是簡單的：不管內(nèi)部還是外部溝通，都能一句話說明白：我們在做什么。
藍圖應該寫在軟件架構設計文檔的扉頁、寫在郵件的簽名檔、寫在內(nèi)部即時通信群
的公告上。
在項目過程中，架構師要保持對目標藍圖的關注，對任何偏離藍圖的設計和決定保持警惕，錯誤的偏離要及時修正，必要的變更要經(jīng)過大家討論，并且需要重新獲得大家
的認同。
共同參與架構
架構師需要對系統(tǒng)架構負責，但并不是說一定要架構師自己完成架構設計，并要項
目團隊嚴格遵守架構決策。
把架構和架構師凌駕于項目和項目組之上，只會讓架構師變成孤家寡人，讓架構曲
局和寡。
- 不要只有架構師一個人擁有架構
- 讓其他人維護框架與架構文檔
學會妥協(xié)
不要企圖在項目中證明自己是正確的，一定要記住，你是來做軟件的，不是來當老
大的。所以不要企圖去證明自己了不起，永遠也別干這種浪費時間、傷害感情的事
很多時候，對架構和技術方案的反對意見，其實意味著架構和技術方案被關注、被
試圖理解和接受。架構師不應該對意見過于敏感，這時架構師應該做的是坦率地分享自
己的設計思路，讓別人理解自己的想法并努力理解別人的想法，求同存異。
對于技術細節(jié)的爭論應該立即驗證而不是繼續(xù)討論，當討論深入到技術細節(jié)的時候
也意味著問題已經(jīng)收斂，對于整體架構設計，各方意見正趨于一致。
而當大家不再討論架構的時候，表明架構已經(jīng)融入到項目、系統(tǒng)和開發(fā)者中了，架
構師越早被項目組遺忘，越表示架構非常成功；項目組越離不開架構師，越表示架構還
有很多缺陷。
成就他人
架構師作為團隊的技術領導者，在項目過程中不要去試圖控制什么，帶著一個彈性
的計劃和藍圖推進，團隊會管好他們自己。你越是強加禁令，隊伍就越是沒有紀律；你
越是強制，團隊就越是不能獨立自主；你越是從外面尋找?guī)椭?，大家就越是沒有信心。
發(fā)現(xiàn)問題，尋找突破
其實即使是在一流的技術團隊里，也一定有數(shù)不清的問題，只是人們習慣了這些問
題，以至于無視它們的存在。正所謂“魚是最后一個看見水的”，天天面對這些問題，反
而不覺得有什么問題。
提出問題，尋求支持
問題被發(fā)現(xiàn)，它只是問題發(fā)現(xiàn)者的問題，而不是問題擁有者的問題，如果想要解決一個問題，就必須提出這個問題，讓問題的擁有者知道問題的存在。
找對關鍵人
- 把“我的問題”表述成“我們的問題”
- 給上司提封閉式問題，給下屬提開放式問題
不要問上司“你覺得該怎么辦？”這種沒有建設性的開放式問題，給上司
提問題是希望能夠得到他的支持，而不是帶著一頭霧水等他去指點迷津。公司
付你薪水不是讓你睜著迷茫的眼睛賣萌。給上司提問應該是“你覺得A 和B 兩
個方案哪個更好？”這種封閉式問題。 - 指出問題而不是批評人
如果在合作中出現(xiàn)問題，告訴他問題的存在和緊迫性，而不是責問他為什
么出現(xiàn)問題。 - 用贊同的方式提出問題
所謂直言有諱是指想要表達的意圖要直截了當說明白，不要兜圈子，但是
在表達方式上要有所避諱，照顧到當事人的感受。
解決問題，達成績效
在解決我的問題之前，先解決你的問題
先解決別人的問題有幾個好處：
你幫別人解決了問題，禮尚往來，別人也會幫你解決問題。
在幫別人解決問題的過程中，熟悉了情況，后面解決自己的問題也就得
心應手了。
解決別人的問題時使用的是你的解決方案，這個方案在你的控制之中，
將來往這個方案里再塞一些東西解決自己的問題，手到擒來。適當?shù)奶颖軉栴}
