百度架構師高併發web架構分析

本文主題是高性能的Web架構，着重於從如何打造快速響應、應對高併發、高吞吐、讓用戶感覺到很是快的體驗的角度來進行闡述的，實際上，對於一個好的 Web 架構來講，除了高性能這個指標外，還必須兼顧高可用、可伸縮、可拓展、安全等多個方面，指望本文的介紹能給對設計高性能架構感興趣的同行學者提供必定的參考。css

高性能web架構主要保證程序的高可用性和高併發性.前端

高可用就是保證程序在99.99%的狀況下可使用,不會由於單機節點故障總體崩潰.mysql

高併發說到底也是爲了高可用服務.保證在大量併發的時候服務不會宕機.nginx

高性能web架構主要體如今如下方面web

數據庫讀寫分離,由於大部分應用都是讀多於寫,能夠配置多臺讀服務器, (目前mysql不支持多臺寫服務器,不過能夠用其餘技術解決)redis
緩存經常使用數據,把訪問量很是多的數據,緩存到分佈式緩存中. 如memcached,redis 等經常使用緩存方案算法
單獨文件服務器集羣,減小對應用服務器壓力sql
單獨圖片服務器集羣, 減小對應用服務器壓力數據庫
web服務器和應用服務器集羣分離. web 服務器併發要比應用服務器併發高不少. 緩解應用服務器壓力.後端
應用服務器集羣,作負載均衡,對話共享.應用服務器目前都支持集羣,
服務器反向代理

Web的本意是蜘蛛網和網的意思，在網頁設計中咱們稱爲網頁的意思。現普遍譯做網絡、互聯網等技術領域。它的表現形式能夠是經過瀏覽器訪問的網站、內嵌H五、或者後端提供的RESTful API等，本文指的Web泛指經過Web技術提供的互聯網服務，不只限於網站。關於架構，百科上的定義是「是有關軟件總體結構與組件的抽象描述，用於指導大型軟件系統各個方面的設計」。本文將重新的的角度、以及如何利用新技術等分析和闡述如何打造高性能的 Web 架構。

網絡

Web運行原理

Web 前端瀏覽器運行機制：

Web 後端服務架構運行機制：

經過以上兩張圖能夠清晰看出無論是在 Web 前端架構運行機制仍是 Web 後端架構中，網絡已經成了必不可少且很是重要的地位。用戶經過網絡訪問 Web 服務器，Web 後端架構中各類服務之間經過網絡來進行通訊和協做，網絡是現代 Web 應用的基石，所以在談到高性能架構時候不得不從網絡談起。

協議對性能的影響

TCP

TCP（Transmission Control Protocol 傳輸控制協議）是一種面向鏈接的、可靠的、基於字節流的傳輸層通訊協議，由IETF的RFC 793定義。在簡化的計算機網絡OSI模型中，它完成第四層傳輸層所指定的功能，用戶數據報協議（UDP）是同一層內，另外一個重要的傳輸協議。在因特網協議族（Internet protocol suite）中，TCP層是位於IP層之上，應用層之下的中間層。不一樣主機的應用層之間常常須要可靠的、像管道同樣的鏈接，可是IP層不提供這樣的流機制，而是提供不可靠的包交換。

下面簡要介紹幾個機制：

三次握手：TCP是因特網中的傳輸層協議，使用三次握手協議創建鏈接。當主動方發出SYN鏈接請求後，等待對方回答SYN+ACK，並最終對對方的 SYN 執行 ACK 確認。這種創建鏈接的方法能夠防止產生錯誤的鏈接。

簡單的說就是創建TCP的網絡鏈接自己至少須要3個來回（在正式發送數據以前），若是單程須要30ms，創建鏈接操做就須要 90ms（毫秒）。

