軟體測驗回顧(11)

網站架構設計

• 軟體測驗回顧(11)
  • 48章：測驗工程師為什么要懂網站架構設計？
    • 測驗工程師怎么學架構知識？
  • 49章：網站高性能架構設計
    • 前端的高性能架構
    • 后端服務器的高性能架構
      • 快取：
      • 集群：
  • 50章：網站高可用架構設計
    • 1.網站不可用原因
      • 1.服務器硬體故障
      • 2.發布新應用的程序
      • 3.應用程式本身的問題
    • 網站高可用架構設計
      • 1.硬體層面加入必要的冗余
      • 2.灰度發布
      • 加強上線前的測驗+啟用預發布驗證
  • 51章：網站伸縮性架構設計
    • 分層的可伸縮性架構
      • 物理分離后的單一功能通過增加或者減少硬體來實作伸縮
      • 應用服務器的可伸縮性設計
      • 快取集群的可伸縮性設計
      • 資料庫的可伸縮性設計
  • 52章：網站可擴展架構設計
    • 事件驅動架構與訊息佇列

48章：測驗工程師為什么要懂網站架構設計？

不懂得網站架構設計知識，在開展測驗時，就真的會有處處被掣肘的感覺了，更別提，這還會直接影響到你的能力提升和職業發展了，

傳統軟體企業,網站的架構設計知識對你來說可能沒那么重要，想跳出傳統軟體產品測驗這個舒適區的話，而在互聯網企業進行軟體測驗的話，很多時候需要針對互聯網的架構來設計有針對性的測驗，另外對于互聯網的壓力測驗以及結果分析也需要對架構知識有比較清楚的認識，

很多時候，你只是知道網站在架構設計上有這些組件，并不清楚這些組件真正的作用，在對應的測驗設計時也很難做到“有的放矢”，

測驗工程師怎么學架構知識？

同樣是對架構知識的學習和掌握，不同角色的工程技術人員都有不同的視角，需要了解和掌握的全域知識和細節程度也各不相同，

對于測驗人員來講，學習架構知識應該有自己獨特的視角，基本只要做到清楚原理、了解在被測系統中的部署架構，從測驗的角度能夠呼叫必要的介面就可以了，

根據我的個人經驗，我認為應該遵循“由廣度到深度”和“自上而下”兩個基本原則，

“由廣度到深度”中的“廣度”是指在平時作業以外的時間中，應該多注重全領域架構知識的積累，此時那些系統性地介紹架構知識的書籍或者專欄就可以給你最大程度的幫助了，

推薦極客時間李運華老師的“從0開始學架構”專欄，以及李智慧老師所著的圖書《大型網站技術架構：核心原理與案例分析》，它們都能幫你從廣度上積累架構知識，

“由廣度到深度”的“深度”是指，對于架構中某一領域的特定知識在專案中要實際使用的時候，必須要刨根問底，通過實際的測驗來加深對架構知識細節的理解，

“自上而下”是指，在實際測驗專案中，當需要設計涉及架構的測驗用例和場景的時候，千萬不要直接基于“點”來設計測驗，而是應該：首先通過全域閱讀理解上層架構設計；然后，在理解了架構設計的初衷和希望達成目的的基礎上，再向下設計測驗場景和用例，

對于架構知識的學習沒有任何捷徑可走，你必須一步一個腳印，才能達到下一個高峰，

接下來4章會分享網站的高性能架構、高可用架構、伸縮性架構以及擴展性架構，

49章：網站高性能架構設計

為了優化網站性能，業界出現了很多相關的架構改進方案和技術手段，單單依靠幾篇文章是很難講清楚的，從中精選了一些對測驗工程師比較關鍵的概念和技術，和你展開今天的分享，

網站的高性能架構設計包括兩大部分內容：一是前端性能，二是后端服務器相關的性能優化和架構設計，

前端的高性能架構

前端高性能架構比較直觀易懂，其本質就是通過各種技術手段去優化用戶實際感受到的前端頁面展現時間，

