經典分佈式系統設計

做者：潘罡 （Van Pan） @ Microsoft

 

在正式介紹Service Fabric以前，咱們認爲應該首先介紹分佈式系統的經典架構。

理解了分佈式系統的演進過程能夠極大程度上幫助理解Service Fabric以及Azure服務中全部針對分佈式系統的優秀產品。

 

簡單系統模型

在IT時代初期，若是須要自行構建一個系統，須要完成如下工做。

• 採購服務器
• 在服務器中安裝Web服務器
• 在服務器中安裝數據庫
• 向ISP申請靜態IP
• 向服務器部署靜態IP
• 向服務器中部署網站
• 向服務器中部署數據庫原始數據
• 向域名供應商購買域名
• 將域名和靜態IP進行綁定
• 向證書供應商購買證書
• 向服務器中部署證書
• 對Web服務器配置證書，監聽域名等
• 網站啓動外部服務監聽，好比HTTP，HTTPS

經典分佈式模型

隨着網站訪問量逐漸增長，系統壓力逐漸上升。

此時根據實際狀況不一樣，會對站點服務器作如下調整。

• 使用性能更好的服務器，簡稱垂直升級。該作法已經不是主流作法，除非在沒法實現下列解決方案前提下才會考慮。
• 數據庫遷移至單獨服務器。
• 數據庫水平升級
  • 數據庫主從分離，讀寫分離。使用單獨服務器做爲寫服務器，其餘服務器做爲讀服務器。成熟數據庫均可以配置主從分離。
  • 數據庫垂直拆分。將數據庫數據不一樣的表放到不一樣的服務器。
  • 數據庫水平拆分。將數據庫表根據特徵拆分至不一樣表。好比2016年數據和2017年數據分表存儲。
• Web服務器垂直拆分，將子系統拆分至單獨服務器
• Web服務器負載均衡，有如下幾種作法
  • 動態域名解析
    • 將服務器放置在不一樣物理地域。好比北京上海兩臺服務器分別針對華南華北用戶。對於同一個域名，華南華北用戶解析到的服務器IP不一樣。
    • 同一臺服務器，不一樣ISP線路優化。有些機房有電信聯通雙線。網站管理員申請電信聯通不一樣IP，用戶在電信聯通環境下針對同一個域名解析到不一樣IP。
    • 同域名多IP負載均衡。即便是同一個ISP，同一個機房的服務器，也能夠經過動態域名解析返回多個不一樣IP。用戶的請求會在不一樣IP間切換，一樣達到了負載均衡效果。
  • 網絡負載均衡
    • 硬件負載均衡。商業負載均衡服務器，例如F5。從硬件層面將網絡鏈接負載均衡至不一樣後臺Web服務器。
    • 軟件負載均衡。如今有大量開源反向代理服務器，例如Nginx。使用該服務能夠在前端監聽端口，而且將請求分發至後臺的不一樣服務器。

當服務器面臨突發的請求壓力（多是被DDos攻擊，也多是由於業務營銷活動，好比雙十一），客戶開始電話轟炸站點卡死不可用，如何快速解決問題？

 

若是發現是數據庫壓力過大，應該怎麼辦？

對數據庫進行拆分嗎？

這幾乎是不可能的，由於數據庫的任何改動都會反向影響代碼修改。並且拆分數據庫須要大量的時間。

比較可行的解決方案，有如下幾種。

• 部署新的讀數據庫服務器，減小當前數據庫服務器承擔的併發壓力
• 關閉一部分線上功能，減小數據庫總體請求

固然最完美的解決方案，就是數據庫設計自己就是針對分佈式的。

若是數據庫也能夠動態擴容，就不會遇到數據庫性能瓶頸。

 

若是發現是Web服務器壓力過大，應該怎麼辦？

最行之有效的方法就是經過網絡負載均衡添加服務器。

但這又引入了另外一個問題。

• 一般狀況下，Web服務器的性能瓶頸一般都是由某個部件致使的，僅僅針對這個組件，就須要部署一整套Web服務，看起來很是不合理。
• 由於如今服務器壓力很大，因此徹底不知道須要部署多少臺服務器纔夠支撐。
• 每臺服務器都須要作相同的部署操做，簡陋一點是每臺都須要人工操做，高級一些是部署腳本，可是由於新增長了服務器，都須要修改負載均衡配置。

若是有某種解決方案，能夠準肯定位性能瓶頸組件，而且在服務器自動增長後自動擴展該組件，就能夠同時解決自動化以及經濟性需求。

 

 

 

 

在下一節中，咱們將會詳細介紹在如今的雲服務環境中，分佈式系統的演進以及系統架構師對於分佈式系統更深的理解。

在掌握了雲時代分佈式系統的最新概念後，才能理解Service Fabric中全部抽象概念以及使用場景。