大型網站技術架構02 網站的高性能架構、網站的可用性架構

大型網站核心架構要素

1. 性能

2. 可用性

3. 伸縮性

4. 擴展性

5. 安全性

 

瞬時響應：網站的高性能架構

1. 網站性能測試：

    1). 不一樣視角下的網站性能

         a. 用戶視角的網站性能：用戶計算機，網站服務器通訊時間，網站服務器處理時間，用戶瀏覽器解析時間等。

         b. 開發人員視角的網站性能：

         c. 運維人員視角的網站性能：優化主幹網，利用虛擬化技術優化資源利用等

    2). 性能測試指標

          a. 響應時間：單個請求時間很差計算，能夠經過重複執行一萬次，測試一萬次執行須要的總響應時間之和，而後除以一萬，獲得單次請求的響應時間。

          b. 併發數：指系統同時處理請求的數目，這個數字也反映了系統的負載特性。測試程序經過多線程模擬併發用戶的辦法來測試系統的併發能力，爲了模擬真實用戶行爲，測試程序並非啓動多線程而後不停

                         地發送請求，而是在兩次之間加入一個隨機等待時間，這個時間被稱爲思考時間。

          c. 吞吐量：單位時間內系統處理的請求數量，體現系統的總體處理能力。

          d. 性能計數器：描述服務器或操做系統性能的一些數據指標。包括System Load、對象與線程數、內存使用、CPU使用、磁盤與網絡IO等指標。這些指標也是系統監控的重要參數，對這些指標設置報警閾值，

                               當監控系統發現性能計數器超過閾值時，就向運維和開發人員報警，及時發現處理系統異常。

    3). 性能測試方法：

         a. 性能測試：以系統設計初期規劃的性能指標爲預期目標，對系統不斷施加壓力，驗證系統在資源可接受範圍內，是否能達到系能逾期。

         b. 負載測試：對系統不斷地增長併發請求以增長系統壓力，直到系統的某項或多項性能指標達到安全臨界值，如某種資源已經呈飽和狀態，這時繼續對系統施加壓力，系統的處理能力不但不能提升，反而降低。

         c. 壓力測試：超過安全負載的狀況下，對系統繼續施加壓力，直到系統崩潰或不能再處理任何請求，以此得到系統最大壓力承受能力。

         e. 穩定性測試：被測試系統在特定硬件、軟件、網絡環境條件下，給系統加載必定業務壓力，是系統運行一段較長時間，以此檢測系統是否穩定。穩定性測試硬不均勻地對系統施加壓力。

         f. 經過測試得出：網站平常運行區間，系統的最大負載點，系統的崩潰點

    4). 性能測試報告：應包括：併發數，響應時間，TPS(每秒事務數)，錯誤率(%)，Load，內存(GB)，備註

    5). 性能優化策略

         a. 性能分析：檢查請求處理的各個環節的日誌，分析哪一個環節響應時間不合理、超過預期；而後檢查監控數據，分析影響能力的主要因素是內存、磁盤、網絡、仍是CPU，是代碼問題仍是架構設計不合理，或

                           系統資源不足。

         b. 性能優化

2. Web前端性能優化

    1). 瀏覽器訪問優化：

         a. 減小http請求：合併CSS，合併JS將瀏覽器須要的JS，CSS合併成一個文件。圖片由多張合成一張。

         b. 使用瀏覽器緩存：緩存靜態資源。在某些時候，靜態資源變換須要及時應用到客戶端瀏覽器，能夠經過修改文件名實現。靜態資源多的時候，考慮逐量更新。

         c. 啓用壓縮

         d. CSS放在頁面最上面、JavaScript放在頁面最下面：若是頁面解析時就須要用到JS，這時放在底部就不合適了。

         e. 減小Cookie傳輸

    2). CDN加速：即內容分發網絡，部署在距離終端用戶最近的網絡服務商，用戶的網絡請求老是先到達他的網絡服務器商那裏，在這裏緩存網站的一些靜態資源(較少變化的數據)。能夠就近以最快的速度返回給用戶，

                        如視頻網站和門戶網站會將用戶訪問量最大的熱點內容緩存在CDN。

    3). 反向代理：反向帶來屬於網站前端架構的一部分，部署在網站的前端，當用戶請求到達網站的數據中心時，最早訪問到的就是反向代理服務器，這裏緩存網站的靜態資源。無需將請求繼續轉發給應用服務器就能

                       返回給用戶。來自互聯網的請求必須通過代理服務器，至關於在Web服務器和可能的網絡攻擊之間創建了一個屏障，起到保護做用。