前端性能優化的方法是相對標準的，而且，目前的前端性能測驗工具，比如我在前面文章中曾經介紹過的WebPageTest和YSlow之類的工具等，都能系統性地分析前端的性能問題，并給出對應的解決方案建議，

后端服務器的高性能架構

后端服務器的高性能架構，業內采用的最主要的技術手段是快取，同時，集群也可以從計算能力的角度，提升后端的處理性能，

快取：

• 從快取中讀取資料的速度更快，
• 無需再重復計算即可直接使用，(降低后端運算負載的作用)

在系統和軟體的不同級別對應有不同層級的快取：

• 瀏覽器級別的快取，會用來存盤之前在網路上下載過的靜態資源；
• CDN本質也是快取，屬于部署在網路服務供應商機房中的快取；
• 反向代理服務器本質上同樣也是快取，屬于用戶資料中心最前端的快取；
• 資料庫中的“熱點”資料，在應用服務器集群中有一級快取，在快取服務集群中有二級快取；
• 甚至是用于URL和服務器IP地址轉換DNS服務器，為了減少重復查詢的次數也采用了快取，

啟用了快取后，當應用程式需要讀取資料時，會先試圖從快取中讀取：

• 如果讀取成功，我們稱為快取命中，此時就可以在很大程度上降低訪問資料庫的時間開銷，
• 如果沒有讀取到資料或者快取中的資料已經過期失效，那么應用程式就會訪問資料庫去獲取相應的資料，獲取到資料后，在把資料回傳給應用程式的同時，還會把該資料寫入到快取中，以備下次使用，

快取主要用來存盤那些相對變化較少，并且遵從“二八原則”的資料，這里的“二八原則”指的是80%的資料訪問會集中在20%的資料上，

如果我們將這20%的資料快取起來，那么這些資料就會具有非常高的讀寫比，讀寫比越高，說明快取中的資料被使用的次數也就越多，從而節省的資料庫訪問也就越多，快取的優勢也就越明顯，

快取技術并不適用于那些需要頻繁修改的資料，對于這種需要頻繁修改的資料來說，經常會出現剛剛寫入快取的資料還沒來得及被讀取就已經失效了的場景，所以，在這種情況下，快取不僅不會帶來性能提升，反而會增加系統開銷，

現在的資料庫已經習慣了有快取的日子，假如哪天快取系統奔潰了，就會在短時間內有大量的請求來訪問資料庫，資料庫就很可能會因為無法承受這樣的并發壓力而宕機，

為了解決這個問題，有些網站會使用快取熱備等技術手段來提供快取的高可用性，即：當某臺快取服務器宕機的時候，會將快取訪問切換到熱備的快取服務器上，

如果你采用了分布式快取服務器集群的話，那么快取的資料將被分布到集群中的多臺服務器上，當其中一臺服務器宕機的時候，也只會丟失一部分快取資料，此時通過訪問資料庫來重建這些快取資料的開銷并不算太大，

分布式快取架構的主流技術方案有兩種：

• 一種是，在企業級應用中廣泛采用的JBoss Cache，JBoss Cache需要在快取集群中的每臺機器上同步所有快取的副本，當集群規模比較大的時候，同步代價會很高，而且，多份副本也會造成存盤資源的浪費，但其最大的優點是速度非常快，所以JBoss Cache更適用于企業級規模不是很大的快取集群，這種企業級的集群一般在幾臺到十幾臺服務器的規模，

• 另一種是，在互聯網應用的主流Memcached，Memcached屬于互不通信的分布式架構，集群中各個節點快取的資料都不一樣，快取使用者基于Hash一致性演算法來定位具體的內容到底快取在集群中的哪個節點，
  因此，Memcached具有快取容量大，存盤效率高，可以很方便地支持集群的擴展，但是速度相對較慢的特點，這些特點決定了Memcached非常適用于現如今的互聯網產品架構，幾乎成為了網站分布式快取架構的代名詞，

互聯網產品架構的應用服務器集群規模一般都很大，即使小規模的應用集群也有上百臺機器，規模大的話可以達到上萬臺，這種架構下的快取集群規模要求也非常大，

從測驗人員的視角來看看，在執行測驗時需要考慮到哪些與快取相關的測驗場景：

