大型網(wǎng)站架構(gòu)優(yōu)化

• 初始階段
  
• 應(yīng)用服務(wù)和數(shù)據(jù)服務(wù)分離
  
• 使用緩存改善網(wǎng)站性能
  
• 使用應(yīng)用服務(wù)器集群改善網(wǎng)站的并發(fā)處理能力
  
• 數(shù)據(jù)庫(kù)讀寫分離
  
• 使用反向代理和CDN加速網(wǎng)站響應(yīng)
  
• 使用分布式文件系統(tǒng)和分布式數(shù)據(jù)庫(kù)系統(tǒng)
  
• 使用NoSQL和搜索引擎
  
• 業(yè)務(wù)拆分
  
• 分布式服務(wù)
  

大型網(wǎng)站架構(gòu)演化的價(jià)值觀

• 技術(shù)的核心價(jià)值是隨網(wǎng)站所需靈活應(yīng)對(duì)
• 技術(shù)發(fā)展的主要力量是網(wǎng)站的業(yè)務(wù)發(fā)展

設(shè)計(jì)誤區(qū)

• 一味追隨大公司的解決方案
• 為了技術(shù)而技術(shù)
• 企圖用技術(shù)解決所有問(wèn)題

大型網(wǎng)站架構(gòu)模式

• 分層-橫向
  • 應(yīng)用層
  • 服務(wù)層
  • 數(shù)據(jù)層
• 分割-縱向
  • 將不同的功能和服務(wù)分割，包裝成高內(nèi)聚低耦合的模塊單元
• 分布式
  切分后的模塊便于分布式部署，即將不同的模塊部署在不同的服務(wù)器上，通過(guò)遠(yuǎn)程調(diào)用協(xié)同工作
  • 分布式應(yīng)用和服務(wù)
  • 分布式靜態(tài)資源
  • 分布式數(shù)據(jù)和存儲(chǔ)
  • 分布式計(jì)算
    • Hadoop
    • MapReduce
  • 分布式配置
  • 分布式鎖
  • 分布式文件
• 集群
  將多臺(tái)服務(wù)器部署相同應(yīng)用構(gòu)成一個(gè)集群，通過(guò)負(fù)載均衡設(shè)備共同對(duì)外提供服務(wù)
• 緩存
  • CDN
  • 反向代理
    前端架構(gòu)的一部分，用戶請(qǐng)求最先訪問(wèn)。這里緩存網(wǎng)站的靜態(tài)資源，無(wú)需將請(qǐng)求繼續(xù)轉(zhuǎn)發(fā)給應(yīng)用服務(wù)就能返回給用戶
  • 本地緩存
  • 分布式緩存
• 異步
  非同步調(diào)用、解耦、隊(duì)列。異步架構(gòu)是典型的生產(chǎn)者消費(fèi)者模式。
  • 提供系統(tǒng)可用性
  • 加快網(wǎng)站響應(yīng)速度
  • 消除并發(fā)訪問(wèn)高峰
• 冗余（避免宕機(jī)情況）
  • 訪問(wèn)和負(fù)載很小的服務(wù)也必須部署至少兩臺(tái)服務(wù)器構(gòu)成一個(gè)集群，通過(guò)冗余實(shí)現(xiàn)服務(wù)高可用
  • 數(shù)據(jù)庫(kù)除了定期備份，存檔保存，實(shí)現(xiàn)冷備份外，還要對(duì)數(shù)據(jù)庫(kù)進(jìn)行主從分離，實(shí)時(shí)同步實(shí)現(xiàn)熱備份
  • 全球范圍內(nèi)部署災(zāi)難數(shù)據(jù)中心，抵御地震等不可抗力導(dǎo)致的網(wǎng)站癱瘓
• 自動(dòng)化
  • 發(fā)布過(guò)程自動(dòng)化
  • 自動(dòng)化代碼管理
  • 自動(dòng)化測(cè)試
  • 自動(dòng)化安全檢測(cè)
  • 自動(dòng)化部署
  • 自動(dòng)化監(jiān)控
  • 自動(dòng)化報(bào)警
  • 自動(dòng)化失效轉(zhuǎn)移
  • 自動(dòng)化失效恢復(fù)
  • 自動(dòng)化降級(jí)
  • 自動(dòng)化分配資源
• 安全

應(yīng)用

大型網(wǎng)站架構(gòu)核心架構(gòu)要素

• 性能
  • 優(yōu)化手段（CDN、反向代理、本地緩存、分布式緩存、異步、集群、代碼層面_多線程等、數(shù)據(jù)庫(kù)優(yōu)化、NOSQL）
  • 性能指標(biāo)（響應(yīng)事件、TPS、系統(tǒng)性能計(jì)數(shù)器等）
    通過(guò)監(jiān)控這些指標(biāo)可以分析系統(tǒng)瓶頸，預(yù)測(cè)網(wǎng)站容量，并對(duì)異常指標(biāo)進(jìn)行報(bào)警，保障系統(tǒng)可用性
  • 要考慮在高并發(fā)訪問(wèn)情況下，超出負(fù)載設(shè)計(jì)能力的情況下可能會(huì)出現(xiàn)的性能問(wèn)題。網(wǎng)站需要長(zhǎng)時(shí)間持續(xù)運(yùn)行，還必須保證系統(tǒng)在持續(xù)運(yùn)行且訪問(wèn)壓力不均勻的情況下保持穩(wěn)定的性能特性
• 可用性
  • 排除故障時(shí)間，即總可用時(shí)間
    一些知名大型網(wǎng)站可以做到4個(gè)9以上的可用性，即可用性超過(guò)99.99%
  • 高可用設(shè)計(jì)目標(biāo)即當(dāng)服務(wù)器宕機(jī)的時(shí)候，服務(wù)或者應(yīng)用依然可用
  • 網(wǎng)站高可用的主要手段是冗余
    • 應(yīng)用服務(wù)器通過(guò)負(fù)載均衡設(shè)備組成集群
    • 存儲(chǔ)服務(wù)需要對(duì)數(shù)據(jù)實(shí)時(shí)備份
  • 需要質(zhì)量保證。通過(guò)預(yù)發(fā)布驗(yàn)證、自動(dòng)化測(cè)試、自動(dòng)化發(fā)布、灰度發(fā)布等手段，減少故障引入線上環(huán)境的可能
  • 衡量一個(gè)系統(tǒng)架構(gòu)設(shè)計(jì)是否滿足高可用的目標(biāo)，就是假設(shè)系統(tǒng)中任何一臺(tái)或者多臺(tái)服務(wù)器宕機(jī)時(shí)以及出現(xiàn)各種不可預(yù)期的問(wèn)題時(shí)，系統(tǒng)整體是否依然可用
• 伸縮性
  • 所謂伸縮性即指通過(guò)不斷向集群中加入服務(wù)器的手段來(lái)緩解不斷上升的用戶并發(fā)壓力和不斷增長(zhǎng)的數(shù)據(jù)存儲(chǔ)需求
  • 衡量架構(gòu)伸縮性的主要標(biāo)準(zhǔn) 就是是否可以用多臺(tái)服務(wù)器構(gòu)建集群，是否容易向集群中增加新的服務(wù)器。加入新的服務(wù)器后是否可以提供和原來(lái)的服務(wù)器無(wú)差別的服務(wù)。集群中可容納的總的服務(wù)器數(shù)量是否有限制。
  • 應(yīng)用服務(wù)器集群，只有服務(wù)器上不保存數(shù)據(jù)，所有的服務(wù)器都是對(duì)等的。通過(guò)使用合適的負(fù)載均衡設(shè)備就可以向集群中不斷加入服務(wù)器
  • 對(duì)于緩存服務(wù)器集群，加入新的服務(wù)器可能會(huì)導(dǎo)致緩存路由失效，進(jìn)而導(dǎo)致集群中的大部分緩存數(shù)據(jù)都無(wú)法訪問(wèn)。需要改進(jìn)緩存路由算法保證緩存數(shù)據(jù)的可訪問(wèn)性。
  • 關(guān)系數(shù)據(jù)庫(kù)雖然支持?jǐn)?shù)據(jù)復(fù)制，主從熱備等機(jī)制，但是很難做到大規(guī)模集群的可伸縮性，可通過(guò)如路由分區(qū)等手段將部署有多個(gè)數(shù)據(jù)庫(kù)的服務(wù)器組成一個(gè)集群。
  • 大部分NoSQL數(shù)據(jù)庫(kù)產(chǎn)品先天即為海量數(shù)據(jù)而生，其對(duì)伸縮性的支持通常都非常好
• 擴(kuò)展性
  • 衡量網(wǎng)站架構(gòu)擴(kuò)展性好壞的主要標(biāo)準(zhǔn)就是網(wǎng)站增加新的業(yè)務(wù)產(chǎn)品時(shí)，是否可以實(shí)現(xiàn)對(duì)現(xiàn)有產(chǎn)品透明無(wú)影響，不需要任何改動(dòng)或者很少改動(dòng)既有業(yè)務(wù)功能就可以上線新產(chǎn)品。不同產(chǎn)品之間是否很少耦合，一個(gè)產(chǎn)品改動(dòng)對(duì)其他產(chǎn)品無(wú)影響，其他產(chǎn)品和功能不需要受牽連進(jìn)行改動(dòng)
  • 網(wǎng)站可伸縮架構(gòu)的主要手段
    • 事件驅(qū)動(dòng)框架
      • 消息隊(duì)列實(shí)現(xiàn)
    • 分布式服務(wù)
      • 將業(yè)務(wù)和可復(fù)用服務(wù)分離開(kāi)來(lái)，通過(guò)分布式服務(wù)框架調(diào)用
• 安全性
  • 保護(hù)網(wǎng)站不受惡意訪問(wèn)和攻擊
  • 保護(hù)網(wǎng)站的重要數(shù)據(jù)不被竊取
  • 衡量網(wǎng)站安全架構(gòu)的標(biāo)準(zhǔn)就是針對(duì)現(xiàn)存和潛在的各種攻擊與竊密手段，是否有可靠的應(yīng)對(duì)策略

瞬時(shí)響應(yīng)：網(wǎng)站的高性能架構(gòu)

網(wǎng)站性能測(cè)試

• 從用戶角度的網(wǎng)站性能
  • 包括用戶計(jì)算機(jī)和網(wǎng)站服務(wù)器通信的時(shí)間、網(wǎng)站服務(wù)器處理的時(shí)間、用戶計(jì)算機(jī)瀏覽器構(gòu)造請(qǐng)求解析響應(yīng)數(shù)據(jù)的時(shí)間
  • 實(shí)踐中，可使用一些前端架構(gòu)優(yōu)化手段，如優(yōu)化頁(yè)面HTML樣式，利用瀏覽器端的并發(fā)和異步特性、調(diào)整瀏覽器緩存策略、使用CDN、反向代理等
• 開(kāi)發(fā)人員視角的網(wǎng)站性能
  • 開(kāi)發(fā)人員關(guān)注的主要是應(yīng)用程序本身及其相關(guān)子系統(tǒng)的性能，包括響應(yīng)延遲、系統(tǒng)吞吐量、并發(fā)處理能力、系統(tǒng)穩(wěn)定性等技術(shù)指標(biāo)。
  • 主要的優(yōu)化手段有使用緩存加速數(shù)據(jù)讀取、使用集群提高吞吐能力、使用異步消息加快請(qǐng)求響應(yīng)及實(shí)現(xiàn)削峰、使用代碼優(yōu)化手段改善程序性能
• 運(yùn)維人員視角的網(wǎng)站性能
  • 運(yùn)維人員更關(guān)注基礎(chǔ)設(shè)施性能和資源利用率，如網(wǎng)絡(luò)運(yùn)營(yíng)商的帶寬能力、服務(wù)器硬件的配置、數(shù)據(jù)中心網(wǎng)絡(luò)架構(gòu)、服務(wù)器和網(wǎng)絡(luò)帶寬的資源利用率等。
  • 主要優(yōu)化手段有建設(shè)優(yōu)化骨干網(wǎng)、使用高性價(jià)比定制服務(wù)器、利用虛擬技術(shù)優(yōu)化資源利用等

性能測(cè)試指標(biāo)

• 響應(yīng)時(shí)間
  • 指應(yīng)用執(zhí)行一個(gè)操作需要的時(shí)間，包括從發(fā)出請(qǐng)求開(kāi)始到收到最后響應(yīng)數(shù)據(jù)所需要的時(shí)間。
  • 響應(yīng)時(shí)間是系統(tǒng)最重要的性能指標(biāo)，直觀的反應(yīng)了系統(tǒng)的“快慢”
  • 測(cè)試程序通過(guò)模擬應(yīng)用程序，記錄收到響應(yīng)和發(fā)出請(qǐng)求之間的時(shí)間差來(lái)計(jì)算系統(tǒng)響應(yīng)時(shí)間。但是記錄及獲取系統(tǒng)時(shí)間這個(gè)操作也需要花費(fèi)一定的時(shí)間，如果測(cè)試目標(biāo)操作本身需要花費(fèi)的時(shí)間極少，比如幾微妙，那么測(cè)試程序就無(wú)法測(cè)試得到系統(tǒng)的響應(yīng)時(shí)間
  • 實(shí)踐中通常采用的辦法是重復(fù)請(qǐng)求，比如一個(gè)請(qǐng)求操作重復(fù)執(zhí)行一萬(wàn)次，測(cè)試一萬(wàn)次執(zhí)行需要的總響應(yīng)時(shí)間之和，然后除以一萬(wàn)，得到單次請(qǐng)求的響應(yīng)時(shí)間
• 并發(fā)數(shù)
  • 指系統(tǒng)能夠同時(shí)處理請(qǐng)求的數(shù)目，這個(gè)數(shù)字也反映了系統(tǒng)的負(fù)載特性。對(duì)于網(wǎng)站而言，并發(fā)數(shù)即網(wǎng)站并發(fā)用戶數(shù)，指同時(shí)提交請(qǐng)求的用戶數(shù)目
  • 網(wǎng)站用戶數(shù) > 網(wǎng)站在線用戶數(shù) > 網(wǎng)站并發(fā)用戶數(shù)
  • 測(cè)試程序通過(guò)多線程模擬并發(fā)用戶的辦法來(lái)測(cè)試系統(tǒng)的并發(fā)處理能力，為了真實(shí)模擬用戶行為，測(cè)試程序并非啟動(dòng)多線程然后不停的發(fā)送請(qǐng)求，而是在兩次請(qǐng)求之間加上一個(gè)隨機(jī)等待時(shí)間，即思考時(shí)間
