大型網(wǎng)站技術架構筆記

1、四、網(wǎng)站的高可用架構-萬無一失 故障分是指對網(wǎng)站故障進行分類加權計算故障責任的方法。如下是個案例：分類描述權重事故級故障嚴重故障，網(wǎng)站整體不可用100A類故障網(wǎng)站訪問不順暢或核心功能不可用20B類故障非核心功能不可用，或核心功能少數(shù)用戶不能訪問5C類故障其他故障1 故障分的計算公式為：故障分=故障時間（分鐘）* 故障權重1. 高可用的網(wǎng)站架構 實現(xiàn)高可用架構的主要手段是數(shù)據(jù)和服務的冗余備份及失效轉移，一旦某些服務器宕機，就將服務切換到其他可用的服務器上，如果磁盤損壞，則從備份的磁盤讀取數(shù)據(jù)。（1）對于應用層的服務器通常為了應對高并發(fā)的訪問請求，會通過負載均衡設備將一組服務器組成一個集群共同對外

2、提供服務，當負載均衡設備通過心跳檢測到某臺服務器不可用時，就將其從集群列表中剔出，并將請求分發(fā)到集群中其他可用的服務器上，是整個集群保存可用，從而實現(xiàn)應用高可用。（2）位于服務層的服務器情況和應用層類似，也是通過集群方式實現(xiàn)高可用，只是這些服務器被應用層通過分布式服務調用框架訪問，分布式服務調度框架會在應用層客戶端中實現(xiàn)負載均衡功能。（3）位于數(shù)據(jù)層的服務器情況比較特殊，數(shù)據(jù)服務器上存儲著數(shù)據(jù)，為了保證數(shù)據(jù)不丟失，數(shù)據(jù)訪問服務不中斷，需要在數(shù)據(jù)寫入時進行數(shù)據(jù)同步復制，將數(shù)據(jù)寫入多臺服務器上，實現(xiàn)數(shù)據(jù)冗余備份。宕機時直接切換到備份服務器上。 網(wǎng)站升級的頻率一般都非常高，每次網(wǎng)站發(fā)布都需要關閉服務

3、，重新啟動系統(tǒng)，相當于服務器宕機。因此網(wǎng)站的可用性架構還需要考慮到網(wǎng)站升級發(fā)布引起的宕機。2. 高可用的應用（1）通過負載均衡進行無狀態(tài)服務的失效轉移（2）應用服務器集群的Session管理 Web應用中將這些多次請求的上下文稱為會話（Session），在單機情況下，session可部署在服務器上的Web容器上管理。在使用負載均衡的集群環(huán)境中，由于負載均衡服務器可能會將請求分發(fā)到集群任何一臺應用服務器上，所以保證每次請求依然能夠獲得正確的session比單機時要復雜的多。在集群環(huán)境下，session管理主要有以下手段。 Session復制：Session復制是早期企業(yè)應用系統(tǒng)使用較多的一種服務

4、器集群Session管理機制。應用服務器開啟Web容器的Session復制功能，在集群中幾臺服務器之間同步Session對象，是每臺服務器上都保存所有用戶的Session信息。這種方案雖然簡單，從本機讀取Session信息也很快，但當集群規(guī)模比較大的時候會占用服務器和網(wǎng)站的大量資源，在大量用戶訪問的情況下，甚至會出現(xiàn)內存不夠Session使用的情況。 Session綁定：Session綁定可以利用負載均衡的源地址Hash算法實現(xiàn)，負載均衡服務器總是將來源于同一IP的請求分發(fā)到同一臺服務器上。這樣在整個回話期間，用戶所有的請求都在同一臺服務器上處理，即Session綁定到某臺特定的服務器上，保證

