[[262675]]

1.應(yīng)用和靜態(tài)資源分離

剛開始的時候應(yīng)用和靜態(tài)資源是保存在一起的，當并發(fā)量達到一定程度的時候就需要將靜態(tài)資源保存到專門的服務(wù)器中，靜態(tài)資源主要包括圖片、視頻、js、css和一些資源文件等，這些文件因為沒有狀態(tài)所以分離比較簡單，直接存放到響應(yīng)的服務(wù)器就可以了，一般會使用專門的域名去訪問。

通過不同的域名可以讓瀏覽器直接訪問資源服務(wù)器而不需要再訪問應(yīng)用服務(wù)器了。架構(gòu)圖如下：

2.頁面緩存

頁面緩存是將應(yīng)用生成的頁面緩存起來，這樣就不需要每次都生成頁面了，從而可以節(jié)省大量的CPU資源，如果將緩存的頁面放到內(nèi)存中速度就更快了。如果使用Nginx服務(wù)器就可以使用它自帶的緩存功能，當然也可以使用專門的Squid 服務(wù)器。頁面緩存的默認失效機制一班都是按緩存時間處理的，當然也可以在修改數(shù)據(jù)之后手動讓相應(yīng)的緩存失效。

頁面緩存主要是使用在數(shù)據(jù)很少發(fā)生變化的頁面，但是很多頁面是大部分數(shù)據(jù)都很少發(fā)生變化，而其中很少一部分數(shù)據(jù)變化頻率卻非常高，比如說一個顯示文章的頁面，正常來說完全可以靜態(tài)化，但是如果文章后面有“頂”和“踩”的功能而且顯示的有響應(yīng)的數(shù)量，這個數(shù)據(jù)的變化頻率就比較高了，這就會影響靜態(tài)化。這個問題可以用先生成靜態(tài)頁面然后使用Ajax來讀取并修改響應(yīng)的數(shù)據(jù)，這樣就可以一舉兩得來，既可以使用頁面緩存也可以實時顯示一些變化頻率高的數(shù)據(jù)來。

其實大家都知道，效率***、消耗最小的就是純靜態(tài)化的html頁面，所以我們盡可能使我們的網(wǎng)站上的頁面采用靜態(tài)頁面來實現(xiàn)，這個最簡單的方法其實也是最有效的方法。但是對于大量內(nèi)容并且頻繁更新的網(wǎng)站，我們無法全部手動去挨個實現(xiàn)，于是出現(xiàn)了我們常見的信息發(fā)布系統(tǒng)CMS，像我們常訪問的各個門戶站點的新聞頻道，甚至他們的其他頻道，都是通過信息發(fā)布系統(tǒng)來管理和實現(xiàn)的，信息發(fā)布系統(tǒng)可以實現(xiàn)最簡單的信息錄入自動生成靜態(tài)頁面，還能具備頻道管理、權(quán)限管理、自動抓取等功能，對于一個大型網(wǎng)站來說，擁有一套高效、可管理的CMS是必不可少的。

 除了門戶和信息發(fā)布類型的網(wǎng)站，對于交互性要求很高的社區(qū)類型網(wǎng)站來說，盡可能的靜態(tài)化也是提高性能的必要手段，將社區(qū)內(nèi)的帖子、文章進行實時的靜態(tài)化，有更新的時候再重新靜態(tài)化也是大量使用的策略，像Mop的大雜燴就是使用了這樣的策略，網(wǎng)易社區(qū)等也是如此。

同時，html靜態(tài)化也是某些緩存策略使用的手段，對于系統(tǒng)中頻繁使用數(shù)據(jù)庫查詢但是內(nèi)容更新很小的應(yīng)用，可以考慮使用html靜態(tài)化來實現(xiàn)，比如論壇中論壇的公用設(shè)置信息，這些信息目前的主流論壇都可以進行后臺管理并且存儲再數(shù)據(jù)庫中，這些信息其實大量被前臺程序調(diào)用，但是更新頻率很小，可以考慮將這部分內(nèi)容進行后臺更新的時候進行靜態(tài)化，這樣避免了大量的數(shù)據(jù)庫訪問請求。

3.集群與分布式

集群是每臺服務(wù)器都具有相同的功能，處理請求時調(diào)用那臺服務(wù)器都可以，主要起分流作用。

分布式是將不同的業(yè)務(wù)放到不同的服務(wù)器中，處理一個請求可能需要用到多臺服務(wù)器，這樣就可以提高一個請求的處理速度，而且集群和分布式也可以同時使用。