• 對于前端的測驗場景，需要分別考慮快取命中和快取不命中情況下的頁面加載時間，
• 基于快取過期測驗策略的設計，需要考慮到必須要重新獲取資料的測驗場景，
• 需要針對可能存在的快取“臟資料”，進行有針對性的測驗，快取“臟資料”，是指資料庫中的資料已經更新，但是快取中的資料還沒來得及更新的場景，
• 需要針對可能的快取穿透進行必要的測驗，快取穿透，是指訪問的資料并不存在，所以這部分資料永遠不會有被快取的機會，因此此類請求會一直重復訪問資料庫，
• 系統冷啟動后，在快取預熱階段的資料庫訪問壓力是否會超過資料庫實際可以承載的壓力，
• 對于分布式快取集群來說，由于各集群使用的快取演算法不同，那么如果要在快取集群中增加更多節點進行擴容的話，擴容對原本已經快取資料的影響也會不同，所以，我們需要針對快取集群擴容的場景，進行必要的測驗和性能評估，

集群：

集群也是提升網站性能和并發處理能力的典型架構設計方法，

當一臺服務器不足以滿足日益增長的用戶流量時，我們就可以考慮使用多臺服務器來組成一個集群：外部請求將統一和負載均衡器打交道；負載均衡器根據不同的負載調度演算法，將訪問請求傳遞給集群中的某臺服務器處理，

集群中的任何一臺服務器宕機都不會給整個系統帶來明顯的影響，我們可以直接替換掉出現了問題的某臺服務器，集群中的每臺服務器都可以被隨時替換或者淘汰掉，就像“牲口”似的可以任人宰割，所以，這種模式，就有點類似于“牲口”模式，

與“牲口”模式對應的是“寵物”模式，比如一些企業級的應用，它們往往不通過集群來擴展系統的能力和提高系統的性能，而是采用更為強勁的服務器，

綜上所述，現今的互聯網應用采用的都是“牲口”模式，在這種模式下，我們在開展測驗時，相應地需要額外關注以下這些測驗點：

• 集群容量擴展，也就是說，集群中加入新的節點后，是否會對原有的session產生影響，
• 對于無狀態應用，是否可以實作靈活的實效轉移，
• 對于基于session的有狀態應用，需要根據不同的session機制驗證會話是否可以正常保持，即保證同一session始終都有同一個確定的節點在處理，
• 當集群中的一個或者多個節點宕機時，對在線用戶的影響是否符合設計預期，
• 對于無狀態應用來說，系統吞吐量是否能夠隨著集群中節點的數量呈線性增長，
• 負載均衡演算法的實際效果，是否符合預期，
• 高并發場景下，集群能夠承載的最大容量，

50章：網站高可用架構設計

網站高可用指的就是，在絕大多的時間里，網站一直處于可以對外提供服務的正常狀態，

業界通常使用有多少個“9”來衡量網站的可用性指標，具體的計算公式也很簡單，就是一段時間內（比如一年）網站可用的時間占總時間的百分比，

我用下面這個表格，列出了四種最常見的可用性等級指標，以及允許的系統不可用時長，

一般來講，業界的網站能做到4個“9”，也就是說在一年內只有53分鐘的時間網站是處于不可用狀態，就已經是算是非常優秀了，

1.網站不可用原因

造成網站不可用的主要原因有以下三大類：

1. 服務器硬體故障；
2. 發布新應用的程序；
3. 應用程式本身的問題，

1.服務器硬體故障

某臺服務器由于硬體故障宕機，可以說不是偶然，而是必然會發生的，網站后臺的服務器數量也越來越多，所以由硬體故障引起問題的概率也是不斷飆升，

2.發布新應用的程序

網站的新版本發布程序中，往往會出現需要重新部署新的應用程式版本，然后再重啟服務的情況，

如果這個更新程序中不采用特殊技術手段的話，也會造成短暫的服務不可用，而且這種形式的不可用，相比服務器硬體故障的不可用更為常見，