5、Session總能在這臺服務器上獲取，這種方法有成為會話粘滯。 利用Cookie記錄Session：一種管理Session的方式是將Session記錄在客戶端，每次請求服務器的時候，將Session放在請求中發(fā)送給服務器，服務器處理完請求后再將修改后的Session響應給客戶端。但是Cookie大小受限，每次請求都需要傳送Cookie，影響性能。如果用戶關閉Cookie，訪問就會不正常。 Session服務器：Session服務器（集群），即把session的管理獨立部署在某一臺機器上，Web服務器不保存用戶Session信息，每次都去Session服務器取數(shù)據(jù)。這種解決方案事實上是將應用服務

6、器的狀態(tài)分離，分為無狀態(tài)的應用服務器和有狀態(tài)的Session服務器。對于有狀態(tài)的Session服務器，一種比較簡單的方式是利用分布式緩存、數(shù)據(jù)庫等。3. 高可用的服務（1）分級管理，核心應用和服務優(yōu)先使用更好的硬件。（2）超時設置，及時將請求轉移到其它服務器上。（3）異步調用，通過消息隊列等異步方式完成。（4）服務降級，網(wǎng)站高峰期間，可以關閉一些不重要的服務或拒絕部分服務，如評論。（5）冪等性設計，保證重復調用和調用一次產(chǎn)生的結果相同。4. 高可用的數(shù)據(jù) 保證數(shù)據(jù)存儲高可用的手段主要是數(shù)據(jù)備份和失效轉移機制。（1）CAP原理：一個提供數(shù)據(jù)服務的存儲系統(tǒng)無法同時滿足數(shù)據(jù)持久性、數(shù)據(jù)可用性、分區(qū)耐

7、受性（伸縮性）。在大型網(wǎng)站中，通常會選擇強化分布式存儲系統(tǒng)的可用性（A）和伸縮性（P），而在某種程度上放棄一致性（C）。 數(shù)據(jù)強一致：數(shù)據(jù)在物理存儲總是一致的。 數(shù)據(jù)用戶一致：數(shù)據(jù)在各個副本的數(shù)據(jù)可能不一致，但是終端用戶訪問時，通過糾錯和校驗機制，可以確定一個一致的且正確的數(shù)據(jù)返回給用戶。 數(shù)據(jù)最終一致：物理存儲和終端用戶訪問的都有可能數(shù)據(jù)不一致，但系統(tǒng)經(jīng)過一段時間的自我恢復和修正最終會達到一致。（2）數(shù)據(jù)備份 異步熱備方式：先同步的寫主庫，然后異步的寫從庫。 同步熱備方式（Master-Slave同步機制）：為了提高性能，可并發(fā)的寫多份數(shù)據(jù)庫，等待所有存儲服務器都返回寫成功后通知應用程序操作

8、成功。 讀寫分離：寫操作只訪問Master庫，讀操作只訪問Slave庫。（3）失效轉移 失效確認：通過心跳檢測和應用程序訪問失敗報告確定失效。 訪問轉移 數(shù)據(jù)恢復5. 高可用的網(wǎng)站質量保證（1）網(wǎng)站發(fā)布（2）自動化測試（3）預發(fā)布驗證，與生產(chǎn)唯一的不同就是沒有配置在負載均衡服務器上。謹慎修改生產(chǎn)數(shù)據(jù)。（4）快速失敗，如果系統(tǒng)在啟動時發(fā)現(xiàn)問題就立刻拋出異常，停止啟動讓工程師介入排查錯誤，而不是啟動后執(zhí)行錯誤的操作。（5）代碼控制（Git正逐步取代SVN的地位） 主干開發(fā)、分支發(fā)布，發(fā)布需要注釋掉未完成的功能。 分支開發(fā)、主干發(fā)布（6）自動化發(fā)布（7）灰度發(fā)布，將集群服務器分成若干部分，每天只發(fā)布

