上一篇：從零開始設計和搭建你的體育賽事比分網站 (2) - 需求整理

3 原型與架構設計

上一模塊中，我們分別從三個部分：需求的收集與劃分、需求的分析、需求的放大與匯總，以企業團隊中產品經理的角度，分析瞭如何進行體育賽事比分網站項目的需求整理。

而在這一模塊中，就模塊而言其實可以分成原型設計和架構設計兩個模塊來介紹，但是我們側重於架構設計的介紹，所以將這兩部分合併為一個模塊。本模塊將會分別從快速原型設計和網站架構設計兩部分出發，邁出體育賽事比分網站搭建的下一步。

3.1 快速原型設計

網站原型是設計方案的表達，是產品經理、交互設計師的產出物之一，也是項目團隊的其他成員的重要參考和評估的依據。網站原型其實也就是頁面界別的信息架構、文案設計以及頁面交互的綜合，是網站功能與內容的示意圖。

3.1.1 界定原型範圍

在設計網站原型之前，我們需要明確幾個關鍵性問題來界定原型範圍：

  • 什麼需要原型化？
    • 網站的優秀設計，比如複雜的交互、新添加的功能以及流程等；
    • 比如為用戶提供與眾不同的搜索體驗時，就需要原型化網站搜索結果，引入多面搜索或添加不離開搜索界面即可預覽文檔的功能等等；
  • 多少網站部件需要原型化？
    • 集中添加一些將來80%時間內會使用的20%的功能要素，即原型化一些最常用的關鍵性功能；
  • 設計原型故事場景
    • 確定了需要進行原型化的網站區域之後，將他們組合成一個或多個場景，根據原型所模擬的用戶體驗指定統一的路徑；
  • 規劃原型迭代
    • 一開始廣泛全面的對網站進行原型化，然後逐步深入到解決方案選定區域的原型化，如此由淺入深逐漸完成整個軟體的原型化，加快迭代速度。

3.1.2 合適的原型保真度

保真度一般是指原型與最終解決方案的相似程度，他擁有多個維度：

而按照精細程度進行劃分，原型的保真度也分為：

選擇合適的原型保真度時，通常沒有一個確定的答案。大多數網站原型設計都是從繪製草圖開始，然後根據系統的複雜程度和保真度的要求，將其轉化為高保真的原型。

3.1.3 高效的原型設計工具

根據不同的設計需求，你可以選擇和使用不同的原型工具。在這裡我舉幾個常用的工具：

Axure RP

墨刀

產品大牛

3.2 網站架構設計

在這裡我們以支持分散式、高並發、高可用為架構目標進行設計。

3.2.1 網站初級架構

一般網站，剛開始的做法是三臺伺服器，一臺部署應用，一臺部署資料庫，一臺部署NFS文件系統，這是較早之前傳統的做法，當並發量高的時候容易出現性能問題。

目前主流的網站架構一般會採用集羣的方式，進行高可用設計，至少是下面這樣子：

  • 使用集羣對網站伺服器冗餘，實現高可用。負載均衡設備也可以與網站一塊部署；
  • 使用資料庫主備模式，實現數據備份和高可用；

3.2.2 網站容量預估與架構分析

預估步驟一般為：

  1. 註冊用戶數-日均UV量-每日的PV量-每天的並發量；
  2. 峯值預估：平常量的2~3倍；
  3. 根據並發量（並發，事務數），存儲容量計算系統容量。

假設通過預估之後，我們存在幾個問題（為了後續介紹優化，這裡假設一下）：

  • 需要部署10臺web伺服器，並且這10臺web伺服器只有高峯期才會用到，例如搶購，活動等等，存在大量浪費；
  • 所有網站應用都部署在同一臺伺服器，造成應用之間耦合嚴重，需要進行垂直或水平切分；
  • 大量的代碼冗餘；
  • 伺服器進行Session同步需要耗費大量的內存和網路帶寬；
  • 操作數據需要頻繁訪問資料庫。

那麼根據以上問題，我們可以進行如下的架構優化：

3.2.3 網站架構優化

a. 業務拆分

根據業務邏輯進行垂直切分，可以將我們的體育賽事比分網站劃分為：

  • 產品子系統；
  • 訂單子系統；
  • 支付子系統；
  • 用戶子系統；
  • 客服子系統；
  • 簡訊郵件子系統；
  • 定時任務子系統；