• 吞吐量
  • 指單位時(shí)間內(nèi)系統(tǒng)處理的請(qǐng)求數(shù)量，體現(xiàn)系統(tǒng)的整體處理能力
  • 對(duì)于網(wǎng)站，可以用“請(qǐng)求數(shù)/秒”、”頁(yè)面數(shù)/秒“、”訪問(wèn)人數(shù)/天“、”處理的業(yè)務(wù)數(shù)/小時(shí)“等來(lái)衡量
  • TPS(每秒事務(wù)數(shù))是吞吐量的一個(gè)常用量化指標(biāo)，此外還有HPS(每秒HTTP請(qǐng)求數(shù))、QPS（每秒查詢數(shù)）等
  • 在系統(tǒng)并發(fā)數(shù)由小逐漸增加的過(guò)程中（這個(gè)過(guò)程也伴隨著服務(wù)系統(tǒng)資源消耗逐漸增加），系統(tǒng)吞吐量先是逐漸增加，達(dá)到一個(gè)極限后，隨著并發(fā)數(shù)的增加反而下降，達(dá)到系統(tǒng)崩潰點(diǎn)后，系統(tǒng)資源耗盡，吞吐量為0
  • 這個(gè)過(guò)程中，響應(yīng)時(shí)間則是先保持小幅上升，到達(dá)吞吐量極限后，快速上升，到達(dá)系統(tǒng)崩潰點(diǎn)后，系統(tǒng)失去響應(yīng)。
  • 形象理解
    • 吞吐量是每天通過(guò)收費(fèi)站的車輛數(shù)目
    • 并發(fā)數(shù)是高速公路上正在行駛的車輛數(shù)目
    • 響應(yīng)時(shí)間是車速
    • 車輛很少時(shí)，車速很快，但是通過(guò)收費(fèi)站的車輛也較少
    • 隨著高速公路上車輛數(shù)目的增多，車速略受影響，但是通過(guò)收費(fèi)站的車輛增加很快
    • 隨著車輛的繼續(xù)增加，車速變的越來(lái)越慢，高速公路越來(lái)越堵，通過(guò)收費(fèi)站的車輛不增反降
    • 如果車流量繼續(xù)增加，超過(guò)某個(gè)極限后，任何偶然因素都會(huì)導(dǎo)致高速全部癱瘓，車走不通，也不會(huì)有車通過(guò)收費(fèi)站，而高速公路成了停車場(chǎng)，資源耗盡
  • 網(wǎng)站性能優(yōu)化的目的，處理改善用戶體驗(yàn)的響應(yīng)時(shí)間，還要盡量提高系統(tǒng)吞吐量，最大限度利用服務(wù)器資源
• 性能計(jì)數(shù)器
  • 它是描述服務(wù)器或者操作系統(tǒng)性能的一些數(shù)據(jù)指標(biāo)、包括SystemLoad、對(duì)象與線程數(shù)、內(nèi)存使用、CPU使用、磁盤與網(wǎng)絡(luò)I/O等指標(biāo)。這些指標(biāo)也是系統(tǒng)監(jiān)控的重要參數(shù)，對(duì)這些指標(biāo)設(shè)置報(bào)警閥值，當(dāng)監(jiān)控系統(tǒng)發(fā)現(xiàn)性能計(jì)數(shù)器超過(guò)閥值時(shí)，就向運(yùn)維和開(kāi)發(fā)人員報(bào)警，及時(shí)發(fā)現(xiàn)處理系統(tǒng)異常
  • System Load即系統(tǒng)負(fù)載，只當(dāng)前正在被CPU執(zhí)行和等待被CPU執(zhí)行的進(jìn)程數(shù)目總和，是反映系統(tǒng)忙閑程度的重要指標(biāo)。多核CPU的情況下，完美情況是所有CPU都在使用，沒(méi)有進(jìn)程在等待處理，所以Load的理想值是CPU的數(shù)目。當(dāng)Load值低于CPU數(shù)目的時(shí)候，表示CPU有空閑，資源存在浪費(fèi)；當(dāng)Load值高于CPU數(shù)目的時(shí)候，表示進(jìn)程在排隊(duì)等待CPU調(diào)度，表示系統(tǒng)資源不足，影響程序的執(zhí)行性能。Linux下使用top命令查看，該值表示最近1分鐘、10分鐘、15分鐘的運(yùn)行隊(duì)列平均進(jìn)程數(shù)

性能測(cè)試方法

• 性能測(cè)試
  • 以系統(tǒng)設(shè)計(jì)初期規(guī)劃的性能指標(biāo)為預(yù)期目標(biāo)，對(duì)系統(tǒng)不斷施加壓力，驗(yàn)證系統(tǒng)在資源可接受范圍內(nèi)，是否達(dá)到性能預(yù)期
• 負(fù)載測(cè)試
  • 對(duì)系統(tǒng)不斷的增加并發(fā)請(qǐng)求以增加系統(tǒng)壓力，直到系統(tǒng)的某項(xiàng)或多項(xiàng)性能指標(biāo)達(dá)到安全臨界值，如某種資源已經(jīng)呈飽和狀態(tài)，這時(shí)繼續(xù)對(duì)系統(tǒng)施加壓力，系統(tǒng)的處理能力不但不能提高反而會(huì)下降
• 壓力測(cè)試
  • 超過(guò)安全負(fù)載的情況下，對(duì)系統(tǒng)持續(xù)施加壓力，直到系統(tǒng)崩潰或不能再處理任何請(qǐng)求，以此獲得系統(tǒng)最大壓力承受能力
• 穩(wěn)定性測(cè)試
  • 被測(cè)試系統(tǒng)在特定硬件、軟件、網(wǎng)絡(luò)環(huán)境條件下，給系統(tǒng)加載一定業(yè)務(wù)壓力，使系統(tǒng)運(yùn)行一段較長(zhǎng)時(shí)間，以此檢測(cè)系統(tǒng)是否穩(wěn)定。在不同生成環(huán)境、不同時(shí)間點(diǎn)的請(qǐng)求壓力是不均勻的，呈波浪特性，因?yàn)闉榱烁玫哪M生產(chǎn)環(huán)境，穩(wěn)定性測(cè)試也應(yīng)不均勻地對(duì)系統(tǒng)施加壓力
• 性能測(cè)試是一個(gè)不斷對(duì)系統(tǒng)增加訪問(wèn)壓力，以獲得系統(tǒng)性能指標(biāo)、最大負(fù)載能力、最大壓力承受能力的過(guò)程。所謂的增加訪問(wèn)壓力，在系統(tǒng)測(cè)試環(huán)境中，就是不斷增加測(cè)試程序的并發(fā)請(qǐng)求數(shù)，一般說(shuō)來(lái)，性能測(cè)試遵循拋物線規(guī)律:
  • 橫坐標(biāo)表示消耗的系統(tǒng)資源，縱坐標(biāo)表示系統(tǒng)處理能力，即吞吐量
  • 開(kāi)始階段，隨著并發(fā)請(qǐng)求數(shù)目的增加，系統(tǒng)使用較少的資源就達(dá)到較好的處理能力（a~b）段，這一段是網(wǎng)站的日常運(yùn)行區(qū)間，網(wǎng)站的絕大部分訪問(wèn)負(fù)載壓力都集中在這一段區(qū)間，被稱作性能測(cè)試
  • 隨著壓力的測(cè)試增加，系統(tǒng)處理能力變緩，直到達(dá)到一個(gè)最大值c點(diǎn)，這是系統(tǒng)的最大負(fù)載點(diǎn)，這一階段被稱作負(fù)載測(cè)試,測(cè)試目標(biāo)是評(píng)估系統(tǒng)因?yàn)橥话l(fā)事件超出日常訪問(wèn)壓力的情況下保證系統(tǒng)正常運(yùn)行情況下能夠承受的最大訪問(wèn)負(fù)載壓力
  • 超過(guò)這個(gè)點(diǎn)后，再增加壓力，系統(tǒng)的處理能力反而下降，而資源消耗卻更多，直到資源消耗達(dá)到極限d，這個(gè)點(diǎn)可以看做是系統(tǒng)的崩潰點(diǎn),超過(guò)這個(gè)點(diǎn)繼續(xù)增大并發(fā)請(qǐng)求數(shù)目，系統(tǒng)不能再處理任何請(qǐng)求,這一段被稱作壓力測(cè)試，測(cè)試目標(biāo)是評(píng)估可能導(dǎo)致系統(tǒng)崩潰的最大訪問(wèn)負(fù)載壓力
• 性能測(cè)試反映的是系統(tǒng)在實(shí)際生產(chǎn)環(huán)境中使用時(shí)，隨著用戶并發(fā)訪問(wèn)數(shù)量的增加，系統(tǒng)的處理能力。與性能曲線相對(duì)應(yīng)的是用戶訪問(wèn)的等待時(shí)間（系統(tǒng)響應(yīng)時(shí)間），如下:
  • 在日常運(yùn)行期間，可以獲得最好的用戶響應(yīng)時(shí)間，隨著并發(fā)用戶數(shù)的增加，響應(yīng)延遲越來(lái)越大，直到系統(tǒng)崩潰，用戶失去響應(yīng)

性能測(cè)試報(bào)告

• 測(cè)試結(jié)果報(bào)告應(yīng)能夠反映上述性能測(cè)試曲線的規(guī)律，閱讀者可以得到系統(tǒng)性能是否滿足設(shè)計(jì)目標(biāo)和業(yè)務(wù)要求、系統(tǒng)最大負(fù)載能力、系統(tǒng)最大壓力承受能力等重要信息，如

性能優(yōu)化策略

• 性能分析
  • 大型網(wǎng)站結(jié)構(gòu)復(fù)雜，用戶從瀏覽器發(fā)出請(qǐng)求直到數(shù)據(jù)庫(kù)完成操作事務(wù)，中間需要經(jīng)過(guò)很多環(huán)節(jié)，如果測(cè)試或者用戶報(bào)告網(wǎng)站響應(yīng)緩慢，存在性能問(wèn)題，必須對(duì)請(qǐng)求經(jīng)歷的各個(gè)環(huán)節(jié)進(jìn)行分析，排查可能出現(xiàn)性能瓶頸的地方，定位問(wèn)題
  • 排查一個(gè)網(wǎng)站的性能瓶頸和排查一個(gè)程序的性能瓶頸的手法基本相同：檢查請(qǐng)求處理的各個(gè)環(huán)節(jié)的日志，分析哪個(gè)環(huán)節(jié)響應(yīng)時(shí)間不合理、超過(guò)預(yù)期；然后檢查監(jiān)控?cái)?shù)據(jù)，分析影響性能的主要因素是內(nèi)存、磁盤、網(wǎng)絡(luò)還是CPU，是代碼問(wèn)題還是架構(gòu)設(shè)計(jì)不合理或者系統(tǒng)資源確實(shí)不足
• 性能優(yōu)化
  • 定位產(chǎn)生性能問(wèn)題的基本原因后，就需要進(jìn)行性能優(yōu)化
    • Web前端性能優(yōu)化
    • 應(yīng)用服務(wù)器性能優(yōu)化
    • 存儲(chǔ)服務(wù)器性能優(yōu)化

Web前端性能優(yōu)化

• 瀏覽器訪問(wèn)優(yōu)化
  • 減少http請(qǐng)求
    • 合并CSS、合并JavaScript、合并圖片
  • 使用瀏覽器緩存
    • 設(shè)置http頭中cache-control和expires的屬性,設(shè)定瀏覽器緩存
    • 靜態(tài)資源文件變化->生成一個(gè)新的文件
    • 使用瀏覽器緩存策略的網(wǎng)站在更新靜態(tài)資源時(shí)應(yīng)采用批量更新的方法以免用戶瀏覽器突然大量緩存失效，集中更新緩存，造成服務(wù)器負(fù)載驟增、網(wǎng)絡(luò)堵塞的情況
  • 啟用壓縮
    • gzip
    • 壓縮對(duì)服務(wù)器和瀏覽器產(chǎn)生一定的壓力，在通信帶寬良好而服務(wù)器資源不足的情況要權(quán)衡考慮
  • CSS放在頁(yè)面最上面、JavaScript放在頁(yè)面最下方
    • 瀏覽器會(huì)在下載完全部css之后才對(duì)整個(gè)頁(yè)面進(jìn)行渲染,所以最好放在頁(yè)面最上面讓瀏覽器盡快下載css
    • 瀏覽器在加載javascript后立即執(zhí)行有可能會(huì)阻塞整個(gè)頁(yè)面，造成頁(yè)面顯示緩慢，所以最好放在頁(yè)面最下面
    • 如果頁(yè)面解析時(shí)就需要用到j(luò)avascript，這時(shí)放在底部就不合適了
  • 減少cookie傳輸
    • cookie因包含在每次請(qǐng)求和響應(yīng)中，太大的cookie會(huì)驗(yàn)證影響數(shù)據(jù)傳輸
    • 對(duì)于某些靜態(tài)資源的訪問(wèn)，如css,script等，發(fā)送cookie沒(méi)有意義，可考慮靜態(tài)資源使用獨(dú)立域名訪問(wèn)，避免請(qǐng)求靜態(tài)資源時(shí)發(fā)送cookie,減少cookie傳輸?shù)拇螖?shù)
• CDN加速
  • 本質(zhì)仍然是一個(gè)緩存，而且將數(shù)據(jù)緩存在離用戶最近的地方
  • CDN部署在網(wǎng)絡(luò)運(yùn)營(yíng)商的機(jī)房，這些運(yùn)營(yíng)商又是終端用戶的網(wǎng)絡(luò)服務(wù)提供商，用戶請(qǐng)求路由的第一跳就達(dá)到了CDN服務(wù)器->有緩存->直接返回給瀏覽器->最短路徑返回響應(yīng)
  • CDN能夠緩存的一般是靜態(tài)資源