9、一部分服務器，觀察運行穩(wěn)定沒有故障時接著發(fā)布其它6. 網(wǎng)站運行監(jiān)控（Ganglia監(jiān)控工具） 不允許沒有監(jiān)控的系統(tǒng)上線。（1）監(jiān)控數(shù)據(jù)采集 用戶行為日志收集（服務器端和瀏覽器端） 服務器性能監(jiān)控（CPU、內存、磁盤IO、網(wǎng)絡IO等） 運行數(shù)據(jù)報告（緩存命中率、平均響應延遲時間、每分鐘發(fā)送郵件數(shù)目、待處理的任務總數(shù)等）（2）監(jiān)控管理 監(jiān)控數(shù)據(jù)采集后，除了用作系統(tǒng)性能評估、集群規(guī)模伸縮性預測等，還可以根據(jù)實時監(jiān)控數(shù)據(jù)進行風險預警，并對服務器進行失效轉移，自動負載調整，最大化利用集群所有機器的資源。五、網(wǎng)站的伸縮性架構-永無止境 網(wǎng)站的伸縮性是指不需要改變網(wǎng)站的軟硬件設計，僅僅通過改變部署的服務器數(shù)

10、量就可以擴大或者縮小網(wǎng)站的服務處理能力。 活動期間向服務器集群中加入更多服務器，及向網(wǎng)絡服務商租借更多的網(wǎng)絡帶寬，以滿足用戶訪問，活動結束后又將這些服務器下線以節(jié)約成本。1. 網(wǎng)站架構的伸縮性設計（1）不同功能進行物理分離實現(xiàn)伸縮 橫向分離：即分層后分離，將業(yè)務處理流程上的不同部分分離部署，實現(xiàn)系統(tǒng)伸縮性。 縱向分離：即分割業(yè)務后分離，將不同的業(yè)務模塊分離部署，實現(xiàn)系統(tǒng)伸縮性。（2）單一功能通過你集群規(guī)模實現(xiàn)伸縮 當一頭牛拉不動車的時候，不要去尋找一頭更強壯的牛，而是用更多的牛。 集群伸縮性又分為應用服務器集群伸縮性和數(shù)據(jù)服務器集群伸縮性。2. 應用服務器集群的伸縮性設計 應用服務器應該設計成

11、無狀態(tài)的，任何一臺服務器處理請求的結果都應該是相同的。 如果HTTP請求分發(fā)裝置可以感知或者可以配置集群的服務器數(shù)量，可以及時發(fā)現(xiàn)集群中新上線或下線的服務器，并能向新上線的服務器分發(fā)請求，停止向已下線的服務器分發(fā)請求，那么就實現(xiàn)了應用服務器集群的伸縮性。這個HTTP請求分發(fā)裝置被稱為負載均衡服務器。（1）HTTP重定向負載均衡 HTTP重定向服務器是一臺普通的應用服務器，其唯一的功能就是根據(jù)用戶的HTTP請求計算一臺真實的服務器地址，并將真實的服務器地址寫入HTTP重定向響應中（響應狀態(tài)嗎302）返回給瀏覽器，然后瀏覽器再自動請求真實的服務器地址。 這種負載均衡方案的優(yōu)點是比較簡單。缺點是瀏覽

12、器需要每次請求兩次服務器才能完成一次訪問，性能較差；使用HTTP302響應嗎重定向，可能是搜索引擎判斷為SEO作弊，降低搜索排名。重定向服務器自身的處理能力有可能成為瓶頸。因此這種方案在實際使用中并不見多。（2）DNS域名解析負載均衡 利用DNS處理域名解析請求的同時進行負載均衡。在DNS服務器中配置多個A記錄，如：IN A 、IN A 、IN A 。每次域名解析請求都會根據(jù)負載均衡算法計算一個不同的IP地址返回，這樣A記錄中配置的多個服務器就構成一個集群，并可以實現(xiàn)負載均衡。 DNS域名解析負載均衡的優(yōu)點是將負載均衡工作交給DNS，省略掉了網(wǎng)絡管理維護負載均衡服務器的麻煩，同時許多DNS服務