慢啓動：在鏈接創建後，這時咱們開始傳輸數據，但這裏存在一個問題，咱們傳送多少數據合適的問題，若是傳的太多了，對方可能沒法處理（入網帶寬太小、或者計算機正在幹別的操做被佔用等），若是多對方沒法處理的數據給整個互聯網實際上是佔用沒必要要的堵塞和佔用，TCP爲了解決問題有一個機制叫慢熱啓動。慢啓動的意思是，剛剛開始傳輸數據的時候，一點一點地提速，不要一上來就像那些特權車同樣霸道地把路佔滿。這麼說仍是不太直觀，下面舉個例子：服務器的出口帶寬是100MB，用戶的入網帶寬是20MB，按照以上數據來講，用戶能夠接受的最大下載數據量是 2.5MB/S，可是爲了整個網絡社會的和諧，初始的時候的時候服務器和用戶都不會以 2.5MB/S 以起始像對方傳輸數據，而是以1460字節開始（MSS），而且隨着對方的ACK迴應包這個能夠傳輸的數量乘以指數增加，直到達到最高數（ssthresh）；若是發生丟包，這個傳輸量將會以指數級降低；若是網絡被閒置，哪怕剛纔已經達到了最高的 2.5MB/S速度，將又會從最小值開始試探性傳輸數據（實際機制比這個更復雜涉及各類狀況判斷變換算法）。
擁塞窗口：TCP擁塞控制中的一個概念：擁塞窗口是衛星通訊在因特網中防止通訊擁塞的一種措施，它是在發端採用了一種「擁塞避免」算法和「慢速啓動」算法相結合的機制。「擁塞窗口」就是「擁塞避免」的窗口，它是一個裝在發送端的可滑動窗口，窗口的大小是不超過收端確認通知的窗口。「慢速啓動」是在鏈接創建後，每收到一個來自收端的確認，就控制窗口增長一個段值大小，當窗口值達到「慢速啓動」的限值後，慢速啓動便中止工做，避免了網絡發生擁塞
丟包重傳：TCP爲了保證不發生丟包，就給每一個包一個序號，同時序號也保證了傳送到接收端實體的包的按序接收。而後接收端實體對已成功收到的包發回一個相應的確認（ACK）；若是發送端實體在合理的往返時延（RTT）內未收到確認，那麼對應的數據包就被假設爲已丟失將會被進行重傳。這裏說的是對於任何一個發送的數據包，對方都須要迴應一個確認包，表示數據收到了，也就是哪怕正常網絡狀況下，每一次數據包發送都意味至少的兩次網絡數據交換。這是一個很好從機制，可是隻要發現丟包就會致使重傳，那麼若是用戶離你比較遠或者訪問你的網絡服務中間任意節點不穩定的話，那將會致使頻繁的從新重複發送同一份數據，所以網絡質量越差越不穩定，你響應用戶的時間就越長，由於大部分時間可能耗費在重複給用戶發送數據上。

HTTP

無論是服務器之間近距離傳輸通訊，仍是用戶請求網頁若是使用 TCP 協議都要受以上流程和機制影響。TCP就在OSI模型的第四層傳輸層，HTTP運行在第七層應用層，因爲分層是單向依賴的，因此HTTP必然依賴於TCP協議來運行，全部 TCP 有的問題一樣 HTTP 所有都會繼承。同時HTTP在此基礎上也有本身的協議規則，好比說瀏覽器最大和服務器創建的鏈接數： HTTP協議也有很是多的規則，其中不一樣的瀏覽器實現也並不是徹底同樣，在不一樣的HTTP版本下，也有實現上的差異，下圖就是每一個瀏覽器對應的能夠同時發起請求的個數，意味着若是能同時請求的文件數，通常網頁平均有90個文件，若是每次只能請求2~6個文件，那效率確定不會很高。

在某些瀏覽器以及不一樣的HTTP版本下，HTTP鏈接機制也不同，好比HTTP 1.0 下，每次傳輸完一個文件後，這個HTTP請求（TCP）鏈接將關閉，須要從新發起（TCP三次握手）創建鏈接才能繼續請求下一個文件，若是網絡單程通訊須要30ms創建一個鏈接須要90秒，關閉TCP還須要四次握手，同一個網站有90個文件須要重複這個步驟，那總共須要多少時間？能夠看出這個嚴重影響了整個網頁的加載速度。

距離對性能的影響

世界上最快的速度就是光速，光纜傳輸的速度首先確定不會超過光速，光在光纜中經過光纖傳輸確定會有損耗，最後在這個傳輸的過程當中傳輸介質不只僅是光纖，還包括了骨幹網到ISP（電信運營商）、到用戶家的普通網線、銅線、路由器、交換機等都有不一樣程度上的損耗。簡單的舉個例子：

光的速度是每秒能夠達到299792458米（30萬千米），對於通常的光纖來講，大部分從1.4~1.6不等，這個值越大，光在該介質中的傳播速度就越慢。

