《大型網站技術架構.核心原理與案例分析》筆記

《大型網站技術架構.核心原理與案例分析》
一.概述
　1.大型網站架構演化
　　1.1 大型網站軟件系統的特色
　　　　高併發，大流量；高可用；海量數據；用戶分佈普遍，網絡狀況複雜；安全環境惡劣；需求快速變動，發佈頻繁；漸進式發展
　　1.2 大型網站架構師演化發展歷程
　　　　1.2.1 初始階段的網站架構：應用程序、數據庫和文件等一體在一臺服務器上
　　　　1.2.2 應用服務和數據服務分離：應用、數據、文件等分開部署
　　　　1.2.3 使用緩存改善網站性能：添加緩存程序，減輕數據庫壓力
　　　　1.2.4 使用應用服務器集羣改善網站的併發處理能力：應用程序集羣化
　　　　1.2.5 數據庫讀寫分離：數據庫主從模式
　　　　1.2.6 使用反向代理和CDN加速網站響應
　　　　1.2.7 使用分佈式文件系統和分佈式數據庫系統
　　　　1.2.8 使用NoSQL和搜索引擎
　　　　1.2.9 業務拆分
　　　　1.2.10 分佈式服務
　　1.3 大型網站架構演化的價值觀
　　　　1.3.1 大型網站架構技術的核心價值是隨網站所需靈活應對
　　　　1.3.2 驅動大型網站技術發展的主要力量是網站的業務發展
　　1.4 網站架構設計誤區
　　　　1.4.1 一味追求大公司的解決方案
　　　　1.4.2 爲了技術而技術
　　　　1.4.3 企圖用技術解決全部問題
　2.大型網站架構模式
　　2.1 網站架構模式
　　　　2.1.1 分層：從業務、網絡、邏輯、物理等方面橫向切分，簡化系統複雜性。
　　　　2.1.2 分割：從同一層級縱向切分細化。
　　　　2.1.3 分佈式：將不一樣模塊部署在不一樣的服務器上，經過遠程調用協同工做，從而獲取到更多的計算資源(好比：CPU,內存,磁盤等)。
　　　　　　分佈式應用和服務：將分層和分割後的應用和服務模塊分佈式部署。
　　　　　　分佈式靜態資源：將靜態資源(如：js,css,圖片等)獨立分佈式部署。
　　　　　　分佈式數據和存儲：採用NoSQL等分佈式存儲方式處理海量數據。
　　　　　　分佈式計算：將大規模計算使用分佈式計算框架進行批處理計算，其特色是移動計算而不是移動數據。
　　　　2.1.4 集羣：將獨立部署的服務器集羣化，即多臺服務器部署相同應用構成一個集羣，經過負載均衡設備共同對外提供服務。
　　　　2.1.5 緩存：將數據存放在距離計算最近的位置以加快處理速度。
　　　　　　CDN：即內容分發網絡，部署在距離終端用戶最近的網絡服務商。
　　　　　　反向代理：反向代理屬於網站前端架構的一部分，部署在網站的前端，當用戶請求到達網站的數據中心時，最早訪問到的就是反向代理服務器。
　　　　　　本地緩存：在應用服務器本地緩存着熱點數據，應用程序能夠在本機內存中直接訪問數據，而無需訪問數據庫。
　　　　　　分佈式緩存：將數據緩存在一個專門的分佈式緩存集羣中，應用程序經過網絡通訊訪問緩存數據。
　　　　　　使用緩存的兩個前提：一是數據訪問熱點不均衡；二是數據在某個時間段內有效，不會很快過時，不然緩存的數據就會因已經失效而產生髒讀。
　　　　2.1.6 異步：是各步經過共享數據的方式實現異步執行協做，典型的例子是生產者消費者模式。
　　　　　　特色：提供系統可用性，加快網站響應速度，消除併發訪問高峯。
　　　　2.1.7 冗餘：必定程度的服務器冗餘運行，數據冗餘備份。服務器至少兩臺構成一個集羣，數據庫按期冷備份，實時同步熱備份，創建災備數據中心。
　　　　2.1.8 自動化
　　　　　　發佈過程自動化：自動化代碼管理，自動化測試，自動化安全檢測，自動化部署，自動化監控，自動化報警，自動化失效轉移，自動化失效恢復，自動化降級，自動化分配資源。
　　　　2.1.9 安全：密碼驗證，手機校驗碼，加密通訊，驗證碼，敏感信息過濾，風險控制。
　　2.2 架構模式在新浪微博的應用

　3.大型網站核心架構要素
　　　　3.1 性能：優化手段有，緩存、CDN、前端優化、後端優化、代碼層優化、數據庫優化、集羣化、分佈式等。
　　　　3.2 可用性：7*24可用，主要手段是冗餘。
　　　　3.3 伸縮性：主要標準是是否能夠用多臺服務器構建集羣，是否容易向集羣中添加新的服務器，新加的服務器是否能夠提供和原來服務器無差異的服務，集羣中可容納的總服務器數量是否有限制。
　　　　3.4 擴展性：主要標準是是否能夠透明無影響添加新業務產品，不一樣產品之間是否不多耦合。主要手段有事件驅動架構和分佈式服務。
　　　　3.5 安全性：是針對現存和潛在的各類攻擊與竊取手段，是否有可靠的對應策略。

