如何構建高擴展性網站？

本篇經過閱讀《高擴展性網站的50條原則》，總結出如下內容。

一方面博主沒有實際的架構經驗，另外一方面知識面也不夠寬闊，因此只能系統的總結書中的要點，並根據本身的理解作些概括。

主要內容

　　本書從多個方面圍繞高擴展性提出了50條建議，一個高擴展性的網站會隨着業務的發展、用戶的增長，自由的擴展架構，從而輕鬆的應付網站的快速發展。下面看看本書的具體內容：

化簡方程

　　1 不要過分的設計

　　過分的設計至關於給系統增長了複雜度與維護的成本。而這些過分的設計，在正常的使用中，卻沒有太大的做用。每每是設計者本身認爲很重要或者錦上添花的功能，實際用處不大。

　　2 設計時考慮到擴展性

　　在設計時要遵循一下的設計原則：設計時考慮20倍的容量，實現時考慮3倍的容量，部署時考慮1.5的容量。一面項目擴大時，臨時擴展形成的困難。

　　3 把方案一簡再簡

　　應該遵循帕累托法則，20%的設計作了80%的工做，因此80%的時間，都應該放在這20%的設計上。

　　一個產品主要的功能其實都集中在幾個點上，把這幾個點設計好了，其餘的都是些附加的功能而已。因此這核心的業務必定要保證足夠的簡潔易用。

　　4 減小DNS查詢

　　每一個不一樣的域下的文件，加載時都須要查詢DNS。好比cnblogs.com與i.cnblogs.com就屬於不一樣的域。那麼在查詢DNS的時候，就會查詢兩次。當業務量很大時，就會形成必定的影響。

　　5 儘量減小對象

　　因爲對象在瀏覽器訪問時，須要加載。因此能夠考慮減小請求文件的數量（數量與瀏覽器併發加載數有關），把一些對象儘可能的合併。好比圖標類的文件，能夠合併成一個大的圖片。合理的文件數量，會加速瀏覽器的訪問加載。

　　6 使用同一品牌的網絡設備

　　因爲一個http請求，可能經過不少物理設備。好比負載均衡器，交換機，路由器。因此儘可能使用同一品牌的設備，會避免一些意外的狀況。

分佈工做

　　7 X軸，橫向複製

　　這種事最簡單的服務擴充，經過克隆或者複製實現，好比你的應用放在多個服務器上進行服務。常見的好比集羣，負載均衡等等，數據庫的讀寫分離。

　　8 Y軸，拆分不一樣的東西

　　大型系統中，拆分不一樣的功能，好比註冊、購買、查詢、雲盤。等等

　　9 Z軸，拆分不一樣的類似的東西

　　好比按照用戶的級別，或者用戶的地理位置等等拆分。

橫向擴展設計

　　10 設計橫向的擴展方案

　　擴展包括橫向、縱向。橫向就是經過複製克隆應用，利用小型機集羣擴展。縱向就是提升服務器的硬件以及網絡設施。

　　經過不少的案例均可以發現，單純的升級硬件實現的縱向擴展，僅僅能解決一點點現實壓力。而經過橫向的集羣擴展，卻可以自由的實現伸縮。

　　11 採用經濟型系統

　　與上面的原則相似，採用高價格的服務器，並不能保證往後的良好性能。應該使用普通的小型機集羣擴展。

　　12 橫向擴展數據中心

　　數據中心有不少的設計方案，好比

　　熱冷站配置：使用熱站提供服務，當熱站崩潰時，使用冷站繼續服務。

　　推薦使用多個實時站點，成本更低，動態調用。缺點是增長了運維的難度。

　　13 利用雲技術進行設計

　　雲計算的有點就是虛擬化，能夠在業務峯值時，彈性的擴充設備。而且在平常處理用，歸還該擴展。

　　缺點是提升了應用於虛擬環境的耦合。後面提到利用物理設備，隔離業務，在虛擬化的雲計算中，可能會對業務隔離錯誤排查形成必定的干擾。

使用正確的工具

　　14 合理使用數據庫

