Home | 簡體中文 | 繁體中文 | 雜文 | 知乎專欄 | Github | OSChina 博客 | 雲社區 | 雲棲社區 | Facebook | Linkedin | 視頻教程 | 打賞(Donations) | About
知乎專欄多維度架構 微信號 netkiller-ebook | QQ群:128659835 請註明“讀者”

14.4. 伺服器部署

一旦數據中心網絡部分完成,下一步就是部署各種伺服器,同時伺服器的部署必須滿足災備的要求,否則無法實現災備切換與故障轉移。

伺服器與交換機連接,按照伺服器重要程度或者是否具備故障轉移,有兩種方案,如具備分散式部署的伺服器可能只連接一條網綫,有些伺服器無法分散式部署,我們是兩個網卡分別連接兩條網綫到兩台交換機,同時網卡綁定為一個適配器。

14.4.1. 網站

網站提供新聞,資訊,開戶,轉帳,活動,報表,在綫客服等等功能

圖 14.4. 動態頁面方案

動態頁面方案

上面是動態頁面方案,分為SSL伺服器,WEB伺服器,API介面伺服器,Admin伺服器。全部具備水平擴展與動態伸縮。下面分別詳細說明他們的功能,為什麼這樣部署。

動態頁面伺服器

  1. SSL:負責處理用戶請求的加密與解密,我們將它與WEB分離,這樣能夠更好的伸縮擴展,同時提供故障轉移功能,我們可以部署很多台這樣的伺服器。在不同城市,然後通過智能DNS將用戶解析到距離用戶最近的節點上。

  2. WEB:動態頁面伺服器

  3. API: Service 伺服器,可以通過SOAP, JSON, MQ等等方式訪問,WEB任何操作都要請求API伺服器完成,WEB伺服器不允許直接操作資料庫,全交由API處理。API具有運用層防火牆的功能與ACL訪問控制列表。

  4. Admin:網站後台

  5. HA:負載均衡軟件或設備

與門戶網站不同,我們的網站訪問量並不大,性能瓶頸基本不存在,更多是考慮高可用。

靜態頁面以及CDN部門這裡就不談了,非常簡單,有興趣可能到 http://netkiller.github.io/ 找相關資料。

14.4.2. 數據源

在交易過程中出現報盤中斷是大忌,我們必須盡一切努力,讓交易系統能源源不斷的接收價格數據。為此我需要重點考慮數據源的災備。

圖 14.5. 數據源災備解決方案

數據源災備解決方案

我們設計了一個DataFeed程序,能夠多方接收數據,因為每個數據源提供的產品不同。我們在這裡可以合併,篩選,過濾等等。這個應用可以實現水平擴展,我們可以放在2個以上的機房當中。

接下來在交易伺服器中,設置多個數據源分別指向Data Feed 1,2~n。與Trader相同機房的DataFeed的優先順序總是最高。

14.4.3. 資料庫

數據的部署要考慮幾個問題,我一直不建議主備方案,而是採用雙活方案。所以我們要考慮兩個機房或者三個機房他們數據複製問題,性能瓶頸問題,數據安全問題等等

圖 14.6. 資料庫災備解決方案

資料庫災備解決方案

上圖我的方案中採用了Master-Master雙活方案,同時每個Master都會有一個Slave。Master 主要用於主要的業務,Slave主要用戶數據分析,報表查詢等等非實時,且長時間允許等等查詢服務

資料庫訪問需要經過SLB伺服器,為資料庫提供負載均衡,故障轉移,水平擴展等等功能。

所有的數據操作只能通過API完成,不能直接連接資料庫並通過SQL存取,上面已經提到過,這裡不再多講。

[提示]提示
如果是三個以上機房,將採用環形複製,大致原理Master A向Master B複製,Master B向 Master C複製,Master C在向Master A 複製,形成一個環路。

如果資料庫查詢如果出現瓶頸,增加Slave即可。