二.架構

　4.瞬時響應：網站的高性能架構
　　　　4.1 網站性能測試
　　　　　　4.1.1 不一樣視角下的網站性能
　　　　　　　　1.用戶視角的網站性能：是用戶在瀏覽器上直觀感覺到的網站響應速度。能夠採用前端優化手段改善，頁面、異步加載、緩存、CDN、反向代理等。
　　　　　　　　2.開發人員視角的網站性能：主要是應用程序自己及其相關子系統的性能。能夠採用緩存、異步、集羣、代碼優化等。
　　　　　　　　3.運維人員視角的網站性能：主要是基礎設施性能和資源利用率。能夠採用優化骨幹網、使用定製服務器、利用虛擬化技術優化資源利用等。
　　　　　　4.1.2 性能測試指標
　　　　　　　　1.響應時間：指應用執行一個操做須要的時間。
　　　　　　　　2.併發數：指系統可以同時處理請求的數目，這個指標也反應了系統的負載。
　　　　　　　　3.吞吐量：指單位時間內系統處理的請求數量，體現系統的總體處理能力。
　　　　　　　　4.性能計數器：指服務器或者操做系統性能的一些數據指標，包括System Load、對象與線程數、內存使用、CPU使用、磁盤與網絡I/O等指標。
　　　　　　4.1.3 性能測試方法：性能測試、負載測試、壓力測試、穩定性測試。
　　　　　　　　性能測試：以系統設計初期規劃的性能指標爲預期目標，對系統不斷施加壓力，驗證系統在資源可接受範圍內，是否能達到性能預期。
　　　　　　　　負載測試：對系統不斷地增長併發請求以增長系統壓力，直到系統的某項或多項性能指標達到安全臨界值。
　　　　　　　　壓力測試：超過安全負載的狀況下，對系統繼續施加壓力，直到系統崩潰或不能再處理任何請求，以此得到系統最大壓力承受能力。
　　　　　　　　穩定性測試：在特定硬件、軟件、網絡環境下，給測試系統加載必定業務壓力，使系統運行一段較長時間，以此檢測系統是否穩定。
　　　　　　4.1.4 性能測試報告：反應系統性能是否知足設計目標和業務要求、系統最大負載能力、系統最大壓力承受能力等重要信息。
　　　　　　4.1.5 性能優化策略
　　　　　　　　1.性能分析：排查性能瓶頸，定位問題。主要因素是內存、磁盤、網絡、CPU仍是代碼問題、架構設計不合理、系統資源不足。
　　　　　　　　2.性能優化：分爲Web前端性能優化、應用服務器性能優化、存儲服務器性能優化3大類。
　　　　4.2 Web前端性能優化：指網站業務邏輯以前的部分。
　　　　　　4.2.1 瀏覽器訪問優化：1.減小http請求；2.使用瀏覽器緩存；3.啓用壓縮；4.CSS放在頁面最上面，JavaScript放在頁面最下面；5.減小Cookie傳輸
　　　　　　4.2.2 CDN(Content Distribute Network 內容分發網絡)加速：本質是緩存一些靜態資源在網絡運營商機房。
　　　　　　4.2.3 反向代理：具備保護網站安全、緩存資源、負載均衡的功能。
　　　　4.3 應用服務器性能優化：指處理網站業務的服務器，優化手段主要有緩存、集羣、異步等。
　　　　　　4.3.1 分佈式緩存：網站性能優化第必定律：優先考慮使用緩存優化性能
　　　　　　　　1.緩存的基本原理：指將數據存儲在相對較高訪問速度的介質中，以供系統處理。一是減小數據訪問時間，二是緩存的數據是通過計算處理，減小計算時間。緩存主要用來存放那些讀寫比很高、不多變化的數據。
　　　　　　　　2.合理使用緩存：使用緩存應避免頻繁修改的數據、沒有熱點的訪問、數據不一致與髒讀、緩存可用性、緩存預熱、緩存穿透。
　　　　　　　　3.分佈式緩存架構：指緩存部署在多個服務器組成的集羣中，以集羣方式提供緩存服務。
　　　　　　　　4.Mencached特色：簡單的通訊協議、豐富的客戶端程序、高性能的網絡通訊、高效的內存管理、互不通訊的服務器集羣架構。
　　　　　　4.3.2 異步操做：使用消息隊列將調用異步化，可改善網站的擴展性。任何能夠晚點作的事情都應該晚點再作。
　　　　　　4.3.3 使用集羣：使用負載均衡技術爲一個應用構建一個由多臺服務器組成的服務器集羣，將併發訪問請求分發到多臺服務器上處理。
　　　　　　4.3.4 代碼優化
　　　　　　　　1.多線程：解決線程安全的主要手段有：將對象設計爲無狀態對象、使用局部對象、併發訪問資源時使用鎖。
　　　　　　　　2.資源複用：儘可能減小開銷很大的系統資源的建立和銷燬(好比：數據庫鏈接，網絡通訊鏈接，線程，複雜對象等)。主要手段有單例和對象池。
　　　　　　　　3.數據結構：在不一樣場景中合理使用恰當的數據結構，靈活組合各類數據結構改善數據讀寫和計算特性可極大優化程序的性能。
　　　　　　　　4.垃圾回收：理解垃圾回收機制有助於程序優化和參數調優，以及編寫內存安全的代碼。JVM內存主要分爲堆(heap)和堆棧(stack)。堆棧用於存儲線程上下文信息，如方法參數、局部變量等。堆則是存儲對象的內存空間，對象的建立和釋放、垃圾回收就在這裏進行。
　　　　4.4 存儲性能優化
　　　　　　4.4.1 機械硬盤 vs. 固態硬盤
　　　　　　4.4.2 B+樹 vs. LSM樹
　　　　　　　　B+樹是一種專門針對磁盤存儲而優化的N叉排序樹，以樹節點爲單位存儲在磁盤中，從根開始查找所需數據所在的節點編號和磁盤位置，將其加載到內存中而後繼續查找，直到找到所需的數據。
　　　　　　　　LSM樹能夠看做是一個N階合併樹。許多NoSQL產品採用LSM樹做爲主要數據結構。
　　　　　　4.4.3 RAID vs.HDFS
　　　　　　　　RAID(廉價磁盤冗餘陣列)技術主要是爲了改善磁盤的訪問延遲，加強磁盤的可用性和容錯能力。
　　　　　　　　RAID0 數據在從內存緩存區寫入磁盤時，根據磁盤數量將數據分紅N份，將數據同時併發寫入N塊磁盤，使得數據總體寫入速度是一塊磁盤的N倍。讀取也是同樣。可是未作備份。
　　　　　　　　RAID1 在寫入磁盤時，將一份數據同時寫入兩塊磁盤，提升了可靠性。
　　　　　　　　RAID10 將全部磁盤平均分紅兩份，數據同時在兩份磁盤寫入，結合RAID0和RAID1兩種方案。
　　　　　　　　RAID3 在數據寫入磁盤時，將數據分紅N-1塊，併發寫入N-1塊磁盤，並在第N塊磁盤記錄校驗數據，任何一塊磁盤損壞，均可以利用其它N-1塊磁盤的數據修復。
　　　　　　　　RAID5 在數據寫入磁盤時，將數據分紅N-1塊，併發寫入N-1塊磁盤，並將檢驗數據螺旋式的寫入全部磁盤中，防止校驗磁盤頻繁寫入。
　　　　　　　　RAID6 與RAID5相似，可是數據只寫入N-2塊磁盤，並螺旋式地在兩塊磁盤中寫入校驗信息。
　　　　　　　　HDFS 以塊(Block)爲單位管理文件內容，一個文件被分割成若干個Block，每寫完一個Block，HDFS就將其自動複製到另外兩臺機器上，保證Block有三個副本。