哈爾濱到拉薩兩地直線距離大概4100千米，假設數據經過光纖的速度爲每秒200000000，取的折射率（損耗）是是1.5。兩地之間純光纖傳輸單程須要 21ms（毫秒），從光纖接入ISP（電信運營商）再到家又會損耗 9ms（毫秒），21 + （9 * 2） = 39 ms，單程傳輸理論上就須要 39 毫秒，若是3次握手乘以 3 就是須要 156 ms 毫秒，也就是兩地用戶之間在進行正式數據傳輸以前就須要156 毫秒了。

若是單個包超過了TCP最大能傳輸的單元（MTU）大小（1460字節）還可能會拆成多個來傳輸，據統計一個網站平均有90個文件請求（網頁、圖片、css、js 等），那最終用戶請求獲取完一個網頁須要多少時間？

如何優化

TCP優化

服務器系統

在着手優化以前，首先要作的就是把服務器的操做系統升級到最新版本。TCP的最佳實踐以及影響及其性能一直在與時俱進，而大多數優化都只在最新的內核中才實現。有可能你的服務器系統選型很早就已經肯定了，也可能由於運維人員的我的喜愛，無論出於什麼緣由以致於古老的系統由於各類緣由一直沿用至今，可是實事求是的講，讓你的服務器跟的上這個時代是全部優化的首要措施（不只僅只是硬件層面）。

服務器配置調優

增大TCP的初始擁塞窗口：可讓第一次往返就傳輸較多數據，而隨後的提速也會很明顯。
慢啓動重啓：禁用慢啓動重啓能夠保證鏈接在閒置時從新傳輸數據能夠仍然保持瞬間發送大量數據的能力。
窗口縮放：啓用窗口縮放能夠增大最大接收窗口的大小，可讓高延遲的鏈接達到更高的吞吐量。
TCP快速打開（Fast Open）：若是你能夠控制服務端能夠客戶端，能夠嘗試這個選項，它可讓TCP在第一個SYN分組中就傳輸數據。

以上幾個建議能夠再加上最新的服務器內核，能夠確保TCP的最佳性能（每一個TCP鏈接都具備較低的延遲和較高的吞吐量），這個影響不只僅是用戶請求網頁，包括你服務器架構中衆多的服務，負載均衡、分佈式、集羣、訪問數據庫、隊列等等全部須要網絡通訊的應用性能和效率，具體的參數配置及設置因爲篇幅請自行百度。

客戶端優化

重用TCP鏈接相當重要，頻繁的三次握手是對性能極大的浪費
不能讓數據傳輸的更快，可讓數據傳輸的更短
壓縮數據，減小沒必要要的比特傳輸
再快也快不不過什麼也不用發，能少發就少發
消除沒必要要的鏈接和數據傳輸自己就是很大的優化，優化好TCP是全部應用高性能的前提和基礎。

HTTP優化

幸運的是現代的瀏覽器愈來愈高效智能（相對IE時代），瀏覽器自己已經作了不少優化，單個域名下進行同時鏈接請求的併發數已經拓展到4~6個，同時若是覺的不夠還能夠設置多個域名；並且瀏覽器還會根據你的地址欄輸入、訪問記錄，訪問意向，鼠標懸停等方式對你要訪問的網頁進行預先DNS解析，預先創建鏈接，分優先級加載（優先加載網頁、css、js）等方式對總體的訪問速度和訪問體驗進行了優化，速度較比以前已經有了很大程度的提高，這也是爲何Chrome能夠作到比IE快那麼的緣由。

瀏覽器

減小DNS查找：每一次主機名解析都須要一次網絡往返，從而增長請求的延遲時間，同時還會阻塞後續請求。
重用TCP鏈接：儘量使用持久鏈接，以消除 TCP 握手和慢啓動延遲（Keep-Alive
減小HTTP重定向：HTTP 重定向極費時間，特別是不一樣域名之間的重定向，更加費時；這裏面既有額外的 DNS 查詢、 * TCP握手，還有其餘延遲。最佳的重定向次數爲零。
HTTPS優化：啓用TLS的會話緩存和無狀態恢復及共享（能夠減小HTTPS後續驗證時間）
去掉沒必要要的資源：任何請求都不如沒有請求快。
在客戶端緩存資源：應該緩存應用資源，從而避免每次請求都發送相同的內容。瀏覽器提供了 Cache-Control，Last-Modified 和 ETag 首部提供驗證機制，可讓不常常變動的內容直接從本地獲取避免重複訪問服務器拉取一樣的資源，要說最快的網絡請求，那就是不用發送請求就能獲取資源。
傳輸壓縮過的內容：傳輸前應該壓縮應用資源，把要傳輸的字節減至最少：確保對每種要傳輸的資源採用最好的壓縮手段。圖片通常會佔到一個網頁須要傳輸的總字節數的一半，HTML、 CSS 和 JavaScript 等文本資源的大小通過 gzip 壓縮平都可以減小 60%~80。
打包資源減小HTTP請求：拼接資源如圖片精靈技術，合併CSS，JS等文件以減小HTTP請求。
合理設置資源域名：HTTP 規定爲了防止客戶端同時發起的請求過多給服務器形成自我DDOS，客戶端對於單個域名一次最多不可發起超過6個並行請求，所以頁面中同域名下資源太多，會形成等待6個資源的返而以防形成請求阻塞，能夠用多個域名來突破並行請求數量。