• 反向代理
  • 傳統(tǒng)代理服務(wù)器位于瀏覽器一側(cè)，代理瀏覽器將http請(qǐng)求發(fā)送到互聯(lián)網(wǎng)上
  • 反向代理服務(wù)器位于網(wǎng)站機(jī)房一側(cè)，代理網(wǎng)站web服務(wù)器接收http請(qǐng)求
  • 反向代理服務(wù)器也具有保護(hù)網(wǎng)站安全的作用
  • 除了安全功能，代理服務(wù)器也可以通過(guò)配置緩存功能加速web請(qǐng)求。當(dāng)用戶第一次訪問(wèn)靜態(tài)內(nèi)容,靜態(tài)內(nèi)容就被緩存在反向代理服務(wù)器上
  • 有些網(wǎng)站也會(huì)把動(dòng)態(tài)內(nèi)容也緩存在代理服務(wù)器上，如熱門詞條，當(dāng)這些動(dòng)態(tài)內(nèi)容有變化時(shí)通過(guò)內(nèi)部通知機(jī)制通知反向代理緩存失效，反向代理會(huì)重新加載最新的動(dòng)態(tài)內(nèi)容再次緩存起來(lái)
  • 反向代理也可以實(shí)現(xiàn)負(fù)載均衡的功能，通過(guò)負(fù)載均衡構(gòu)建的應(yīng)用集群可以提高系統(tǒng)總體處理能力

應(yīng)用服務(wù)器性能優(yōu)化

• 分布式緩存
  • 網(wǎng)站性能優(yōu)化第一定律：優(yōu)先考慮使用緩存優(yōu)化性能
  • 緩存的基本原理-hash->hashcode->索引下標(biāo)
  • 網(wǎng)站數(shù)據(jù)通常遵循28定律，即80%的訪問(wèn)落在20%的數(shù)據(jù)上，因?yàn)槔胔ash和內(nèi)存的高效訪問(wèn)屬性，將這20%的數(shù)據(jù)緩存起來(lái)，可很好的改善系統(tǒng)性能，提高數(shù)據(jù)讀取速度，減低存儲(chǔ)訪問(wèn)壓力
  • 合理使用緩存,如過(guò)分依賴低可用的緩存系統(tǒng)，不恰當(dāng)?shù)氖褂镁彺娴脑L問(wèn)特性等
  • 頻繁修改的數(shù)據(jù)，一般說(shuō)來(lái)，數(shù)據(jù)的讀寫比在2:1以上，即寫入一次緩存，在數(shù)據(jù)更新前至少讀取兩次，緩存才有意義
  • 沒(méi)有熱點(diǎn)的訪問(wèn)，如果應(yīng)用系統(tǒng)訪問(wèn)數(shù)據(jù)沒(méi)有熱點(diǎn)，緩存就沒(méi)有意義。因?yàn)榫彺媸褂脙?nèi)存作為存儲(chǔ)，內(nèi)存資源寶貴而有限，不可能將所有數(shù)據(jù)都緩存起來(lái)，只能將最新訪問(wèn)的數(shù)據(jù)緩存起來(lái)，而將歷史數(shù)據(jù)清理出緩存
  • 數(shù)據(jù)不一致與臟讀，通常會(huì)對(duì)緩存的數(shù)據(jù)設(shè)置失效時(shí)間，一旦超過(guò)失效時(shí)間，就要從數(shù)據(jù)庫(kù)中重新加載。應(yīng)用要容忍一定時(shí)間的數(shù)據(jù)不一致，如賣家已經(jīng)編輯了商品屬性，但是需要過(guò)一段時(shí)間才能被買家看到。還有一種策略是數(shù)據(jù)更新時(shí)立即更新緩存，不過(guò)這也會(huì)帶來(lái)更多系統(tǒng)開(kāi)銷和事務(wù)一致性的問(wèn)題
  • 緩存可用性，緩存數(shù)據(jù)丟失或者緩存不可用不會(huì)影響到應(yīng)用程序的處理，其可以從數(shù)據(jù)庫(kù)直接獲取數(shù)據(jù)。當(dāng)緩存服務(wù)器崩潰時(shí)，數(shù)據(jù)庫(kù)會(huì)因?yàn)橥耆荒艹惺苋绱舜蟮膲毫Χ礄C(jī)，即緩存雪崩。
    • 緩存熱備等手段提高緩存可用性，當(dāng)某臺(tái)緩存服務(wù)器宕機(jī)時(shí)將緩存訪問(wèn)切換到熱備服務(wù)器上。但這種設(shè)計(jì)顯然有違緩存的初衷，緩存根本就不應(yīng)該被當(dāng)做一個(gè)可靠的數(shù)據(jù)源來(lái)使用
    • 通過(guò)分布式緩存服務(wù)器集群，將緩存數(shù)據(jù)分不到集群多臺(tái)服務(wù)器上可在一定程度上改善緩存的可用行。當(dāng)一臺(tái)緩存服務(wù)器宕機(jī)的時(shí)候，只有部分緩存數(shù)據(jù)丟失，重新從數(shù)據(jù)庫(kù)加載這部分?jǐn)?shù)據(jù)不會(huì)對(duì)數(shù)據(jù)庫(kù)產(chǎn)生很大影響。
    • landon:從這個(gè)例子引入了兩種分布式集群的做法
      • 將總體數(shù)據(jù)分別劃分到分布式子服務(wù)器，一臺(tái)掛掉不會(huì)影響其他(緩存的設(shè)計(jì))
      • 水平擴(kuò)展，所有的分布式子服務(wù)器邏輯全部一致，一臺(tái)掛掉不會(huì)影響所有（應(yīng)用服務(wù)器的設(shè)計(jì)）
      • 當(dāng)然也有如一致性hash的算法，也可以動(dòng)態(tài)的增加或減少機(jī)器
  • 緩存預(yù)熱,緩存存放的是熱點(diǎn)數(shù)據(jù)，熱點(diǎn)數(shù)據(jù)又是緩存系統(tǒng)利用lru對(duì)不斷訪問(wèn)的數(shù)據(jù)篩選淘汰出來(lái)的，這個(gè)過(guò)程需要花費(fèi)較長(zhǎng)的時(shí)間。新啟動(dòng)的緩存系統(tǒng)如果沒(méi)有任何數(shù)據(jù)，在重新緩存數(shù)據(jù)的過(guò)程中，系統(tǒng)的系統(tǒng)和數(shù)據(jù)庫(kù)負(fù)擔(dān)都不好->在緩存系統(tǒng)啟動(dòng)的時(shí)候就把熱點(diǎn)數(shù)據(jù)加載好
  • 緩存穿透，如因?yàn)椴磺‘?dāng)?shù)臉I(yè)務(wù)或者惡意攻擊持續(xù)高并發(fā)的請(qǐng)求某個(gè)不存在的數(shù)據(jù)，由于緩存沒(méi)有保存該數(shù)據(jù)，所有的請(qǐng)求都會(huì)落到數(shù)據(jù)庫(kù)上，會(huì)到數(shù)據(jù)庫(kù)造成很大壓力->簡(jiǎn)單的對(duì)策是將不存在的數(shù)據(jù)也緩存起來(lái)，value為null
• 分布式緩存架構(gòu)
  • JBoss Cache
    • 需要更新同步的分布式緩存
    • 該分布式緩存在集群中所有服務(wù)器中保存相同的緩存數(shù)據(jù)
    • 當(dāng)某臺(tái)服務(wù)器有緩存更新的時(shí)候，會(huì)通知集群中其他機(jī)器更新緩存數(shù)據(jù)或者清除緩存數(shù)據(jù)
    • 其通常將應(yīng)用程序和緩存部署在同一臺(tái)服務(wù)器上，應(yīng)用程序可以從本地快速獲取緩存數(shù)據(jù)，不過(guò)這種方式受限于內(nèi)存。另外當(dāng)集群規(guī)模較大時(shí)，緩存更新信息需要同步到集群中所有機(jī)器，代價(jià)驚人。所以大型網(wǎng)站很少使用
  • Memcached
    • 不互相通信的分布式緩存
    • 大型網(wǎng)站需要緩存的數(shù)據(jù)量一般都很大龐大
    • Memcached采用一種集中式的緩存集群管理，也被稱作互不通信的分布式架構(gòu)方式
    • 緩存與應(yīng)用分離部署，緩存系統(tǒng)部署在一組專門的服務(wù)器上，應(yīng)用程序通過(guò)一致性hash等路由算法選擇緩存服務(wù)器遠(yuǎn)程遠(yuǎn)程訪問(wèn)緩存數(shù)據(jù)
    • 緩存服務(wù)器之間不通信，緩存集群的規(guī)模可以很容易的實(shí)現(xiàn)擴(kuò)容，具有良好的可伸縮性
    • Memcached
      • 簡(jiǎn)單的通訊協(xié)議-基于文本的自定義協(xié)議:命令關(guān)鍵字+命令操作數(shù)，如get ,可以看到這個(gè)redis很像，所以后續(xù)很多NoSQL產(chǎn)品都借鑒了或直接支持這套協(xié)議
      • 豐富的客戶端程序，幾乎支持所有主流的網(wǎng)站編程語(yǔ)言
      • 高性能的網(wǎng)絡(luò)通信，其服務(wù)端通信模塊基于libevent,一個(gè)基于事件觸發(fā)的網(wǎng)絡(luò)通信程序庫(kù)
      • 高效的內(nèi)存管理-固定空間分配(解決內(nèi)存碎片問(wèn)題)-LRU算法
      • 互不通信的服務(wù)器集群架構(gòu)：客戶端路由一致性hash算法成為數(shù)據(jù)存儲(chǔ)伸縮性架構(gòu)設(shè)計(jì)的經(jīng)典范式;也正是集群內(nèi)服務(wù)器互不通信使得集群可以做到幾乎不限制的線性伸縮
• 異步操作
  • 使用消息隊(duì)列將調(diào)用異步化
  • 注意由于數(shù)據(jù)寫入消息隊(duì)列后立即返回給有用戶，數(shù)據(jù)在后續(xù)的業(yè)務(wù)校驗(yàn)寫數(shù)據(jù)庫(kù)等操作可能是失敗，因此在使用消息隊(duì)列進(jìn)行業(yè)務(wù)異步處理后，需要適當(dāng)?shù)男薷臉I(yè)務(wù)流程進(jìn)行配合。如訂單提交后，訂單數(shù)據(jù)寫入消息隊(duì)列，不能立即返回用戶訂單提交成功，需要在消息隊(duì)列的訂單消費(fèi)者進(jìn)程真正處理該訂單甚至商品出庫(kù)后再通過(guò)郵件等通知用戶訂單成功
  • 任何可以晚點(diǎn)做的事情都應(yīng)該晚點(diǎn)再做
• 使用集群
  • 使用負(fù)載均衡技術(shù)為一個(gè)應(yīng)用構(gòu)建一個(gè)由多臺(tái)服務(wù)器組成的服務(wù)器集群，將并發(fā)請(qǐng)求分發(fā)到多臺(tái)服務(wù)器上處理
• 代碼優(yōu)化
  • 多線程
    • 從資源利用的角度看，使用多線程的原因主要有兩個(gè)：IO阻塞和多CPU
    • 假設(shè)服務(wù)器上執(zhí)行的都是相同類型任務(wù):啟動(dòng)線程數(shù)=[任務(wù)執(zhí)行時(shí)間/(任務(wù)執(zhí)行時(shí)間-IO等待時(shí)間)] * CPU內(nèi)核數(shù);如果是cpu計(jì)算型任務(wù)，那么線程數(shù)最多不超過(guò)CPU內(nèi)核數(shù)，因?yàn)閱?dòng)再多線程，cpu也來(lái)不及調(diào)度；而如果是任務(wù)需要等待磁盤操作，網(wǎng)絡(luò)響應(yīng)，那么啟動(dòng)多線程有助于提高任務(wù)并發(fā)度，提高系統(tǒng)吞吐能力，改善系統(tǒng)性能
    • 注意線程安全問(wèn)題
      • 將對(duì)象設(shè)計(jì)為無(wú)狀態(tài)對(duì)象
      • 使用局部對(duì)象
      • 并發(fā)訪問(wèn)資源使用鎖
  • 資源復(fù)用
    • 單例
    • 對(duì)象池(如連接池、線程池等)
  • 數(shù)據(jù)結(jié)構(gòu)
    • hash散列算法Time33算法:hash(i)=hash(i-1) * 33 + str[i]
    • 某些相似字符串hashcode比較接近->字符串取信息指紋->再對(duì)指紋求hashcode
    • 原始字符串->MD5->信息指紋->hash計(jì)算->hashcode
  • 垃圾回收
    • 理解垃圾回收機(jī)制
    • 根據(jù)系統(tǒng)業(yè)務(wù)特點(diǎn)和對(duì)象生命周期，合理設(shè)置jvm參數(shù)等->盡量減少full gc

存儲(chǔ)性能優(yōu)化

• 機(jī)械硬盤 vs. 固定硬盤
• B+樹(shù)(關(guān)系數(shù)據(jù)庫(kù)) vs. LSM樹(shù)(許多NoSQL產(chǎn)品)
  • LSM-Tree (Log-Structured Merge-Tree)
• RAID(實(shí)現(xiàn)數(shù)據(jù)在多塊磁盤上的并發(fā)讀寫和數(shù)據(jù)備份) vs. HDFS(Hadoop分布式文件系統(tǒng)，可配合MapReduce)
  • 磁盤陣列（Redundant Arrays of Independent Disks，RAID）
  • Raid0、Raid1、Raid10、Raid3、Raid5、Raid6、
  • Raid技術(shù)可以通過(guò)已經(jīng)實(shí)現(xiàn)，也可通過(guò)軟件實(shí)現(xiàn)，該技術(shù)在傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)及文件系統(tǒng)中影響比較廣泛，但大型網(wǎng)站比較喜歡使用NOSQL及分布式文件系統(tǒng)
  • HDFS中，系統(tǒng)在整個(gè)存儲(chǔ)集群中的多臺(tái)服務(wù)器上進(jìn)行數(shù)據(jù)并發(fā)讀寫和備份，可以看做在服務(wù)器集群規(guī)模上實(shí)現(xiàn)了類似Raid的功能

小結(jié)

• 網(wǎng)站性能對(duì)最終用戶而言是一種主觀感受，性能優(yōu)化的最終目的就是改善用戶的體驗(yàn)，使他們感覺(jué)網(wǎng)站很快。離開(kāi)這個(gè)目的，追求技術(shù)上的所謂高性能，是舍本逐末，沒(méi)有多大意義
• 用戶體驗(yàn)的快或是慢，可以通過(guò)技術(shù)手段改善，也可以通過(guò)優(yōu)化交互體驗(yàn)改善
• 技術(shù)是為業(yè)務(wù)服務(wù)，技術(shù)選型和架構(gòu)決策依賴業(yè)務(wù)規(guī)則，離開(kāi)業(yè)務(wù)發(fā)展的支撐和驅(qū)動(dòng)，技術(shù)走不遠(yuǎn)，甚至?xí)呙月?/span>
• 前沿技術(shù)總是出現(xiàn)在前沿業(yè)務(wù)領(lǐng)域

