如何構建高擴展性網站？

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

一方面博主沒有實際的架構經驗，另一方面知識面也不夠寬闊，所以只能系統的總結書中的要點，并根據自己的理解做些歸納。

</blockquote>

主要內容

本書從多個方面圍繞高擴展性提出了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條原則》

來自：http://www.cnblogs.com/xing901022/p/4425124.html