[[188687]]

每個公司的IT環境，不論大小復雜度，總會有個系統架構層次。有了這個架構體系，那所有的運維事情大體都圍繞著這個系統架構上的每個元素及整體關聯進行運維保障工作。運維架構從某種角度可以劃分為兩大陣營：

商業封閉式系統架構(IOE架構)：以使用IBM、Oracle、EMC產品為代表的一系列軟硬件產品為主要元素的運維系統架構，以及圍繞這個架構的人、事、物、流程標準。

開源系統架構(非IOE架構)：以使用廉價PC服務器，開源產品技術(而非IOE)為主要元素的運維系統架構，以及圍繞這個架構的人、事、物、流程標準。

基于上述兩種運維架構的單位企業都很多，幾乎涉及到了政府、企事業、民營的各個行業單位。有的單位使用上述其中一種運維架構為主，而還有相當多一些單位會混用上述兩種運維架構。

一、商業封閉式系統架構(IOE架構)

典型的IOE架構即以IOE產品軟硬件為主要平臺的系統架構。這種架構中使用了大量IOE為代表的產品元素，在運維技術要求、采購成本方面相對(下述的非IOE架構)是高門檻。該架構的設備系統在性能與穩定性方面表現出色，服務對象主要面向一些特定服務對象以及特定服務為主。基于IOE架構的典型企業如：金融業、電信業，交通運輸業。

IOE架構以縱向擴展為特點，通常通過增加CPU、內存、磁盤、擴展柜、冗余備件、備份設備等方式來提高處理能力及穩定性。該架構的處理能力主要取決于單臺(套)設備(系統)的***擴展能力，很難通過增加設備(系統)數量來增加處理能力，換句話說該架構很難通過擴大集群規模的方式來解決問題。雖然單方面可擴展IOE元素資源(如小型機集群、Oracle RAC、EMC擴展柜等)，但其單機擴展能力畢竟是有限的，而且隨著縱向擴展的規模增大，其實施技術難度、管理復雜度以及隱患風險都會正比例大幅上升。在IOE架構中，往往比較關注“點”，例如宕機通常是一種非常嚴重的事件。

IOE典型的系統架構圖如下圖1-1示例：

圖1-1

上述即典型的IOE型系統架構。該架構一般會將相同業務系統的數據都集中在一套IOE架構中，提供集中管理的(關系型)數據庫，依靠大型高端設備來提供高處理能力和擴展性，數據的保存與備份通常也會集中保存到磁盤陣列(與帶庫)中。

在該架構中，其服務器多使用小型機、大型機(還有以往的中型機)，存儲則多使用知名 品牌的中高端存儲陣列、帶庫等設備。服務器與存儲之間多使用SAN存儲網絡。這些服務器、存儲等硬件本身往往就是雙冗余的，線路連線也都是雙冗余的，而且 設備性能指標往往非常好，例如一臺普通中端的Power 7系列服務器可以輕松劃分出若干個系統分區或者一二十個虛擬機系統。

而對于系統使用的軟件，往往也是IOE相關產品。例如數據庫系統往往會使用Oracle，而系統應用架構往往就是Oracle RAC或者PowerHA。

二、開源系統架構(非IOE架構)

典型開源系統架構即以開源產品為基礎的系統架構。這種架構使用了大量PC服務器及非IOE的 商業產品，同時納入了大量開源產品元素。該架構在運維技術要求、采購成本方面相對低廉，容易上手。該架構的設備系統在單機性能與穩定性方面較弱，但在大規 模集群、自主靈活與開發定制方面表現出色。該系統架構服務對象主要面向廣大普通用戶，基于開源系統架構的典型企業如：以BAT(百度、阿里、騰訊)為代表的眾多互聯網企業，以及大量中小型企業。

開源系統架構以橫向擴展，分布式部署為特點。通常通過往集群中增加單機設備資源解決存儲空間、性能以及穩定性問題，其集群規模可以小到兩三臺PC服務器組成，也可以大到上萬臺PC服務器集群。對于數據庫的擴展也很方便，可以通過分布式MySQL集群便解決了數據庫擴展性的問題。另外非結構化數據庫及分布式文件系統在處理非結構化數據的存儲與使用方面也很靈活方便。

當然隨著開源系統橫向擴展的規模增大，其實施技術難度、管理復雜度以及隱患風險同樣會正比例大幅上升。在開源系統架構中，往往關注“面”，單個宕機通常不再是嚴重的事件。開源系統架構的難度在于海量運維，在于運維架構的開發與磨合。

開源系統架構圖如下圖1-2示例：

圖1-2

上述開源系統架構中使用了CDN和反向代理以提高網站性能。

例如我們的服務器可能部署在北京，對于北京及周邊用戶來說訪問是較快的，而對于遠離北京的用戶的訪問則感覺較慢，因為數據傳輸時間比較長。對于這種情況，常常使用CDN解決，CDN將數據內容緩存到運營商(或自建CDN)的機房，用戶訪問時先從最近的CDN機房獲取數據，這樣大大減少了網絡訪問的路徑。比較專業的CDN運營商有藍汛、網宿。

對 于反向代理，則是部署在網站的機房，當用戶請求達到時首先訪問反向代理服務器，反向代理服務器將(Varnish)緩存的數據返回給用戶，如果沒有沒有緩 存數據才會繼續走應用服務器獲取，也減少了獲取數據的成本。當然對于海量訪問請求，或者龐大集群服務中，單靠F5、LVS、或者Ngnix等反向代理往往 不能滿足架構穩定需要，這個時候就需要分多層、綜合運用上述負載均衡以及代理(反代理)，同時可能需要引入zookeeper等功能以協調(服務)任務調 度。