萬(wàn)無(wú)一失：網(wǎng)站的高可用架構(gòu)

網(wǎng)站可用性的度量與考核

• 網(wǎng)站可用性度量
  • 業(yè)界通常用多少個(gè)9來(lái)衡量網(wǎng)站的可用性
    • QQ的可用性是4個(gè)9，即QQ服務(wù)99.99%可用，這意味著QQ服務(wù)要保證其在所有運(yùn)行時(shí)間中，只有0.01%的時(shí)間不可用，即一年中大約最多53分鐘不可用
  • 網(wǎng)站不可用時(shí)間（故障時(shí)間）= 故障修復(fù)時(shí)間點(diǎn)-故障發(fā)現(xiàn)（報(bào)告）時(shí)間點(diǎn)
  • 網(wǎng)站年度可用性指標(biāo)=（1-網(wǎng)站不可用時(shí)間/年度總時(shí)間） * 100%
  • 對(duì)于大多數(shù)網(wǎng)站而言，2個(gè)9是基本可用；3個(gè)9是較高可用；4個(gè)9是具有自動(dòng)恢復(fù)能力的高可用；5個(gè)9是極高可用性（年度不可用時(shí)間小于5分鐘）
• 網(wǎng)站可用性考核
  • 可用性指標(biāo)是網(wǎng)站架構(gòu)設(shè)計(jì)的重要指標(biāo)，對(duì)外是服務(wù)承諾，對(duì)內(nèi)是考核指標(biāo)。具體每個(gè)工程師的考核，更多的是使用故障分

高可用的網(wǎng)站架構(gòu)

• 網(wǎng)站的高可用架構(gòu)設(shè)計(jì)的主要目的就是保證服務(wù)器硬件故障時(shí)服務(wù)依然可用、數(shù)據(jù)依然保存并能夠被訪問(wèn)
• 實(shí)現(xiàn)高可用架構(gòu)的主要手段是數(shù)據(jù)和服務(wù)的冗余備份及失效轉(zhuǎn)移
• 一個(gè)典型的網(wǎng)站通常遵循如下的基本分層架構(gòu)模型
  
  • 典型的分層模型是三層，即應(yīng)用層、服務(wù)層、數(shù)據(jù)層
  • 應(yīng)用層主要負(fù)責(zé)具體業(yè)務(wù)邏輯處理；服務(wù)層主要負(fù)責(zé)提供可復(fù)用的服務(wù)；數(shù)據(jù)層負(fù)責(zé)數(shù)據(jù)的存儲(chǔ)與訪問(wèn)等
  • 中小型網(wǎng)站在具體部署時(shí)通常將應(yīng)用層和服務(wù)層部署在一起，而數(shù)據(jù)層則另外部署，而這也是網(wǎng)站架構(gòu)演化的第一步
• 復(fù)雜的大型網(wǎng)站架構(gòu)中，劃分的粒度會(huì)更小、更詳細(xì)、結(jié)構(gòu)更加復(fù)雜，服務(wù)器規(guī)模更加龐大,但通常還是能夠把這些服務(wù)器劃分到這三層中:
  • 應(yīng)用層的服務(wù)器通常為了應(yīng)對(duì)高并發(fā)的訪問(wèn)請(qǐng)求，會(huì)通過(guò)負(fù)載均衡設(shè)備將一組服務(wù)器組成一個(gè)集群共同對(duì)外提供服務(wù)。負(fù)載均衡設(shè)備通過(guò)心跳檢測(cè)等手段監(jiān)控某臺(tái)應(yīng)用服務(wù)器不可用時(shí)就將其從集群列表中剔除并將請(qǐng)求轉(zhuǎn)發(fā)到集群中其他可用的服務(wù)器上，使整個(gè)集群保持可用，從而實(shí)現(xiàn)高可用
  • 位于服務(wù)層的服務(wù)器情況和應(yīng)用層的服務(wù)器類似，也是通過(guò)集群方式實(shí)現(xiàn)高可用，只是這些服務(wù)器被應(yīng)用層通過(guò)分布式服務(wù)框架調(diào)用，分布式服務(wù)調(diào)用框架會(huì)在應(yīng)用層客戶端程序中實(shí)現(xiàn)軟件負(fù)載均衡，并通過(guò)服務(wù)注冊(cè)中心對(duì)外提供服務(wù)的服務(wù)器進(jìn)行心跳檢測(cè)，發(fā)現(xiàn)有服務(wù)不可用，立即通知客戶端程序修改服務(wù)訪問(wèn)列表，剔除不可用的服務(wù)器
  • 數(shù)據(jù)服務(wù)器上存儲(chǔ)這數(shù)據(jù)，為了保證服務(wù)器宕機(jī)時(shí)數(shù)據(jù)不丟失，數(shù)據(jù)訪問(wèn)服務(wù)不中斷，需要在數(shù)據(jù)寫入時(shí)進(jìn)行數(shù)據(jù)同步復(fù)制，將數(shù)據(jù)寫入多臺(tái)服務(wù)器上，實(shí)現(xiàn)數(shù)據(jù)冗余備份。當(dāng)數(shù)據(jù)服務(wù)器宕機(jī)時(shí)，應(yīng)用程序?qū)⒃L問(wèn)切換到有備份數(shù)據(jù)的服務(wù)器上
  • 網(wǎng)站升級(jí)的頻率較高，如大型網(wǎng)站一周發(fā)布一次。每次網(wǎng)站發(fā)布都需要關(guān)閉服務(wù)，重新部署系統(tǒng)，整個(gè)過(guò)程相當(dāng)于服務(wù)器宕機(jī)。因此網(wǎng)站的可用性架構(gòu)設(shè)計(jì)不但要考慮實(shí)際的硬件故障引起的宕機(jī)，還要考慮網(wǎng)站升級(jí)發(fā)布引起的宕機(jī)而后者更加頻率，不能因?yàn)橄到y(tǒng)可以接受偶爾的停機(jī)故障將降低可用性設(shè)計(jì)的標(biāo)準(zhǔn)

高可用的應(yīng)用

• 應(yīng)用層主要處理網(wǎng)站應(yīng)用的業(yè)務(wù)邏輯，因?yàn)橛袝r(shí)也被稱為業(yè)務(wù)邏輯層->應(yīng)用的一個(gè)顯著特點(diǎn)是應(yīng)用的無(wú)狀態(tài)性
• 所謂無(wú)狀態(tài)的應(yīng)用是指應(yīng)用服務(wù)器不保存業(yè)務(wù)的上下文信息，而僅根據(jù)每次請(qǐng)求提交的數(shù)據(jù)進(jìn)行相應(yīng)的業(yè)務(wù)邏輯處理，多個(gè)服務(wù)實(shí)例（服務(wù)器）之間完全對(duì)等，請(qǐng)求提交到任意服務(wù)器，處理結(jié)果都是完全一樣的
• 通過(guò)負(fù)載均衡進(jìn)行無(wú)狀態(tài)服務(wù)的失效轉(zhuǎn)移
  • 負(fù)載均衡，顧名思義，主要使用在業(yè)務(wù)量和數(shù)據(jù)量較高的情況下，當(dāng)單臺(tái)服務(wù)器不足以承擔(dān)所有的負(fù)載壓力時(shí)，通過(guò)負(fù)載均衡手段，將流量和數(shù)據(jù)分?jǐn)偟揭粋€(gè)集群組成的多臺(tái)服務(wù)器上，以提高整體的負(fù)載處理能力
  • 目前不管是開(kāi)源免費(fèi)的負(fù)載均衡軟件還是昂貴的負(fù)載均衡硬件，都提供失效功能
  • 在網(wǎng)站應(yīng)用中，當(dāng)集群中的服務(wù)是無(wú)狀態(tài)對(duì)等時(shí)，負(fù)載均衡可以起到事實(shí)上高可用的作用
  • 當(dāng)Web服務(wù)器集群中的服務(wù)器都可用時(shí)，負(fù)載均衡服務(wù)器會(huì)把用戶發(fā)送的訪問(wèn)請(qǐng)求分發(fā)到任意一臺(tái)服務(wù)器上進(jìn)行處理，而當(dāng)10.0.0.1宕機(jī)時(shí)，負(fù)載均衡服務(wù)器通過(guò)心跳檢測(cè)機(jī)制發(fā)現(xiàn)服務(wù)器失去響應(yīng)，就會(huì)把它從服務(wù)器列表中刪除，從而請(qǐng)求發(fā)送到其他服務(wù)器上，這些服務(wù)器是完全一樣的，請(qǐng)求在任何一臺(tái)服務(wù)器中處理都不會(huì)影響最終的結(jié)果
  • 由于負(fù)載均衡在應(yīng)用層實(shí)際起到了系統(tǒng)高可用的作用，因?yàn)榧词鼓硞€(gè)應(yīng)用訪問(wèn)量非常少，只用 一臺(tái)服務(wù)器提供服務(wù)就綽綽有余，但如果需要保證該服務(wù)可用，也必須至少部署兩臺(tái)服務(wù)器，使用負(fù)載均衡技術(shù)構(gòu)建一個(gè)小型的集群
• 應(yīng)用服務(wù)器集群的Session管理
  • 事實(shí)上，業(yè)務(wù)總是有狀態(tài)的，如交易類的電子商務(wù)網(wǎng)站，需要有購(gòu)物車記錄用戶的購(gòu)買信息等
  • Web應(yīng)用中將這些多次請(qǐng)求修改使用的上下文對(duì)象稱作為Session.單機(jī)情況下，Session可由部署在服務(wù)器上的web容器如jboss管理。在使用負(fù)載均衡的集群環(huán)境中，由于負(fù)載均衡服務(wù)器可能會(huì)將請(qǐng)求分發(fā)到集群中任何一臺(tái)應(yīng)用服務(wù)器上，所以保證每次請(qǐng)求依然能夠獲得正確的Session比單機(jī)要負(fù)載的多
  • 集群環(huán)境下，Session管理主要有以下幾種手段：
    • Session復(fù)制
      • 應(yīng)用服務(wù)器開(kāi)啟web容器的session復(fù)制功能，在集群中的幾臺(tái)服務(wù)器之間同步session對(duì)象
      • 只能用在集群規(guī)模比較小的情況。當(dāng)集群規(guī)模較大，集群服務(wù)器之間通過(guò)大量的通信進(jìn)行session復(fù)制，占用服務(wù)器和大量網(wǎng)絡(luò)資源，系統(tǒng)不堪負(fù)擔(dān)
      • 所有用戶的session信息在每臺(tái)服務(wù)器上都有備份，大量用戶訪問(wèn)的情況，甚至?xí)霈F(xiàn)服務(wù)器內(nèi)存不夠session使用的情況
      • 大型網(wǎng)站的核心應(yīng)用集群就是數(shù)千臺(tái)服務(wù)器，同時(shí)在線用戶可達(dá)千萬(wàn)，該方案不適用
    • Session綁定
      • 利用負(fù)載均衡的源地址Hash算法實(shí)現(xiàn)，負(fù)載均衡服務(wù)器總是將來(lái)源統(tǒng)一Ip的請(qǐng)求分發(fā)到同一臺(tái)服務(wù)器上（也可以根據(jù)cookie信息將同一個(gè)用戶的請(qǐng)求總是分發(fā)到同一臺(tái)服務(wù)器上）
      • 整個(gè)會(huì)話期間，用戶所有的請(qǐng)求都在同一臺(tái)服務(wù)器上處理，即Session綁定在某臺(tái)特定服務(wù)器上，保證Session總能在這臺(tái)服務(wù)器上獲取
      • 但是這種方案不符合高可用需求，因?yàn)橐坏┠撑_(tái)服務(wù)器宕機(jī)那么該機(jī)器上的session也就不復(fù)存在了，用戶請(qǐng)求切換到其他機(jī)器后因?yàn)闆](méi)有session而無(wú)法完成業(yè)務(wù)處理.雖然大部分負(fù)載均衡服務(wù)器都提供源地址負(fù)載均衡算法，但很少有網(wǎng)站利用這個(gè)算法進(jìn)行Session管理
    • 利用Cookie記錄Session
      • 將session記錄在客戶端，利用瀏覽器支持的cookie記錄session
      • 受Cookie大小有限，能記錄的信息有限；每次請(qǐng)求響應(yīng)都需要傳輸cookie，影響性能；如果用戶關(guān)閉cookie，訪問(wèn)就會(huì)不正常
      • 但由于cookie的簡(jiǎn)單易用，可用性高，支持應(yīng)用服務(wù)器的線上伸縮，而大部分應(yīng)用記錄的session信息又比較小。因?yàn)槭聦?shí)上許多網(wǎng)站或多或少地使用cookie記錄session
    • session服務(wù)器
      • 利用獨(dú)立部署的Session服務(wù)器集群統(tǒng)一管理session
      • 應(yīng)用服務(wù)器每次讀寫session，都訪問(wèn)session服務(wù)器
      • 這種解決方案事實(shí)上是將應(yīng)用服務(wù)器的狀態(tài)分離，分為無(wú)狀態(tài)的應(yīng)用服務(wù)器和有狀態(tài)的session服務(wù)器，然后針對(duì)這兩種服務(wù)器的不同特性分別設(shè)計(jì)其架構(gòu)
      • 對(duì)于有狀態(tài)的session服務(wù)器，一種比較簡(jiǎn)單的方法是利用分布式緩存，數(shù)據(jù)庫(kù)等，在這些產(chǎn)品的基礎(chǔ)上進(jìn)行包裝，使其符合session的存儲(chǔ)和訪問(wèn)要求

高可用的服務(wù)

