在金融信息化建設快速發(fā)展的今天，IT架構(gòu)技術支撐能力顯得尤為重要。作為一名銀行數(shù)據(jù)中心的從業(yè)人員，根據(jù)十幾年來的工作經(jīng)歷，談談自身的感受。從小型機和集中式存儲的物理架構(gòu)，到現(xiàn)在的分布式、大數(shù)據(jù)、智能化的IT架構(gòu)，銀行信息化架構(gòu)也隨著時代的進步在不斷的升級，已開始逐步從集中式架構(gòu)演變到分布式架構(gòu)，基于分布式架構(gòu)的云數(shù)據(jù)中心成為必然趨勢。
一、為什么需要分布式數(shù)據(jù)中心？
隨著云計算、大數(shù)據(jù)和物聯(lián)網(wǎng)等新技術的大規(guī)模使用，數(shù)據(jù)中心成為了醫(yī)療、政府、互聯(lián)網(wǎng)和金融等行業(yè)建設的重點。特別是銀行數(shù)據(jù)中心由于承載核心業(yè)務，不允許任何數(shù)據(jù)中斷、要求能夠快速響應業(yè)務變化和具備一定的靈活性，已經(jīng)成為了名副其實的“生產(chǎn)中心”。反觀數(shù)據(jù)中心，傳統(tǒng)的集中式架構(gòu)已經(jīng)無法滿足新時代業(yè)務的需求。而基于分布式架構(gòu)的數(shù)據(jù)中心是一個和集中式架構(gòu)相對應的技術體系，包括了分布式業(yè)務部署、分布式計算、存儲、網(wǎng)絡安全等多種分布式技術的集合。在傳統(tǒng)數(shù)據(jù)中心無法保證業(yè)務響應能力、連續(xù)性和靈活性，發(fā)展達到一定瓶頸的時候，分布式架構(gòu)就自然成為了一種必然的選擇。
在早期的數(shù)據(jù)中心建設中，大多數(shù)IT建設者們并不太關注采用何種技術架構(gòu)，覺得沒有那么重要。數(shù)據(jù)中心建設的重點就是讓承載的業(yè)務系統(tǒng)穩(wěn)定運行，為服務器、存儲和網(wǎng)絡設備提供一個良好的運行環(huán)境，讓業(yè)務系統(tǒng)沒那么容易“宕機”即可。所以早期大部分數(shù)據(jù)中心都是煙囪式的架構(gòu)設計，每個業(yè)務系統(tǒng)都會配置一套獨立硬件設備，數(shù)據(jù)完全是割裂的，導致設備利用率非常低，資源完全無法共享。
為了應對信息化的快速發(fā)展，提高設備利用率和靈活性，云計算技術被大規(guī)模推廣和采用。云計算可以提供可用的、便捷的、按需的資源提供，逐漸成為了主流的數(shù)據(jù)中心架構(gòu)，目前大多數(shù)行業(yè)的數(shù)據(jù)中心都已經(jīng)具備了云計算的能力。除了大規(guī)模數(shù)據(jù)庫等少數(shù)業(yè)務場景以外，新業(yè)務應用基本都是使用云模式進行構(gòu)建，同時還有大量現(xiàn)有的業(yè)務應用正不斷向云計算環(huán)境進行遷移。
基于云計算架構(gòu)的數(shù)據(jù)中心建設已經(jīng)成為主流的建設模式，提供更多的是一種服務。而基于分布式架構(gòu)的數(shù)據(jù)中心，更多的是指一種數(shù)據(jù)中心的計算模式，而不是一種服務形式，它是云計算數(shù)據(jù)中心的技術基礎和擴充。
二、集中和分布式架構(gòu)兩種數(shù)據(jù)中心的區(qū)別
分布式架構(gòu)數(shù)據(jù)中心在技術層次上，主要包括兩個概念：單個數(shù)據(jù)中心內(nèi)的分布式架構(gòu)和多個數(shù)據(jù)中心的分布式架構(gòu)。單個數(shù)據(jù)中心內(nèi)的分布式架構(gòu)，主要包括分布式計算、存儲、安全網(wǎng)絡等多種分布式技術的合集。多個數(shù)據(jù)中心的分布式架構(gòu)主要是指將傳統(tǒng)多個數(shù)據(jù)中心統(tǒng)一整合為一個數(shù)據(jù)中心。實現(xiàn)業(yè)務連續(xù)性災備，多中心運營和管理等。例如：將多個不同地區(qū)，不同規(guī)模的數(shù)據(jù)中心使用統(tǒng)一的管理平臺進行資源的統(tǒng)一管理，使用統(tǒng)一的運營平臺實現(xiàn)統(tǒng)一運行。
2.1分布式計算架構(gòu)
數(shù)據(jù)中心的分布式計算更多的是指分布式軟件架構(gòu)，是以分布式計算技術為基礎，用于解決大規(guī)模問題的軟件架構(gòu)。分布式軟件架構(gòu)具有較好的伸縮性，特別在處理大數(shù)據(jù)問題時，分布式架構(gòu)能顯著提高處理速度。常見的分布式軟件架構(gòu)有分布式操作系統(tǒng)、文件系統(tǒng)和數(shù)據(jù)庫等。
以數(shù)據(jù)庫為例，傳統(tǒng)數(shù)據(jù)中心是單個數(shù)據(jù)庫為主，數(shù)據(jù)集中存儲在一臺服務器或存儲上，數(shù)據(jù)的處理也集中在單個或多個集群節(jié)點內(nèi)完成。傳統(tǒng)數(shù)據(jù)中心數(shù)據(jù)庫以Oracle、Db2為主，但是當單表數(shù)據(jù)量爆炸或者單個數(shù)據(jù)庫無法承受高強度I/O時，集中式的架構(gòu)是無法解決性能和數(shù)據(jù)處理瓶頸問題的。淘寶網(wǎng)最早使用的就是Oracle數(shù)據(jù)庫，隨著用戶和商品信息量的增加，最后不得不改走分布式數(shù)據(jù)庫的路線。分布式架構(gòu)的數(shù)據(jù)庫具有靈活的體系結(jié)構(gòu)，更適合分布式的管理與控制，而且可擴展性好，也易于擴充。
2.2分布式存儲架構(gòu)
傳統(tǒng)數(shù)據(jù)中心通常為集中式存儲架構(gòu)，單臺存儲的性能和擴展能力是有限的，一般達不到線性擴展。隨著存儲容量的增加，存儲的性能會先增加然后達到一定瓶頸后逐漸降低。面對海量PB級數(shù)據(jù)，如果使用傳統(tǒng)獨立SAN存儲設備，要么擴展能力達不到，要么擴展能力可以達到海量PB級別，但是容量和性能不會線性增長，而且以后存儲擴容和運維成本也非常高。
隨著數(shù)據(jù)中心業(yè)務數(shù)據(jù)的不斷增加，大數(shù)據(jù)的海量數(shù)據(jù)挖掘與日志分析正逐漸成為一個主要應用場景。在面對極具彈性的存儲需求和性能要求下，傳統(tǒng)數(shù)據(jù)中心單機或者獨立的SAN存儲設備基本無法滿足大數(shù)據(jù)處理的需要，分布式存儲就顯得尤為重要。
以Hadoop為例，這是一款比較成熟而且應用比較多的大數(shù)據(jù)處理的分布式開源軟件。其最底部是HDFS分布式存儲，HDFS的設計本質(zhì)就是為了大量的數(shù)據(jù)能夠分布式存儲而存在的。HDFS可以將數(shù)據(jù)存放在很多不同的機器上，而用戶不必關心具體的數(shù)據(jù)在哪，HDFS會管理這些數(shù)據(jù)。HDFS是一個高度容錯的分布式存儲系統(tǒng)，可以分布式部署，以流式訪問模式訪問應用程序的數(shù)據(jù)，可以提高整個系統(tǒng)的數(shù)據(jù)吞吐量，非常合適用于具有超大數(shù)據(jù)集的應用中，而且隨著整個分布式存儲系統(tǒng)的擴展，容量和性能會成正比進行線性增長，非常適合大數(shù)據(jù)類的業(yè)務處理和應用。
2.3分布式安全網(wǎng)絡
傳統(tǒng)數(shù)據(jù)中心網(wǎng)絡安全是基于安全域、安全邊界的防護機制，是一套縱向安全策略，只關注業(yè)務流量的訪問控制，將流量安全控制作為唯一的規(guī)劃考慮因素。而虛擬化技術的大量使用使得網(wǎng)絡邊界模糊化，主要依賴橫向安全策略，能夠滿足安全流量動態(tài)遷移到其它物理服務器。傳統(tǒng)基于已經(jīng)難以滿足虛擬化環(huán)境下的應用模式，虛擬化的服務提供模式，使得對使用者身份、權(quán)限和行為的鑒別、控制與審計變得更加困難。這會導致許多基于傳統(tǒng)數(shù)據(jù)中心的安全防護手段失效。
在云計算數(shù)據(jù)中心，多臺虛擬機都在一個服務器設備內(nèi)運行，虛擬機之間通過虛擬化交換機進行連接，通信流量并沒有通過外部交換設備，導致傳統(tǒng)安全設備對這部分的流量失去監(jiān)控。目前大多數(shù)虛擬化軟件廠商沒有在虛擬機通信的東西向流量提供高效的檢測和隔離方式，如果某臺虛擬機出現(xiàn)安全問題，可能會對相關連的資源池產(chǎn)生嚴重的安全威脅。另外，虛擬機會隨時遷移到其他服務器設備上，造成安全域邊界的動態(tài)化，傳統(tǒng)數(shù)據(jù)中心固定邊界的防護手段也會失效。當虛擬機遷移到新服務器設備上，如果新服務器設備沒有對應的安全保護策略，就可能對遷移后的虛擬機造成安全威脅。
為解決云計算數(shù)據(jù)中心存在的安全問題，需要采用分布式的方式部署安全管理軟件或系統(tǒng)。通常分布式網(wǎng)絡安全產(chǎn)品由集中管理平臺+分布式安全管理軟件組成。集中管理平臺負責安全策略的集中管理，并對安全策略的遷移功能提供支持。同時接收虛擬化安全設備的日志以及統(tǒng)計信息，并分析整個數(shù)據(jù)中心的安全態(tài)勢。安全軟件是以分布式的形式部署虛擬機和虛擬化平臺上，可以克服傳統(tǒng)物理安全設備的局限，更貼近虛擬機的位置，利用引流或者重定向機制，獲取所有虛擬機的流量，實現(xiàn)分布式的安全防護。
2.4分布式云數(shù)據(jù)中心
傳統(tǒng)數(shù)據(jù)中心為了做到業(yè)務高可用，保證業(yè)務連續(xù)數(shù)據(jù)，防止數(shù)據(jù)丟失，通過采用“同城主備/雙活數(shù)據(jù)中心”或者“兩地三中心”的架構(gòu)。但是不管采用哪一種架構(gòu)方案，都會產(chǎn)生一定的IT資源浪費問題。“主備數(shù)據(jù)中心”，解決了業(yè)務連續(xù)性問題，但是平時只啟用一個數(shù)據(jù)中心資源，另外一個做備份。“雙活數(shù)據(jù)中心”，解決了業(yè)務高可用問題，但是兩個數(shù)據(jù)中心需要部署和運行同樣業(yè)務，同樣會浪費一個數(shù)據(jù)中心的資源。“兩地三中心”，同時最大程度的兼顧業(yè)務和數(shù)據(jù)安全，但是IT資源浪費最嚴重。
在分布式云數(shù)據(jù)中心概念里，多個數(shù)據(jù)中心不再是主/備或者雙活的關系，而是通過云計算技術、廣域網(wǎng)二層網(wǎng)絡互連技術和數(shù)據(jù)復制技術，將多個數(shù)據(jù)中心組建成一個分布式的跨中心和地域的“虛擬資源池”。所有業(yè)務和數(shù)據(jù)都可以按需被分配到不同的數(shù)據(jù)中心，實現(xiàn)比“雙活”或者“兩地三中心”更優(yōu)的業(yè)務部署方案。同時還可以實現(xiàn)數(shù)據(jù)中心資源利用率的最大化，降低運維和管理成本，更好的保證業(yè)務的連續(xù)性。
基于分布式架構(gòu)的云數(shù)據(jù)中心，主要考慮三個問題：業(yè)務訪問網(wǎng)絡，大二層網(wǎng)絡和數(shù)據(jù)同步復制。業(yè)務訪問網(wǎng)絡可以通過全局負載均衡GLSB和智能DNS實現(xiàn)不同區(qū)域的本地訪問，使用大二層互聯(lián)網(wǎng)絡技術可以解決虛擬機遷移問題。數(shù)據(jù)同步復制可使用微服務+容器+分布式存儲復制技術解決。通過微服務解耦業(yè)務，無狀態(tài)應用使用容器通過大二層網(wǎng)絡進行遷移，有狀態(tài)應用可以跟隨虛擬機進行遷移，冷數(shù)據(jù)盡量集中存儲，共享訪問，避免過多的數(shù)據(jù)遷移。
2.5兩種架構(gòu)的主要區(qū)別
通過上述對集中式和分布式架構(gòu)在資源處理能力、業(yè)務支撐能力、安全管理能力、可用性和一致性、運維和管理等多個方面的分析可以看出：集中式架構(gòu)在系統(tǒng)復雜度、數(shù)據(jù)一致性、安全措施實施方便性和運維管理復雜度等方面有一定優(yōu)勢。分布式架構(gòu)在資源使用成本和擴展能力、業(yè)務部署的靈活和系統(tǒng)可用性等方面具有明顯優(yōu)勢。而且集中式架構(gòu)的復雜性可以通過加強管理和設計降低復雜度，安全措施則可以通過增加安全系統(tǒng)和手段加強控制，數(shù)據(jù)一致性則需要通過先進的分布式系統(tǒng)與大規(guī)模運維平臺來支持，當然前提是需要犧牲一定的可用性，這也是分布式架構(gòu)面臨的一個挑戰(zhàn)，下文我們會進行詳細論述。
三、分布式架構(gòu)數(shù)據(jù)中心的挑戰(zhàn)
隨著數(shù)據(jù)中心信息系統(tǒng)數(shù)量的增加和處理數(shù)據(jù)量越來越大，分布式架構(gòu)的優(yōu)勢會越來越明顯，但是越是先進的架構(gòu)所面臨的挑戰(zhàn)也就越大。
3.1設計上的挑戰(zhàn)
由于分布式架構(gòu)采用多節(jié)點設計，這種架構(gòu)最大的難點是會導致數(shù)據(jù)一致性和可用性上的挑戰(zhàn)，所有的分布式架構(gòu)設計都繞不開這兩個挑戰(zhàn)。
根據(jù)CAP理論，分布式系統(tǒng)只能滿足其中兩項而不可能滿足全部三項。在分布式計算環(huán)境下，P是必須要現(xiàn)實的，否則分布式網(wǎng)絡節(jié)點通訊就會出現(xiàn)問題，所以只能在C和A之間做出選擇，即選擇CP模型或者AP模型，實際的選擇需要根據(jù)自身的業(yè)務場景來根據(jù)各個不同的模型特點進行取舍。對于一些離線的應用或者對可用性要求不高的業(yè)務，可以采用CP模型。這一類模型相對簡單，但是應用場景也有限。例如日志數(shù)據(jù)分析系統(tǒng)，大部分數(shù)據(jù)都在本地，我們只需要在分布式架構(gòu)中配置一定的冗余節(jié)點和恢復機制即可。如果某個節(jié)點出現(xiàn)故障，分析系統(tǒng)會自動等待其他備用節(jié)點恢復后再繼續(xù)運行，因為短時間停止不會對系統(tǒng)產(chǎn)生太多影響，但是各個節(jié)點分析的數(shù)據(jù)要求必須保持一致性。
在數(shù)據(jù)中心，核心系統(tǒng)和重要業(yè)務系統(tǒng)占比較大，如果采用分布式架構(gòu)，可能即需要高可用性也要求數(shù)據(jù)一致性，這是分布式架構(gòu)設計最大的一個挑戰(zhàn)。以銀行業(yè)為例，保證業(yè)務的連續(xù)性和高可用性是非常重要的一個需求，可以采用AP模型進行設計。但是數(shù)據(jù)一致性也是要盡量保證的，因為金融系統(tǒng)如果數(shù)據(jù)不一致，會產(chǎn)生嚴重的數(shù)據(jù)問題。關于數(shù)據(jù)一致性，在分布式架構(gòu)中可以按程度分為強一致性、弱一致性和最終一致性。為了保證金融系統(tǒng)的高可用和業(yè)務連續(xù)性，數(shù)據(jù)強一致性很難達到，弱一致性又無法滿足要求，做為取舍，可以實現(xiàn)數(shù)據(jù)的最終一致性。在分布式系統(tǒng)中，數(shù)據(jù)會被存儲在多個節(jié)點，各個節(jié)點的數(shù)據(jù)被應用修改后，最終一致性不要求各個節(jié)點同時更新數(shù)據(jù)，只要求盡快將各個節(jié)點更新后的數(shù)據(jù)分布到整個系統(tǒng)中，這樣在保證系統(tǒng)可用性的同時會實現(xiàn)數(shù)據(jù)的最終一致性，保證金融行業(yè)對數(shù)據(jù)要求。當然，并不是所有的金融業(yè)務都可以采用最終一致性的方案，例如核心實時交易系統(tǒng)，必要要求實時處理數(shù)據(jù)并保持強一致性，這也是目前大多數(shù)金融機構(gòu)核心交易系統(tǒng)還在使用集中式架構(gòu)的原因。
3.2建設過程中的挑戰(zhàn)
分布式云數(shù)據(jù)中心在建設過程中同樣也面臨一些挑戰(zhàn)，主要包括網(wǎng)絡、存儲和計算三個方面：
在網(wǎng)絡方面，多個分布式云數(shù)據(jù)中心之間的通信是個問題。需要考慮多個不同區(qū)域的網(wǎng)絡訪問接入、負載均衡問題。還要滿足分散在多個云數(shù)據(jù)中心之間的業(yè)務通信和切換的需要。目前主流的技術方案是以大二層網(wǎng)絡技術為主，打通多個數(shù)據(jù)之間的網(wǎng)絡，形成一個統(tǒng)一的邏輯網(wǎng)絡。但是目前各個網(wǎng)絡設備廠商之間的大二層網(wǎng)絡和協(xié)議不統(tǒng)一，設備兼容性有一定的問題，這也是分布式云數(shù)據(jù)中心改造所需要解決的一個問題。
在存儲方面，數(shù)據(jù)實時同步，實現(xiàn)統(tǒng)一的存儲資源共享并建立高可靠性的數(shù)據(jù)保護機制，是一個比較嚴峻的挑戰(zhàn)。多個數(shù)據(jù)中心可能分散在不同地域，各個數(shù)據(jù)中心之間的網(wǎng)絡帶寬有限，可能無法做到數(shù)據(jù)實時同步，只能采用異步傳輸。那么數(shù)據(jù)一致性和完整性可能就等不到保證。上文提到的應用解耦+微服務架構(gòu)可以解決一部分問題。但是對于傳統(tǒng)的無法進行微服務改造的應用仍然是個難題。在數(shù)據(jù)一致性和可用性上可能需要一些取舍。
在計算方面，目前技術相對成熟。將資源云化以后，利用云計算技術可以實現(xiàn)對計算資源在多個云數(shù)據(jù)中心的統(tǒng)一調(diào)度和管理。還可以設定權(quán)限，進行精細化管理。在計算方面的一些挑戰(zhàn)，通常指對計算資源的管理。例如在某一個應用出現(xiàn)故障時，是將這個資源在本地進行重建還是在其他云數(shù)據(jù)中心進行遷移和重啟，因為這會影響到各個節(jié)點的其他業(yè)務訪問，需要提前進行統(tǒng)一的規(guī)劃和安排。
四、結(jié)束語
相對于傳統(tǒng)數(shù)據(jù)中心，構(gòu)建分布式架構(gòu)的云數(shù)據(jù)中心是非常有必要的，它影響著數(shù)據(jù)中心建設的方方面面。在未來，沒有分布式架構(gòu)的數(shù)據(jù)中心一定不會是一個優(yōu)秀的數(shù)據(jù)中心。通過云計算技術的不斷發(fā)展與實踐，我相信分布式架構(gòu)一定會成為銀行數(shù)據(jù)中心的未來發(fā)展方向。即使銀行未來數(shù)據(jù)中心的架構(gòu)不是完全分布式的，但是分布式架構(gòu)也絕對不會缺席，一定會有分布式架構(gòu)的一席之地。