　　5.萬無一失：網站的高可用架構
　　　　5.1 網站可用性的度量與考覈
　　　　　　5.1.1 網站可用性度量 　　　　 網站不可用時間(故障時間)=故障修復時間點-故障發現(報告)時間點
　　　　　　　　　　　　　　　　　　　　網站年度可用性指標=(1-網站不可用時間)*100%
　　　　　　5.1.2 網站可用性考覈 　　　　 故障分=故障時間(分鐘)*故障權重
　　　　5.2 高可用的網站架構：主要目的是保證服務器硬件故障時服務依然可用、數據依然保存並能狗被訪問。主要手段是數據和服務的冗餘備份及失效轉移。
　　　　5.3 高可用的應用：應用層主要處理網站應用的業務邏輯，具備無狀態性。
　　　　　　5.3.1 經過負載均衡進行無狀態服務的失效轉移
　　　　　　5.3.2 應用服務器集羣的Session管理：1.Session複製；2.Session綁定；3.利用Cookie記錄Session；4.Session服務器
　　　　5.4 高可用的服務：1.分級管理；2.超時設置；3.異步調用；4.服務降級；5.冪等性設計
　　　　5.5 高可用的數據：主要手段是數據備份和失效轉移機制。數據備份是保證數據有多個副本。
　　　　　　　　高可用的數據具有：數據持久性、數據可訪問性、數據一致性、
　　　　　　5.5.1 CAP原理：一個提供數據服務的存儲系統沒法同時知足數據一致性(Consistency)、數據可用性(Availibility)、分區耐受性(PartitionTolerance)這個三個條件。
　　　　　　　　　　數據一致性又分：數據強一致、數據用戶一致、數據最終一致。
　　　　　　5.5.2 數據備份
　　　　　　　　冷備份：優勢是簡單和廉價，成本和技術難度都較低。缺點是不能保證數據最終一致。
　　　　　　　　異步熱備份：指多份數據副本的寫入操做異步完成，應用程序收到數據服務系統的寫操做成功響應時，只寫成功了一份，存儲系統將會異步地寫其餘副本。
　　　　　　　　同步熱備份：指多份數據副本的寫入操做同步完成，即應用程序收到數據服務系統的寫成功響應時，多份數據都已經寫操做成功。
　　　　　　5.5.3 失效轉移：1.失效確認；2.訪問轉移；3.數據恢復。
　　　　5.6 高可用網站的軟件質量保證
　　　　　　5.6.1 網站發佈
　　　　　　5.6.2 自動化測試
　　　　　　5.6.3 預發佈驗證
　　　　　　5.6.4 代碼控制：1.主幹開發、分支發佈(Git)；2，分支開發、主幹發佈(SVN).
　　　　　　5.6.5 自動化發佈：週四做爲發佈日，一週前三天準備發佈，最後一天驗證發佈。
　　　　　　5.6.6 灰度發佈：指在部分服務器上發佈新版本，其他服務器保持老版本，而後監控用戶操做行爲，收集驗證，以肯定最終的發佈版本。也稱做AB測試。
　　　　5.7 網站運行監控：不容許沒有監控的系統上線。
　　　　　　5.7.1 監控數據採集
　　　　　　　　1.用戶行爲日誌收集：指用戶在瀏覽器上所作的全部操做及其所在的操做環境，包括用戶操做系統與瀏覽器版本信息，IP地址。頁面訪問路徑、頁面停留時間等。
　　　　　　　　服務器端日誌收集，客戶端瀏覽器日誌收集(嵌入專門的JavaScript腳本收集用戶真實的操做行爲).
　　　　　　　　2.服務器性能監控：指收集如系統Load、內存佔用、磁盤IO、網絡IO等對儘早作出故障預警，及時判斷應用情況防患於未然。
　　　　　　　　3.運行數據報告：指監控一些與具體業務場景相關的技術和業務指標，如緩存命中率、平均響應延遲時間、每分鐘發送郵件數目、待處理的任務總數等。
　　　　　　5.7.2 監控管理：系統報警、失效轉移、自動優雅降級。

