原文出自“億歐網”；

原文鏈接：https://www.iyiou.com/p/116586.html?utm_source=tuicool&utm_medium=referral

[ 億歐導讀 ]本文分析了傳統集中式數據中心和分佈式架構數據中心的主要區別，探索了未來數據中心架構發展的趨勢。

圖片來自“Unsplash”

一、什麼是數據中心？

什麼是數據中心？百度百科給出定義是：數據中心是全球協作的特定設備網絡，用來在因特網絡基礎設施上傳遞、加速、展示、計算、存儲數據信息。數據中心大部分電子元件都是由低直流電源驅動運行的。

數據中心的產生致使人們的認識從定量、結構的世界進入到不確定和非結構的世界中，它將和交通、網絡通訊一樣逐漸成為現代社會基礎設施的一部分，進而對很多產業都產生了積極影響。不過數據中心的發展不能僅憑經驗，還要真正的結合實踐，促使數據中心發揮真正的價值作用，促使社會的快速變革。

二、為什麼需要分佈式數據中心？

說到發展，數據中心正隨著各個行業的蓬勃發展而不斷高速的建設著。雲計算、大數據和物聯網等新技術的大規模使用，讓數據中心成為了醫療、政府、互聯網和金融等行業建設的重點。特別是在銀行 、保險等領域，數據中心由於承載核心業務，不允許任何數據中斷、要求能夠快速響應業務變化和具備一定的靈活性，已經成為了名副其實的“生產中心”。反觀數據中心，傳統的集中式架構已經無法滿足新時代業務的需求。而基於分佈式架構的數據中心是一個和集中式架構相對應的技術體系，包括了分佈式業務部署、分佈式計算、存儲、網絡安全等多種分佈式技術的集合。在傳統數據中心無法保證業務響應能力、連續性和靈活性，發展達到一定瓶頸的時候，分佈式架構就自然成為了一種必然的選擇。

在早期的數據中心建設中，大多數IT建設者們並不太關注採用何種技術架構，覺得沒有那麼重要。數據中心的建設重點就是讓承載的業務系統穩定運行，為服務器、存儲和網絡設備提供一個良好的運行環境，讓業務系統沒那麼容易“宕機”即可。所以早期大部分數據中心都是煙囪式的架構設計，每個業務系統都會配置一套獨立硬件設備，數據完全是割裂的，導致設備利用率非常低，資源完全無法共享。典型的“標配”方案為兩臺高端小型機（或X86服務器）做數據庫服務器雙機，然後再加兩臺或以上應用服務器，後端連接兩臺FC交換機（或IPSAN交換機）和一臺存儲設備。直到現在，仍然可以看到許多招標文件中有類似的配置方案。當然，並不能說明這種配置方案不好或者不對，只能說在沒有很好規劃和合理利用的情況下，這樣的配置會導致數據中心空間、能耗、製冷大規模增加，而且設備數量的隨意增加還會嚴重影響運維和管理的效率。

為了應對信息化的快速發展，提高設備利用率和靈活性，雲計算技術被大規模推廣和採用。雲計算可以提供可用的、便捷的、按需的資源提供，逐漸成為了主流的數據中心架構，目前大多數行業的數據中心都已經具備了雲計算的能力。除了大規模數據庫等少數業務場景以外，新業務應用基本都是使用雲模式進行構建，同時還有大量現有的業務應用正不斷向雲計算環境進行遷移。將應用系統運行在虛擬化環境中似乎已經成為了一種常態。在雲計算環境中，服務器虛擬化是基本的雲計算技術之一。虛擬化軟件廠商正在逐步將基於物理資源的數據中心向虛擬化資源的數據中心進行轉變，有效的控制了數據中心內服務器數量和規模的增長，提高了服務器的利用效率。同時，虛擬化系統所具備的特性極大的提高了數據中心繫統的可靠性。特別在主動運維、災備建設和故障切換等方面對數據中心的業務連續性是一種質的飛躍。在這一階段，虛擬化技術的大規模應用讓傳統數據中心在不改變集中式的架構條件下，獲得了最大化的資源整合和共享，但是架構仍然沒有太大的變化，更多的是一種服務模式的轉變。