集群有兩個方式：一種是在靜態(tài)資源集群。另一種是應(yīng)用程序集群。靜態(tài)資源集群比較簡單。應(yīng)用程序集群在處理過程中最核心的問題就是Session 同步問題。

Session 同步有兩種處理方式：一種是在Session 發(fā)生變化后自動同步到其他服務(wù)器，另一種就是用個程序統(tǒng)一管理Session。所有集群的服務(wù)器都使用同一個Session，Tomcat 默認使用就是***種方式，通過簡單的配置就可以實現(xiàn)，第二種方式可以使用專門的服務(wù)器安裝Mencached等高效的緩存程序統(tǒng)一來管理session，然后再應(yīng)用程序中通過重寫Request并覆蓋getSession 方法來獲取制定服務(wù)器中的Session。

對于集群來說還有一個核心的問題就是負載均衡，也就是接收到一個請求后具體分配到那個服務(wù)器去處理的問題，這個問題可以通過軟件處理也可以使用專門的硬件（如：F5）解決。

4. 反向代理

反向代理指的是客戶端直接訪問的服務(wù)器并不真正提供服務(wù)，它從別的服務(wù)器獲取資源然后將結(jié)果返回給用戶。

圖：

4.1 反向代理服務(wù)器和代理服務(wù)器的區(qū)別

代理服務(wù)器的作用是代我門獲取想要的資源然后將結(jié)果返回給我們，所要獲取的資源是我門主動告訴代理服務(wù)器的，比如，我門想訪問Facebook，但是直接訪問不了，這時就可以讓代理服務(wù)器訪問，然后將結(jié)果返回給我們。

反向代理服務(wù)器是我門正常訪問一臺服務(wù)器的時候，服務(wù)器自己去調(diào)用了別的服務(wù)器資源并將結(jié)果返回給我們，我門自己并不知道。

代理服務(wù)器是我們主動使用的，是為我們服務(wù)的，他不需要有自己的域名；反向代理服務(wù)器是服務(wù)器自己試用的，我門并不知道，它有自己的域名，我門訪問它和訪問正常的網(wǎng)址沒有任何區(qū)別。

反向代理服務(wù)器主要有三個作用：

1. 可以作為前端服務(wù)器跟實際處理請求的服務(wù)器集成；

2. 可以做負載均衡

3. 轉(zhuǎn)發(fā)請求，比如說可以將不同類型的資源請求轉(zhuǎn)發(fā)到不同的服務(wù)器去處理。

5. CDN

cdn其實是一種特殊的集群頁面緩存服務(wù)器，他和普通集群的多臺頁面緩存服務(wù)器相比，主要是它存放的位置和分配請求的方式有點特殊。CDN 服務(wù)器是分布在全國各地的，當接收到用戶請求后會將請求分配到最合適的CDN服務(wù)器節(jié)點獲取數(shù)據(jù)。比如聯(lián)通的用戶分配到聯(lián)通的節(jié)點，上海的用戶分配到上海的節(jié)點。

CDN的每個節(jié)點其實就是一個頁面緩存服務(wù)器，如果沒有請求資源的緩存就會從主服務(wù)器獲取，否則直接返回緩存的頁面。

CDN分配請求（負載均衡）的方式是用專門的CDN域名解析服務(wù)器在解析域名的時候就分配好的。一般的做法是在ISP哪里試用CNAME將域名解析到一個特定的域名，然后再將解析到的那個域名用專門的CDN服務(wù)器解析道相應(yīng)的CDN節(jié)點。如圖。

第二步訪問CDN的DNS服務(wù)器是應(yīng)為CNAME記錄的目標域名使用NS記錄指向了CDN的DNS服務(wù)器。CDN的每個節(jié)點可能也是集群了多臺服務(wù)器。

6. 底層的優(yōu)化

前面說的所有都是架構(gòu)都是建立在最前面介紹的基礎(chǔ)結(jié)構(gòu)之上的。很多地方都需要通過網(wǎng)絡(luò)傳輸數(shù)據(jù)，如果可以加快網(wǎng)絡(luò)傳輸?shù)乃俣?，那將會讓整個系統(tǒng)得到改善。

7.數(shù)據(jù)庫集群和庫表散列