3. 應用服務器性能優化：

    1). 分佈式緩存：網站性能優化的第必定律：優先考慮使用緩存優化性能。

         a. 緩存的基本原理：緩存指將數據存儲在相對較高訪問速度的存儲介質中，以供系統處理。一方面緩存訪問速度快，能夠減小數據訪問時間，另外一方面若是緩存的數據是通過計算處理獲得的，那麼被緩存的數據

                                     無需重複計算便可直接使用，所以緩存還起到減小計算時間的做用。

                                     緩存的本質是一個內存Hash表，網站數據訪問一般遵循二八定律。

         b. 合理使用緩存：頻繁修改的數據(不適合)，沒有熱點的訪問(不適合)，數據不一致與髒讀(注意)，緩存可用性(緩存崩潰後，數據庫直面訪問可否承受)，緩存預熱(提早將緩存數據加載出來)，

                                  緩存穿透(一個簡單的對應策略是敬愛給你不存在的數據也緩存起來(其值爲null))

                                  通常來講，數據的讀寫比在2:1以上，即寫入一次緩存，在數據更新前至少讀取兩次，緩存在有意義

         c. 分佈式緩存架構：一種是以JBoss Cache爲表明的須要更新同步的分佈式緩存，一種是以Memcached爲表明的不互相通訊的分佈式緩存。

         d. memcached : 簡單的通訊協議，豐富的客戶端程序，高性能的網絡通訊，高效的內存管理，互不通訊的服務器集羣架構

    2). 異步操做：使用消息隊列將調用異步化，可改善網站的擴展性。事實上使用消息隊列還可改善網站系統的性能。消息隊列具備很好的削峯做用。

                       注意，因爲數據寫入消息隊列後馬上返回給用戶，數據在後續的業務校驗、寫數據庫等操做可能失敗，所以在使用消息隊列進行業務異步處理後，須要適當修改業務流程進行配合。如訂單提交後，訂單

                       數據寫入消息隊列，不能當即返回用戶訂單提交成功。須要在消息隊列的訂單消費者進程真正處理完該訂單，甚至商品出庫後，再經過電子郵件或SMS消息通知用戶訂單成功，以避免交易糾紛。

                       任何能夠晚點作的事情都應該晚點再作。

    3). 使用集羣

    4). 代碼優化：

         a. 多線程：從資源利用的角度角度看，使用多線程的緣由主要有兩個：IO阻塞與多CPU。啓用線程數 = [任務執行時間/(任務執行時間-IO等待時間)]*CPU內核數

                        解決線程安全主要手段有以下幾點：將對象設計成無狀態對象，使用局部變量，併發訪問資源時使用鎖。

         b. 資源複用：主要有兩種模式：單例(Singleton)和對象池(Object Pool)

         c. 數據結構：hash等

         d. 垃圾回收

4. 存儲性能優化：

    1). 機械硬盤  VS  固態硬盤

    2). B+樹  VS LSM樹

    3). RAID  VS HDFS

         a. RAID(廉價磁盤冗餘陣列)技術主要是爲了改善磁盤的訪問延遲，加強磁盤的可用性和容錯能力。目前服務器級別的計算機都支持插入多塊磁盤(8塊或者更多)，經過使用RAID技術，實現數據在多塊磁盤上的

             併發讀寫和數據備份。

             RAID0：根據磁盤數量將數據分紅N分，同時併發寫入N塊磁盤，使得數據總體寫入速度是一塊磁盤的N倍。讀取時也同樣，但只要有一塊損壞，數據完整性就被破壞。

             RAID1：數據在寫入磁盤時，將一份數據同時寫入兩塊磁盤，這樣任何一塊磁盤損壞都不會致使數據丟失，插入一塊新磁盤就能夠經過複製的方式自動修復，具備極高的可靠性。

             RAID10：結合RAID0和RAID1兩種方案，將全部磁盤平均分紅兩份，數據同時在兩份磁盤寫入，至關於RAID1，可是在每一份磁盤裏面的N/2塊磁盤上，利用RAID0技術併發訪問。既提升可靠性又改善性能，

                           不過RAID10磁盤複用率較低。

             RAID3：分N塊，數據寫入N-1塊，校驗數據寫入到第N塊。

             RAID5：相似RAID3但校驗數據螺旋式地寫入全部磁盤中。避免磁盤頻繁修改被寫壞。

             RAID6：數據寫入N-2塊，並螺旋式地在兩塊磁盤中寫入校驗信息。

         b. 在HDFS(Hadoop 分佈式文件系統)中，系統在整個存儲集羣的多臺服務器上進行數據併發讀寫和備份，能夠看做在服務器集羣規模上實現相似RAID的功能，所以不須要磁盤RAID。

             HDFS以塊(Block)爲單位管理文件內容，一個文件被分割成若干個Block，當應用程序寫文件時，每寫完一個Block，HDFS就將其複製到另外兩臺機器上，保證每一個Block有三個副本，及時有兩臺服務器宕機，數據

             依然能夠被訪問，至關於RAID1的數據複製功能。

             對文件進行處理計算時，經過MapReduce併發計算任務框架，能夠啓動多個計算子任務，同時讀取文件的多個Block，併發處理，至關於實現RAID0的併發訪問。