距離優化

應用服務器

若是有條件，咱們能夠把應用服務器儘可能部署到靠近用戶的位置，沒辦法改變最大傳輸速度，能夠縮短了兩地之間的距離，天然也就縮短所需花費的時間。

CDN（Content Delivery Network）

對於靜態資源（不須要常常改變的資源，如圖片、文件、網頁模板等）咱們能夠把它放到CDN上，讓用戶能夠以最短的距離訪問咱們資源的路勁最短。

代理服務器

若是核心服務器無法部署到靠近用戶近的地方，能夠嘗試用代理服務器，用戶鏈接較近的服務器，由代理服務器經過專線、或者保持長鏈接的形式進行最終的服務訪問。

最遠的距離

若是機房連的是某個運營商的網絡，用戶是另外一個運營商的網絡，那麼最終這中間也將形成極大的訪問延遲，有條件機房應該部署的雙線，不然可能會形成「世界上最遠的距離不是天涯海角，而是你在電信，我在網通」。

Apple 曾經在 WWDC 上分享了一個對網絡鏈接優化的取得巨大成功的案例，蘋果工程師經過使用HTTP的持久鏈接和管道、重用iTunes中既有的鏈接，使得低網速用戶的性能提高了原來的3倍。很明顯，理解而且優化好網絡層回報是巨大的。

瀏覽器

一個網頁的加載速度不只僅取決於資源的獲取，就算資源已經達到用戶的瀏覽器，達到徹底解析而且並加載完成還須要佈局和渲染和相關腳本的執行，所以最後部分是否也能保持高性能對用戶的總體體驗來講依然相當重要。用戶對於性能的感知調查數據：

這個表格解釋了Web性能社區總結的經驗：必須在250ms內渲染頁面，或者至少提供視覺反饋（告知、loading、進度條等），才能保證用戶不走開。

從以上數據能夠看出無論你的服務器實際運行的多快，若是想讓用戶感受很快，就必須在幾百毫秒內相應用戶操做。超過1s，用戶的預期流程就會中斷，心思就會向其餘任務轉移，有數據代表7秒是用戶能夠忍受的平均極限，若是7秒沒有響應大部分都會離開，10秒以上除非你有明確的反饋，不然用戶基本上都會終止掉任務。通常說 Web 前端一般指的是網站業務邏輯以前的部分，影響前端的影響主要分爲三部分。

在此我向你們推薦一個架構學習交流羣。交流學習羣號： 744642380，裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化、分佈式架構等這些成爲架構師必備的知識體系。還能領取免費的學習資源，目前受益良

取得資源

上一部分的內容其實已經包含了大部分瀏覽器獲取內容大部分知識，這張咱們談一個也被人們忽視的新技術。

新協議

HTTP 協議簡單的本質讓它得以日新月異的發展，它的應用如今已經不只僅在於Web瀏覽器方面，不少嵌入式設備如傳感器、智能設備，設置咖啡壺都在用HTTP做爲主要的控制和數據交換協議。可是因爲本來的特性如純文本協議傳輸、請求到響應的簡單模式等已經沒法知足於現代的近似實時響應速度的要求，爲了應對這些挑戰，2012年HTTP2.0的開發被提上日程，它本來是Google內部一個實驗性的項目，因其極大的提高了Web的性能，所以被W3C做爲 2.0 的基礎，現已獲得Chrome，Opera，Firefox等的支持，最大的改進：

多路複用
採用了數據格式化數據（頭部和內容進行分離和壓縮）
利用二進制數據分幀來傳輸數據（請求和響應）
能夠設置請求優先級
服務器主動推送
而且支持向下兼容

技術成熟度

