現代數據架構的7項關鍵技術

Jim Scott 陳琳華

這些關鍵技術正在“重塑”企業IT基礎架構以實現對大量寶貴數據更加快捷和更加靈活的訪問。

重新構建企業IT基礎架構不是一件小事，其通常是由一系列不斷變化的關鍵業務驅動因素引發的。如今企業的處境正是如此。簡而言之，目前已經主導企業IT近30年的平臺再也無法處理推動業務發展所需的工作負載。

數字化轉型的核心是數據，而數據已成為了商業活動中最有價值的東西。長期以來，由于格式不兼容、傳統數據庫的局限性以及無法靈活地合并來自多個來源的數據導致企業未能充分利用數據。如今新出現的技術有望改變這種局面。

改進軟件部署模型是消除數據使用障礙的一個主要環節。更高的“數據敏捷性”需要更加靈活的數據庫和更具擴展性的實時流平臺。事實上，至少有七種基礎技術可以為企業提供靈活的實時“數據結構”。

與正在被取代的技術不同，這七項軟件創新具有可擴展性，可滿足眾多用戶和用例的需求。對于企業而言，這些技術可讓他們做出更快且更明智的決策，從而帶來更好的客戶體驗。

1. NoSQL數據庫

RDBMS已經在數據庫市場占據了近30年的主導地位。然而面對不斷增長的數據量和越來越快的數據處理速度，傳統的關系型數據庫已經顯得力不從心。得益于出色的處理速度和可擴展性，NoSQL數據庫正在逐步占據主導地位。對于文檔數據庫，它們從軟件工程角度提供了一個更為簡單的模式。這種簡單的開發模式不僅可加快產品上市速度，還可幫助企業更快地響應客戶和內部用戶的需求。

2.實時流平臺

實時對客戶做出響應對于客戶體驗來說至關重要。這也是為什么以消費者為導向的行業在過去十年中被全面顛覆的原因。它們與企業實時響應用戶的能力密切相關。告之客戶自己將在24小時內提供解決方案是一種非常糟糕的客戶體驗，因為客戶已經在執行他們在23小時前做出的決定了。然而轉向實時模式需要事件流。

雖然由消息驅動的應用程序已經出現了多年時間，但是今天的流平臺與它們的前輩相比規模更大且成本更低。流處理技術近期取得的進步為許多新的業務優化方法奠定了堅實的基礎。及時響應客戶只是一個方面。通過為軟件開發和測試團隊提供實時反饋環路，事件流還可以幫助企業提高產品質量，以及更加迅速地開發出新的軟件。

3. Docker和容器

容器對開發人員和運維人員以及企業本身都有很大的好處。傳統的基礎設施隔離方法是靜態分區，即為每個工作負載分配一個獨立且固定的資源（無論是物理服務器還是虛擬機）。靜態分區的好處是更容易排除故障，但是提供大量未被充分利用的硬件需要很高的成本。例如，Web服務器平均僅使用10%左右的總可用計算資源。

容器技術最大的優勢是它們能夠創建一種新型隔離方式。那些對容器不甚了解的人可能會認為他們可以通過Ansible、Puppet或Chef等工具獲得同樣的優勢，但是事實上這些技術相互間具有高度的互補性。此外，無論如何嘗試，這些自動化工具都無法為那些在不同的基礎設施和硬件設置之間自由移動工作負載創建所需的隔離性。同一容器可在本地數據中心的裸機硬件上運行，也可以在無需任何更改的情況下在公有云上的虛擬機中運行，而這是才是真正的工作負載移動性。

4.容器倉庫

容器倉庫對敏捷性至關重要。如果沒有用于創建容器鏡像的devops進程和用于存儲容器鏡像的倉庫，那么每臺運行容器的機器上都必須創建相應的容器。通過容器倉庫，容器鏡像可以從任意一臺配置為從該倉庫讀取的機器上啟動。在處理多個數據中心時，情況會變得十分復雜。如果在某個數據中心上創建了容器鏡像，那么如何將該鏡像移動到另一個數據中心上呢？理想情況下，企業可以通過聚合數據平臺在數據中心之間映射該容器倉庫。

其中的一個關鍵問題是，在本地部署和云端之間進行映射與在兩個本地數據中心之間映射存在著很大的差異。不過，無論企業使用的是物理基礎設施還是云基礎設施，聚合數據平臺提供的功能均可解決這一問題。

5.容器編排