5. 網站性能對用戶而言是一種主觀感覺，性能優化的最終目的是改善用戶的體驗，是他們感受網站很快。離開這個目的，追求技術上的所謂高性能，是捨本逐末，

    沒有多大意義。而用戶體驗的快或慢，能夠經過技術手段改善，也能夠經過優化交互體驗改善。

 

萬無一失：網站的可用性架構

1. 網站可用性的度量與考覈：

    1). 網站可用性度量：網站不可用也被稱做網站故障，業界一般用多少個9來衡量網站的可用性。

    2). 網站可用性考覈：

2. 高可用的網站架構：網站高可用性架構設計的主要目的就是保證服務器硬件故障時服務依然可用、數據依然保存並可以被訪問。實現高可用性的主要手段是數據和服務的冗餘備份以及失效轉移。磁盤損壞，則從備份的磁盤讀取數據。

3. 高可用的應用：

    1). 經過負載均衡進行無狀態服務的失效轉移：對於應用服務器集羣，實現這種服務可用狀態實時監測、自動轉移失敗任務的機制是負載均衡。負載均衡服務器經過心跳監測機制判斷服務器是否可用。

    2). 應用服務器集羣的Session管理：集羣環境下，Session管理主要有如下幾種手段：

         a. Session複製：大型網站不適合

         b. Session綁定：能夠利用負載均衡在源地址Hash算法實現，負載均衡服務器老是未來源於同一IP的請求分發到同一臺服務器上。但這種方式不符合對系統高可用性的要求，由於一旦服務器宕機，Session就不存在了。不多被採用。

         c. 利用Cookie記錄Session：將Session記錄在客戶端，每次請求服務器的時候，經Session放在請求中發送給服務器，服務器處理完請求後再修改Session響應客戶端。缺點：受cookie大小限制，影響性能，若瀏覽器關閉cookie，

            沒法使用等。

         d. Session服務器：利用獨立部署的Session服務器(集羣)統一管理Session應用服務器每次讀寫Session時，都訪問Session服務器。

             這種解決方案事實上是將應用服務器的狀態分離，分爲無狀態的應用服務器和有狀態的Session服務器，而後針對這兩種服務器的不一樣特性分別設計其架構。

             對於有狀態的Session服務器，一種比較簡單的方法是利用分佈式緩存、數據庫等，在這些產品的基礎上進行包裝，使其符合Session的存儲和訪問要求。若是業務場景對Session管理有比較高的要求，好比利用Session服務集成

             單點登陸(SSO)、用戶服務等功能，則須要開發專門的Session服務管理平臺。