　　6.永無止境：網站的伸縮性架構
　　　　　　網站的伸縮性：指不須要改變網站的軟硬件設計，僅僅經過改變部署的服務器數量就能夠擴大或者縮小網站的服務處理能力。
　　　　　　6.1 網站架構的伸縮性設計
　　　　　　　　網站的伸縮性設計可分爲兩類：一類是根據功能進行物理分離實現伸縮；二類是單一功能經過集羣實現伸縮。
　　　　　　　　6.1.1 不一樣功能進行物理分離實現伸縮
　　　　　　　　　　縱向分離(分層後分離)：將業務處理流程上的不一樣部分分離部署，實現系統伸縮性。
　　　　　　　　　　橫向分離(業務分割後分離)：將不一樣的業務模塊分離部署，實現系統伸縮性。
　　　　　　　　6.1.2 單一功能經過集羣規模實現伸縮
　　　　　　6.2 應用服務器集羣的伸縮性設計：採用負載均衡服務器控制請求分發
　　　　　　　　6.2.1 HTTP重定向負載均衡：方案簡單，可是須要瀏覽器兩次請求才能完成一次訪問，性能較差。
　　　　　　　　6.2.2 DNS域名解析負載均衡：根據負載均衡算法計算一個不一樣的IP地址返回對應的真實服務器地址。
　　　　　　　　6.2.3 反向代理負載均衡：將請求根據負載均衡算法轉發到不一樣的Web服務器上。Web服務器處理完成的響應也需經過反向代理服務器返回給用戶。反向代理服務器轉發請求在HTTP協議層面。
　　　　　　　　6.2.4 IP負載均衡：在網絡層經過修改請求目標地址進行負載均衡。操做系統內核進程獲取網絡數據包，根據負載均衡算法計算獲得一臺真實Web服務器地址，將數據目的IP地址修改成真實Web服務器地址，返回時再將數據包源地址修改成自身的IP地址發送給用戶。
　　　　　　　　6.2.5 數據鏈路層負載均衡：指在通訊協議的數據鏈路層修改mac地址進行負載均衡。分發過程當中不修改IP地址，只修改目的mac地址，經過配置真實物理服務器集羣全部機器虛擬IP和負載均衡服務器IP地址一致，從而達到不修改數據包的源地址和目的地址就能夠進行數據分發的目的。
　　　　　　　　6.2.6 負載均衡算法：1.根據負載均衡算法和Web服務器列表計算獲得集羣中一臺Web服務器的地址；2.將請求數據發送到該地址對應的Web服務器上。
　　　　　　　　　　常見算法：輪詢(Round Robin,RR):依次分發到天天服務器上，請求數目平均。
　　　　　　　　　　加權輪詢(Weighted Round Robin,WRR):按照配置的權重將請求分發到每一個服務器，權重重的分配更多請求。
　　　　　　　　　　隨機(Random):請求被隨機分配到各個應用服務器。
　　　　　　　　　　最少鏈接(Least Connections):記錄每一個應用服務器正在處理的鏈接數，將新到的請求分發到最少鏈接的服務器上。
　　　　　　　　　　源地址散列(Source Hashing):根據請求源IP地址進行Hash計算，獲得應用服務器，這樣來自同一個IP地址的請求總在同一個服務器上處理，該請求的上下文信息能夠存儲在這臺服務器上，在一個會話週期內重複使用，實現會話粘滯。
　　　　　　6.3 分佈式緩存集羣的伸縮性設計：新加入緩存服務器後應使整個緩存服務器集羣中的已緩存數據儘量還被訪問到。
　　　　　　　　6.3.1 Memcached分佈式緩存集羣的訪問模式
　　　　　　　　　　路由算法負責根據應用程序輸入的緩存數據(Key)計算獲得應該將數據寫入到哪臺服務器或者應該從哪臺服務器讀數據。
　　　　　　　　6.3.2 Memcached分佈式緩存集羣的伸縮性挑戰：新的緩存服務器加入致使緩存命中率降低。
　　　　　　　　6.3.3 分佈式緩存的一致性Hash算法：經過一致性Hash環的數據結構實現Key到緩存服務器的Hasee映射。
　　　　　　　　　　算法：先構造一個長度爲2的32次冪的整數環，根據節點名稱的Hash值(其分佈範圍爲[0,2的32次冪-1])將緩存服務器節點放置在這個Hash環上。再根據緩存的數據的Key值計算獲得其Hash值，在環上順時針查找對應的服務器節點。
　　　　　　6.4 數據存儲服務器集羣的伸縮性設計：必須保證數據的可靠存儲，保證數據的可用性和正確性。分爲關係數據庫集羣和NoSQL數據庫的伸縮性設計。
　　　　　　　　6.4.1 關係數據庫集羣的伸縮性設計：數據庫主從讀寫分離，也能夠業務分割分離實現數據分庫。數據庫分片產品有：Amoeba和Cobar。
　　　　　　　　6.4.2 NoSQL數據庫的伸縮性設計：實現高可用性和可伸縮性，主要有HBase，Redis，MongoDB。
　　　　　　　　　　NoSQL主要指非關係的、分佈式的數據庫設計模式。