HTTP 2.0標準於2015年5月以RFC 7540正式發佈，Google Chrome、Mozilla Firefox、Microsoft Edge和Opera已支持HTTP 2.0，並默認啓用。Internet Explorer自IE 11開始支持HTTP 2.0，目前谷歌、Facebook、Twitter 等服務器已經採用2.0協議。

2016年4月26日 nginx-1.10.0 stable 也已經提供了對 HTTP 2.0的支持，理論上不須要對程序進行優化，僅僅更換 HTTP 2.0，就能夠有效的提高50%以上的性能。

頁面佈局和渲染

隨着互聯網過去幾十年的發展過程當中，僅僅從超文本這個角度來看理解Web內容，已經不適用了，隨着富媒體以及最近幾年的H5的盛行，Web愈來愈像是是個應用程序，而不能單純當作是個網頁，可是影響瀏覽器最終加載完成呈現給用戶的因素大致上能夠分爲如下幾部分：

DOM：頁面的內容最終在瀏覽器裏解析後以DOM（Document Object Model）的形式來承載，也就是頁面的實際內容，包括的了頁面結構、文字、富媒體等。
CSSOM：頁面的的表現形式CSSOM（CSS Object Model）的形式承載，也就是所謂的樣式數據，關於數據應該怎麼顯示。
渲染樹：隨着DOM（頁面有哪些內容）和CSSOM（頁面應該怎樣呈現）所有解析完成之後，瀏覽器將會基於兩者建立渲染樹，以後瀏覽器就有足夠的數據去佈局、繪製呈現內容給用戶。

執行（Javascript）

在現代瀏覽器中JS是必不可少的，它決定了頁面的業務邏輯、交互以及行爲。可是在業務呈現完成以前，它倒是個很大的禍害，腳本在解析執行的過程當中，只要遇到同步的document.write將會阻塞DOM的解析和構建，一樣，JS也會查詢任何對象的計算樣式、從而也成功的阻塞了CSS的處理，結果，DOM以及CSSOM的構建將頻繁的交織在一塊兒，DOM構建在JS執行完畢以前沒法進行，而JS在CSSOM構建完成前也沒法進行，所以若是不能處理好JS，將會嚴重的影響到頁面的性能。

高性能JavaScript

1、使用事件代理

　　當過多的時間句柄被頻繁觸發時，頁面反應會遲鈍。

　　如一個div有10個按鈕，只需給div附加一次事件句柄，而沒必要給每一個按鈕添加一個句柄。

　　　　事件冒泡時刻捕捉到事件並判斷時那個事件發出的。【觸發事件的元素 = ev.srcElement ? ev.srcElement : ev.target;】

2、緩存選擇器查詢結果

　　減小選擇器查詢的次數，並儘量緩存選中的結果，便於之後的重用。

後端服務架構

高性能架構確定不只僅指的是響應速度，還包括了能處理高的併發量，有高的吞吐量，一個好的高性能架構設計少不了理論的支撐，也少不了具體的套路，本部分將從兩個方面展開。

理論

在解決高併發、海量數據處理、高可靠性等一系列問題和挑戰的過程當中，大型的互聯網公司有不少被驗證行之有效的解決方案，這些解決方案被更多的網站重複驗證，造成了一套可靠的理論指導，在正確的理論基礎上去打造高性能架構能夠避免少走不少彎路。

（1）緩存

緩存就是將數據存放在距離計算最近的位置以加快處理速度。緩存是改善軟件性能的第一手段，現代CPU愈來愈快的一個重要因素就是使用了更多的緩存，在複雜的軟件設計中，緩存幾乎無處不在。無論是在系統、軟件仍是網絡在遇到性能瓶頸的時候一般緩存是很是有效的解決方案。

（2）異步

異步對應的是同步處理，簡單的說異步就是發起計算任務後不須要也不能調用者馬上獲得結果，處理這個調用的部件在完成後，經過狀態、通知和回調來通知調用者。若是是你要進行的操做很是耗時，通常咱們選擇先返回通知用戶，複雜的業務邏輯在後臺繼續執行，不需用戶等待。列如用戶註冊後可能涉及到開通帳號、發送短信或者郵件、開通相關空間或者權限，實際上發短信或者發郵件等可能比較耗時操做也可能會引起失敗，咱們能夠註冊帳號步驟完成後直接通知用戶，後續的一系列操做後臺經過隊列等方式異步去執行，失敗能夠後臺自動重試，用戶已經能夠利用帳號和密碼登錄。使用異步能有效的提升網站響應速度、提升系統可用性、提高總體的用戶體驗。