　　目前有許多的數據庫版本，好比傳統的關係型數據庫Oracle、MySQl，還有比較新的非關係型數據庫NoSql，好比MongoDB，以及內存數據庫FastDB，還有專門針對SSD固態硬盤的Aerospike等等。

　　可是到了選型的時候，仍是要一句我的的業務需求來定。看你的數據庫要求的是速度，仍是安全性等等。

　　15 防火牆，處處都是防火牆

　　防火牆能夠對一些無效的訪問進行攔截過濾。一般把一些CSS，靜態文件，圖片，JS等不採用防火牆，而關鍵的業務涉及到我的信息時採用。合理的設計防火牆，也會對網站的性能產生必定的影響。

　　16 積極的利用日誌文件

　　利用各類日誌以及工具，實時的監控業務。不只僅是監控服務器的內存CPU，還應該監控業務上的數據。好比splunk（提供日誌的蒐集，存儲，搜索，圖形化展現）。

不要作重複的工做

　　17 不要當即檢查剛作過的工做

　　好比剛剛寫如了數據，不要當即讀取。雖然有些客戶須要保證數據的完整，不能丟失。可是能夠經過日誌等記錄，寫完查這種作法，仍是不推薦。

　　18 中止重定向

　　重定向會消耗必定的延遲，計算資源。應該儘可能避免

　　19 放鬆時序約束

　　大多數的關係型數據庫講究ACID屬性，擴展時就形成必定的困擾。所以某些業務適當的放鬆時序約束，能夠提升網站的性能。

　　好比某站在預約酒店時，用戶預約後，會等待酒店的審覈。好比某寶，在提款時，進行範圍時間的確認。這種就是擴大了時序約束，進而提升網站性能以及事務安全。

積極利用緩存

　　20 利用CDN

　　能夠利用CDN保存客戶的數據和內容。大概的過程是，用戶在進行網站訪問時，轉到CDN的服務器，CDN執行DNS查詢，把用戶請求分攤到不一樣的服務器。有不少的CDN服務商提供這種服務。

　　21 使用過時頭

　　針對不一樣的對象類型，使用過時頭，減小對象請求。常見的HTTP對應屬性爲:public no-cahe max-age等等

　　22 緩存Ajax調用

　　正確修改Http頭Last-Modified Cache-Control Expires等屬性。

　　23 利用頁面緩存

　　緩存響應以前的冬天請求，下降web服務器的負載。

　　24 利用應用緩存

　　好比針對某些特殊的用戶，緩存其請求數據。

　　25 利用對象緩存

　　適用於反覆查詢使用的數據對象。好比一個購物網站，緩存器熱銷產品數據。

　　26 把對象緩存放在本身的層上

　　使用單獨的緩層，易於擴展和維護。

從錯誤中吸收教訓

　　27 積極的學習

　　一個公司有學習的氛圍，纔會衍生出更好的產品。學習的內容一方面包括客戶的業務知識，一方面來自技術和運維領域。

　　28 不要依靠QA發現失誤

　　僱傭測試或者質量保證人員，最大的目的是爲了檢測產品的正確性。它能減小成本，提升開發人員的開發速度，由於開發人員不須要時刻關注代碼的正確性，能夠交給QA來測試。

　　可是QA只負責發現問題，如何避免爲題仍是得依靠開發人員。

　　29 沒有回退的設計是失敗的設計

　　這裏的回退，指的是產品發佈的回退。若是碰上某些版本的BUG，可能須要交付以前可運行的版本，此時沒有回退，就沒法交付產品了。

　　這裏推薦學習持續集成的相關內容。

　　30 討論失敗並從中吸收教訓

　　不該該在同一個問題上失敗兩次，每次失敗多進行總結是不可缺乏的。

數據庫原則

　　關係型數據庫的ACID屬性：

　　原子性：一個事務要麼全執行，要麼都不執行，

　　一致性：事務開始和結束時，全部數據狀態要一致，

　　隔離性：事務的表現，是事務對數據庫惟一的操做，

　　持久性：事務完成，操做不能更改。

　　31 注意代價高的關係

