大型網站技術架構的演進

>>>  技術話題—商業文明的嶄新時代  >>> 簡體     傳統

最近我在閱讀2本關于大型網站架構的書:《大型網站技術架構——核心原理與案例分析》李智慧、《大型網站系統與Java中間件實踐》曾憲杰。

我期望從這些書中學習到大型網站是如何做架構的,這個過程會遇到什么問題。當看完這2本書后,我總結出兩個大問題:

1. 網站技術架構為什么會演進?換個說法就是為什么網站會變大?

2. 演進的過程會遇到什么問題?或者說為了演進,會遇到什么問題?

網站技術架構為什么會演進

我個人總結出來我們的技術架構演進的兩種驅動力,驅動著我們為什么演進網站的技術架構:

1. 內在驅動力:我們期望把當前的業務做得更好,開發更多新業務

2. 外在驅動力:用戶量的上升、用戶種類的多樣化

這兩種驅動力不是獨立的,更多時候是并行的。我想淘寶就是兩種驅動力并行驅動的結果。

演進的原因很簡單。但是在什么時機我們就應該演進網站的技術架構了,以及如何演進?面對這些問題,說實話,我沒有任何經驗,再說現實中每家企業當時都面臨的問題都不一樣,所以,我很難從經驗中總結出什么是演進的時機。

但是我可以從另一個角度切入這個問題:研究網站內外結構,找到這些結構可能出現的問題點,知道或者預見到問題點了,你當然就知道應該怎么演進了。類似于你了解了PC機的結構,你也就知道什么時候要加內存了,什么時候要加硬盤了。

那么我們先看看網站的外部結構:

外部結構中,我們可以看由以下幾個部分構成:

U:代表用戶群。當用戶群變了,我們的網站如何演進?用戶群的分析,我目前能知道的維度有:數量,種類,地理位置(區域)。

N:代表網絡環境。網絡環境在每個地區都不同。你可以想像我們為什么需要CDN。當我們期望每個區域的用戶都能得到好的體驗,我們的網站如何演進?

S:代表安全。就是我們要安全到什么程度?這與網站當前所處階段及你網站的性質有關。

C:代表我們的網站。屬于內部結構

網站的內部結構:

內部結構的組成:

A:應用服務。

D:數據服務

總結下來就是我們在考慮網站是否應該演進了或者如何演進時,這些組成部分為我們提供了考慮問題的基準。

那么我們為什么不一開始就把網站設計成“大型”的。李智慧在后記里寫到:“不要企圖去設計一個大型網站”,“原因是互聯網發展運行有其自己的規律,短暫的互聯網歷史已經一再證明這種企圖行不通”。還說了:“大型網站不是設計出來的,而是逐步演化出來的”。對于最后這句話,我需要提醒下:“不是設計出來的”并不代表“隨意設計”。

對于“大型網站的設計”,我個人的看法是現在我們的有“云”了,計算是可以買的,只要我們的設計能適應“云”,我是不是就可以一開始就設計大型網站了?

演進的過程會遇到什么問題

- 最初

從一個小網站說起。一臺服務器也就足夠了。

- 數據服務與應用服務分離

越來越多的用戶代表著越來越多的數據,一臺服務器已經滿足不了。我們將數據服務和應用服務分離,給應用服務器配置更好的CPU,內存。而給數據服務器配置更好更大的硬盤。

- 使用緩存

因為80%的業務訪問都集中在20%的數據上,如果我們能將這部分數據緩存下來,性能一下子就上來了。而緩存又分為兩種:本地緩存和遠程分布式緩存。具體使用哪種?還是兩種都用,我目前不知道。

這里有一個問題,書沒有提到:應該緩存哪些數據?應該有一些原則的吧。

- 使用服務器集群

當這臺服務器的處理能力達到上限時,它就會成為瓶頸。雖然你是可以通過購買更強大的硬件,但總會有上限。這時,我們就需要服務器的集群。這時,就必須加個新東西:負載均衡調度服務器。

但是,使用服務器集群時,需要考慮一個問題:Session的管理問題。Session的管理有以下幾種方式:

* Session Sticky:打個比方就是如果我們每次吃飯都要保證我們用的是自己的碗筷,而只要我們在一家飯店里存著我們的碗筷,只要我們每次去這家飯店吃飯就好了。

這種方式的問題:

1. 一臺服務器重啟,上面的session都沒了

2. 負載均衡器成了有狀態的機器,要實現容災會有麻煩

* Session復制:就像我們在所有的飯店里都存一份自己的碗筷。不適合做大規模集群,適合機器不多的情況

這種方案的問題:

1. 應用服務器間帶寬問題

2. 大量用戶在線時,占用內存過多



* 基于Cookie:類似于每次吃飯都把自己的碗筷帶上

這種方案的問題:

1. Cookie的長度限制

2. 安全性

3. 數據中心外部帶寬的消耗

4. 性能影響,服務器處理每次的請求的內容又多了