（3）分層（水平劃分）

分層架構是將系統分紅若干個水平層，每一層都有清晰的角色和分工，不須要知道其餘層的細節，下層對上層屏蔽掉複雜的邏輯細節，層與層之間經過簡單接口的通訊，只要提供的接口不變，各層能夠根據本身的須要進行各類升級改造而不影響其餘層。分層架構是最多見的軟件架構，也是事實上的標準架構。若是你不知道要用什麼架構，那就用它。雖然沒有明確約定，軟件必定要分紅多少層，可是四層的結構最多見。

表現層（presentation）：用戶界面，負責視覺和用戶互動
業務層（business）：實現業務邏輯
持久層（persistence）：提供數據，SQL 語句就放在這一層
數據庫（database）：保存數據

經過分層對業務的橫向切割，能夠更好的將一個龐大複雜的軟件系統劃分層不一樣的部分，同時也便於合做開發和維護。分層還有一個特色，依賴關係都是從上往下，上層的服務依賴下層，下層的服務不會依賴上層，讓依賴關係更加簡單。典型經典的案列就是互聯網的基礎體系結構OSI參考模型。

（4）分割（垂直劃分）

網站越大，功能越複雜，服務和數據處理的種類也越多，將這些不一樣的功能和服務分割開來，包裝成高內聚低耦合的模塊單元。一方面有助於軟件的開發和維護，另外一方面，便於不一樣模塊的分佈式部署，提升網站的併發處理能力和功能擴展能力大型Web應用程序分割的粒度可能會很小。好比在應用層，將不一樣業務進行分割，例如將購物、論壇、搜索、廣告分割成不一樣的應用，由獨立的團隊負責，部署在不一樣的服務器上；在同一個應用內部，若是規模龐大業務複雜，會繼續進行分割，好比購物業務，能夠進一步分割成機票酒店業務、3C業務，小商品業務等更細小的粒度。而即便在這個粒度上，仍是能夠繼續分割成首頁、搜索列表、商品詳情等模塊，這些模塊無論在邏輯上仍是物理部署上，均可以是獨立的。一樣在服務層也能夠根據須要將服務分割成合適的模塊。

（5）分佈式

百科的定義是「分佈式處理則是將不一樣地點的，或具備不一樣功能的，或擁有不一樣數據的多臺計算機經過通訊網絡鏈接起來，在控制系統的統一管理控制下，協調地完成大規模信息處理任務的計算機系統。」

簡單的說分佈式就是將不一樣模塊部署在不一樣的服務器上，經過遠程調用協同工做。分層和分割的一個主要目的是爲了切分後的模塊便於分佈式部署。分佈式意味着可使用更多的計算機完成一樣的功能，計算機越多，CPU、內存、存儲資源也就越多，可以處理的併發訪問和數據量就越大，進而可以爲更多的用戶提供服務。

但分佈式在解決網站高併發問題的同時也帶來了其餘問題。首先，分佈式意味着服務調用必須經過網絡，這可能會對性能形成比較嚴重的影響；其次，服務器越多，服務器宕機的機率也就越大，一臺服務器宕機形成的服務不可用可能會致使不少應用不可訪問，使網站可用性下降；另外，數據在分佈式的環境中保持數據一致性也很是困難，分佈式事務也難以保證，這對網站業務正確性和業務流程有可能形成很大影響；分佈式還致使網站依賴錯綜複雜，開發管理維護困難。所以分佈式設計要根據具體狀況量力而行，切莫爲了分佈式而分佈式。

（6）集羣

分佈式是將不一樣的功能模塊部署到多臺計算機上，而集羣簡單的說是指將部署着一樣功能組件的計算機集中起來提供服務。由於服務器集羣有更多服務器提供相同服務，所以能夠提供更好的併發特性，當有更多用戶訪問的時候，只須要向集羣中加入新的機器便可。同時由於一個應用由多臺服務器提供，當某臺服務器發生故障時，負載均衡設備或者系統的失效轉移機制會將請求轉發到集羣中其餘服務器上，使服務器故障不影響用戶使用。因此在網站應用中，即便是訪問量很小的分佈式應用和服務，也至少要部署兩臺服務器構成一個小的集羣，目的就是提升系統的可用性。

（7）冗餘