基於雲計算架構的數據中心建設已經成為主流的建設模式，但是在架構上還有很多可以改進的地方。

1、基於雲計算架構的數據中心只能解決單個數據中心內部的資源共享和使用等問題，無法解決資源的靈活擴展問題，資源的增加仍然是採用垂直架構。由於單個計算、存儲或者網絡設備都有性能上限，擴展到一定能力後必然要進行拆分，重新建設資源池，又會形成新的資源孤島，並沒有從根本上解決數據中心的發展問題。

2、隨著各個行業的信息化發展，越來越多的企業需要建設多個不同地域的數據中心。比如銀行業和保險業會按照銀監會和保監會的要求建設災備中心，集團企業會建設分公司分數據中心。這些數據中心如何進行統一的管理和應用，保證業務的連續性，解決業務協同問題，是對傳統數據中心一個巨大的挑戰。

基於雲計算的數據中心提供更多的是一種服務。通常情況下，我們提到雲計算，指的是一種計算、存儲、軟件等服務的交互和使用模式。而基於分佈式架構的數據中心，更多的是指一種數據中心的計算模式，而不是一種服務形式，它是雲計算數據中心的技術基礎和擴充。

三、集中和分佈式架構兩種數據中心的區別

分佈式架構數據中心在技術層次上，主要包括兩個概念：單個數據中心內的分佈式架構和多個數據中心的分佈式架構。

單個數據中心內的分佈式架構，主要包括分佈式計算、存儲、安全網絡等多種分佈式技術的合集。多個數據中心的分佈式架構主要是指將傳統多個數據中心統一整合為一個數據中心。實現業務連續性災備，多中心運營和管理等。例如：將多個不同地區，不同規模的數據中心使用統一的管理平臺進行資源的統一管理，使用統一的運營平臺實現統一運行。

3.1 分佈式計算架構

按照分佈式計算的定義是利用網絡把成千上萬臺計算機連接起來，組成一臺虛擬的超級計算機，完成單臺計算機無法完成的超大規模的問題求解。

而數據中心的分佈式計算更多的是指分佈式軟件架構。

是以分佈式計算技術為基礎，用於解決大規模問題的軟件架構。分佈式軟件架構具有較好的伸縮性，特別在處理大數據問題時，分佈式架構能顯著提高處理速度。常見的分佈式軟件架構有分佈式操作系統、文件系統和數據庫等等。

以數據庫為例，傳統數據中心是單個數據庫為主，數據集中存儲在一臺服務器或存儲上，數據的處理也集中在單個或多個集群節點（一般為2-8個）內完成。傳統數據中心數據庫以Oracle、Db2或者MySql為主，但是當單表數據量爆炸或者單個數據庫無法承受高強度I/O時，集中式的架構是無法解決性能和數據處理瓶頸問題的。最早以前淘寶網就是使用的Oracle數據庫，而且還組建了全球最大的Oracle數據庫群集，可是隨著淘寶網的用戶和商品信息量增加，最後不得不走分佈式數據庫的路線。分佈式架構的數據庫具有靈活的體系結構 ，更適合分佈式的管理與控制， 而且可擴展性好，也易於擴充。 當然，分佈式數據庫也有自身的一些缺點，例如數據一致性差，網絡通信開銷較大，數據的存取結構比較複雜。但是不可否認，在某些應用場景下，沒有分佈式架構的數據庫，數據就很難進行管理和建設。

3.2 分佈式存儲架構

隨著數據中心業務數據的不斷增加，大數據的海量數據挖掘與日誌分析正逐漸成為一個主要應用場景。在面對極具彈性的存儲需求和性能要求下，傳統數據中心單機或者獨立的SAN存儲設備基本無法滿足大數據處理的需要。如同數據庫系統一樣，獨立的存儲設備在性能和數據存儲容量等方面都面臨著一定的瓶頸。

傳統數據中心通常為集中式存儲架構，單臺SAN或IPSAN存儲設備通常配置2-8個控制器，通過存儲擴展櫃進行容量擴展。如果增加性能，需要增加控制器和緩存，甚至需要更換存儲設備型號為高端存儲。按照集中式的存儲架構，單臺存儲的性能和擴展能力是有限的，一般達不到線性擴展。隨著存儲容量的增加，存儲的性能會先增加然後達到一定瓶頸後逐漸降低。因為一開始大量的磁盤增加會提升存儲整體讀寫性能，但是當磁盤性能達到控制器的性能後會嚴重影響控制器對數據的處理和運行，性能會逐漸下降。