　　7.隨需應變：網站的可擴展架構
　　　　　　擴展性(Extensibility):指對現有系統影響最小的狀況下，系統功能可持續擴展或提高的能力。
　　　　　　伸縮性(Scalability):指系統可以經過增長(減小)自身資源規模的方式加強(減小)本身計算處理事務的能力。
　　　　　　7.1 構建可擴展的網站架構：核心思想是模塊化，並下降模塊間的耦合性，提升模塊的複用性。
　　　　　　　　模塊分佈式部署之後具體聚合方式主要有分佈式消息隊列和分佈式服務。
　　　　　　7.2 利用分佈式消息隊列下降系統耦合性
　　　　　　　　7.2.1 事件驅動架構(Event Driven Architecture):在低耦合模塊之間傳輸事件消息，以保持模塊的鬆散耦合，並藉助事件消息的通訊完成模塊間的合做。
　　　　　　　　7.2.2 分佈式消息隊列：採用隊列數據結構，實現消息分佈式異步調用。
　　　　　　7.3 利用分佈式服務打造可複用的業務平臺
　　　　　　　　大型系統存在的問題：1.編譯、部署困難；2.代碼分支管理困難；3.數據庫鏈接耗盡；4.新增業務困難。
　　　　　　　　解決方案：核心思想是拆分，將模塊獨立部署，下降系統耦合性。
　　　　　　　　縱向拆分：將一個大應用拆分爲多個小應用，若是新增業務較爲獨立，就直接將其設計部署爲一個獨立的Web應用系統。
　　　　　　　　橫向拆分：將複用的業務拆分出來，獨立部署爲分佈式服務，新增業務只須要調用這些分佈式服務，不須要依賴具體模塊代碼，而模塊內業務邏輯變化時，只要接口保持一致就不會影響業務程序和其餘模塊。
　　　　　　　　7.3.1 WebService與企業分佈式服務
　　　　　　　　　　WebService缺點：1.臃腫的註冊與發現機制；2.低效的XML序列化手段；3.開銷相對較高的HTTP遠程通訊；4.複雜的部署與運維手段。
　　　　　　　　7.3.2 大型網站分佈式服務的需求與特色
　　　　　　　　　　負載均衡，失效轉移，高效的遠程通訊，整合異構系統，對應用最少侵入，版本管理，實時監控。
　　　　　　　　7.3.3 分佈式服務框架設計：服務消費者程序經過服務接口使用服務，而服務接口經過代理加載具體服務，具體服務能夠是本地代碼塊，也能夠是遠程服務，所以對應用較少侵入，應用程序只須要調用服務接口，服務框架根據配置自動調用本地或遠程實現。
　　　　　　　　7.3.4 可擴展的數據結構：NoSQL數據庫的動態列設計。
　　　　　　7.5 利用開放平臺建設網站生態圈
　　　　　　　　開放平臺是網站內部和外部交互的接口，外部須要面對衆多的第三方開發者，內部須要面對網站內諸多的業務服務。
　　　　　　　　API接口：是開放平臺暴露給開發者使用的一組API，其形式能夠是RESTful、WebService、RPC等各類形式。
　　　　　　　　協議轉換：將各類API輸入轉換成內部服務能夠識別的形式，並將內部服務的返回封裝成API的格式。
　　　　　　　　安全：須要設置身份識別、權限控制等，開放平臺還須要分等級的訪問寬帶限制。
　　　　　　　　審計：記錄第三方應用的訪問狀況，並進行監控、計費等。
　　　　　　　　路由：將開放平臺的各類訪問路由映射到具體的內部服務。
　　　　　　　　流程：將一組離散的服務組織成一個上下文相關的新服務，隱藏服務細節，提供統一接口供開發者調用。