• 可復(fù)用的服務(wù)模塊為業(yè)務(wù)產(chǎn)品提供基礎(chǔ)公共服務(wù)，大型網(wǎng)站中這些服務(wù)通常都獨(dú)立分布式部署，被具體應(yīng)用遠(yuǎn)程調(diào)用。可復(fù)用的服務(wù)和應(yīng)用一樣，也是無(wú)狀態(tài)的服務(wù)，因此也可以使用類似負(fù)載均衡的失效轉(zhuǎn)移策略實(shí)現(xiàn)高可用的服務(wù)
• 具體實(shí)踐中的高可用服務(wù)策略
  • 分級(jí)管理：運(yùn)維上將服務(wù)器進(jìn)行分級(jí)管理，核心應(yīng)用和服務(wù)優(yōu)先使用更好的硬件；同時(shí)在服務(wù)部署上也進(jìn)行必要的隔離，避免故障的連鎖反應(yīng)，如低優(yōu)先級(jí)的服務(wù)通過(guò)啟動(dòng)不同的線程或者部署在不同的虛擬機(jī)上進(jìn)行隔離，而高優(yōu)先級(jí)的服務(wù)則需要部署在不同的物理機(jī)上，核心服務(wù)和數(shù)據(jù)甚至需要部署在不同地域的數(shù)據(jù)中心
  • 超時(shí)設(shè)置：在應(yīng)用程序中設(shè)置服務(wù)調(diào)用超時(shí)時(shí)間，一旦超時(shí)，通信框架就拋出異常，應(yīng)用程序根據(jù)服務(wù)調(diào)度策略，可選擇繼續(xù)重試或者將請(qǐng)求轉(zhuǎn)移到提供相同服務(wù)的其他機(jī)器上，避免如服務(wù)端宕機(jī)、線程死鎖引起的可能導(dǎo)致應(yīng)用程序?qū)Ψ?wù)端的調(diào)用失去響應(yīng)情況,進(jìn)而導(dǎo)致用戶請(qǐng)求長(zhǎng)時(shí)間得不到響應(yīng)同時(shí)還占用應(yīng)用程序的資源
  • 異步調(diào)用：應(yīng)用對(duì)服務(wù)的調(diào)用通過(guò)消息隊(duì)列等異步方式完成;當(dāng)然并非所有服務(wù)調(diào)用都可以異步調(diào)用，對(duì)于獲取用戶信息這類調(diào)用才用異步會(huì)延遲響應(yīng)時(shí)間，得不償失。對(duì)于那些必須確認(rèn)服務(wù)調(diào)用成功才能進(jìn)行下一步操作的應(yīng)用也不適合使用異步調(diào)用
  • 服務(wù)降級(jí)：網(wǎng)站訪問(wèn)高峰，服務(wù)可能因?yàn)榇罅康牟l(fā)調(diào)用而性能下降，嚴(yán)重時(shí)會(huì)導(dǎo)致服務(wù)宕機(jī)。為了保證核心應(yīng)用和功能的正常運(yùn)行，需要對(duì)服務(wù)進(jìn)行降級(jí):
    • 拒絕服務(wù)：拒絕低優(yōu)先級(jí)應(yīng)用的調(diào)用，減少服務(wù)調(diào)用并發(fā)數(shù)，確保核心應(yīng)用正常使用;或者隨機(jī)拒絕部分請(qǐng)求調(diào)用，節(jié)省資源，讓另一部分請(qǐng)求得以成功，避免要死大家一起死
    • 關(guān)閉功能：關(guān)閉部分不重要的服務(wù)或者服務(wù)內(nèi)部關(guān)閉部分不重要的功能，以節(jié)約系統(tǒng)開(kāi)銷為重要的服務(wù)和功能讓出資源
  • 冪等性設(shè)計(jì)
    • 服務(wù)重復(fù)調(diào)用是無(wú)法避免的，如應(yīng)用調(diào)用失敗會(huì)將調(diào)用請(qǐng)求重新發(fā)送給其他服務(wù)器，但是這個(gè)失敗可能是個(gè)虛假的失敗，如服務(wù)已經(jīng)處理成功，但是因?yàn)榫W(wǎng)絡(luò)故障應(yīng)用沒(méi)有收到響應(yīng)，這時(shí)應(yīng)用重新提交請(qǐng)求就會(huì)導(dǎo)致服務(wù)重復(fù)調(diào)用。如果該服務(wù)是一轉(zhuǎn)賬操作，就會(huì)產(chǎn)生嚴(yán)重后果。而應(yīng)用層不需要關(guān)心是否真的失敗，只要沒(méi)有收到成功的調(diào)用響應(yīng)，就可以認(rèn)為調(diào)用失敗，并重試服務(wù)調(diào)用。因?yàn)楸仨氃诜?wù)層保證服務(wù)重復(fù)調(diào)用和調(diào)用一次產(chǎn)生結(jié)相同，即服務(wù)具有冪等性。
    • 有些服務(wù)天生就是冪等性，如將用戶性別設(shè)置為男性，不管設(shè)置多少次，結(jié)果都一樣。但對(duì)于轉(zhuǎn)賬交易等操作，則需要通過(guò)交易編號(hào)等信息進(jìn)行服務(wù)調(diào)用有效性校驗(yàn)，只有有效的操作才能繼續(xù)進(jìn)行

高可用的數(shù)據(jù)

• 保證數(shù)據(jù)存儲(chǔ)高可用的手段主要是數(shù)據(jù)備份和失效轉(zhuǎn)移機(jī)制
• 緩存的高可用，實(shí)踐中爭(zhēng)議很大。一種觀點(diǎn)因?yàn)榫彺嬉殉蔀閿?shù)據(jù)服務(wù)的重要組成部分，緩存服務(wù)失效則可能會(huì)導(dǎo)致數(shù)據(jù)庫(kù)負(fù)擔(dān)過(guò)高而宕機(jī)，進(jìn)而影響整個(gè)網(wǎng)站的可用性，因?yàn)榫彺娣?wù)需要實(shí)現(xiàn)和數(shù)據(jù)存儲(chǔ)服務(wù)同樣的高可用
• 另一種觀點(diǎn)認(rèn)為緩存服務(wù)不是數(shù)據(jù)存儲(chǔ)服務(wù)，緩存服務(wù)器宕機(jī)因?yàn)榫彺鏀?shù)據(jù)丟失的導(dǎo)致服務(wù)器負(fù)載壓力過(guò)高應(yīng)該通過(guò)其他手段解決，而不是提高緩存服務(wù)本身的高可用
• 擴(kuò)大緩存服務(wù)器集群規(guī)模的一個(gè)簡(jiǎn)單手段就是整個(gè)網(wǎng)站共享同一個(gè)分布式緩存集群并通過(guò)邏輯或物理分區(qū)的方式將每個(gè)應(yīng)用的緩存部署在多臺(tái)服務(wù)器上，任何一臺(tái)宕機(jī)因?yàn)榈木彺媸Ф贾挥绊憫?yīng)用緩存數(shù)據(jù)的一小部分，不會(huì)對(duì)應(yīng)用性能和數(shù)據(jù)庫(kù)負(fù)載造成太大影響

CAP原理

• 為了保證數(shù)據(jù)的高可用，通常會(huì)犧牲了另一個(gè)很重要的指標(biāo)：數(shù)據(jù)一致性
• 高可用數(shù)據(jù)含義：
  • 數(shù)據(jù)持久性：各種情況下都不會(huì)出現(xiàn)數(shù)據(jù)丟失的問(wèn)題->數(shù)據(jù)備份一個(gè)或多個(gè)副本，存放在不同的物理存儲(chǔ)設(shè)備上
  • 數(shù)據(jù)可訪問(wèn)性：當(dāng)一個(gè)數(shù)據(jù)存儲(chǔ)設(shè)備損壞則需要訪問(wèn)切換到另一個(gè)存儲(chǔ)設(shè)備上,如果這個(gè)過(guò)程不能很快完成或者完成過(guò)程中需要停止用戶訪問(wèn)數(shù)據(jù)，那么這段時(shí)間是不可訪問(wèn)的
  • 數(shù)據(jù)一致性：數(shù)據(jù)多份副本情況下，如果網(wǎng)絡(luò)、服務(wù)器或者軟件出現(xiàn)故障，會(huì)導(dǎo)致部分副本寫入成功，部分寫入失敗，則會(huì)造成各個(gè)副本之間數(shù)據(jù)不一致、實(shí)踐中，導(dǎo)致數(shù)據(jù)不一致的情形有很多種，表現(xiàn)形式也多種多樣
• CAP原理認(rèn)為：一個(gè)提供數(shù)據(jù)服務(wù)的存儲(chǔ)系統(tǒng)無(wú)法同時(shí)滿足數(shù)據(jù)一致性、數(shù)據(jù)可用性、分區(qū)耐受性（系統(tǒng)具有跨網(wǎng)絡(luò)分區(qū)的伸縮性）
• 大型網(wǎng)站應(yīng)用中，數(shù)據(jù)規(guī)模總是快速擴(kuò)張，因?yàn)榭缮炜s性即分區(qū)耐受性必不可少，規(guī)模變大，機(jī)器數(shù)量也會(huì)變得龐大，這時(shí)網(wǎng)絡(luò)和服務(wù)器故障會(huì)頻繁出現(xiàn)，要想保證可用就必須保證分布式處理系統(tǒng)的高可用性。所以大型網(wǎng)站中，通常會(huì)選擇強(qiáng)化分布式存儲(chǔ)系統(tǒng)的可用性A和伸縮性P，而在某種程度上放棄一致性C.
• 一般說(shuō)來(lái)，數(shù)據(jù)不一致通常出現(xiàn)在系統(tǒng)高并發(fā)寫操作或者集群狀態(tài)不穩(wěn)如故障恢復(fù)、集群擴(kuò)容
• 數(shù)據(jù)一致性
  • 數(shù)據(jù)強(qiáng)一致
  • 數(shù)據(jù)用戶一致:數(shù)據(jù)在物理存儲(chǔ)中的各個(gè)副本的數(shù)據(jù)可能是不一致，但終端用戶訪問(wèn)通過(guò)糾錯(cuò)和校驗(yàn)機(jī)制，可以確定一個(gè)一致且正確的數(shù)據(jù)返回給用戶
  • 數(shù)據(jù)最終一致

數(shù)據(jù)備份

• 數(shù)據(jù)冷備：定期將數(shù)據(jù)復(fù)制到某種存儲(chǔ)介質(zhì);缺點(diǎn)不能保證數(shù)據(jù)最終一致，因定期復(fù)制，備份中的數(shù)據(jù)比系統(tǒng)的數(shù)據(jù)舊如果系統(tǒng)數(shù)據(jù)丟失則從上個(gè)備份點(diǎn)開(kāi)始后更新的數(shù)據(jù)就會(huì)永久丟失;同時(shí)也不能保證數(shù)據(jù)可永興，從冷備存儲(chǔ)中恢復(fù)數(shù)據(jù)需要較長(zhǎng)的時(shí)間而這段時(shí)間無(wú)法訪問(wèn)數(shù)據(jù)，系統(tǒng)也不可用
• 數(shù)據(jù)熱備
  • 異步熱備
    • 存儲(chǔ)服務(wù)器分為Master和Slave，應(yīng)用程序正常只連接主存儲(chǔ)服務(wù)器，數(shù)據(jù)寫入時(shí)由master的寫操作代理模塊將數(shù)據(jù)寫入本機(jī)存儲(chǔ)系統(tǒng)后立即返回寫操作成功響應(yīng)，然后通過(guò)異步線程將寫操作數(shù)據(jù)同步到slave
  • 同步熱備
    • 指多分?jǐn)?shù)據(jù)副本的寫入操作同步完成，即應(yīng)用程序收到數(shù)據(jù)服務(wù)器系統(tǒng)的寫成功響應(yīng)時(shí)，多分?jǐn)?shù)據(jù)都已經(jīng)寫操縱成功.
    • 具體實(shí)現(xiàn)的時(shí)候，為了提供性能，在用用程序客戶端并發(fā)現(xiàn)向多個(gè)存儲(chǔ)服務(wù)器同時(shí)寫入數(shù)據(jù)然后等待所有存儲(chǔ)服務(wù)器都返回操作成功的響應(yīng)后再通知應(yīng)用程序?qū)懖僮鞒晒?/span>
    • 這種情況下，存儲(chǔ)服務(wù)器沒(méi)有主從之分，完全對(duì)等，便于管理和維護(hù)
• 傳統(tǒng)的企業(yè)級(jí)關(guān)系數(shù)據(jù)庫(kù)系統(tǒng)幾乎都提供了數(shù)據(jù)實(shí)時(shí)同步備份的機(jī)制，而一開(kāi)始就為大型網(wǎng)站設(shè)計(jì)的各種NoSQL數(shù)據(jù)庫(kù)如HBase更是將數(shù)據(jù)備份機(jī)制作為產(chǎn)品最主要的功能點(diǎn)
• 關(guān)系數(shù)據(jù)庫(kù)熱備機(jī)制即通常所說(shuō)的master-slave同步機(jī)制，該機(jī)制不但解決了數(shù)據(jù)備份問(wèn)題還該神了數(shù)據(jù)庫(kù)系統(tǒng)性能。實(shí)踐匯總，通常使用讀寫分離，寫操作只訪問(wèn)master，讀操作只訪問(wèn)slave

失效轉(zhuǎn)移

• 若數(shù)據(jù)服務(wù)器集群中任何一臺(tái)服務(wù)器宕機(jī)，那么應(yīng)用程序針對(duì)這臺(tái)服務(wù)器的所有讀寫操作都需要重新路由到其他服務(wù)器，保證數(shù)據(jù)訪問(wèn)不會(huì)丟失，這個(gè)過(guò)程叫做失效轉(zhuǎn)移
• 失效確認(rèn)：判斷服務(wù)器宕機(jī)時(shí)系統(tǒng)進(jìn)行失效轉(zhuǎn)移的第一步
  • 心跳檢測(cè)
  • 應(yīng)用程序訪問(wèn)失敗報(bào)告(控制中心還需要再一次進(jìn)行發(fā)送心跳檢測(cè)以免錯(cuò)誤判斷服務(wù)器宕機(jī))
• 訪問(wèn)轉(zhuǎn)移：確認(rèn)某臺(tái)數(shù)據(jù)存儲(chǔ)服務(wù)器宕機(jī)后，就需要將數(shù)據(jù)讀寫訪問(wèn)路由到其他服務(wù)器上(服務(wù)器是否是存儲(chǔ)對(duì)等，如主從結(jié)構(gòu)的存儲(chǔ)服務(wù)器其存儲(chǔ)的數(shù)據(jù)完全一樣可直接切換，而不對(duì)等存儲(chǔ)則需要重新路由)
• 數(shù)據(jù)恢復(fù)：因?yàn)殄礄C(jī)所以數(shù)據(jù)存儲(chǔ)副本會(huì)減少，必須將副本數(shù)目恢復(fù)到系統(tǒng)設(shè)置的值;否則再有服務(wù)器宕機(jī)時(shí)就可能出現(xiàn)無(wú)法訪問(wèn)轉(zhuǎn)移

高可用網(wǎng)站的軟件質(zhì)量保證