網站須要7 24小時連續運行，可是服務器隨時可能出現故障，特別是服務器規模比較大時，出現某臺服務器宕機是必然事件。要想保證在服務器宕機的狀況下網站依然能夠繼續服務，不丟失數據，就須要必定程度的服務器冗餘運行，數據冗餘備份，這樣當某臺服務器宕機時，能夠將其上的服務和數據訪問轉移到其餘機器上。

（8）自動化

在無人值守的狀況下網站能夠正常運行，一切均可以自動化是網站的理想狀態。目前大型網站的自動化架構設計主要集中在發佈運維方面。

網站在運行過程當中可能會遇到各類問題：服務器宕機、程序Bug、存儲空間不足、忽然爆發的訪問高峯。網站須要對線上生產環境進行自動化監控，對服務器進行心跳檢測，並監控其各項性能指標和應用程序的關鍵數據指標。若是發現異常、超出預設的閾值，就進行自動化報警，向相關人員發送報警信息，警告故障可能會發生。在檢測到故障發生後，系統會進行自動化失效轉移，將失效的服務器從集羣中隔離出去，再也不處理系統中的應用請求。待故障消除後，系統進行自動化失效恢復，從新啓動服務，同步數據保證數據的一致性。在網站遇到訪問高峯，超出網站最大處理能力時，爲了保證整個網站的安全可用，還會進行自動化降級，經過拒絕部分請求及關閉部分不重要的服務將系統負載降至一個安全的水平，必要時，還須要自動化分配資源，將空閒資源分配給重要的服務，擴大其部署規模。經過減小人爲干預，使自動化可有效減小故障。

實踐

正確使用架構方案能夠更好地利用業界和前人的思想與實踐，用更少的時間開發出更好的系統，使設計者的水平也達到更高的境界，使用者應該對本身的遇到的問題深入分析後，再採起相應的解決方案，不恰當地使用模式只會畫虎不成反類犬，不但沒有解決原來的老問題，反而帶來了更棘手的新問題，好的架構設計須要創建在對問題深入理解之上的創造與創新。

應用服務器性能優化

用服務器是處理網站業務的服務器，網站的業務代碼都部署在這裏，是網站開發最複雜，變化最多的地方，對於性能問題優化手段主要有緩存、集羣、異步等。

（1）緩存

網站性能優化第必定律：優先考慮使用緩存優化性能。當網站遇到性能瓶頸時，第一個想到的解決方案就是使用緩存。在整個網站應用中，緩存幾乎無所不在，既存在於瀏覽器，也存在於應用服務器和數據庫服務器；既能夠對數據緩存，也能夠對文件緩存，還能夠對頁面片斷緩存。合理使用緩存，對網站性能優化意義重大。

（2）異步

使用消息隊列將調用異步化，可改善網站系統的性能。事實上，使用消息隊列還可讓系統耦合性更低同時更加具備擴展性，在不使用消息隊列的狀況下，用戶的請求數據直接寫入數據庫，在高併發的狀況下，會對數據庫形成巨大的壓力，同時也使得響應延遲加重。在使用消息隊列後，用戶請求的數據發送給消息隊列後當即返回，再由消息隊列的消費者進程（一般狀況下，該進程一般獨立部署在專門的服務器集羣上）從消息隊列中獲取數據，異步寫入數據庫。因爲消息隊列服務器處理速度遠快於數據庫（消息隊列服務器也比數據庫具備更好的伸縮性），所以用戶的響應延遲可獲得有效改善。消息隊列具備很好的削峯做用即經過異步處理，將短期高併發產生的事務消息存儲在消息隊列中，從而削平高峯期的併發事務。在電子商務網站促銷活動中，合理使用消息隊列，可有效抵禦促銷活動剛開始大量涌入的訂單對系統形成的衝擊。

（3）集羣

在網站高併發訪問的場景下，使用負載均衡技術爲一個應用構建一個由多臺服務器組成的服務器集羣，將併發訪問請求分發到多臺服務器上處理，避免單一服務器因負載壓力過大而響應緩慢，使用戶請求具備更好的響應延遲特性。

存儲性能優化

在Web應用中，除了大量的業務邏輯須要CPU處理之外，另外一個很大的性能問題是海量的數據讀寫對磁盤訪問形成巨大壓力，雖然能夠經過Cache解決一部分數據讀壓力，可是不少時候，磁盤仍然是系統最嚴重的瓶頸。並且磁盤中存儲的數據是網站最重要的資產，磁盤的可用性和容錯性也相當重要。

（1）機械硬盤/固態硬盤