　　8.固若金湯：網站的安全架構
　　　　8.1 道高一尺魔高一丈的網站應用攻擊與防護
　　　　　　8.1.1 XSS攻擊(跨站點腳本攻擊Cross Site Script):指黑客經過篡改網頁，注入惡意HTML腳本，在用戶瀏覽網頁時，控制用戶瀏覽器進行惡意操做的一種攻擊方式。
　　　　　　　　消毒：對HTML進行過濾和消毒處理，即對某些html危險字符轉義防止惡意腳本攻擊。
　　　　　　　　HttpOnly：即瀏覽器禁止頁面JavaScript訪問帶有HttpOnly屬性的Cookie。
　　　　　　8.1.2 注入攻擊：注入攻擊有兩種，SQL注入攻擊和OS注入攻擊。SQL注入攻擊原理是在HTTP請求中注入惡意SQL語句，服務器用請求參數構造數據庫SQL命令時，惡意SQL被一塊兒構造並在數據庫中執行。
　　　　　　　　SQL注入獲取數據庫表結構手段：開源軟件，錯誤回顯，盲注。
　　　　　　　　防護SQL注入手段：消毒(請求參數消毒，過濾請求數據);參數綁定(使用預編譯手段，實現SQL預編譯和參數綁定).
　　　　　　8.1.3 CSRF攻擊(CrossSiteRequestForgery,跨站點請求僞造)：經過跨站請求，以合法用戶的身份進行非法操做。核心是利用瀏覽器Cookie或Session。
　　　　　　　　CSRF防護手段：表單Token，驗證碼，Referer check。
　　　　　　8.1.4 其餘攻擊和漏洞：ErrorCode，HTML註釋，文件上傳，路徑遍歷。
　　　　　　8.1.5 Web應用防火牆：ModSecurity，SiteShell。
　　　　　　8.1.6 網站安全漏洞掃描：不按期地對網站的服務器進行漏洞掃描，查漏補缺。對代碼按期作安全檢測和代碼漏洞檢查。
　　　　8.2 信息加密技術及密鑰安全管理：單向散列加密、對稱加密、非對稱加密。
　　　　　　8.2.1 單向散列加密：指經過對不一樣輸入長度的信息進行散列計算，獲得固定長度的輸出，這個散列計算過程是單向的，即不能對固定長度的輸出進行計算從而得到輸入信息。
　　　　　　8.2.2 對稱加密：指加密和解密使用的密鑰是同一個密鑰。優勢是算法簡單，加解密效率高，系統開銷小，
　　　　　　8.2.3 非對稱加密：指加密和解密使用的密鑰不是同一密鑰。其中一個對外界公開的公鑰，另外一個只有全部者知道的私鑰。
　　　　　　8.2.4 密鑰安全管理：一種是把密鑰和算法放在一個獨立的服務器上，一種是將加解密算法放在應用系統中，密鑰則放在獨立服務器上。
　　　　8.3 信息過濾與反垃圾
　　　　　　8.3.1 文本匹配：主要解決敏感詞過濾
　　　　　　8.3.2 分類算法：採用貝葉斯分類算法進行機率統計分類。
　　　　　　8.3.3 黑名單：將信息在黑名單列表中查找匹配，若是查找成功，則過濾該信息。
　　　　8.4 電子商務風險控制
　　　　　　8.4.1 風險：存在着帳戶風險、買家風險、賣家風險、交易風險。
　　　　8.4.2 風控：1.規則引擎。2.統計模型。
三.案例

　　9.淘寶網的架構演化案例分析:從最初的開源框架到採用資深專業技術，最後回到開源框架，並獨立開發開源系統。
　　　　Linux+Apache+MySQL+PHP-->Linux+Weblogic+Oracle+Java-->Linux+JBoss+Oracle+Java+Spring-->Linux+JBoss+MySQL+Java+Spring-->獨立開發框架系統

　　10.維基百科的高性能架構設計分析：Linux+Apache+MySQL+PHP
　　　　Wikipedia架構主要組成：GeoDNS(域名服務器),LVS(負載均衡服務器),Squid(反向代理服務器),Lighttpd(應用服務器),PHP,Memcached(分佈式緩存系統),Lucene(搜索引擎),MySQL(數據庫).