與靜態硬件分區不同的是，每個容器似乎都有自己專用的操作系統。而與虛擬機不同的是，容器不需要對計算和內存進行靜態分區。這使得管理員可以在服務器上啟動大量容器，而不必擔心內存不足。在使用像Kubernetes這樣的容器編排工具時，管理員可以非常容易地啟動、關閉和移動容器，或是在環境中的某個地方重新啟動容器。

在引入了新的基礎設施組件，例如MapR-DB或MongoDB文檔數據庫、MapR-ES或Apache Kafka等事件流平臺、Kubernetes等編排工具以及用于在Docker容器中創建和部署軟件的devops流程之后，我們必須要將重點轉向另一個問題，即我們應當在這些容器中部署些什么東西。下面就讓我們了解一下微服務。

6.微服務

從歷史上看，微服務并不是一個新出現的概念。今天的微服務與以前的不同之處在于NoSQL數據庫、事件流、容器編排等技術可隨著數以千計的微服務的創建而不斷擴展。如果沒有這些新的數據存儲、事件流和基礎設施編排方式，那么大規模部署微服務是不可能的。管理海量數據、事件和容器實例所需的基礎設施將無法擴展到需要的級別。

所有的微服務都是為了提供敏捷性。微觀上，一項服務通常由單個功能或一組功能組成。微服務的功能越小越單一，那么創建、測試和部署起來就越容易。這些服務必須互不掛鉤，否則企業將無法享受到微服務承諾的靈活性。微服務可以依賴于其他服務，但通常是通過負載平衡的REST API或事件流。事件流可讓企業通過請求和響應主題輕松跟蹤事件的歷史記錄。這種方法對于故障排除具有很大的好處，因為整個請求流和請求中的所有數據都可以在隨意回放。

由于微服務僅有很小的工作單元，并且由于彼此分離，因此隨著時間的推移更換或升級服務幾乎不會遇到什么障礙。在老模式下，由于對RPC等嚴重依賴，因此在進行更換可升級時必須要關閉所有連接，然后再重新建立連接。此外，負載平衡也一個很大的問題，因為手動配置非常容易出錯。

7.函數即服務

我們已經看到微服務正逐步在整個行業中占據一席之地，同樣我們也看到了無服務器計算正在興起，或許將無服務器計算稱之為函數即服務（FaaS）更為準確些。FaaS可通過將代碼打包在輕量級架構中，內置在容器內，（基于某些觸發器）進行按需執行并自動進行負載平衡的方式創建微服務，這些要歸功于輕量級架構。FaaS的魅力在于它們可讓開發人員幾乎完全專注于函數。因此FaaS可以被視為由微服務催生而來的東西。

觸發事件是FaaS的關鍵組成部分。沒有它們，函數就無法被調用，只有當工作需要時資源才會被使用。自動調用函數是FaaS真正的價值所在。想象一下，每次讀取用戶的配置文件時都會生成一個審計事件，這是一個必須運行以通知安全團隊的函數。更具體地說，它們可能只會過濾掉某些類型的記錄。用戶還可以對它們進行選擇，因此它們畢竟是一個可完全定制的業務函數。值得關注的是，通過FaaS部署模式正確配置工作流會變得非常簡單。

進行整合

觸發服務背后的東西實際上只不過是事件流中的事件。雖然某些類型的事件會比其他事件被更頻繁地用作觸發器，但是對于任何事件來說只要用戶希望它們成為觸發器，那么它們都可以被作為觸發器使用。觸發器事件可以是文檔更新，或是在新文檔上運行OCR進程，也可以是向NoSQL數據庫添加OCR進程文本。我們可以設想一些更為有意思的方式，如每當上傳圖像時都可以通過機器學習框架對圖像進行識別和評分。這方面沒有什么限制。在定義了觸發器事件后，一旦事件發生，那么函數就會被觸發，隨后函數將開始工作。

FaaS將成為微服務使用的下一個階段。然而，用戶在部署FaaS時必須考慮一個重要因素，那就是供應商鎖定。FaaS隱藏了具體的存儲機制、特定的硬件基礎設施以及編排方式，而這些對開發人員來說都是非常重要的東西。這種抽象會導致托管的FaaS產品為整個行業制造出有史以來最大的供應商鎖定機會。由于API未標準化，因此用戶在不徹底放棄原來運行的東西之前想從公有云上的FaaS產品中遷移走幾乎是不可能的。如果用戶通過聚合數據平臺中的事件以一種更為系統的方式使用FaaS，那么在云提供商之間遷移將會變得更加容易。