13、還支持基于地理位置的域名解析。缺點是，目前的DNS是多級解析，每一級DNS都可能緩存A記錄，當下線某臺服務器后，即使修改了DNS的A記錄，要使其生效也需要較長時間，這段時間，DNS依然會將域名解析到已經(jīng)下線的服務器，導致用戶訪問失敗，而且DNS負載均衡的控制權在域名服務商那里，網(wǎng)站無法對其做更多改善和更強大的管理。 事實上，大型網(wǎng)站總是部分使用DNS域名解析，利用域名解析作為第一級負載均衡手段，即域名解析得到一組服務器并不是實際提供的Web服務的物理服務器，而是同樣提供負載均衡服務的內部服務器，這組內部負載均衡服務器再進行負載均衡，將請求分發(fā)到真實的服務器。（3）反向代理負載均衡 反向代理服務

14、器處于Web服務器前面，這個位置也正好是負載均衡服務器的位置，所以大多數(shù)反向代理服務器同時提供負載均衡的功能，管理一組Web服務器，將請求根據(jù)負載均衡算法轉發(fā)到不同的Web服務器。Web服務器處理完成的響應也需要通過反向代理服務器返回給用戶。由于Web服務器不直接對外提供訪問，因此Web服務器不需要使用外部IP地址，而反向代理服務器則需要配置雙網(wǎng)卡和內部外部兩套IP地址。 優(yōu)點是部署簡單，缺點是可能成功系統(tǒng)的瓶頸。（4）IP負載均衡 IP負載均衡，即在網(wǎng)絡層通過修改請求目標地址進行負載均衡。 用戶請求數(shù)據(jù)包到達負載均衡服務器后，負載均衡服務器在操作系統(tǒng)內核進行獲取網(wǎng)絡數(shù)據(jù)包，根據(jù)負載均衡算法計

15、算得到一臺真實的WEB服務器地址，然后將數(shù)據(jù)包的IP地址修改為真實的WEB服務器地址，不需要通過用戶進程處理。真實的WEB服務器處理完畢后，相應數(shù)據(jù)包回到負載均衡服務器，負載均衡服務器再將數(shù)據(jù)包源地址修改為自身的IP地址發(fā)送給用戶瀏覽器。 這里的關鍵在于真實WEB服務器相應數(shù)據(jù)包如何返回給負載均衡服務器，一種是負載均衡服務器在修改目的IP地址的同時修改源地址，將數(shù)據(jù)包源地址改為自身的IP，即源地址轉換（SNAT），另一種方案是將負載均衡服務器同時作為真實物理服務器的網(wǎng)關服務器，這樣所有的數(shù)據(jù)都會到達負載均衡服務器。 IP負載均衡在內核進程完成數(shù)據(jù)分發(fā)，較反向代理均衡有更好的處理性能。但由于所有

16、請求響應的數(shù)據(jù)包都需要經(jīng)過負載均衡服務器，因此負載均衡的網(wǎng)卡帶寬成為系統(tǒng)的瓶頸。（5）數(shù)據(jù)鏈路層負載均衡 顧名思義：數(shù)據(jù)鏈路層負載均衡是指在通信協(xié)議的數(shù)據(jù)鏈路層修改mac地址進行負載均衡，如下圖： 這種數(shù)據(jù)傳輸方式又稱作三角傳輸模式，負載均衡數(shù)據(jù)分發(fā)過程中不修改IP地址，只修改目的的mac地址，通過配置真實物理服務器集群所有機器虛擬IP和負載均衡服務器IP地址一致，從而達到負載均衡，這種負載均衡方式又稱為直接路由方式（DR）. 用戶請求到達負載均衡服務器后，負載均衡服務器將請求數(shù)據(jù)的目的mac地址修改為真是WEB服務器的mac地址，并不修改數(shù)據(jù)包目標IP地址，因此數(shù)據(jù)可以正常到達目標WEB服務