4. 高可用的服務：可複用的服務模塊爲業務產品提供基礎公共服務，大型網站中這些服務一般都獨立分佈式部署，被具體應用遠程調用。可複用的服務和應用同樣，也是無狀態的服務，所以可使用相似負載均衡的失效轉義策略實現

    高可用服務。除此以外，具體實踐中，還有如下幾點高可用的服務策略：

    1). 分級管理：運維上將服務器進行分級管理，核心應用和服務優先使用更好的硬件，在運維響應速度上也格外迅速。同時在服務部署上也進行必要的隔離，避免故障的連鎖反應。低優先級的服務經過啓動不一樣的線程或者部署在不一樣的

         虛擬機上，核心服務和數據甚至要部署在不一樣的地址數據中心。

    2). 超時設置：因爲服務宕機、線程死鎖等緣由，可能致使應用程序對服務端的調用失去響應，進而致使用戶請求長時間得不到響應，同時還佔用應用程序資源，不利於及時將請求轉移到正常的服務器上。

         在應用程序中設置服務調用超時時間，一旦超時，通訊框架就拋出異常，應用程序根據服務調度策略，可選擇繼續重試或者將請求轉移到提供相同服務的其餘服務器上。

    3). 異步調用：應用對服務的調用經過消息隊列等異步方式完成。固然並非全部服務調用均可以異步調用，對於獲取用戶信息這類調用，採用異步方式會延長響應時間，得不償失。對於那些必須確認服務器調用成功才能進行下一步

         的操做也不適合異步調用。

    4). 服務降級：在網站訪問高峯期，爲了保證核心應用和功能的正常運行，須要對服務進行降級。降級有兩種手段：拒絕服務及關閉服務。

         拒絕服務：拒絕低優先級應用的調用，減小服務調用併發數，確保核心應用正常使用；或者隨機拒絕部分請求調用，節省資源，讓另外一部分請求得以成功，避免要死你們一塊兒死的慘劇。

         關閉功能：關閉部分不重要的服務，或者服務內部關閉部分不重要的功能，以節省系統開銷，爲重要的服務和功能讓出資源。

    5). 冪等性設計：保證服務重複調用的和調用一次產生的結果相同，即服務具備冪等性。

5. 高可用的數據：保證數據存儲高可用的手段主要是數據備份和失效轉移機制。數據備份是保證數據有多個副本，任意副本的失效都不會致使數據的永久丟失，從而實現數據徹底的持久化。而失效轉移機制則保證當前一個數據副本不可

    訪問時，能夠快速切換訪問數據的其餘副本，保證系統可用。

    緩存服務的高可用性：擴大緩存服務器集羣規模的一個簡單手段就是整個網站共享一個分佈式緩存集羣，單獨的應用和產品再也不部署本身的緩存服務器，只須要向共享緩存集羣申請資源便可。

    1). CAP原理：CAP原理認爲，一個提供數據服務的存儲系統沒法同時知足數據一致性(Consistency)、數據可用性(Availibility)、分區耐受性(Partition Tolerance，系統具備跨網絡分區的伸縮性)這三個條件。

         高可用的數據有以下幾層含義：數據持久性，數據可訪問性，數據一致性

         大型網站中，一般會選擇強化分佈式存儲系統的可用性(A)和伸縮性(P)，而在某種程度上放棄一致性。具體來講，數據一致性有分爲以下幾點：

         數據強一致：各個副本的數據在物理存儲中老是一致的

         數據用戶一致：各個副本可能不一致，但返回給用戶的經過糾錯機制等，返回給用戶一個正確的數據。

         數據最終一致：通過一段時間之後，數據最終會達到一致

    2). 數據備份：

         冷備份：優勢是簡單和廉價，成本和技術難度都比較低。缺點是不能保證數據最終一致性。同時因爲數據落後，也不能保證數據可用性。

         熱備份：異步熱備份和同步熱備份

         a. 異步熱備份：指多份數據副本的寫入操做異步完成，即應用程序收到數據服系統的寫操做成功響應時，只寫成功一份，存儲系統會異步地寫入其餘副本。

         b. 同步熱備份：指多份數據副本的寫入操做同步完成，即應用程序收到數據服務系統寫入成功響應時，多份數據都已經寫操做成功。

    3). 失效轉移：

         a. 失效確認：兩種方式，心跳檢測和應用程序訪問失敗報告。對於應用程序的訪問失敗報告，控制中心還須要在一次發送心跳檢測進行確認。

         b. 訪問轉移：確認某臺存儲服務器宕機後，須要將數據讀寫訪問從新路由到其餘服務器上。

         c. 數據恢復：必須將副本的數目恢復到系統設定值，防止再有服務器宕機。從健康的服務器複製數據，將數據副本數目恢復到設定值。