大型網(wǎng)站都有復(fù)雜的應(yīng)用，這些應(yīng)用必須使用數(shù)據(jù)庫，那么在面對大量訪問的時候，數(shù)據(jù)庫的瓶頸很快就能顯現(xiàn)出來，這時一臺數(shù)據(jù)庫將很快無法滿足應(yīng)用，于是我們需要使用數(shù)據(jù)庫集群或者庫表散列。

在數(shù)據(jù)庫集群方面，很多數(shù)據(jù)庫都有自己的解決方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是類似的方案，您使用了什么樣的DB，就參考相應(yīng)的解決方案來實施即可。

上面提到的數(shù)據(jù)庫集群由于在架構(gòu)、成本、擴張性方面都會受到所采用DB類型的限制，于是我們需要從應(yīng)用程序的角度來考慮改善系統(tǒng)架構(gòu)，庫表散列是常用并且最有效的解決方案。我們在應(yīng)用程序中安裝業(yè)務(wù)和應(yīng)用或者功能模塊將數(shù)據(jù)庫進行分離，不同的模塊對應(yīng)不同的數(shù)據(jù)庫或者表，再按照一定的策略對某個頁面或者功能進行更小的數(shù)據(jù)庫散列，比如用戶表，按照用戶ID進行表散列，這樣就能夠低成本的提升系統(tǒng)的性能并且有很好的擴展性。sohu的論壇就是采用了這樣的架構(gòu)，將論壇的用戶、設(shè)置、帖子等信息進行數(shù)據(jù)庫分離，然后對帖子、用戶按照板塊和ID進行散列數(shù)據(jù)庫和表，最終可以在配置文件中進行簡單的配置便能讓系統(tǒng)隨時增加一臺低成本的數(shù)據(jù)庫進來補充系統(tǒng)性能。

8. 小結(jié)

網(wǎng)站架構(gòu)的整個演變過程主要是圍繞大數(shù)據(jù)和高并發(fā)這兩個問題展開的，解決方案主要分為使用緩存和多資源兩種類型。多資源主要指多存儲（包括多內(nèi)存）、多CPU和多網(wǎng)絡(luò)，對于多資源來說又可以分為單個資源處理一個完整的請求和多個資源合作處理一個請求兩種類型，如多存儲和多CPU中的集群和分布式，多網(wǎng)絡(luò)中的CDN和靜態(tài)資源分離。理解了整個思路之后就抓住了架構(gòu)演變的本質(zhì)，而且自己可能還可以設(shè)計出更好的架構(gòu)。

其它簡單總結(jié)：

首先，我認為解決問題之前首先要有清晰的思路，如果只是用來別人的解決方案那也只能是拿來主義，沒有真正理解，沒有做到舉一反三。

海量數(shù)據(jù)和高并發(fā)經(jīng)常被連在一塊說事兒，雖然他們完全是兩回事兒。海量數(shù)據(jù)純指的是數(shù)據(jù)庫的海量數(shù)據(jù)，而并發(fā)指的卻包括數(shù)據(jù)庫和服務(wù)器的高訪問量。

那么問題來了，既然是數(shù)據(jù)庫的數(shù)據(jù)量大，那怎么辦呢？要想解決問題，首先要知道問題是什么！??！那么海量數(shù)據(jù)會給我?guī)硎裁礃拥膯栴}呢？

海量數(shù)據(jù)帶來的問題無非就是增刪改查的問題，除了之外還能有啥問題呢？總不能是帶來安全問題吧（打臉一，還真有可能是安全問題）

1 數(shù)據(jù)庫訪問緩慢

2 插入更新緩慢，這個問題只能通過分庫分表解決

要解決數(shù)據(jù)庫訪問緩慢的問題還有幾種方法，既然訪問數(shù)據(jù)庫慢的話，在邏輯允許的情況下可以不訪問數(shù)據(jù)庫呢？

1 使用緩存

2 使用頁面靜態(tài)化

既然不訪問數(shù)據(jù)庫逃不過去了，那我們就對數(shù)據(jù)庫進行優(yōu)化

3 優(yōu)化數(shù)據(jù)庫（包含的內(nèi)容非常多，比如參數(shù)配置，索引優(yōu)化，sql優(yōu)化等等）

4 分離數(shù)據(jù)庫中活躍的數(shù)據(jù)

5 讀寫分離

6 批量讀取和延遲修改；

7 使用搜索引擎搜索數(shù)據(jù)庫中的數(shù)據(jù)；

8 使用NoSQL和Hadoop等技術(shù)；