面對海量PB級數據，如果使用傳統獨立SAN存儲設備，要麼擴展能力達不到，要麼擴展能力可以達到海量PB級別，但是容量和性能不會線性增長，而且以後存儲擴容和運維成本也非常高。

面對數據中心越來越多的大數據業務增長需求，首先要能存得下大量數據。傳統的存儲系統容量是有限的，又無法跨越多個存儲設備，即使利用虛擬化技術做存儲資源整合，那麼單位存儲成本也會非常高，而且數據處理性能有限。

以Hadoop為例，這是一款比較成熟而且應用比較多的大數據處理的分佈式開源軟件。其最底部是HDFS分佈式存儲。HDFS的設計本質就是為了大量的數據能夠分佈式存儲而存在的。HDFS可以將數據存放在很多不同的機器上。而用戶不必關心具體的數據在哪，HDFS會管理這些數據。HDFS是一個高度容錯的分佈式存儲系統。可以分佈式部署，以流式訪問模式訪問應用程序的數據，可以大大提高整個系統的數據吞吐量，非常合適用於具有超大數據集的應用中，而且隨著整個分佈式存儲系統的擴展，容量和性能會成正比進行線性增長，非常適合大數據類的業務處理和應用。

基於分佈式架構的數據庫和存儲都是未來數據中心必不可少的發展方向之一，沒有分佈式架構，數據中心就沒有能力管理大數據。

3.3 分佈式安全網絡

基於雲計算技術數據中心為應用部署帶來了靈活性和資源彈性配置，提高了硬件資源利用率，縮短了部署時間，但是同時也引入了新的安全問題。

傳統數據中心網絡安全是基於安全域、安全邊界的防護機制，是一套縱向安全策略，只關注業務流量的訪問控制，將流量安全控制作為唯一的規劃考慮因素。

而虛擬化技術的大量使用使得網絡邊界模糊化，主要依賴橫向安全策略，能夠滿足安全流量動態遷移到其它物理服務器。傳統基於已經難以滿足虛擬化環境下的應用模式，虛擬化的服務提供模式，使得對使用者身份、權限和行為的鑑別、控制與審計變得更加困難。這會導致許多基於傳統數據中心的安全防護手段失效。

在雲計算數據中心，多臺虛擬機都在一個服務器設備內運行，虛擬機之間通過虛擬化交換機進行連接，通信流量並沒有通過外部交換設備，導致傳統安全設備對這部分的流量失去監控。目前大多數虛擬化軟件廠商沒有在虛擬機通信的東西向流量提供高效的檢測和隔離方式，如果某臺虛擬機出現安全問題，可能會對相關連的資源池產生嚴重的安全威脅。另外，虛擬機會隨時遷移到其他服務器設備上，造成安全域邊界的動態化，傳統數據中心固定邊界的防護手段也會失效。當虛擬機遷移到新服務器設備上，如果新服務器設備沒有對應的安全保護策略，就可能對遷移後的虛擬機造成安全威脅。

為解決雲計算數據中心存在的安全問題，需要採用分佈式的方式部署安全管理軟件或系統。通常分佈式網絡安全產品由集中管理平臺+分佈式安全管理軟件組成。集中管理平臺負責安全策略的集中管理，並對安全策略的遷移功能提供支持。同時接收虛擬化安全設備的日誌以及統計信息，並分析整個數據中心的安全態勢。

安全軟件是以分佈式的形式部署虛擬機和虛擬化平臺上，可以克服傳統物理安全設備的侷限，更貼近虛擬機的位置，利用引流或者重定向機制，獲取所有虛擬機的流量，實現分佈式的安全防護。

3.4 分佈式雲數據中心