互聯網網站的功能更新迭代非常快，基本都是以“天”為單位來發布上線的，也就是說幾乎每天都有需要中斷服務來完成服務升級的可能，

顯然，從業務角度來看，這種為了應用升級造成的服務不可用，完全不可能被接受，這就好比eBay或者淘寶告訴你說，我們每天某個時間段需要內部升級維護無法對外提供服務一樣，讓人無法接受，，因此，我們的高可用架構設計必須能夠提供切實可行的方案，將這種停機升級的影響降到最小，

3.應用程式本身的問題

發布的應用程式版本身存在潛在的記憶體泄露，那么經過較長時間的運行積累后，最侄訓造成服務器的記憶體被占滿，之后必須要靠重啟服務來恢復，

應用程式在測驗環境沒有經過充分的測驗驗證，或者說由于測驗環境的配置和實際生產環境之間存在差異，有可能造成應用程式在生產環境部署完后無法使用的情況，從而造成服務不可用，

網站高可用架構設計

們在網站高可用架構設計上，探索出了對應的三類方法，

• 第一類方法是，從硬體層面加入必要的冗余；
• 第二類方法是，灰度發布；
• 第三類方法是，加強應用上線前的測驗，或者開啟預發布驗證，

1.硬體層面加入必要的冗余

對于第一類硬體故障造成的網站不可用，最直接的解決方案就是從硬體層面加入必要的冗余，同時充分發揮集群的“牲口”優勢，

比如，對于應用服務器來說，即使沒有伸縮性的要求，我們也會至少采用兩臺同樣的服務器，并且引入一臺額外的負載均衡器，所有的外部請求會先到負載均衡器，然后由負載均衡器根據不同的分配演算法選擇其中的某一臺服務器來提供服務，

因此，從測驗人員的角度來看，知道了應用服務器集群的作業原理，就可以在設計測驗的時候，針對集群中的某一個或者某幾個節點的故障情況設計測驗用例，

再比如，對于資料存盤的服務器來說，往往通過資料冗余備份和失效轉移機制來實作高可用，為了防止存盤資料的服務器發生硬體故障而造成資料丟失，我們往往會引入多個資料存盤服務器，并且會在資料有更新操作的時候自動同步多個資料存盤服務器上的資料，

從測驗人員的角度來看，我們依舊可以針對這種情況設計出針對部分資料服務器發生故障時的測驗用例，以完成系統應對故障的反應情況的測驗

2.灰度發布

由于發布新應用造成的系統不可用，我們采用的主要技術手段是灰度發布，

使用灰度發布的前提是，應用服務器必須采用集群架構，假定現在有一個包含100個節點的集群需要升級安裝新的應用版本，那么這個時候的更新程序應該是：

• 首先，從負載均衡器的服務器串列中洗掉其中的一個節點；
• 然后，將新版本的應用部署到這臺洗掉的節點中并重啟該服務；
• 重啟完成后，將包含新版本應用的節點重新掛載到負載均衡服務器中，讓其真正接受外部流量，并嚴密觀察新版本應用的行為；
• 如果沒有問題，那么將會重復以上步驟將下一個節點升級成新版本應用，如果有問題，就會回滾這個節點的上一個版本，
• 如此反復，直至集群中這100個節點全部更新為新版本應用，

在這個升級的程序中，服務對外來看一直處于正常狀態，宏觀上并沒有出現系統不可用的情況，就好比是為正在飛行中的飛機更換引擎，而飛機始終處于“正常飛行”的狀態一樣，

加強上線前的測驗+啟用預發布驗證

對于第三類應用程式本身的問題造成的系統不可用，我們一方面要加強應用程式上線部署前的測驗以保證應用本身的質量，另一方面需要啟用所謂的預發布驗證，

我們一定遇到過這樣的尷尬情況：應用在測驗環境中經過了完整、全面的測驗，并且所有發現的缺陷也已經被修復并驗證通過了，可是一旦發布到了生產環境，還是立馬暴露出了很多問題，

這其中的主要原因是，測驗環境和生產環境存在差異，