• 網(wǎng)站為了保證線上系統(tǒng)的可用性而采取了一些與傳統(tǒng)軟件開(kāi)發(fā)不用的質(zhì)量保證手段
• 網(wǎng)站發(fā)布：發(fā)布過(guò)程事實(shí)上和服務(wù)器宕機(jī)效果相當(dāng)，相當(dāng)于一次提前預(yù)知的服務(wù)器宕機(jī),通常使用發(fā)布腳本完成發(fā)布。發(fā)布過(guò)程每次關(guān)閉的都是集群中的一小部分并在發(fā)布完成后立即可以訪問(wèn)，因此整個(gè)發(fā)布過(guò)程不影響用戶使用
• 自動(dòng)化測(cè)試：目前大部分網(wǎng)站都采用web自動(dòng)化測(cè)試技術(shù)，使用自動(dòng)化測(cè)試工具或者腳本完成測(cè)試，比較流行的web自動(dòng)化測(cè)試工具是ThoughtWorks開(kāi)發(fā)的Selenium.大部分網(wǎng)站也會(huì)開(kāi)發(fā)自己的自動(dòng)化測(cè)試工具可以一鍵完成系統(tǒng)部署、測(cè)試數(shù)據(jù)生成、測(cè)試執(zhí)行、測(cè)試報(bào)告生成等全部測(cè)試過(guò)程
• 預(yù)發(fā)布驗(yàn)證：即使是經(jīng)過(guò)嚴(yán)格的測(cè)試，軟件部署到線上服務(wù)器之后還是經(jīng)常會(huì)出現(xiàn)各種問(wèn)題，甚至根本無(wú)法啟動(dòng)服務(wù)器，主要原因是測(cè)試環(huán)境和線上環(huán)境并不相同,特別是依賴的其他服務(wù)如數(shù)據(jù)庫(kù)、緩存、第三方服務(wù)如銀行網(wǎng)銀接口等或其他一些為如依賴的服務(wù)線上環(huán)境還沒(méi)有準(zhǔn)備好，都有可能導(dǎo)致應(yīng)用故障。因此網(wǎng)站發(fā)布時(shí)是將測(cè)試通過(guò)的代碼包發(fā)布到預(yù)發(fā)布機(jī)器上，在該機(jī)器上進(jìn)行預(yù)發(fā)布驗(yàn)證執(zhí)行典型流程等確認(rèn)系統(tǒng)沒(méi)有問(wèn)題才正式發(fā)布。預(yù)發(fā)布服務(wù)器是一種特殊用途的服務(wù)器，它和線上正式服務(wù)器唯一不同的就是沒(méi)有配置在負(fù)載均衡服務(wù)器上，外部用戶無(wú)法訪問(wèn).網(wǎng)站工程師通過(guò)在自己的開(kāi)發(fā)用計(jì)算機(jī)上配置hosts文件綁定域名IP關(guān)系直接用IP訪問(wèn)預(yù)發(fā)布服務(wù)器.問(wèn)題是預(yù)發(fā)布服務(wù)器連接的是真實(shí)的生產(chǎn)環(huán)境，驗(yàn)證操作都是真實(shí)有效的數(shù)據(jù)，可能會(huì)引起不可預(yù)期的問(wèn)題。如測(cè)試第三方支付，商品售價(jià)數(shù)千美金，為了測(cè)試工程師將金額改為1美元，但是第二天發(fā)現(xiàn)大量商品以1美元價(jià)格成交.另外網(wǎng)站應(yīng)用中強(qiáng)調(diào)的一個(gè)處理錯(cuò)誤的理念是快速失敗，即如果系統(tǒng)在啟動(dòng)中發(fā)現(xiàn)問(wèn)題立刻拋出異常，停止啟動(dòng)讓工程師介入排查錯(cuò)誤而不是啟動(dòng)后執(zhí)行錯(cuò)誤的操作
• 代碼控制
  • 網(wǎng)站代碼控制的核心問(wèn)題是如何進(jìn)行代碼管理，即能保證代碼發(fā)布版本的穩(wěn)定正確同時(shí)又能保證不同團(tuán)隊(duì)的開(kāi)發(fā)互不影響，因?yàn)楹诵膽?yīng)用系統(tǒng)和公用業(yè)務(wù)模塊涉及許多團(tuán)隊(duì)，需要對(duì)相同的代碼庫(kù)進(jìn)行共同開(kāi)發(fā)和維護(hù)。而這些團(tuán)隊(duì)對(duì)同一個(gè)應(yīng)用的開(kāi)發(fā)維護(hù)（開(kāi)發(fā)周期和發(fā)布時(shí)間點(diǎn)各不相同）,如果控制環(huán)節(jié)出問(wèn)題，則會(huì)將有問(wèn)題的代碼發(fā)布上線，從而導(dǎo)致系統(tǒng)故障
  • SVN代碼控制和發(fā)布方式
    • 主干開(kāi)發(fā)、分支發(fā)布：代碼修改都在主干(trunk)上進(jìn)行，需要發(fā)布的時(shí)候，從主干上拉一個(gè)分支(branch)發(fā)布，該分支即成為一個(gè)發(fā)布版本，如果該版本發(fā)現(xiàn)bug，繼續(xù)在該分支上修改發(fā)布并將修改合并(merge)回主干.
    • 分支開(kāi)發(fā)、主干發(fā)布：任何修改都不得在主干上直接進(jìn)行，需要開(kāi)發(fā)一個(gè)新功能或修復(fù)一個(gè)bug時(shí)，從主干上一個(gè)分支開(kāi)發(fā)，開(kāi)發(fā)完成并且測(cè)試通過(guò)則合并會(huì)主干，然后從主干上進(jìn)行發(fā)布，主干上的代碼永遠(yuǎn)是最新發(fā)布的版本
    • 前者反映目前整個(gè)應(yīng)用的狀態(tài)，便于管理和控制，也利于持續(xù)集成；后者各個(gè)分支獨(dú)立開(kāi)發(fā)，互不干擾，可以使不同發(fā)布周期的開(kāi)發(fā)在同一應(yīng)用中進(jìn)行
    • 目前網(wǎng)站應(yīng)用開(kāi)發(fā)中主要用后者
    • 因?yàn)閷?duì)于前者，對(duì)于同一個(gè)應(yīng)用，對(duì)于不同開(kāi)發(fā)周期，不同發(fā)布時(shí)間的喜喪母，有可能A項(xiàng)目發(fā)布的時(shí)候，B項(xiàng)目只開(kāi)發(fā)了一半，這時(shí)候的主干代碼是半成品，根本不能發(fā)布。而后者的話，只需要將A項(xiàng)目的分支合并會(huì)主干即可發(fā)布，不受B項(xiàng)目發(fā)布時(shí)間的影響
    • 目前開(kāi)源技術(shù)設(shè)計(jì)，Git正逐步取代svn地位，而Git對(duì)于分布式開(kāi)發(fā)，分支開(kāi)發(fā)能有更好的支持.
• 自動(dòng)化發(fā)布
  • 很多網(wǎng)站選擇周四作為發(fā)布日，這樣一周前面有三天時(shí)間可以準(zhǔn)備發(fā)布，后面還有一天時(shí)間可以挽回錯(cuò)誤。如果選擇周五發(fā)布，發(fā)現(xiàn)問(wèn)題就必須要周末加班
  • 網(wǎng)站火車站發(fā)布模型
    
  • 由于火車站發(fā)布模型是基于規(guī)則驅(qū)動(dòng)的流程，所以該流程可以自動(dòng)化.人的干預(yù)越少，自動(dòng)化程度越高，引入故障的可能性就越小
• 灰度發(fā)布
  • 大型網(wǎng)站的主要業(yè)務(wù)服務(wù)器集群規(guī)模非常龐大，一旦發(fā)現(xiàn)故障，即使想要發(fā)布回滾有需要很長(zhǎng)時(shí)間才能完成
  • 大型網(wǎng)站會(huì)使用灰度發(fā)布模式，將集群服務(wù)器分成若干部分，每天只發(fā)布一部分服務(wù)器，觀察運(yùn)行穩(wěn)定沒(méi)有故障，第二天繼續(xù)發(fā)布一部分服務(wù)器，持續(xù)幾天才把整個(gè)集群全部發(fā)布完畢，期間如果發(fā)現(xiàn)問(wèn)題則只需要回滾已發(fā)布的一部分服務(wù)器即可
  • 灰度發(fā)布也長(zhǎng)用于用戶測(cè)試，即在部分服務(wù)器上發(fā)布新版本，其余服務(wù)器保持老版本或者發(fā)布另一個(gè)版本，然后監(jiān)控用戶操作行為、收集用戶提要報(bào)告、比較用戶對(duì)兩個(gè)版本的滿意度，以確定最終的發(fā)布版本。這種手段也被稱作AB測(cè)試

網(wǎng)站運(yùn)行監(jiān)控

• 不允許沒(méi)有監(jiān)控的系統(tǒng)上線
• 監(jiān)控?cái)?shù)據(jù)采集
  • 用戶行為日志收集
    • 服務(wù)器端日志收集：如Apache等幾乎所有web服務(wù)器都具備日志記錄功能，可以記錄大部分用戶行為日志，開(kāi)啟web服務(wù)器的日志記錄功能即可
    • 客戶端瀏覽器日志收集：如利用頁(yè)面嵌入專門的javascript腳本收集用戶的真實(shí)操作，但是比較麻煩
    • 因大型網(wǎng)站的用戶日志數(shù)據(jù)量驚人，數(shù)據(jù)存儲(chǔ)與計(jì)算壓力很大，目前許多網(wǎng)站逐步開(kāi)發(fā)基于實(shí)時(shí)計(jì)算框架storm的日志統(tǒng)計(jì)與分析工具
  • 服務(wù)器性能監(jiān)控
    • 收集服務(wù)器性能指標(biāo)如系統(tǒng)Load、內(nèi)存占用、磁盤IO、網(wǎng)絡(luò)IO等對(duì)其盡早做出故障預(yù)警
    • 網(wǎng)站使用比較廣泛的開(kāi)源性能監(jiān)控工具是Ganglia,其支持大規(guī)模集群并支持以圖形的方式在瀏覽器展示實(shí)時(shí)性能曲線
  • 運(yùn)行數(shù)據(jù)報(bào)告
    • 監(jiān)控一些與具體業(yè)務(wù)場(chǎng)景相關(guān)的技術(shù)和業(yè)務(wù)指標(biāo)，如緩存命中率、平均響應(yīng)延遲時(shí)間、待處理的任務(wù)總數(shù)等
    • 應(yīng)用程序需要在代碼中處理運(yùn)行數(shù)據(jù)采集的邏輯
• 監(jiān)控管理
  • 系統(tǒng)報(bào)警：監(jiān)控指標(biāo)如果某個(gè)閥值意味系統(tǒng)可能要出現(xiàn)故障->需要對(duì)相關(guān)人員報(bào)警
  • 失效轉(zhuǎn)移：監(jiān)控系統(tǒng)在發(fā)現(xiàn)故障的情況下主動(dòng)通知應(yīng)用，進(jìn)行失效轉(zhuǎn)移；當(dāng)然應(yīng)用程序訪問(wèn)失敗時(shí)也會(huì)進(jìn)行失敗轉(zhuǎn)移
  • 自動(dòng)優(yōu)雅降級(jí)：為了應(yīng)付突然爆發(fā)的訪問(wèn)高峰，主動(dòng)關(guān)閉部分功能，釋放部分系統(tǒng)資源；監(jiān)控系統(tǒng)實(shí)時(shí)監(jiān)控所有服務(wù)器的運(yùn)行狀況，根據(jù)監(jiān)控參數(shù)判斷應(yīng)用訪問(wèn)負(fù)載情況

永無(wú)止境：網(wǎng)站的伸縮性架構(gòu)

• 網(wǎng)站的伸縮性指不需要改變網(wǎng)站的軟硬件設(shè)計(jì)，僅僅通過(guò)改變部署的服務(wù)器數(shù)量就可以擴(kuò)大或者縮小網(wǎng)站的服務(wù)處理能力
• 大型系統(tǒng)的漸進(jìn)式的演化過(guò)程中，最重要的技術(shù)手段就是使用服務(wù)器集群，通過(guò)不斷的向集群中添加服務(wù)器來(lái)增加整個(gè)集群的處理能力
• 只要技術(shù)上能做到向集群中加入服務(wù)器的數(shù)量和集群的處理能力成線性關(guān)系，那么網(wǎng)站就可以以此手段不斷提升自己的規(guī)模
• 對(duì)于如電商網(wǎng)站的促銷活動(dòng)，某個(gè)短時(shí)間內(nèi)訪問(wèn)量和交易規(guī)模突然爆發(fā)式增長(zhǎng)，然后又回歸正常狀態(tài)。此時(shí)需要網(wǎng)站的技術(shù)架構(gòu)具有極好的伸縮性-活動(dòng)期間向服務(wù)器集群中加入更多服務(wù)器及向網(wǎng)絡(luò)服務(wù)商租借更多的網(wǎng)絡(luò)帶寬以滿足用戶訪問(wèn)；活動(dòng)結(jié)束后又將這些服務(wù)器下線以節(jié)約成本

網(wǎng)站架構(gòu)的伸縮性設(shè)計(jì)

不同功能進(jìn)行物理分離實(shí)現(xiàn)伸縮

• 不同的服務(wù)器部署不同的服務(wù)，提供不同的功能
• 網(wǎng)站發(fā)展早期-新增服務(wù)器總是從現(xiàn)有服務(wù)器中分離出部分功能和服務(wù)
  • 縱向分離（分層后分離）：將業(yè)務(wù)處理流程上的不同部分分離部署，實(shí)現(xiàn)系統(tǒng)伸縮性
  • 橫向分離（業(yè)務(wù)分割后分離）：將不同的業(yè)務(wù)模塊分離部署，實(shí)現(xiàn)系統(tǒng)伸縮性

單一功能通過(guò)集群實(shí)現(xiàn)伸縮

• 將不同功能分離部署可以實(shí)現(xiàn)一定程度的伸縮性，但隨著網(wǎng)站訪問(wèn)量的逐步增加，即使分離到最小力度的獨(dú)立部署，單一的服務(wù)器也不能滿足業(yè)務(wù)規(guī)模的要求
• 必須使用服務(wù)器集群，即將相同服務(wù)部署在多臺(tái)服務(wù)器上構(gòu)成一個(gè)集群整體對(duì)外提供服務(wù)
• 當(dāng)一頭牛拉不動(dòng)的時(shí)候，不要去尋找一頭更強(qiáng)壯的牛，而是用兩頭牛來(lái)拉車
• 集群伸縮性可分為應(yīng)用服務(wù)器集群伸縮性和數(shù)據(jù)服務(wù)器集群伸縮性；而數(shù)據(jù)服務(wù)器集群也可以分為緩存數(shù)據(jù)服務(wù)器集群和存儲(chǔ)數(shù)據(jù)服務(wù)器集群