　　應該在設計階段完善的設計表的結構，等開發開始時，在增長某些列，可能會花費很高的代價。

　　32 使用正確的數據庫鎖

　　數據庫有不少鎖的概念，好比隱式鎖、顯式鎖、行鎖、頁鎖、範圍鎖、表鎖、數據庫鎖等等。

　　不合理的使用鎖，會影響網站的吞吐量。

　　33 不要使用多階段提交

　　好比兩階段提交：先表決，在提交。這回下降擴展性，由於在其提交事務完成前，是不能做其餘操做的。

　　34 不要使用select for update

　　由於FOR UPDATE從句會致使鎖定行，下降事務處理的速度。

　　35 不要選擇全部的數據

　　好比select * from xxx;

　　這種作法第一是不開與數據的擴展，好比原本有四列數據，業務處理代碼直接寫死。當增長了一列數據時，就會致使出錯；另外就是會查詢出沒必要要的數據。

　　或者inset into xxx values(xxxx);

　　這是當列信息不匹配時，也會出錯。

容錯設計與故障控制

　　36 採用隔離故障的」泳道「

　　服務與數據的劃分有不少種，好比容器，集羣，池，分片，泳道。泳道意味着每一個業務有本身的領域，不能跨泳道調用。

　　37 不要信任單點故障

　　有不少系統設計成單點模式，當整個系統只是用該模塊時，當出現單點故障，整個系統也就崩潰了。

　　38 避免系統串聯

　　好比一個系統有不少的組件組成，每一個組件99.9%的安全性，當串聯3個組件時，整個系統的可用性就變成了99.7%。

　　39 確保可以啓用/禁用功能

　　對於某些共享庫，第三方服務，應該提供開啓或者關閉的功能。

避免或分發狀態

　　40 努力實現無狀態

　　實現狀態會限制擴展性，增大成本

　　41 儘量在瀏覽器端維護會話

　　一方面下降服務器壓力，另外一方面任何的請求能夠發送給任何的服務器。

　　42 利用分佈式緩存存放狀態

　　使用獨立的緩存層，利於擴展。有不少分佈式的緩存方案，好比memcached。

異步通訊和消息總線

　　43 儘量使用異步通訊

　　異步通訊，能夠確保每一個服務和層之間的獨立性，這樣易於早呢更加系統的擴展性和減少耦合度。

　　44 確保消息總線可以擴展

　　儘可能採用Y軸或者Z軸擴展，即按業務需求和功能擴展。由於單純的複製或者克隆，反而會增長各個消息訂閱者的監聽數目。按照業務隔離，能夠分離業務壓力。

　　45 避免讓消息總線過分擁擠

　　衡量價值與消息的成本。

其餘原則

　　46 慎用第三方解決方案擴展

　　企業若是出現問題，那麼尋找第三方可以解決燃眉之急。可是卻不是長久之計，由於解決方案的提供商有不少客戶，你的危機並非他們的危機，因此不可能在關鍵時刻，盡職盡責。所以企業仍是應該有必定的掌控力（這個詞真是高大上！）。

　　47 清除、歸檔和成本合理的存儲

　　有一些沒必要要的數據，就應該按期的刪除。一些略有價值的數據進行按期的歸檔直接刪除。一些頗有價值的數據，應該進行備份以及快速訪問。

　　48 刪除事務處理中的商業智能

　　應該把產品系統與業務系統分離，提升產品的擴展性。

　　避免業務擴展時，受到系統架構的限制。

　　49 設計可以監控的應用

　　應該設計全局的監控策略，保證回答

　　」發生了 問題了嗎？「

　　」哪裏發生了問題？「

　　」發生了什麼問題？「

　　」會發生問題嗎？「

　　」能自動修復嗎？「

　　50 要能勝任

　　應該在每一個設計中涉及到最優秀的架構，不能徹底依賴第三方的解決方案。

　　一個簡單優秀的架構，都是小而精的，若是單純的依靠開源解決架構，雖然解決了問題，卻會致使應用的臃腫。

參考

　　【1】《高擴展性網站的50條原則》