為了避免這類由于環境差異造成的問題，我們往往會預發布服務器，預發布服務器和真實的服務所處的環境沒有任何差別，連接的第三方服務也沒有任何差別，唯一不同的是預發布服務器不會通過負載均衡服務器對外暴露，只有知道其IP地址的內部人員才可以對其進行訪問，此時，我們就可以借助自動化測驗來對應用做快速的驗證測驗，

51章：網站伸縮性架構設計

可伸縮性翻譯自Scalability，指的是通過簡單地增加硬體配置而使服務處理能力呈線性增長的能力，最簡單直觀的例子，就是通過在應用服務器集群中增加更多的節點，來提高整個集群的處理能力，

可擴展性翻譯自Extensibility，指的是網站的架構設計能夠快速適應需求的變化，當需要增加新的功能實作時，對原有架構不需要做修改或者做很少的修改就能夠快速滿足新的業務需求，

分層的可伸縮性架構

網站的可伸縮性架構設計主要包含兩個層面的含義：

• 1 根據功能進行物理分離來實作伸縮；
• 2 物理分離后的單一功能通過增加或者減少硬體來實作伸縮，

物理分離后的單一功能通過增加或者減少硬體來實作伸縮

• 縱向的可伸縮性，指的是通過增加單一服務器上的硬體資源來提高處理能力，
• 橫向的可伸縮性，指的是通過使用服務器集群來實作單一功能的可擴展性，
  • 這種方式是基于集群的可伸縮性實作的，也是目前最主流的網站可伸縮性方法，也就是我之前提到過的“牲口”模式，很多時候當我們談及網站的可伸縮性設計時，如果沒有特定的背景關系或者特指的場景，往往指的都是基于集群的可伸縮性，

基于集群的可伸縮性設計，是和網站本身的分層架構設計相對應的：

• 在應用服務器層面有應用服務器集群的可伸縮性架構設計；
• 在快取服務器層面有快取服務器的可伸縮性架構設計；
• 在資料庫層面有資料庫服務器的可伸縮性架構設計，

應用服務器的可伸縮性設計

當一臺應用服務器不足以支撐業務流量的時候，我們就可以用多臺服務器來分擔業務流量，

為了保證這批服務器對外暴露的是一個統一的節點，我們就需要一個負載均衡器作為統一的視窗來對外提供服務，同時負載均衡器會把實際的業務請求轉發給集群中的機器去具體執行，通過負載均衡演算法（比如輪詢演算法、基于加權的輪詢演算法、最小鏈接演算法等）將用戶流量分配到集群機器，從這個意義上說，將負載均衡器稱為任務分配器才更合適，

為了實作線性可伸縮性，我們希望應用本身是無狀態的，此時，任何請求都可以在集群中任意節點上來執行，也就是說集群的處理能力將隨著節點數量的增多呈現線性增長的態勢，

但是，如果應用本身是有狀態的，那么就會要求基于一次會話（session）的多次請求都被分配到集群中某一臺固定的服務器上去執行，

從測驗人員的角度來想想，應該考慮哪些相關的測驗場景，為此，我總結了以下幾點供你參考：

• 需要通過壓力測驗來得出單一節點的負載承受能力；
• 驗證系統整體的負載承受能力，是否能夠隨著集群中的節點數量呈現線性增長；
• 集群中節點的數量是否有上限；
• 新加入的節點是否可以提供和原來節點無差異的服務；
• 對于有狀態的應用，是否能夠實作一次會話（session）的多次請求都被分配到集群中某一臺固定的服務器上；
• 驗證負載均衡演算法的準確性，

快取集群的可伸縮性設計

傳統的快取服務器集群是無法通過簡單地加入新的節點來實作擴容的，

假定，一個快取集群中有3臺機器，那么我們在將需要快取的內容存入快取集群的程序，包括了這三步：

• 首先，將需要快取的內容的Key值做Hash運算；
• 然后，將得到的Hash值對3取余數；
• 最后，將快取內容寫入余數所代表的那臺服務器，

而此時，如果我們在快取集群中加入了一臺新的機器，也就是說快取集群中機器的數量變成了4，這時Key的Hash值就應該對4取余，你會發現這么一來，原本已經快取的絕大多數內容就都失效了，必須重構整個快取集群，而這，顯然不能被接受，