* Session服務器:同樣可以是集群的。這種方式適用于session數量及web服務器數量大的情況

這種方案需要考慮的是:

1. 保證session服務器的可用性

2. 我們在寫應用時需要做調整,我目前不知道應用服務器能否將這部分邏輯透明化

- 數據庫讀寫分離

數據庫的一部分讀(未緩存、緩存過期)及所有的寫操作都還需要經過數據庫。當用戶量達到一定量,數據庫將會成為瓶頸。這邊我們使用數據庫提供的熱備功能,將所有的讀操作引入slave服務器。注意:讀寫分離解決的是讀壓力大的問題。

因為數據庫的讀寫分離了,所以,我們的應用程序也得做相應的變化。我們實現一個數據訪問模塊使上層寫代碼的人不知道讀寫分離的存在。這里,我很想知道如果我使用ORM模型時,如何實現讀寫的分離?

數據庫讀寫分離會遇到如下問題:

* 數據復制問題: 考慮時延、數據庫的支持、復制條件支持。不要忘了,分機房后,這個更是問題。

* 應用對于數據源的路由問題

- 使用反向代理和CDN加速網站響應

使用CDN可以很好的解決不同的地區的訪問速度問題,反向代理則在服務器機房中緩存用戶資源:

- 使用分布式文件系統

- 數據庫專庫專用:數據垂直拆分。這樣可以解決部分數據寫的問題


垂直拆分數據庫時,會遇到的問題:

* 跨業務的事務

* 應用的配置項多了

關于事務的問題,有兩種辦法:

* 使用分布式事務

* 去掉事務或不追求強事務

- 某個業務的數據表的數據量或者更新量達到了單個數據庫的瓶頸:數據水平拆分

將同一個表的數據拆分到兩個數據庫中

數據水平拆分會遇到的問題:

* SQL的路由問題,需要知道某個User在哪個數據庫上。

* 主鍵的策略會有不同。

* 查詢時的性能問題,如分頁問題

- 使用搜索引擎:解決數據查詢問題

- 部分場景可使用NoSQL提高性能

- 開發數據統一訪問模塊:解決上層應用開發的數據源問題

- 業務拆分及應用拆分

網站的業務日益復雜,建立一個獨立的大型應用來完成這所有的業務變得不實際。從管理角度來,也不方便管理。然而,業務的拆分很難找到一種通用的模式,這是一個企業管理問題和技術問題的混合問題。同時和每個企業的具體情況有關。

但是從這兩本書來看,最終架構都走向服務化,也就是SOA。而如何實現SOA,是另一個很大的話題,不是本篇文章的范疇。

我從程立08年的演講中截個圖來說明SOA后的架構大概是怎樣的:

- 非功能性問題

    – 安全性問題、監控問題

    – 發布問題:新的架構意味著新的發布方式

    – 分機房

這兩本書都沒有說分機房的問題。我沒有經驗,可是也可以猜到如果要分機房了,所有上面的問題都可能要重新考慮。

    – 組織架構的變化

我們的技術架構的變化,勢必會引起我們的組織架構的變化,反之亦然。

這部分看似不應該由我們來管,但是,我覺得,我們技術人員也要參與一部分的組織架構的設計。舉個例子,組織架構的設計會涉及績效,而績效有時很像一個國家的法律。如果一個國家的法律不健全,會發生什么?你懂的。

同時,我們還必須考慮人員對新架構的學習成本。

這部分我目前在看相關的書籍,還沒有一個系統的認識。

總結:

- 關于演進的順序

在現實中,技術架構的演進不一定就是按文章從頭到尾這樣列下來的,所以,要視具體情況來下決定。

- 關于傳統演進與現代有“云”環境下的演進

很可惜,只有李智慧談到云,而且只點了一下——“現在越來越多人的網站從建立之初就是搭建在大型網站提供的云計算服務基礎之上,所需的一切資源:計算、存儲、網絡都可以按需購買線性伸縮,不需要自己一點一點地拼湊各種資源,綜合使用各種技術方案逐步去完善自己的網站架構”。

因為我用“云”的時間也不長,還不能總結出有云架構與傳統的無云架構在演進的時候有什么不同。

說回傳統的架構演進,我自己總結和思考的結果是:

在對網站進行架構調整時,可以從兩大的維度考慮:數據服務和應用服務。而這個調整的過程中,需要分清當前哪個點是瓶頸,需要知道哪個點優化的優先級最高。同時,最重要的一點:我們雖然作為技術人員,也應該去學習業務知識,這樣我們在考慮問題時分清哪些是業務問題,哪些是技術問題,分清后才能對癥下藥。你要知道有些問題用技術手段并不比用業務手段更有效。12306的分時賣票就是一個典型例子。


dotNET跨平臺 2015-08-23 08:48:32

[新一篇] iOS應用架構談開篇

[舊一篇] 還記得嗎?人類20年前曾這樣使用電腦!!
回頂部
寫評論


評論集


暫無評論。

稱謂:

内容:

驗證:


返回列表