可擴展的Web架構和分佈式系統

原文連接:http://www.aosabook.org/en/distsys.htmlhtml

開源軟件已經成爲一些大型網站的基石。隨着這些網站的發展,圍繞其架構的最佳實踐和指導原則應運而生。本章旨在討論設計大型網站時須要考慮的一些關鍵問題,以及用於實現這些目標的一些構建模塊。算法

本章主要集中在Web系統上,儘管有些材料也適用於其餘分佈式系統。數據庫

1.1 分佈式網站設計原則

構建和操做可伸縮的Web站點或應用程序究竟意味着什麼?在原始層,它只是經過Internet鏈接用戶與遠程資源,可伸縮性的部分是指資源或訪問這些資源的方式分佈在多個服務器上。緩存

與生活中的大多數事情同樣,從長遠來看在構建Web服務時花時間預先計劃能夠有所幫助;理解大型網站背後的一些考慮和權衡能夠在建立較小的Web站點時作出更明智的決定。下面是一些影響大型Web系統設計的關鍵原則:服務器

  • 可用性:網站的正常運行時間對許多公司的聲譽和功能相當重要。對於一些較大的在線零售網站來講,即便幾分鐘不可用,也可能致使數千美圓或數百萬美圓的收入損失,所以,設計他們的系統持續可用和失效快速恢復,是一項基本的業務和技術要求。分佈式系統中的高可用性要求仔細考慮關鍵部件的冗餘,部分系統故障時的快速恢復,以及問題發生時的優雅降級。
  • 性能:網站的性能已成爲大多數網站的重要考慮因素。網站的速度影響用戶的使用和用戶滿意度,以及搜索引擎排名,這是與收入和保持直接相關的一個因素。所以,建立一個對快速響應和低延遲進行優化的系統是關鍵。
  • 可靠性:系統須要是可靠的,對數據的請求將始終返回相同的的數據。若是數據更改或更新,則同一請求應返回新數據。用戶須要知道,若是某個東西被寫入系統,或者被存儲,它將繼續存在,而且能夠被信賴,以備未來檢索
  • 可伸縮性當涉及到任何大型分佈式系統時,規模只是可擴展要考慮的一個方面。一樣重要的是增長處理大量負載所需的工做量,一般稱爲系統的可伸縮性。可伸縮性能夠指系統的許多不一樣參數:它能處理多少額外的流量,增長存儲容量有多容易,甚至能處理多少事務。
  • 管理性:設計一個易於操做的系統是另外一個重要的考慮因素。系統的可管理性等同於操做的可伸縮性:維護和更新。可管理性要考慮的問題是,簡單診斷和理解發生的問題,容易修改和更新,系統操做簡單(即,是否常常無端障或異常運行)
  • 成本:成本是一個重要因素。這顯然包含硬件和軟件成本。可是考慮部署和維護須要的其餘方面也是很重要的。系統開發所需的開發人員時間,運行系統所需的操做工做量,甚至所需的培訓也都要考慮在內。成本是全部開銷的總和。

這些設計原則爲分佈式Web系統架構提供了決策基礎。可是,他們也可能相互矛盾,實現一個目標就要犧牲另外一個。例如:經過簡單的添加更多服務器(可伸縮性)來解決容量問題,代價是可管理性(你必須操做額外的服務器)和成本(服務器價格)網絡

在設計任何類型的Web應用程序時,考慮這些原則很重要,即便知道一個設計可能犧牲其中一個或者多個。架構

1.2 基礎知識

大型網站設計須要考慮的核心問題:服務,冗餘,分區和失敗處理負載均衡

實例:圖片託管應用異步

  用戶能夠上傳本身的圖像到服務器,經過網絡連接或者API請求圖像,像Filckr 和Picasa分佈式

服務

  1)圖像的讀寫由一個server完成

  2)將讀圖像和寫圖像分紅不一樣的服務:服務異常,將致使全部服務不可用

       3)不一樣的用戶分佈在不一樣的碎片上,一個碎片隻影響部分用戶

冗餘:

  服務:設計成無共享架構,避免單點故障

分區:

  縱向擴容 : 增長單個服務器資源

  橫向擴容:增長更多的節點,服務分解成分區的或者碎片 風險:不一致性,數據局部性,網絡訪問資源時間延長

1.3 快速可擴展數據組成部分

 數據存取:

緩存:

  本地緩存

    全局緩存

 分佈式緩存

代理:

  將多個請求(數據相同,數據相近)合成一個請求。 LAN代理

索引:讀取快,更新慢:不止更新數據,還要更新索引

  多級索引,數據庫經常使用技術

  嵌套索引

負載均衡:

  隨機選取,輪換,特定算法(依據內存,CPU)

  開源軟件:HAProxy

隊列:

  異步

  請求隊列

  開源:RabbitMQ,ActiveMQ,BeanstalkMQ,Redis,Zookeeper

相關文章
相關標籤/搜索