使得快取集群也可以做到按需、高效地伸縮，那就必須采用更為先進的Hash一致性演算法，

道了快取集群擴容的實作細節后，我們再從測驗人員的角度出發：

• 針對快取集群中新增節點的測驗，驗證其對原有快取的影響是否足夠小；
• 驗證系統冷啟動完成后，快取中還沒有任何資料的時候，如果此時網站負載較大，資料庫是否可以承受這樣的壓力；
• 需要驗證各種情況下，快取資料和資料庫資料的一致性；
• 驗證是否已經對潛在的快取穿透攻擊進行了處理，因為如果有人刻意利用這個漏洞來發起海量請求的話，就有可能會拖垮資料庫，

資料庫的可伸縮性設計

從實際應用的角度來看，資料庫的可伸縮性設計主要有四種方式：

• 第一種方式是目前最常用的業務分庫將一個龐大的資料庫拆分成多個不同的資料庫，比如，對于電商網站來說，它們可以考慮將用戶相關的表放在一個資料庫中，而商品相關的表放在另一個資料庫中，
  • 但最大的問題是跨資料庫資料的join操作只能通過代碼在記憶體中完成，實作代價和成本都比較高，這種方式目前在一些中大型電商有不同程度的應用，
• 第二種方式是讀寫分離的資料庫設計其中主庫用于所有的寫操作，從庫用于所有的讀操作，然后主從庫會自動進行資料同步操作，
  • 這個架構最大的問題在于可能出現資料不一致的情況，比如，寫入的資料沒能及時同步到從庫，就可能會出現資料不一致，另外，這種讀寫分離的設計對資料庫可伸縮性的貢獻來講，比較有限，很難從根本上解決問題，
  • 主要應用在中小型規模的網站中，同時讀寫分離的設計也通常會和業務分庫的設計一起采用，來提高業務分庫后的資料庫性能，
• 第三種資料庫的可伸縮性設計：分布式資料庫，
  • 分布式資料庫同樣存在資料不一致的問題，并且，這個方法通常只在單個資料表例外龐大的時候才會被采用，否則我還是更推薦業務分庫的方法，
  • 這種資料庫設計可以說是比較主流的應對大規模高并發應用的資料庫方案，
• 第四種方式則是完全顛覆了傳統關系型資料資料庫的NoSQL設計，
  • NoSQL放棄了事務一致性，并且天生就是為了可伸縮性而設計的，所以在可伸縮性方面具有天然優勢，因此，在互聯網領域被廣泛使用，

從測驗的角度出發，無論是資料庫架構哪種設計，我們一般都會從以下幾個方面來考慮測驗用例的設計：

• 正確讀取到剛寫入資料的延遲時間；
• 在資料庫架構發生改變，或者同樣的架構資料庫引數發生了改變時，資料庫基準性能是否會發生明顯的變化；
• 壓力測驗程序中，資料庫服務器的各項監控指標是否符合預期；
• 資料庫在線擴容程序中對業務的影響程度；
• 資料庫集群中，某個節點由于硬體故障對業務的影響程度，

52章：網站可擴展架構設計

可擴展性，指的是網站的架構設計能夠快速適應需求的變化，當需要增加新的功能實作時，對原有架構不需要做修改或者做很少的修改就能夠快速實作新的業務需求，

提升網站可擴展性性的核心，就是降低系統各個模塊和組件之間的耦合，耦合程度越低，各個模塊和組件的復用可能性就越大，系統的可擴展性也會越好，

從現在來看，實作網站可擴展性架構的主要技術手段包括事件驅動架構和微服務架構，

微服務架構從根本上改變了網站的架構形式，帶來可擴展性便利的同時，還帶來了很多其他優秀的特性，在微服務架構下，一個大型復雜軟體系統不再由一個單體組成，而是由一系列的微服務組成，其中每個微服務可被獨立開發和部署，各個微服務之間是松耦合的，每個微服務僅專注于完成一件任務，并要很好地完成該任務，