17、器，該服務器在處理完數(shù)據(jù)后可以經(jīng)過網(wǎng)管服務器而不是負載均衡服務器直接到達用戶瀏覽器。 使用三角傳輸模式的鏈路層負載均衡是目前大型網(wǎng)站所使用的最廣的一種負載均衡手段。在linux平臺上最好的鏈路層負載均衡開源產(chǎn)品是LVS(linux virtual server)。（6）負載均衡算法 負載均衡服務器的實現(xiàn)可以分成兩個部分：（1）根據(jù)負載均衡算法和WEB服務器列表計算得到集群中一臺WEB服務器的地址；（2）將請求數(shù)據(jù)發(fā)送到改地址對應的WEB服務器上。 常用的負載均衡算法如下幾種：（1）輪詢：即將請求依次分發(fā)到每臺應用服務器上，每臺服務器需要處理的請求數(shù)目都相同，適合于所有服務器硬件都相同的場景。（

18、2）加權輪詢：根據(jù)應用服務器硬件性能情況，在輪詢的基礎上，安裝配置的權重將請求分發(fā)到每個服務器。（3）隨機：將請求隨機分配到各個應用服務器，好的隨機數(shù)本身就很均衡。（4）最少連接：記錄每個服務器正在處理的連接數(shù)，將新到的請求分發(fā)到最少連接的服務器上。同時可以實現(xiàn)加權。（5）原地址散列：根據(jù)請求來源的IP地址進行Hash計算，得到應用服務器，這樣來自同一個IP地址請求總在同一個服務器上處理。3. 分布式緩存集群的伸縮性設計 分布式緩存集群伸縮性設計的最主要目標即：必須讓新上線的緩存服務器對整個分布式緩存集群影響最小，也就是說新加入緩存服務器后應使整個緩存服務器集群中已經(jīng)緩存的數(shù)據(jù)盡可能還被訪問到

19、。（1）余數(shù)Hash 余數(shù)Hash可以保證緩存數(shù)據(jù)在整個緩存服務器集群中比較均衡地分布。如果不需要考慮緩存服務器集群伸縮性，余數(shù)Hash乎能滿足絕大多數(shù)的緩存路由需求。 余數(shù)Hash伸縮時改變機器數(shù)量（除數(shù)）使緩存節(jié)點幾乎不能命中。一種解決辦法是在網(wǎng)站訪問量最小的時候擴容緩存服務器集群，這時候對數(shù)據(jù)庫的負載沖擊最小。然后通過模擬請求的方法逐漸預熱緩存，使緩存中的數(shù)據(jù)重新分布，但需要技術團隊通宵加班。（2）分布式緩存的一致性Hash算法 一致性hash算法通過一個叫做一致性hash環(huán)的數(shù)據(jù)結構實現(xiàn)KEY到緩存服務器的Hash映射。 具體算法過程為：先構造一個長度為二的32次方的整數(shù)環(huán)，根據(jù)節(jié)點名

20、稱的Hash值（02的31次方）將緩存服務器節(jié)點放置在這個Hash環(huán)上。然后根據(jù)需要緩存的數(shù)據(jù)的KEY值計算得到其Hash值，然后在Hash環(huán)上順時針查找距離這個KEY的Hash值最近的緩存服務器節(jié)點，完成KEY到服務器的Hash映射查找。 由于KEY是順時針查找距離其最近的節(jié)點，因此伸縮時新加入一個節(jié)點只影響整個環(huán)中的一小段。 如果使用直接查找節(jié)點，那么當新添加一臺緩存服務器時，只是影響到了其中一臺緩存服務器，其他兩頭緩存服務器的壓力并沒有得到緩解，因此此方案還是存在問題。一種替代的方案就是增加一個虛擬層，即把每臺緩存服務器虛擬為一組服務器平均放到上面的環(huán)里面。這樣當新增加緩存服務器時，把新