9 進行業(yè)務(wù)的拆分；

高并發(fā)的解決方案

其實這個問題必須結(jié)合上面的海量數(shù)據(jù)來討論，什么情況下會出現(xiàn)高并發(fā)呢？一定是平時訪問量就比較大的情況，那么平時訪問量比較大相應(yīng)的數(shù)據(jù)存儲也就越來越多，這都是相輔相成的，當然也有個例，比如剛需，比如12306，這里的高并發(fā)相比于它的數(shù)據(jù)來說已經(jīng)不算海量了。那么平時訪問量大如何解決呢？因為這里牽扯到服務(wù)器和數(shù)據(jù)庫的問題，所以要從這兩方面來進行優(yōu)化

1 增加web服務(wù)器數(shù)量，也就是做集群，做負載均衡。既然一臺服務(wù)器無法完成任務(wù)，那就多用幾臺，幾臺不夠用機房

在通向第二種解決方法之前，還有沒有除了數(shù)據(jù)庫服務(wù)器之外能做的一些優(yōu)化手段呢？當然有

1.1 頁面緩存

1.2 cdn

1.3 反向代理

1.4 應(yīng)用程序和靜態(tài)資源分離（比如***下載的資源單獨放在一起，給這臺服務(wù)器提供很高的帶寬資源）

2 增加數(shù)據(jù)庫服務(wù)器數(shù)量，同樣做集群，做負載均衡。

海量數(shù)據(jù)的解決方案

1 使用緩存

好多事情都是相輔相成的，相比來說使用緩存更多是用來解決高并發(fā)問題的，因為海量數(shù)據(jù)導(dǎo)致了訪問的緩慢，容易造成高并發(fā)問題的嚴重性，又因為數(shù)據(jù)庫一般是web訪問的瓶頸，所以我們在業(yè)務(wù)邏輯允許的情況下盡量先避免操作數(shù)據(jù)庫，于是，就有了緩存。將必要的數(shù)據(jù)存放在內(nèi)存中，而不必每次都去數(shù)據(jù)庫中讀取造成不必要的性能浪費和加快訪問速度---這就是緩存帶來的好處。那使用緩存以及選用管理緩存軟件時應(yīng)該注意些什么東西呢？

2 頁面靜態(tài)化---不想解釋，還有什么值得去解釋呢？

3 數(shù)據(jù)庫優(yōu)化

3.1 數(shù)據(jù)庫表結(jié)構(gòu)涉及

3.2 數(shù)據(jù)類型的選用

3.3 sql優(yōu)化

3.4 索引優(yōu)化

3.5 配置優(yōu)化

需要注意的地方實在太多，應(yīng)該作為單獨的一章拿出來講

4 分離數(shù)據(jù)庫中的活躍數(shù)據(jù)

為什么要分離呢？說一個我實際環(huán)境中遇到的問題吧！有一個表只有10幾個字段，表有130萬條數(shù)據(jù)，但大小已經(jīng)到了5G的數(shù)據(jù)，這本身是不太合理的，這么少的數(shù)據(jù)占用了太多的數(shù)據(jù)，說明其中有些字段存儲了大量的字符串（比如說文章內(nèi)容等），每次檢索這個表時大部分是用不到這些大字段內(nèi)容的，但卻需要耗時比較長，產(chǎn)生很多的慢日志。這時我們可以考慮將表進行垂直切分，將活躍數(shù)據(jù)分離開來，這樣能大大加快訪問速度。

歡迎大家和我一起學(xué)習交流構(gòu)建Java云架構(gòu)，我這邊會將近期研發(fā)的Java云架構(gòu)的搭建過程和精髓記錄下來，幫助更多有興趣研發(fā)Java高級架構(gòu)的朋友，大家來一起探討Java高級架構(gòu)的搭建過程及如何運用于企業(yè)項目。

我本人邀約各大BATJ架構(gòu)大牛共創(chuàng)Java架構(gòu)師社區(qū)，致力于免費提供Java架構(gòu)行業(yè)交流平臺，通過這個平臺讓大家相互學(xué)習成長，提高技術(shù)，讓自己的水平進階一個檔次，成功通往Java架構(gòu)技術(shù)大?；蚣軜?gòu)師發(fā)展 （關(guān)注我：私信：【架構(gòu)】，即可獲?。?/p>

希望此文能幫到大家的同時，也聽聽大家的觀點。歡迎留言討論，加關(guān)注，分享你的高見！持續(xù)更新！