傳統數據中心為了做到業務高可用，保證業務連續數據，防止數據丟失，通過採用“同城主備/雙活數據中心”或者“兩地三中心”的架構。但是不管採用哪一種架構方案，都會產生一定的IT資源浪費問題。“主備數據中心”，解決了業務連續性問題，但是平時只啟用一個數據中心資源，另外一個做備份。“雙活數據中心”，解決了業務高可用問題，但是兩個數據中心需要部署和運行同樣業務，同樣會浪費一個數據中心的資源。“兩地三中心”，同時最大程度的兼顧業務和數據安全，但是IT資源浪費最嚴重。

在分佈式雲數據中心概念裡，多個數據中心不再是主/備或者雙活的關係，而是通過雲計算技術、廣域網二層網絡互連（大二層）技術和數據複製技術，將多個數據中心組建成一個分佈式的跨中心和地域的“虛擬資源池”。所有業務和數據都可以按需被分配到不同的數據中心，實現比“雙活”或者“兩地三中心”更優的業務部署方案。

基於分佈式架構的雲數據中心以往可能受技術限制，難以實現。但是隨著各種技術的不斷髮展，難度已經大大降低，完全可以實現。主要考慮三個問題：業務訪問網絡，大二層網絡和數據同步複製。業務訪問網絡可以通過全局負載均衡GLSB和智能DNS實現不同區域的本地訪問，使用大二層互聯網絡技術可以解決虛擬機遷移問題。數據同步複製可使用微服務+容器+分佈式存儲複製技術解決。通過微服務解耦業務，無狀態應用使用容器通過大二層網絡進行遷移，有狀態應用可以跟隨虛擬機進行遷移，冷數據儘量集中存儲，共享訪問，避免過多的數據遷移。

目前已經有可以落地的方案幫助企業實現分佈式架構的雲數據中心。同時還可以實現數據中心資源利用率的最大化，降低運維和管理成本，更好的保證業務的連續性。

3.5 兩種架構的主要區別

通過上述對集中式和分佈式架構在資源處理能力、業務支撐能力、安全管理能力、可用性和一致性、運維和管理等多個方面的分析可以看出：

集中式架構在系統複雜度、數據一致性、安全措施實施方便性和運維管理複雜度等方面有一定優勢。分佈式架構在資源使用成本和擴展能力、業務部署的靈活和系統可用性等方面具有明顯優勢。而且集中式架構的複雜性可以通過加強管理和設計降低複雜度，安全措施則可以通過增加安全系統和手段加強控制，數據一致性則需要通過先進的分佈式系統與大規模運維平臺來支持，當然前提是需要犧牲一定的可用性，這也是分佈式架構面臨的一個挑戰，下文我們會進行詳細論述。

四、分佈式架構建設的挑戰

隨著數據中心信息系統數量的增加和處理數據量越來越大，分佈式架構的優勢會越來越明顯。但是越是先進的架構所面臨的挑戰也就越大，由於分佈式架構採用多節點設計，這種架構最大的難點是會導致數據一致性和可用性上的挑戰，所有的分佈式架構設計都繞不開這兩個挑戰。

在分佈式架構中，有一個非常著名的CAP理論（又被稱作布魯爾定理），定義如下：

對於任何一個分佈式計算系統，不可能同時滿足以下三點：一致性（Consistency)、可用性（Availability）和容忍網絡分區（Partitiontolerance）。

一致性通常指數據一致性，即要求所有節點數據保持一致。可用性即要求每個節點在故障時都可以提供服務。容忍網絡分區，通常指各個節點之間的網絡通信性能。

根據CAP理論，分佈式系統只能滿足其中兩項而不可能滿足全部三項。

CP模型：

不考慮A（可用性），多個節點之間數據具備強一致性。如果某個節點故障，那麼就將這個故障節點丟棄（不考慮A），否則會導致各個節點之間數據同步被無限延長。為了保證數據的一致性，大多數金融行業的分佈式關係型數據庫採用這一模型，

AP模型：不考慮C（一致性），多個節點之間要求高可用。如果某個節點故障，並與其他節點失去聯繫，為了保證節點的可用性，會放棄全局數據一致性（不考慮C）。節點訪問並使用本地節點數據，各個節點數據會導致不一致。大多數非關係型的數據庫採用這一模型，因為不需要高度的數據一致性。

CA模型：不考慮P（容忍網絡分區），兩個或多個節點之間要求必須具備可用性的同時又要求數據一致。如果某個節點故障，為了同時保證可用性和數據一致性，那麼只能對分佈式網絡進行強制分區，劃分成多個不同的分區來保證C和A，會導致分區被割裂。