應(yīng)用服務(wù)器集群的伸縮性設(shè)計(jì)

• 應(yīng)用服務(wù)器設(shè)計(jì)成無(wú)狀態(tài)，即應(yīng)用服務(wù)器不存儲(chǔ)請(qǐng)求上下文信息
• 利用負(fù)載均衡服務(wù)器實(shí)現(xiàn)請(qǐng)求分發(fā)：感知或者可以配置集群的服務(wù)器數(shù)量；可以及時(shí)發(fā)現(xiàn)集群中新上線或者下線的服務(wù)器；能向新上線的服務(wù)器分發(fā)請(qǐng)求，停止向已下線的服務(wù)器分發(fā)請(qǐng)求,即實(shí)現(xiàn)了應(yīng)用服務(wù)器集群的伸縮性
• 實(shí)現(xiàn)負(fù)載均衡的基礎(chǔ)技術(shù)
  • HTTP重定向負(fù)載均衡
    • 利用http重定向協(xié)議實(shí)現(xiàn)負(fù)載均衡
    • http重定向服務(wù)器是一臺(tái)普通的應(yīng)用服務(wù)器，其唯一的功能是根據(jù)用戶的http請(qǐng)求計(jì)算一臺(tái)真實(shí)的web服務(wù)器地址并將該web服務(wù)器地址寫入http重定向響應(yīng)中（302）返回給有用戶瀏覽器
    • 瀏覽器自動(dòng)重定向請(qǐng)求實(shí)際的物理服務(wù)器ip，完成訪問(wèn)
    • 優(yōu)點(diǎn)是比較簡(jiǎn)單；缺點(diǎn)是瀏覽器需要兩次請(qǐng)求才能完成一次訪問(wèn)，性能較差；重定向服務(wù)器自身的處理能力有可能成為瓶頸；http302響應(yīng)碼重定向有可能使搜索引擎判斷為seo(Search Engine Optimization)作弊，降低搜索排名。所以實(shí)踐中并不多見(jiàn)
  • DNS域名解析負(fù)載均衡
    • DNS服務(wù)器中配置多個(gè)A記錄，每次域名解析請(qǐng)求都會(huì)根據(jù)負(fù)載均衡算法計(jì)算一個(gè)不同的ip地址返回，這樣A記錄中配置多個(gè)服務(wù)器就構(gòu)成了一個(gè)集群并可實(shí)現(xiàn)負(fù)載均衡
    • 其優(yōu)點(diǎn)是將負(fù)載均衡的工作轉(zhuǎn)交給dns,省去了網(wǎng)站管理維護(hù)負(fù)載服務(wù)器的麻煩;許多dns還支持基于地理位置的域名解析，可解析成距離用戶地理最近的一個(gè)服務(wù)器地址，加快用戶訪問(wèn)速度
    • 其缺點(diǎn)是dns是多級(jí)解析，每一級(jí)dns都可能緩存A記錄；當(dāng)下線某臺(tái)服務(wù)器后，即使修改了dns的A記錄，要使其生效也需要較長(zhǎng)時(shí)間，這段時(shí)間dns仍然會(huì)將域名解析到已經(jīng)下線的服務(wù)器，導(dǎo)致用戶訪問(wèn)失敗；而且dns負(fù)載均衡的控制權(quán)在域名服務(wù)商那里，網(wǎng)站無(wú)法對(duì)其做更多改善和更強(qiáng)大的管理
    • 事實(shí)上，大型網(wǎng)站總是部分使用dns域名解析,利用域名解析作為第一級(jí)負(fù)載均衡手段，即域名解析得到的一組服務(wù)器并不是實(shí)際提供web服務(wù)的物理服務(wù)器而是同樣提供負(fù)載均衡服務(wù)的內(nèi)部服務(wù)器，這組內(nèi)部負(fù)載均衡服務(wù)器再進(jìn)行負(fù)載均衡，將請(qǐng)求分發(fā)到真實(shí)的web服務(wù)器上
      
  • 反向代理負(fù)載均衡
  • IP負(fù)載均衡
  • 數(shù)據(jù)鏈路層負(fù)載均衡
  • 負(fù)載均衡算法
  • 負(fù)載均衡算法
    • Round Robin-輪詢
    • Weighted Round Robin-加權(quán)輪詢
    • Random-隨機(jī)
    • Least Connections-最少連接
    • Source Hashing-源地址散列

分布式緩存集群的伸縮性設(shè)計(jì)

• 分布式緩存服務(wù)器集群中不同服務(wù)器中緩存的數(shù)據(jù)各不相同，緩存訪問(wèn)請(qǐng)求不可以在緩存服務(wù)器集群中的任意一臺(tái)處理，必須先找到緩存有需要數(shù)據(jù)的服務(wù)器，然后才能訪問(wèn)（注：和部署相同應(yīng)用的應(yīng)用服務(wù)器集群不同，有狀態(tài)-數(shù)據(jù)，數(shù)據(jù)量很大，如果緩存機(jī)器數(shù)據(jù)一樣，一則失去了緩存集群的意義_就因?yàn)閿?shù)據(jù)量很大才使用集群，二則集群間同步數(shù)據(jù)及其復(fù)雜）
• 必須讓新上線的緩存服務(wù)器對(duì)整個(gè)分布式緩存集群影響最小，即新加入緩存的服務(wù)器后應(yīng)使整個(gè)緩存服務(wù)器集群中已經(jīng)緩存的數(shù)據(jù)盡可能還被訪問(wèn)到
• Memcached分部署緩存集群的訪問(wèn)模型
  • 分布式緩存的一致性Hash算法
    • 構(gòu)造一個(gè)長(zhǎng)度為0~2^32的整數(shù)環(huán)，即一致性hash環(huán)
    • 根據(jù)節(jié)點(diǎn)名稱的hash值將緩存服務(wù)器節(jié)點(diǎn)放在這個(gè)hash環(huán)上
    • 根據(jù)需要緩存數(shù)據(jù)的key值計(jì)算得到其hash值
    • 在hash環(huán)上順時(shí)針查找距離這個(gè)key的hash值最近的緩存服務(wù)器節(jié)點(diǎn)
  • 解決一致性hash算法帶來(lái)的負(fù)載不均衡問(wèn)題
    • 使用虛擬層，將每臺(tái)物理緩存服務(wù)器虛擬為一組虛擬緩存服務(wù)器，將虛擬緩存服務(wù)器的hash值放置在hash環(huán)上
    • key在環(huán)上先找到虛擬服務(wù)器節(jié)點(diǎn)，再得到物理服務(wù)器的信息

數(shù)據(jù)存儲(chǔ)服務(wù)器集群的伸縮性設(shè)計(jì)

• 數(shù)據(jù)存儲(chǔ)服務(wù)器必須保證數(shù)據(jù)的可靠存儲(chǔ)，任何情況下都必須保證數(shù)據(jù)的可用性和正確性
• 關(guān)系數(shù)據(jù)庫(kù)集群的伸縮性設(shè)計(jì)
  • 數(shù)據(jù)復(fù)制：主從-讀寫分離
  • 業(yè)務(wù)分割：不同業(yè)務(wù)數(shù)據(jù)表部署在不同的數(shù)據(jù)庫(kù)集群上-分庫(kù)
  • 分片：將一張表拆開(kāi)分別存儲(chǔ)在多個(gè)數(shù)據(jù)庫(kù)重
    • Amoeba
    • Cobar
      • Cobar服務(wù)器集群
        • 無(wú)狀態(tài)
      • MySQL服務(wù)器集群的伸縮
        • 數(shù)據(jù)同步遷移-Schema為單位
• NoSql數(shù)據(jù)庫(kù)的伸縮性設(shè)計(jì)
  • 放棄了SQL和事務(wù)一致性保證（ACID）
  • 強(qiáng)化高可用性和可所伸縮性
  • HBase
    • 其伸縮性主要依賴其可分裂的HRegion和可伸縮性的HDFS（分布式文件系統(tǒng)）
    • HBase啟動(dòng)多個(gè)HMaster，通過(guò)Zookeeper選出一個(gè)主服務(wù)器
    • 應(yīng)用程序通過(guò)zookeeper獲得主HMaster的地址
    • 輸入key獲得這個(gè)key所在HRegionServer地址
    • 請(qǐng)求HRegionServer上的HRegion，獲得需要的數(shù)據(jù)

隨需應(yīng)變：網(wǎng)站的可擴(kuò)展架構(gòu)

• 對(duì)現(xiàn)有系統(tǒng)影響最小的情況下，系統(tǒng)功能可持續(xù)擴(kuò)展及提升
• 擴(kuò)展性
  • 指對(duì)現(xiàn)有系統(tǒng)影響最小的情況下，系統(tǒng)功能可持續(xù)擴(kuò)展或提升的能力。表現(xiàn)在系統(tǒng)基礎(chǔ)設(shè)施穩(wěn)定不需要經(jīng)常變更、應(yīng)用之間較少依賴和耦合，對(duì)需求變更可以敏捷響應(yīng)。它是系統(tǒng)架構(gòu)設(shè)計(jì)層面的開(kāi)閉原則，即對(duì)擴(kuò)展開(kāi)放，對(duì)修改關(guān)閉、架構(gòu)設(shè)計(jì)考慮未來(lái)功能擴(kuò)展，當(dāng)系統(tǒng)增加新功能時(shí)，不需要對(duì)現(xiàn)有系統(tǒng)的結(jié)構(gòu)和代碼進(jìn)行修改
• 伸縮性
  • 指系統(tǒng)能夠通過(guò)增加減少自身資源規(guī)模的方式增強(qiáng)減少自己計(jì)算事務(wù)的能力。如果這種增減是成比例的，則為線性伸縮性。在網(wǎng)站架構(gòu)中，通常指利用集群的方式增加服務(wù)器數(shù)量，提供系統(tǒng)的整體事務(wù)吞吐能力
• 利用分布式消息隊(duì)列降低系統(tǒng)耦合性
  • 事件驅(qū)動(dòng)架構(gòu)
  • 分布式消息隊(duì)列
    • 消息生成者應(yīng)用程序通過(guò)遠(yuǎn)程訪問(wèn)接口將消息推送給消息隊(duì)列服務(wù)器
    • 消息隊(duì)列服務(wù)器將消息寫入本地內(nèi)存隊(duì)列后立即返回給成功響應(yīng)給消息生產(chǎn)者
    • 消息隊(duì)列服務(wù)器根據(jù)消息訂閱者列表查找訂閱該消息的消息消費(fèi)者應(yīng)用程序，將消息隊(duì)列中的消息按照先進(jìn)先出的原則將消息通過(guò)遠(yuǎn)程通信接口發(fā)行給消息消費(fèi)者程序
    • 伸縮性：無(wú)狀態(tài),將新服務(wù)器加入分布式消息隊(duì)列集群中，通知生產(chǎn)者服務(wù)器更改消息隊(duì)列服務(wù)器列表即可
    • 可用性：如果內(nèi)存隊(duì)列已滿則會(huì)將消息寫入磁盤；消息推送模塊在將內(nèi)存隊(duì)列消息處理完成以后，將磁盤內(nèi)容加載到內(nèi)存隊(duì)列繼續(xù)處理；為了避免消息隊(duì)列服務(wù)器宕機(jī)造成消息丟失，會(huì)將消息成功發(fā)送到消息隊(duì)列的消息存儲(chǔ)在消息生產(chǎn)者服務(wù)器，等消息真正被消息消費(fèi)者服務(wù)器處理后才刪除消息；在消息隊(duì)列服務(wù)器宕機(jī)后，生產(chǎn)者服務(wù)器會(huì)選擇分布式消息隊(duì)列服務(wù)器集群中其他的服務(wù)器發(fā)布消息
• 利用分布式服務(wù)打造可復(fù)用的業(yè)務(wù)平臺(tái)
  • 將模塊獨(dú)立部署，降低系統(tǒng)耦合性
  • 縱向拆分：將一個(gè)大應(yīng)用拆分為多個(gè)小應(yīng)用
  • 橫向拆分：將復(fù)用的業(yè)務(wù)拆分處理，獨(dú)立部署為分布式服務(wù)
  • Web Service
  • 大型網(wǎng)站分布式服務(wù)的需求與特點(diǎn)：
    • 負(fù)載均衡
    • 失效轉(zhuǎn)移
    • 高效的遠(yuǎn)程通信
    • 整合異構(gòu)系統(tǒng)
    • 對(duì)應(yīng)用最少浸入
    • 版本管理
    • 實(shí)時(shí)監(jiān)控
  • 分布式服務(wù)框架設(shè)計(jì)
    • Facebook#Thrift
    • 阿里巴巴#Dubbo
  • 可擴(kuò)展的數(shù)據(jù)結(jié)構(gòu)
    • NoSQL#ColumnFamily-->Google#Bigtable
  • 利用開(kāi)放平臺(tái)建設(shè)網(wǎng)站生態(tài)圈
    • API接口、協(xié)議轉(zhuǎn)換、安全、審計(jì)、路由、流程

固若金湯：網(wǎng)站的安全架構(gòu)

網(wǎng)站應(yīng)用攻擊與防御

• XSS(Cross Site Script)攻擊:指黑客通過(guò)篡改網(wǎng)頁(yè)，注入惡意html腳本，用戶瀏覽網(wǎng)頁(yè)時(shí)，控制用戶瀏覽器進(jìn)行惡意操作的一種攻擊方式
  • 消毒
  • HttpOnly-進(jìn)制頁(yè)面JavaScript訪問(wèn)帶有httponly屬性的cookie
• 注入攻擊
  • SQL注入攻擊
    • 消毒
    • 預(yù)編譯-綁定參數(shù)
  • OS注入攻擊
• CSRF(Cross Site Request Forgery)，跨站點(diǎn)請(qǐng)求偽造-以用戶的身份偽造請(qǐng)求
  • 表單token-隨機(jī)數(shù)
  • 驗(yàn)證碼
  • Referer check：http請(qǐng)求頭中的referer域中記錄著請(qǐng)求來(lái)源，可通過(guò)驗(yàn)證請(qǐng)求來(lái)源，驗(yàn)證其是否合法-圖片防盜鏈