　　11.海量分佈式存儲系統Doris的高可用架構設計分析
　　　　11.1 分佈式存儲系統的高可用架構
　　　　　　系統總體分爲三部分：應用程序服務器,是存儲系統的客戶，對系統發起數據操做請求。
　　　　　　數據存儲服務器,是存儲系統的核心，負責存儲數據、響應應用服務器的數據操做請求。
　　　　　　管理中心服務器，由兩臺機器組成的主-主熱備集羣，負責集羣管理，對數據存儲集羣進行健康心跳檢測，集羣擴容、故障恢復管理，對應用程序服務器提供集羣地址配置信息服務等。
　　　　11.2 不一樣故障狀況下的高可用解決方案
　　　　　　11.2.1 分佈式存儲系統的故障分類：瞬時故障，臨時故障，永久故障。
　　　　　　11.2.2 正常狀況下系統訪問結構：寫數據時，將數據寫入集羣所有服務器。讀數據時，從任意一臺服務器讀取。
　　　　　　11.2.3 瞬時故障的高可用解決方案：是一種嚴重性較低的故障，通常系統通過較短暫的時間便可自行恢復。
　　　　　　11.2.4 臨時故障的高可用解決方案：是將發生故障的服務器寫數據操做轉移到臨時存儲服務器。
　　　　　　11.2.5 永久故障的高可用解決方案：從其餘序列中正常的服務器中複製所有數據才能恢復正常狀態。
　　　　　　永久故障是指服務器上的數據永久丟失，不能恢復。

　　12.網購秒殺系統架構設計案例分析
　　　　12.1 秒殺活動的技術挑戰
　　　　　　1.對現有網站業務形成衝擊。 　　2.高併發下的應用、數據庫負載。　　3.忽然增長的網絡及服務器帶寬。　　4.直接下單。
　　　　12.2 秒殺系統的應對策略
　　　　　　1.秒殺系統獨立部署。　　　　2.秒殺商品頁面靜態化。　　3.租借秒殺活動網絡帶寬。　　4.動態生成隨機下單頁面URL。
　　　　12.3 秒殺系統架構設計：1.購買按鈕只有在秒殺活動開始的時候纔可點擊。2.下單表單也儘量簡單，配置用戶默認設置。
　　　　　　1.如何控制秒殺商品頁面購買按鈕的點亮：秒殺頁面設計爲靜態頁面，緩存在CDN、反向代理服務器上，使用內嵌腳本控制秒殺商品頁面的展現。
　　　　　　2.如何只容許第一個提交的訂單被髮送到訂單子系統：控制進入下單頁面的入口，只有少數用戶能進入下單頁面，其餘用戶直接進入秒殺結束頁面。

　　13.大型網站典型故障案例分析
　　　　13.1 寫日誌也會引起故障
　　　　　　故障現象：服務器報警，硬盤可用空間低於警惕值。
　　　　　　緣由分析：服務器硬盤容量過小，應用服務器集羣日誌打印過多，沒有及時清除。
　　　　　　經驗教訓：應用程序本身的日誌輸出配置和第三方組件日誌輸出分別配置。
　　　　　　檢查log配置文件，日誌輸出級別至少爲Warn，並檢查log輸出代碼調用是否符合真實日誌級別。
　　　　13.2 高併發訪問數據庫引起的故障
　　　　　　故障現象：應用發佈後，數據庫Load居高不下。
　　　　　　緣由分析：檢查數據庫，發現某條SQL頻繁執行。
　　　　　　經驗教訓：首頁不該該訪問數據庫，首頁須要的數據能夠從緩存服務器或者搜索引擎服務器獲取。
　　　　　　首頁最好是靜態的。
　　　　13.3 高併發狀況下鎖引起的故障
　　　　　　故障現象：應用服務器不定時地響應超時而報警，可是很快又超時解除。
　　　　　　緣由分析：程序中某個單例中多處使用了synchronized(this)，高併發下容易出現排隊等待現象。
　　　　　　經驗教訓：使用鎖操做要謹慎，代碼提交必須檢視。
　　　　13.4 緩存引起的故障
　　　　　　故障現象：沒有發佈新應用，可是數據庫服務器Load飆升，並失去響應。
　　　　　　緣由分析：緩存服務器集羣所有被關閉。
　　　　　　經驗教訓：緩存服務器的管理和其餘應用服務器同樣重要。新手操做必須通過導師檢查。
　　　　13.5 應用啓動不一樣步引起的故障
　　　　　　故障現象：發佈應用後，服務器當即崩潰。
　　　　　　緣由分析：應用程序Web環境使用Apache+JBoss模式，用戶請求經過Apache轉發JBoss。發佈時Apache和JBoss同時啓動，因爲JBoss啓動時需加載不少應用並初始化，花費時間較長，結果JBoss尚未徹底啓動，Apache就已經啓動開始接收用戶請求，大量請求阻塞在JBoss進程中，致使JBoss崩潰。
　　　　　　經驗教訓：檢查各應用環節啓動時間，合理銜接各部分程序。
　　　　13.6 大文件讀寫獨佔磁盤引起的故障
　　　　　　故障現象：圖片上傳很是慢，有時等待服務器超時。
　　　　　　緣由分析：圖片存儲服務器有幾個文件很是大。
　　　　　　經驗教訓：存儲的使用須要根據不一樣文件類型和用途進行管理。
　　　　13.7 濫用生成環境引起的故障
　　　　　　故障現象：監控發現某個時段內，應用忽然變慢，內部網絡訪問延遲很是厲害。
　　　　　　緣由分析：發現有工程師在線上生成環境進行性能壓力測試。
　　　　　　經驗教訓：規範線上生成環境操做規範，預防不當操做。
　　　　13.8 不規範的流程引起的故障
　　　　　　故障現象：應用發佈後，數據庫Load迅速飆升，回滾後發佈報警消失。
　　　　　　緣由分析：發現訪問緩存的代碼被註釋了，爲了測試方便，註釋後提交時忘記修改。
　　　　　　經驗教訓：代碼提交前使用diff進行比較，確認沒有提交不應提交的代碼。增強CodeReview.
　　　　13.9 很差的編程習慣引起的故障
　　　　　　故障現象：應用更新某功能後，有少許用戶投訴沒法正常訪問。
　　　　　　緣由分析：用戶第一次使用該功能，歷史記錄爲空，構造了一個空對象。
　　　　　　經驗教訓：程序在輸入數據時，必須作必要檢查；程序在調用其餘方法時，輸入對象儘可能保證不是null，必要時構造空對象。