由以上幾個模式可以看出，在分佈式計算環境下，P是必須要現實的，否則分佈式網絡節點通訊就會出現問題，所以只能在C和A之間做出選擇，即選擇CP模型或者AP模型，實際的選擇需要根據自身的業務場景來根據各個不同的模型特點進行取捨。

對於一些離線的應用或者對可用性要求不高的業務，可以採用CP模型。這一類模型相對簡單，但是應用場景也有限。例如日誌數據分析系統，大部分數據都在本地，我們只需要在分佈式架構中配置一定的冗餘節點和恢復機制即可。如果某個節點出現故障，分析系統會自動等待其他備用節點恢復後再繼續運行，因為短時間停止不會對系統產生太多影響，但是各個節點分析的數據要求必須保持一致性。

在數據中心，核心系統和重要業務系統佔比較大，如果採用分佈式架構，可能即需要高用性也要求數據一致性，這是分佈式架構設計最大的一個挑戰。

以金融行業為例，保證業務的連續性和高可用性是非常重要的一個需求，可以採用AP模型進行設計。但是數據一致性也是要儘量保證的，因為金融系統如果數據不一致，會產生嚴重的數據問題。關於數據一致性，在分佈式架構中可以按程度分為強一致性、弱一致性和最終一致性。為了保證金融系統的高可用和業務連續性，數據強一致性很難達到，弱一致性又無法滿足要求，做為取捨，可以實現數據的最終一致性。在分佈式系統中，數據會被存儲在多個節點，各個節點的數據被應用修改後，最終一致性不要求各個節點同時更新數據，只要求儘快將各個節點更新後的數據分佈到整個系統中，這樣在保證系統可用性的同時會實現數據的最終一致性，保證金融行業對數據要求。當然，並不是所有的金融業務都可以採用最終一致性的方案，例如核心實時交易系統，必要要求實時處理數據並保持強一致性，這也是目前大多數金融機構核心交易系統還在使用集中式架構的原因。

分佈式雲數據中心在建設過程中同樣也面臨一些挑戰，主要包括網絡、存儲和計算三個方面：

在網絡方面，多個分佈式雲數據中心之間的通信是個問題。需要考慮多個不同區域的網絡訪問接入、負載均衡問題。還要滿足分散在多個雲數據中心之間的業務通信和切換的需要。目前主流的技術方案是以大二層網絡技術為主，打通多個數據之間的網絡，形成一個統一的邏輯網絡。但是目前各個網絡設備廠商之間的大二層網絡和協議不統一，設備兼容性有一定的問題，這也是分佈式雲數據中心改造所需要解決的一個問題。

在存儲方面，數據實時同步，實現統一的存儲資源共享並建立高可靠性的數據保護機制，是一個比較嚴峻的挑戰。多個數據中心可能分散在不同地域，各個數據中心之間的網絡帶寬有限，可能無法做到數據實時同步，只能採用異步傳輸。那麼數據一致性和完整性可能就等不到保證。上文提到的應用解耦+微服務架構可以解決一部分問題。但是對於傳統的無法進行微服務改造的應用仍然是個難題。在數據一致性和可用性上可能需要一些取捨。

在計算方面，目前技術相對成熟。將資源雲化以後，利用雲計算技術可以實現對計算資源在多個雲數據中心的統一調度和管理。還可以設定權限，進行精細化管理。在計算方面的一些挑戰，通常指對計算資源的管理。例如在某一個應用出現故障時，是將這個資源在本地進行重建還是在其他雲數據中心進行遷移和重啟，因為這會影響到各個節點的其他業務訪問，需要提前進行統一的規劃和安排。

五、結束語

相對於傳統數據中心，構建分佈式架構的雲數據中心是非常有必要的，它影響著數據中心建設的方方面面。在未來，沒有分佈式架構的數據中心一定不會是一個優秀的數據中心。通過雲計算技術的不斷髮展與實踐，我相信分佈式架構一定會成為數據中心的未來發展方向。即使未來數據中心的架構不是完全分佈式的，但是分佈式架構也絕對不會缺席，一定會有分佈式架構的一席之地。