21、增加的虛擬節(jié)點平均分配到環(huán)中，這樣就能緩解每臺緩存服務器，達到分布式緩存集群高伸縮性。一般，一臺物理服務器虛擬為150個虛擬服務器合適。 計算機的任何問題都可以通過增加一個虛禮層來解決。4. 數(shù)據(jù)存儲服務器集群的伸縮性設計 和緩存服務器集群的伸縮性設計不同，數(shù)據(jù)存儲服務器集群的伸縮性對數(shù)據(jù)的持久性和可用性提出了更高的要求。（1）關系數(shù)據(jù)庫集群的伸縮性設計 主要的關系數(shù)據(jù)庫都支持數(shù)據(jù)復制功能，使用這個功能可以對數(shù)據(jù)庫進行簡單伸縮。 數(shù)據(jù)庫主從讀寫分離外； 利用業(yè)務分隔模式使不同業(yè)務的數(shù)據(jù)表部署在不同的數(shù)據(jù)庫集群上，即俗稱的數(shù)據(jù)分庫。但是這種方式的制約條件時跨庫不能進行join操作。 對一些單表數(shù)

22、據(jù)任然很大的表還需要進行分片，將一張表拆開分別存儲在多個數(shù)據(jù)庫中。目前支持分布式數(shù)據(jù)分片的關系數(shù)據(jù)庫產(chǎn)品主要有開源的Amoeba和Cobar（阿里巴巴），下圖為Cobar部署模型。 Cobar是一個分布式關系數(shù)據(jù)庫訪問代理，介于應用服務器和數(shù)據(jù)庫服務器之間。應用程序通過JDBC驅動訪問Cobar集群，Cobar服務器根據(jù)SQL和分庫規(guī)則分解SQL，分發(fā)到MySQL集群不同的數(shù)據(jù)庫實例上執(zhí)行（每個MySQL實例都部署為主/從結構，保證數(shù)據(jù)高可用）。 前端通信模塊負責和應用程序通信，接搜到SQL請求（select * from users where userid in (12,22,23)）后轉