在微服務架構下，當網站需要增加新功能時，我們除了可以添加新的業務邏輯外，還可以利用原本已經存在的微服務來構建新的功能，由于服務和服務之間是相互隔離的，并且單個服務還可以被其他多個服務復用，所以系統的可擴展性會比較好，

重點分享事件驅動架構是如何提升網站的可擴展性的，

而事件驅動架構的落地靠的是訊息佇列，所以我會同時和你分享訊息佇列的內容，最后，我會再和你分享引入了訊息佇列后，從測驗人員的角度來看會有哪些需要額外關注的點，

事件驅動架構與訊息佇列

系統各個模塊之間只是通過訊息佇列來傳輸事件訊息，而各模塊之間并沒有直接的呼叫關系、保持松散的耦合關系，

事件驅動架構最典型的一個應用就是作業系統中常見的生產者和消費者模式，將其應用到網站設計中就是分布式訊息佇列，

分布式訊息佇列同樣采用了生產者和消費者模式：

• 訊息的發送者負責將訊息發布到訊息佇列中，也就是“生產者”；
• 另外，系統中會有一個或者多個訊息接收者訂閱訊息，訂閱目的是為了獲取訊息并進行處理，這里的訊息訂閱者其實就是“消費者”，訊息接收者發現訊息佇列中有新的訊息后，就會立馬對其進行處理，

在這種模式下，訊息的發送者和接收者之間并沒有任何直接的聯系，是松耦合的，它們的協作是通過訊息佇列這個“中間人”進行的，訊息的發送者將訊息發送至訊息佇列后，就結束了對訊息的處理，而訊息的接收者只是從訊息佇列中獲取訊息進行后續的處理，并不需要知道這些訊息從哪里來，因此可以很方便地實作高可擴展性，

所以，采用這種模式的話，當網站需要增加新功能的時候，只要增加對應的新模塊，再由對此模塊感興趣的“消費者”進行訂閱，就可以實作對原有系統功能的擴展了，而對原本的系統模塊本身并沒有影響，

引入了訊息佇列后，我們不僅可以提高系統的可擴展性，還可以再一定程度上改善網站架構的高性能、高可用性和可伸縮性，

• 從性能方面來看，訊息發送者不需要等接收者實際處理完成后才回傳，也就是從原本的同步處理變成了異步處理，所以用戶會感知到網站性能的提升，
• 從高可用方面來看，假如訊息的接收者模塊發生了短時間的故障，此時并不會影響訊息發送者向訊息佇列中發送訊息，等到訊息接收者模塊恢復后可以繼續后續的處理，只要這段時間內訊息佇列本身沒有被塞滿而出現訊息丟失的情況，從整體角度看，系統并不會感知到訊息接收者模塊曾經發生過短暫故障，也就相當于保證了系統的高可用，
• 從可伸縮性方面來看，訊息佇列的核心其實就是一個無狀態的存盤，所以，當系統需要能夠保留更多的訊息時，我們通過簡單地增加存盤空間就可以實作，尤其是，大規模的電商網站來更會將訊息佇列擴展成為分布式訊息佇列集群，來實作訊息佇列的可伸縮性，

在測驗時需要特別關注哪些點:

• 從構建測驗資料的角度來看，為了以解耦的方式測驗系統的各個模塊，我們就需要在訊息佇列中構造測驗資料，這也是為什么很多互聯網的自動化測驗框架中都會集成有訊息佇列寫入工具的主要原因，
• 從測驗驗證的角度來看，我們不僅需要驗證模塊的行為，還要驗證模塊在訊息佇列中的輸出是否符合預期，為此，互聯網的自動化測驗框架中也都會集成訊息佇列的讀取工具，
• 從測驗設計的角度來看，我們需要考慮訊息佇列滿、訊息佇列擴容等情況下系統功能是否符合設計預期，
• 除此之外，我們還需要考慮，某臺訊息佇列服務器宕機的情況下，丟失訊息的可恢復性以及新的訊息不會繼續發往宕機的服務器等等，

標籤：其他

上一篇：軟體測驗回顧(9)-準備測驗資料

下一篇：線性回歸：最小二乘法實作