機械硬盤是目前最經常使用的一種硬盤，經過馬達驅動磁頭臂，帶動磁頭到指定的磁盤位置訪問數據，因爲每次訪問數據都須要移動磁頭臂，所以機械硬盤在數據連續訪問（要訪問的數據存儲在連續的磁盤空間上）和隨機訪問（要訪問的數據存儲在不連續的磁盤空間）時，因爲移動磁頭臂的次數相差巨大，性能表現差異也很是大。在網站應用中，大部分應用訪問數據都是隨機的，這種狀況下SSD具備更好的性能表現。固態硬盤又稱做SSD或Flash硬盤，這種硬盤沒有機械裝置，數據存儲在可持久記憶的硅晶體上，所以能夠像內存同樣快速隨機訪問。並且SSD具備更小的功耗和更少的磁盤震動與噪聲，若是你的業務對磁盤讀寫速度有很高的要求能夠嘗試換SSD盤。

（2）RAID/HDFS

一般在服務器中咱們常用 RAID（廉價磁盤冗餘陣列）技術主要是爲了改善磁盤的訪問延遲，加強磁盤的可用性和容錯能力。目前服務器級別的計算機都支持插入多塊磁盤（8塊或者更多），經過使用RAID技術，實現數據在多塊磁盤上的併發讀寫和數據備份。RAID技術能夠經過硬件實現，好比專用的RAID卡或者主板直接支持，也能夠經過軟件實現。RAID技術在傳統關係數據庫及文件系統中應用比較普遍，可是在大型網站比較喜歡使用的NoSQL，以及分佈式文件系統中，RAID技術卻遭到冷落。例如在HDFS中，系統在整個存儲集羣的多臺服務器上進行數據併發讀寫和備份，能夠看做在服務器集羣規模上實現了相似RAID的功能，所以不須要磁盤RAID。HDFS 是一個高度容錯性的文件系統，適合部署在廉價的機器上，HDFS能提供高吞吐量的數據訪問，很是適合大規模數據集上的應用。

結論

第一部分咱們從對整個系統性能影響重大的因素網絡，用戶訪問Web服務離不開網絡，咱們把內容傳遞到用戶設備上也離不開網絡，服務器之間內部通訊更是徹底依賴網絡，所以網絡的性能直接關係到整個產品的性能，而在現實中咱們常常低估了它的重要性，TCP等傳輸協議和網絡傳輸的距離和介質是對網絡性能的最主要的影響因素。第二部分咱們討論了對用戶感知最爲明顯的瀏覽器部分，用戶的瀏覽器什麼時候獲取完內容，渲染和部署內容、以及最後的執行都會用戶最終能感覺到的性能息息相關。最後討論了打造高性能架構的基石後端服務架構，能夠看出來打造高性能Web應用有賴於大量的技術的，咱們的產品的總體性能是全部這些組成部分性能的表現之和。

網站性能對最終用戶而言是一種主觀感覺，性能優化的最終目的就是改善用戶的體驗，使他們感受網站很快。離開這個目的，追求技術上的所謂高性能，是捨本逐末，沒有多大意義。而用戶體驗的快或是慢，能夠經過技術手段改善，也能夠經過優化交互體驗改善。

即便在技術層面，性能優化也須要全面考慮，綜合權衡：性能提高一倍，但服務器數量也須要增長一倍；或者響應時間縮短，同時數據一致性也降低，這樣的優化是否能夠接受？這類問題的答案不是技術團隊能回答的。歸根結底，技術是爲業務服務的，技術選型和架構決策依賴業務規劃乃至企業戰略規劃，離開業務發展的支撐和驅動，技術走不遠，甚至還會迷路。固然也沒有任何一個網站從出生第一天具有了超級高的訪問量，網站的性能問題都是在成長的過程的逐步暴露出來的，不一樣的階段會面臨對應的問題，分析本身的產品和業務特徵、如今具體面臨的問題、因未來須要面臨的挑戰，而後應用合理方式去設計架構，正確使用理論能夠更好地利用業界和前人的思想與實踐，用更少的時間開發出更好的系統，使設計者的水平也達到更高的境界。可是每種理論模式受其適用場景限制，對系統的要求和約束也不少，不恰當地使用模式只會畫虎不成反類犬，不但沒有解決原來的老問題，反而帶來了更棘手的新問題，好的架構設計絕對不是模仿，不是生搬硬套某個模式，必定是對問題深入理解之上的創造與創新。