23、交給SQL解析模塊，SQL解析模塊解析獲得SQL中的路由規(guī)則查詢條件（userid in （12,22,23）再轉交給SQL路由模塊，SQL路由模塊根據(jù)路由規(guī)則配置（userid為偶數(shù)路由至數(shù)據(jù)庫A，奇數(shù)則路由至數(shù)據(jù)庫B）將應用程序提交的SQL分解成兩條SQL(select * from users where userid in (12,22)；select * from users where userid in (23)轉交給SQL執(zhí)行代理模塊，發(fā)送至數(shù)據(jù)庫A和數(shù)據(jù)庫B分別執(zhí)行。數(shù)據(jù)庫A和數(shù)據(jù)庫B的執(zhí)行結果返回至SQL執(zhí)行模塊，通過結果合并模塊將兩個返回結果集合并成一個結果集，最終返回該

24、應用程序，完成在分布式關系數(shù)據(jù)庫中的一次訪問請求。 Cobar的伸縮有兩點：Cobar服務器集群的伸縮和MySQL服務器集群的伸縮。 Cobar服務器可以看做是無狀態(tài)的應用服務器，因此其集群伸縮可以簡單實用負載均衡的手段實現(xiàn)。而MySQL中存儲著數(shù)據(jù)，要保證集群擴容后數(shù)據(jù)一致負載均衡，必須要做數(shù)據(jù)遷移，如下圖（利用數(shù)據(jù)同步功能進行數(shù)據(jù)遷移）。（2）NoSQL數(shù)據(jù)庫的伸縮設計 NoSQL主要是指非關系的、分布式的數(shù)據(jù)庫設計模式。一般而言，NoSQL數(shù)據(jù)庫產(chǎn)品都放棄了關系數(shù)據(jù)庫的兩大重要基礎：以關系代數(shù)為基礎的結構化查詢語言（SQL）和事物一致性保證（ACID），而強化了高可用性和可伸縮性。目前應

25、用最廣泛的是Apache HBase。 HBase的伸縮性主要依賴其可分裂的HRegion及可伸縮的分布式文件系統(tǒng)HDFS實現(xiàn)。 HBase中，數(shù)據(jù)以HRegion為單位進行管理，應用程序如果想要訪問一個數(shù)據(jù)，必須先找到HRegion，然后將數(shù)據(jù)讀寫操作提交給HRegion，由HRegion完成存儲層面的數(shù)據(jù)操作。每個HRegion中存儲一段Key值區(qū)間（k1k2）的數(shù)據(jù)，HRegionServer是物理服務器，每個HRegionServer上可以啟動多個HRegion實例，當一個HRegion中寫入的數(shù)據(jù)太多，達到配置的閾值時，HRegion會分裂成兩個HRegion，并將HRegion在整

26、個集群中進行遷移，以使HRegionServer負載均衡。 所有的HRegion的信息都記錄在HMaser服務上，為了保證高可用性，HBase啟動多個HMaser，并通過Zookeeper選舉一個Master，應用程序通過Zookeeper獲得主HMaser的地址，輸入Key值獲得這個Key所在的HRegionServer地址，然后請求HRegionServer上的HRegion，獲得需要的數(shù)據(jù)。六、網(wǎng)站的可擴展架構-隨需應變 擴展性是指對現(xiàn)有系統(tǒng)影響最小的情況下，系統(tǒng)功能可持續(xù)擴展或提升的能力。表現(xiàn)在系統(tǒng)基礎設施不需要經(jīng)常變更，應用之間較少依賴和耦合，對需求變更可以敏捷響應。它是系統(tǒng)架構設計

27、層面的開閉原則（對擴展開放，對修改關閉），架構設計考慮未來功能擴展，當系統(tǒng)增加新功能時，不需要對現(xiàn)有系統(tǒng)的結構和代碼進行修改。 軟件架構師最大的價值不在于掌握多少先進的技術，而在于具有將一個大系統(tǒng)切分成N個低耦合的子模塊的能力，這些子模塊包含橫向的業(yè)務模塊，也包含縱向的基礎技術模塊。 設計網(wǎng)站可擴展架構的核心思想是模塊化，并在此基礎上，降低模塊間的耦合性，提供模塊的復用性。模塊通過分布式部署，獨立的模塊部署在獨立的服務器上（集群）從物理上分離模塊之間的耦合關系。1. 利用分布式消息隊列降低系統(tǒng)耦合性 事件驅動框架：通過在低耦合的模塊之間傳輸事件消息，以保持模塊的松散耦合，并借助事件消息的通信完

28、成模塊間合作，典型的架構就是生產(chǎn)者消費者模式。在大型網(wǎng)站架構中，具體實現(xiàn)手段很多，最常用的就是分布式消息隊列。 消息隊列利用發(fā)布-訂閱模式工作，消息發(fā)送者發(fā)布消息，一個或者多個消息接收者訂閱消息。 由于消息發(fā)送者不需要等待消息接受者處理數(shù)據(jù)就可以返回，系統(tǒng)具有更好的響應延遲；同時，在網(wǎng)站訪問高峰，消息可以暫時存儲在消息隊列中等待處理，減輕數(shù)據(jù)庫等后端存儲的負載壓力。 目前開源的和商業(yè)的分布式消息隊列產(chǎn)品有很多，比較著名的有Apache ActiveMQ等。2. 利用分布式服務打造可復用的業(yè)務平臺 分布式服務則通過接口分解系統(tǒng)耦合性，不同子系統(tǒng)通過相同的接口描述進行服務調用。 巨無霸應用存在的問題：編譯、部署困難，代碼分支管理困難，數(shù)據(jù)庫連接耗盡，新增業(yè)務困難。 解決方案就是拆分，將模塊獨立部署，降低系統(tǒng)耦合性。（1）Web Service Web Service用以整合異構系統(tǒng)及構建分布式系統(tǒng)。 服務提供者通過WSDL（Web服務描述語言）向注冊中心描述自身提供的服務接口屬性，注冊中心使用UDDI（統(tǒng)一描述、發(fā)現(xiàn)和集成） 發(fā)