業務拆分的作用：

  • 每個子系統可交由專門的人負責；
  • 解決模塊之間耦合以及擴展性問題；
  • 每個子系統單獨部署，避免集中部署導致一個應用掛了，全部應用不可用的問題。

根據業務子系統進行等級定義，分為核心系統和非核心繫統：

  • 核心系統：產品子系統、訂單子系統、支付子系統；
  • 非核心繫統：評論子系統、客服子系統、介面子系統。

等級定義的作用：核心和非核心子系統組合部署，用於流量突然爆發時，對關鍵應用進行保護，關閉非核心子系統，實現自動降級。

b.應用集羣部署

  • 分散式部署：將業務拆分後的應用單獨部署，應用直接通過RPC進行遠程調用；
  • 集羣部署：應對高可用的要求，每個應用至少部署兩臺伺服器進行集羣部署；
  • 負載均衡：高可用系統必須
  • 一般應用通過負載均衡實現高可用；
  • 分散式服務通過內置的負載均衡實現高可用；
  • 關係型資料庫通過主備方式實現高可用；

c.多級緩存

緩存按照存放的位置，可以分為兩種：本地緩存和分散式緩存。在這裡我們採用二級緩存的方式進行緩存設計：

  • 一級緩存：本地緩存；
  • 二級緩存：分散式緩存；

一級緩存，緩存數據字典和常用的熱點數據等不可變/有規律變化的信息。二級緩存，緩存需要的所有緩存。當一級緩存過期或不可用時，訪問二級緩存的數據。如果二級緩存也沒有，則訪問資料庫。

緩存的比例一般1:4即可考慮使用緩存。根據業務特性可使用以下緩存過期策略：

  • 緩存自動過期；
  • 緩存觸發過期；

d.單點登錄

系統分割為多個子系統進行部署之後，我們可以採用Session同步、Cookies、分散式Session方式避免會話管理問題。

在體育賽事比分網站架構設計中，我們可以採用分散式Session，建立完善的單點登錄或賬戶管理系統。流程如下：

  1. 用戶第一次登錄時，將會話信息寫入分散式Session；
  2. 用戶再次登錄時，調用分散式Session，判斷是否有會話信息，如果沒有則跳轉到登錄頁；
  3. 分散式Session一般採用Cache中間件實現，可以使用Redis實現持久化，方便分散式Session宕機後，可以從持久化存儲Redis中載入會話信息；
  4. 存入會話時，可以設置會話保持的時間，比如10分鐘，超過後自動超時；

e.資料庫集羣

大型網站需要存儲海量的數據，為了達到海量數據存儲、高可用、高性能，一般採用讀寫分離和分庫分表的方式進行架構設計。

讀寫分離一般解決讀比例大於寫比例的場景，可採用一主一備、一主多備貨多主多備方式。

我們將體育賽事比分網站在業務拆分的基礎上，結合分庫分表和讀寫分離：

  1. 業務拆分後，每個子系統需要單獨的庫；
  2. 如果單獨的庫太大，可以根據業務特性，進行再次分庫，比如商品庫；
  3. 分庫後，如果表中的數據量很大，則進行分表，一般可以按照ID、時間等進行分表；
  4. 在分庫分表的基礎上進行讀寫分離。

f.服務化

將多個子系統公用的功能進行抽取，作為公共服務使用。比如體育賽事比分網站的用戶子系統就可以抽取為公用的服務。

g.消息隊列

消息隊列可以解決子系統之間的耦合，實現非同步、高可用、高性能，是分散式系統的標準配置。在體育賽事比分網站中，消息隊列主要應用在購物下單、信息發送環節。

  1. 用戶創建訂單後，寫入消息隊列，返回客戶端；
  2. 簡訊郵件子系統讀取消息隊列信息，完成簡訊與郵件的發送；
  3. 定時任務子系統讀取消息隊列信息，檢測訂單支付狀態；

h.其他架構

除了以上介紹的業務拆分、應用集羣、多級緩存、單點登錄、資料庫集羣、服務化、消息隊列外，還有CDN、反向代理、分散式文件系統等架構技術。

3.2.4 架構總結

本模塊中，我們從以下幾個方面大概介紹瞭如何進行體育賽事比分網站的原型與架構設計。下一個模塊我們將會介紹如何進行前後端開發，敬請期待！

飛鯨體育數據 —— 球探網12年匠心打造，實時、海量、可靠的體育數據服務

更多技術乾貨敬請關註：飛鯨體育數據-知乎

推薦閱讀：

相關文章