四.架構師

　　　　14.架構師領導藝術
　　　　　　架構師職責：架構設計，軟件開發等技術工做，規劃產品路線、估算人力資源和時間資源、安排人員職責分工、肯定計劃里程碑點、指導工程師工做、過程風險評估與控制等。
　　　　　　14.1 關注人而不是產品：尋找一個值得共同奮鬥的目標，營造一個讓你們都能最大限度發揮自我價值的工做氛圍。
　　　　　　14.2 發掘人的優秀：是事情成就了人，而不是人成就了事。
　　　　　　　　發掘一我的的優秀遠比發掘一個優秀的人更有意義。
　　　　　　14.3 共享美好藍圖
　　　　　　　　藍圖應該是表述清楚的：產品要作什麼、不作什麼、要達到什麼業務目標，都須要描述清楚。
　　　　　　　　藍圖應該是形象的：產品能爲用戶創造什麼價值、能實現什麼樣的市場目標、產品最終會長什麼樣，都須要形象地想象出來。
　　　　　　　　藍圖應該是簡單的：無論內部仍是外部溝通，都能一句話說明白：咱們在作什麼。
　　　　　　14.4 共同參與架構
　　　　　　　　1.不要只有架構師一我的擁有架構
　　　　　　　　2.讓其餘人維護框架與架構文檔
　　　　　　14.5 學會妥協
　　　　　　14.6 成就他人：經過工做的挑戰發掘自個人潛能，從新認知自我和世界。

　　　　15.網站架構師職場攻略
　　　　　　15.1 發現問題尋找突破
　　　　　　15.2 提出問題，尋求支持
　　　　　　　　提出問題Tips：1.把「個人問題」表述成「咱們的問題」。2.給上司提封閉式問題，給下屬提開放式問題。3.指出問題而不是批評人。4.用贊同的方式提出問題。
　　　　　　15.3 解決問題，達成績效
　　　　　　　　解決問題Tips：1.在解決個人問題以前，先解決你的問題。2.適當的逃避問題。

　　　　16.漫畫網站架構師
　　　　大型網站架構技術一覽：
　　　　　　1.前端架構：瀏覽器優化技術、CDN、動靜分離，靜態資源獨立部署、圖片服務、反向代理、DNS。
　　　　　　2.應用層架構：開發框架、頁面渲染、負載均衡、Session管理、動態頁面靜態化、業務拆分、虛擬化服務器。
　　　　　　3.服務層架構：分佈式消息、分佈式服務、分佈式緩存、分佈式配置。
　　　　　　4.存儲層架構：分佈式文件、關係數據庫、NoSQL數據庫、數據同步。
　　　　　　5.後臺架構：搜索引擎、數據倉庫、推薦系統。
　　　　　　6.數據採集與監控：瀏覽器數據採集、服務器業務數據採集、服務器性能數據採集、系統監控、系統報警。
　　　　　　7.安全架構：Web攻擊、數據保護。
　　　　　　8.數據中心機房架構：機房架構、機櫃架構、服務器架構。

備註：
做者：Shengming Zeng
博客：http://www.cnblogs.com/zengming/

本文是原創，歡迎你們轉載；但轉載時必須註明文章來源，且在文章開頭明顯處給明連接。<歡迎有不一樣想法或看法的同窗一塊兒探討，共同進步>