• 其他攻擊和漏洞
  • Error Code：許多Web服務(wù)器默認(rèn)是打開(kāi)異常信息輸出的，即服務(wù)器端未處理的異常堆棧信息會(huì)直接輸出到客戶端瀏覽器，給黑客造成可乘之機(jī).通過(guò)配置web服務(wù)器參數(shù)跳轉(zhuǎn)500(表示服務(wù)器內(nèi)部錯(cuò)誤)頁(yè)面到專門的錯(cuò)誤頁(yè)面即可
  • HTML注釋：許多開(kāi)發(fā)人員會(huì)在一些服務(wù)器頁(yè)面程序中使用html注釋語(yǔ)法進(jìn)行程序注釋，這些注釋會(huì)顯示在客戶端瀏覽器，給黑客造成攻擊便利。程序發(fā)布前需要進(jìn)行代碼review或自動(dòng)掃描，避免該漏洞
  • 文件上傳：如果上傳一個(gè)可執(zhí)行程序，則可通過(guò)該程序獲得服務(wù)端命令執(zhí)行能力。防御手段是設(shè)置上傳文件白名單，只允許上傳可靠的文件類型等
  • 路徑遍歷：攻擊者在請(qǐng)求的url中使用先對(duì)路徑，遍歷系統(tǒng)未開(kāi)放的目錄和文件。防御方法則是將js等資源文件部署在獨(dú)立服務(wù)器、使用獨(dú)立域名，其他文件不使用靜態(tài)url訪問(wèn)，動(dòng)態(tài)參數(shù)不包含文件路徑信息
• web應(yīng)用防火墻
  • ModSecurity
• 網(wǎng)站安全漏洞掃描：根據(jù)內(nèi)置規(guī)則，構(gòu)造具有攻擊性的url請(qǐng)求，模擬黑客攻擊行為，用來(lái)發(fā)現(xiàn)網(wǎng)站安全漏洞的工具

信息加密技術(shù)

• 單向散列加密-不可逆
  • 因人們?cè)O(shè)置密碼具有一定的模式，可通過(guò)彩虹表（常用密碼和對(duì)應(yīng)的密文關(guān)系）等手段猜測(cè)破解
  • MD5,SHA
• 對(duì)稱加密
  • 加密和解密使用的密鑰是同一個(gè)密鑰或者互相可推算
  • DES、RC
• 非對(duì)稱加密
  • 用公鑰加密的信息必須用私鑰才能解開(kāi)；用私鑰加密的信息只有公鑰才能解開(kāi)
  • 公鑰對(duì)外界公開(kāi)，私鑰只有所有者知道
  • 用在信息安全傳輸、數(shù)字簽名等場(chǎng)合
  • RSA
• 密鑰安全管理
  • 將密鑰和算法放在一個(gè)獨(dú)立的服務(wù)器上
  • 將加密算法放在應(yīng)用系統(tǒng)，密鑰則放在獨(dú)立服務(wù)器中，實(shí)際存儲(chǔ)密鑰中，密鑰被切分成數(shù)片

信息過(guò)濾與反垃圾

電子商務(wù)風(fēng)險(xiǎn)控制

案例

淘寶

• LAMP->Java+Oracle->WebX+IBatis->JBoss替換Weblogic->Jetty替代JBoss
• WebX、AntX、Jetty
• Tair、TFS、OceanBase、TDDL
• 集群環(huán)境下分布式高可用系統(tǒng)的架構(gòu)設(shè)計(jì)

維基百科

• GeoDNS：可將域名解析到離用戶最近的服務(wù)器
• LVS：基于Linux的開(kāi)源負(fù)載均衡服務(wù)器
• Squid:基于Linux的開(kāi)源反向代理服務(wù)器
• Lightttpd:開(kāi)源的應(yīng)用服務(wù)器
• PHP
• Memcached
• Lucene：Apache出品、Java開(kāi)發(fā)的開(kāi)源全文搜索引擎
• MySql
• 前端性能優(yōu)化：
  • 核心是反向代理服務(wù)器Squid集群，請(qǐng)求通過(guò)lvs負(fù)載均衡分發(fā)到squid服務(wù)器，熱點(diǎn)詞條被緩存，大量請(qǐng)求可直接返回
  • Squid緩存不能命中的請(qǐng)求再通過(guò)lvs轉(zhuǎn)發(fā)到apache應(yīng)用集群
  • CDN
• 服務(wù)端性能優(yōu)化
  • 硬件改善
  • PHP改善
• 后端性能優(yōu)化
  • 使用緩存
  • 熱點(diǎn)特別集中的數(shù)據(jù)直接緩存到應(yīng)用服務(wù)器的本地內(nèi)存中
  • 緩存數(shù)據(jù)的內(nèi)容盡量是應(yīng)用服務(wù)器可以直接使用的格式
  • 使用緩存服務(wù)器存儲(chǔ)session對(duì)象
  • memcached
  • MySql
    • 使用較大的服務(wù)器內(nèi)存
    • RAID0
    • 數(shù)據(jù)庫(kù)事務(wù)一致性設(shè)置在較低水平
    • Master宕機(jī)則立即切換到slave，同時(shí)關(guān)閉數(shù)據(jù)庫(kù)寫服務(wù)

海量分布式存儲(chǔ)系統(tǒng)Doris的高可用架構(gòu)設(shè)計(jì)分析

• 應(yīng)用程序服務(wù)器：對(duì)系統(tǒng)發(fā)起數(shù)據(jù)操作請(qǐng)求
• 數(shù)據(jù)存儲(chǔ)服務(wù)器：負(fù)責(zé)存儲(chǔ)數(shù)據(jù)、響應(yīng)應(yīng)用服務(wù)器的數(shù)據(jù)操作請(qǐng)求
• 管理中心服務(wù)器：負(fù)責(zé)集群管理，對(duì)數(shù)據(jù)存儲(chǔ)集群進(jìn)行監(jiān)控心跳檢測(cè)；集群擴(kuò)容、故障恢復(fù)管理；對(duì)應(yīng)用程序服務(wù)器集群地址配置信息服務(wù)等
• 數(shù)據(jù)存儲(chǔ)服務(wù)器根據(jù)應(yīng)用的可用性級(jí)別設(shè)置數(shù)據(jù)復(fù)制份數(shù)，即每個(gè)數(shù)據(jù)實(shí)際存儲(chǔ)的副本數(shù)目
• 正常訪問(wèn)模型：寫數(shù)據(jù)時(shí)，需要路由計(jì)算獲得兩臺(tái)不同的服務(wù)器，同時(shí)將數(shù)據(jù)寫入兩臺(tái)服務(wù)器；而讀數(shù)據(jù)時(shí)則只需要到這兩臺(tái)服務(wù)器上任意一臺(tái)服務(wù)讀取即可
• 瞬時(shí)故障的高可用解決方案：
  • 多次重試
  • 可能是應(yīng)用服務(wù)器自己的故障，則需要請(qǐng)求管理中心服務(wù)器進(jìn)行故障仲裁，存儲(chǔ)服務(wù)器進(jìn)行監(jiān)控心跳檢測(cè)
• 臨時(shí)故障的高可用解決方案:
  • 數(shù)據(jù)有多分副本，讀數(shù)據(jù)只需要路由選擇正常服務(wù)機(jī)器即可
  • 寫數(shù)據(jù)，正常服務(wù)的機(jī)器依然正常寫入，發(fā)生故障的機(jī)器需要將數(shù)據(jù)寫入到臨時(shí)存儲(chǔ)服務(wù)器
  • 等待故障服務(wù)器恢復(fù)后再將臨時(shí)服務(wù)器中的數(shù)據(jù)遷移到該機(jī)器
• 永久故障的高可用解決方案
  • 臨時(shí)故障超時(shí)或者人工確認(rèn)為永久故障，系統(tǒng)啟動(dòng)備用服務(wù)器替代原來(lái)永久失效的服務(wù)器，進(jìn)入永久故障恢復(fù)

網(wǎng)購(gòu)秒殺系統(tǒng)架構(gòu)設(shè)計(jì)案例分析

• 秒殺系統(tǒng)獨(dú)立部署
• 秒殺頁(yè)面靜態(tài)化
• 租借秒殺活動(dòng)網(wǎng)絡(luò)帶寬
• 動(dòng)態(tài)生成隨機(jī)下單頁(yè)面url-下單頁(yè)面url加入由服務(wù)器端生成的隨機(jī)數(shù)作為參數(shù),秒殺開(kāi)始的時(shí)候才能得到
• 使用javascript腳本控制秒殺商品頁(yè)面購(gòu)買按鈕的點(diǎn)亮
• javaScript服務(wù)器集群（lightttp）、定時(shí)任務(wù)服務(wù)器、秒殺商品服務(wù)器集群（apache）、下單服務(wù)器集群（jety）、訂單處理子系統(tǒng)、全局計(jì)數(shù)器服務(wù)器（memcached）

大型網(wǎng)站典型故障案例分析

• 寫日志也會(huì)引發(fā)故障
  • 開(kāi)發(fā)人員將log輸出的level全局配置為debug
  • 應(yīng)用程序自己的日志輸出配置和第三方組件日志輸出要分別配置
• 高并發(fā)訪問(wèn)數(shù)據(jù)庫(kù)引發(fā)的故障
  • SQL執(zhí)行頻率非常高，遠(yuǎn)超正常水平
  • 這條SQL被網(wǎng)站首頁(yè)調(diào)用
  • 首頁(yè)不應(yīng)該訪問(wèn)數(shù)據(jù)庫(kù)，首頁(yè)需要的數(shù)據(jù)可以從緩存服務(wù)器或者搜索服務(wù)器獲取
  • 首頁(yè)最好靜態(tài)
• 高并發(fā)情況下鎖引發(fā)的故障
  • 程序中某個(gè)單例對(duì)象多處使用了synchronized(this)
  • 某個(gè)需要遠(yuǎn)程調(diào)用的操作也被加了，這個(gè)操作偶爾會(huì)比被執(zhí)行，但是每次執(zhí)行都需要較長(zhǎng)的時(shí)間才能完成，這段時(shí)間鎖被占用，所有的用戶線程都要等待，響應(yīng)超時(shí)，這個(gè)操作執(zhí)行完釋放鎖，其他線程迅速執(zhí)行，超時(shí)解除
  • 使用鎖操作要謹(jǐn)慎
• 緩存引發(fā)的故障
  • 某缺乏經(jīng)驗(yàn)的工程師關(guān)閉了緩存服務(wù)器集群中全部的十幾臺(tái)memcached服務(wù)器，導(dǎo)致網(wǎng)站全部癱瘓-數(shù)據(jù)庫(kù)服務(wù)器Load飆升
  • 當(dāng)緩存不僅僅是改善性能而且成為網(wǎng)站架構(gòu)不可或缺的一部分時(shí)，對(duì)緩存服務(wù)器的管理就需要提高到和其他服務(wù)器一樣的級(jí)別
• 應(yīng)用啟動(dòng)不同步引發(fā)的故障
  • apache+jboss,用戶請(qǐng)求通過(guò)apache轉(zhuǎn)發(fā)jboss.發(fā)布時(shí)，apache和jboss同時(shí)啟動(dòng)，由于jboss啟動(dòng)時(shí)需要加載很多應(yīng)用并初始化，花費(fèi)時(shí)間較長(zhǎng)，結(jié)果jboss還沒(méi)有完全啟動(dòng)，apache就已經(jīng)啟動(dòng)并開(kāi)始接收用戶請(qǐng)求，大量請(qǐng)求被阻塞在jboss進(jìn)程中，最終導(dǎo)致jboss崩潰
  • 網(wǎng)站很多場(chǎng)景需要后臺(tái)服務(wù)準(zhǔn)備好，前臺(tái)應(yīng)用才能啟動(dòng)，否則就會(huì)導(dǎo)致故障
  • 本例中，啟動(dòng)腳本應(yīng)該先啟動(dòng)jboss，然后在腳本中不斷curl訪問(wèn)某個(gè)特定頁(yè)面，直到收到ok，才啟動(dòng)apache
• 大文件讀寫?yīng)氄即疟P引發(fā)的故障
  • 圖片存儲(chǔ)服務(wù)器，大部分文件只有幾百k,但是有幾個(gè)文件非常大，有幾百m，讀寫這些文件一次需要幾十秒。則這段時(shí)間，磁盤基本上被這個(gè)文件操作獨(dú)占，導(dǎo)致其他用戶的文件操作緩慢
  • 存儲(chǔ)的使用需要根據(jù)不同文件類型和用途進(jìn)行管理
• 濫用生產(chǎn)環(huán)境引發(fā)的故障
  • 工程師在線上生產(chǎn)環(huán)境進(jìn)行性能壓力測(cè)試，占用了大部分帶寬
  • 訪問(wèn)線上生產(chǎn)環(huán)境要規(guī)范，不小心就會(huì)導(dǎo)致大事故
• 不規(guī)范的流程引發(fā)的故障
  • 工程師開(kāi)發(fā)，為了測(cè)試方便，特意注釋掉讀取緩存的代碼，結(jié)果開(kāi)發(fā)完成后忘記把注釋去掉，直接提交到代碼庫(kù)并被發(fā)布到線上環(huán)境
  • 代碼提交前使用diff命令進(jìn)行代碼比較，確認(rèn)沒(méi)有提交不該提交大代碼
  • 加強(qiáng)code review，代碼在正式提交前必須被至少一個(gè)其他工程師做過(guò)code review，并且共同承擔(dān)因代碼引起的故障責(zé)任
• 不好的編程習(xí)慣引發(fā)的故障
  • 程序在處理一個(gè)輸入的對(duì)象時(shí)，如果不能明確該對(duì)象是否為空，必須做空指針判斷
  • 程序再調(diào)用其他方法時(shí)，輸入的對(duì)象盡量保證不是null,必要是構(gòu)造空對(duì)象

架構(gòu)師

• 領(lǐng)導(dǎo)藝術(shù)
  • 關(guān)注人而不是產(chǎn)品
  • 發(fā)掘人的優(yōu)秀
  • 共享美好藍(lán)圖
  • 共同參與架構(gòu)
  • 學(xué)會(huì)妥協(xié)
  • 成就他人
• 職場(chǎng)攻略
  • 發(fā)現(xiàn)問(wèn)題，尋找突破
  • 提出問(wèn)題，尋求支持