6. 高可用網站的軟件質量保證：

    1). 網站發佈：一般經過發佈腳本來完成發佈。發佈過程當中，每次關閉的服務器都是集羣中的一小部分，並在發佈完成後當即能夠訪問，所以整個發佈過程不影響用戶使用。

    2). 自動化測試：自動化測試工具能夠一鍵完成系統部署，測試數據生成、測試執行、測試報告生成等所有測試過程 

    3). 預發佈驗證：沙箱測試，與真實線上環境儘可能保持一致。

    4). 代碼控制：

          a. 主幹開發，分支發佈：代碼修改都在主幹上進行，須要發佈的時候，從主幹拉一個分支發佈，該分支即成爲一個發佈版本，若是該版本有bug，繼續在分支上修改發佈，將修改合併(merge)回主幹，直到下次主幹發佈。

          b. 分支開發，主幹發佈：任何修改都不能在主幹上直接運行，須要開發一份新功能或者修復一個bug時，從主幹拉一份分支進行開發，開發完成且經過測試後，合併回主幹，而後從主幹進行發佈，主幹上的代碼永遠是最新

                                          發佈的版本。

          這兩種方式各有優缺點。主幹開發，分支發佈，主幹代碼反應目前整個應用的狀態，一目瞭然，便於管理和控制，也利於持續集成。分支開發，主幹發佈方式，各個分支獨立進行，互不干擾，可使不一樣發佈週期的開發

          在同一應用中進行。

    5). 自動化發佈：人干預越少，自動化程度越高，引入故障的可能性就越小，火車準點到達，你們按時下班的可能性就越大。

    6). 灰度發佈：應用發佈成功後，仍然可能會發現由於軟件問題而引入的故障，這時候就須要作發佈回滾，即卸載剛剛發佈的軟件，將上一個版本恢復。爲應對這種局面，大型網站會使用灰度發佈模式，將集羣服務器分若干部分，

          天天只發布一部分。

          灰度發佈，也經常使用於用戶測試，即在部分服務器上發佈新版本，而後監控用戶操做行爲，收集用戶體驗報告。比較用戶對兩種版本的滿意度，以肯定最終發佈的版本。這種手段稱爲AB測試。

7. 網站運行監控：不容許沒有監控的系統上線。

    1). 監控數據採集

         a. 用戶行爲日誌收集：用戶行爲日誌指用戶在瀏覽器上所作的全部操做以及所在的操做系統環境，包括：用戶操做系統與瀏覽器版本，IP地址、頁面訪問路徑、頁面停留時間等。這些數據對統計網站的PV/UV指標、分析用戶行爲、

             優化網站設計、個性化營銷與推薦等很是重要。

             用戶行爲日誌收集手段有兩種：

             a1. 服務器端日誌收集

             a2. 客戶端瀏覽器日誌收集：利用頁面嵌入JS腳本收集用戶真實的操做行爲，所以比服務器日誌收集更加準確。缺點是比較麻煩。

             此外，大型網站的用戶日誌數量驚人，數據存儲和計算壓力大，目前許多網絡逐步開發基於實時計算框架Storm的日誌統計與分析工具。

         b. 服務器性能監控：收集服務器性能指標，如系統Load、內存佔用、磁盤IO、網絡IO等儘早做出故障預警，及時判斷應用情況，防患於未然，將故障扼殺在萌芽時期很是重要。

             目前網站使用比較普遍的開源性能監控工具是Ganglia，它支持大規模服務器集羣，並支持以圖形的方式在瀏覽器展現實時性能曲線。

         c. 運行數據報告：網站還須要監控一些與具體業務場景相關的技術與業務指標，好比緩衝命中率、平均響應延遲時間、每分鐘發送郵件數目、待處理的任務總數等。

    2). 監控管理：監控數據採集後，除了用做系統性能評估、集羣規模伸縮性預測等，還能夠根據實時監控數據進行風險預警，並對服務器進行失效轉移，自動負載調整，最大化利用集羣全部機器的資源。

          a. 系統報警：監控管理系統能夠配置報警閾值和製售人員的聯繫方式，報警方式除了郵件，即時通訊工具，還能夠配置手機短信，語音報警，系統報警時，工程師即便在千里以外，夜裏睡覺也能被及時通知，迅速響應。

          b. 失效轉移：除了應用程序訪問失敗時進行失效轉移，監控系統還能夠在發現故障的狀況下主動通知應用，進行失效轉移

          c. 自動優雅降級：優雅降級是指網站爲了應付忽然爆發的訪問高峯，主動關閉部分功能，釋放部分系統資源，保證網站核心功能正常訪問的一個手段。